敏捷开发 | 为什么需要敏捷开发。

Posted 2021-04-25 小马技术圈

敏捷开发

    敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

    换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

    敏捷最大的特色是迭代式开发。

P1

为什么要敏捷开发

    敏捷是一种软件开发方法，或者项目管理方法。

    在很多年前的通信或是银行领域，他们的软件主要是内部使用。而那时候软件开发采用的是瀑布模型，把软件开发过程划分为需求、分析、设计、开发、测试等不同阶段。瀑布开发方式同样也能完成所有的任务，甚至这种方式延续至今。瀑布模型从出现到持续到现在已经有很长时间，包括目前大学的软件工程专业的课程内容也主要采用这种方式。

    另外一种开发方式是一些初创团队或者小公司使用的是“伪敏捷”开发方式，实际上，这种状况是既不 “敏捷” 又不“瀑布”，是一种混乱或者无序的开发模式，其软件开发过程是无序的。

    随着互联网的发展和对软件的需求越来越不稳定，而瀑布模型的过程太长，于是敏捷开发方式出现了。 

    这就是为什么要使用敏捷开发的原因。敏捷开发方式通过迭代将瀑布模型分隔成更小的周期，从而实现迭代。

敏捷开发

P2

快速迭代

01

研发理念

快速迭代是一种产品研发理念，产品研发从”上线-反馈-修改-上线”这样一个反复更新的过程，比较适用于互联网产品。我们公司的产品有需要本地部署的套装系统，也有SaaS化产品，所以相对来说，也是比较适合敏捷开发，快速迭代。

02

试错成本低

快速迭代适用于快速变化的环境，以及用户自己无法真实描述出自己的需求，以及可迭代产品的试错成本低，可以进行快速版本更新。在自己能承受的范围之内做一些小步的尝试，如果错了，错在哪里？为什么会错？等等这些，然后逐步改进，在未来项目开展中少走弯路。这就是相当于，以较小的试错成本换取整个项目的成功。

03

及时反馈

快速迭代，即使产品是半成品，也是可以发布上线的。尽早让用户接触使用到你的产品，去评判你的想法，你的设计是否满足用户需求，是否能赢得用户喜爱，快速推出，关注用户反馈。经过多次的反馈修改后呈现出的产品，一定是非常好的产品，深受用户喜爱的产品。

04

如何快速迭代

快速迭代建议采用短周期迭代法，将项目开发周期分解到月、分解到周，一般建议迭代周期在1~4周。小步快跑、快速迭代，分级满足客户需求，并且通过不断的沟通，减少大家理解上的偏差，降低项目风险，降低试错成本。并且在每个迭代快结束的时候进行评审验证，保证产品的正确性。

P3

敏捷开发能提高项目效率吗

    敏捷开发实际上是在看不见的地方提高了效率。最大的地方就是避免返工。

    小王在某个研发中心工作，公司决定尝试把前端页面外包给一个团队，公司负责出图，外包公司写出html+CSS。

    虽然这个团队隔一周就会反馈进度，并且当时一切都进行得很正常。但是最终交付的时候拿到的代码全是用Table布局的，对于小王公司来说根本没用，迫不得已只能返工。

    对于大型的软件项目来说一个大的瀑布模型，即使做了充分的设计、讨论，最终返工的概率也非常大。但现在互联网化的产品不再适应瀑布模型了。

    那敏捷软件开发的核心逻辑是快速迭代，同时也具备了快速试错。那么敏捷能避免返工吗？

    当然还是不能，但敏捷开发返工的影响能降低到最低，就已经是很大的成功了。

P5

敏捷开发的缺点及不足

    敏捷开发方法一点问题和缺点都没有吗？敏捷开发实际在开发过程中也会暴露一些问题，但是可以想办法优化流程，尽量降低这些问题的影响。

    敏捷软件开发的特征是增量的，因此每个迭代都会有新的业务分析，新的开发工作在进行。这带来的一个问题是，不会有一个统一的 PRD 文档出现，最后在项目结束时候，交付物中没有好的文档。所以敏捷往往强调可交付的软件更为重要，在代码质量上下功夫，做到代码即文档。

    敏捷中参与人员都是根据团队划分的，例如独立的 PM、BA、DEV，不再存在管理部分、研发部门。如果企业的组织架构没有改变，敏捷团队的存在可能会出现组织架构上的矛盾。

如何解决

敏捷实践中会议多的问题

▽

    敏捷开发中常见的会议有：每日站会、迭代计划、项目回顾会议、产品展示会议等。

    但如果设定一个迭代的时间是两周，那么迭代计划开了一整天就没有时间进行开发和干活了。

    因此各个会议的推荐时间和主要目的是：

    ●站会应该在15分钟内完成；

    目的是更新进度和暴露开发中遇到的问题，不应该讨论具体的问题。

    ●迭代计划会议不超过2小时；

    会议之前应该准备好所有的需求分析，如果遇到需求不合理应该及时跳过，不应该在会议中寻求解决方案。

    ●回顾会议不应该超过1小时；

    把重点放到上一次行动是否明确执行以及需要改进点上。可以通过投票讨论优先级高的改进点。

    ●产品展示会议不应该超过30分钟。

    ●参会人员应该准时到达。对迟到的容忍就是对准时到的人惩罚。

    ●每个会议必须有主持人、会议目标、会议准备，否则会议是冗长而无效的。

    当今的社会发展太过迅速，竞争非常激烈。如果再继续以前的模式，充分搜集依据，等到一个关键的节点再去进行迭代，整个反馈机制与流程未免太过冗长，无法做到即时跟进。从项目实践经历来看，只有小步试错，快速迭代，及时反馈才能适应当今互联网时代的发展。

分享/交流

我Hi好 笔记本科技 科技笔记本