参与过许多项目的研发，有的中间加入，有的从0到1搭建。在这个过程中经常遇到的问题就是：
按照什么方式来管理研发流程，是瀑布还是敏捷，是按照功能方式还是按照固定周期。
为此很多人是拿来主义，看到大厂在使用敏捷那咱们也使用敏捷，然后鸡飞狗跳的搞一些形式主义。
今天咱们就总结下。
项目从0到1
如果项目是从0开始搭建，这个时候更加适合瀑布模式开发。
为什么呢？
此时项目人员对于整个项目还没有整体的认知，没有搞清楚整个业务流程和业务场景，甚至项目面对的客户群体。所以这个时候需要产品经理做前期的调研，形成项目初期的整体项目需求文档。
有了项目文档，也就有了项目整体的业务流程和业务场景，此时再交给研发人员就可以正常进入研发阶段了。
此时就不适合搞什么敏捷方式，因为根基没有，也就谈不上交付可执行软件价值。
项目从1到2
项目有了一期的基础，也就是说有了项目最基本的功能框架，能够满足客户的基本需求。
这个时候也就引出了客户新功能需求，以及对一期功能的优化和升级。
这时候有大量的功能需要开发，这个时候更加适合增量方式。
为什么呢？
首先已不适合瀑布模式了，这个时候项目参与人员已有了项目的整体理念，并且熟悉了项目的业务流程，已无需等待整个需求出来再动手开发了。这时候给出简版的需求或者描述就可以动手开发。
其次也不建议使用迭代方式，迭代方式更多从时间维度来制定研发过程。例如两周一个迭代，就是在两周内完成一次软件版本的发布，在这个时间内根据团队的产出能力来约定上线功能的多少，但此时更多强调功能尽快上线，但功能的大小是不一的，有的可能几天就可以完成，有的则不然。
所以此时更建议使用增量方式，以尽快完成完整功能为标准。
项目2到N
项目已经发布了几个稳定版本，并且已进入一个稳定运营期。
这个时候建议使用固定的迭代周期方式来发布。
一方面对于用户来说更加的稳定，优化，不会因为频繁的发布引起宕机问题。另一方面对于研发团队来说也是一种有节奏的发布，能够更好的协调团队资源来完成一个迭代内功能，并进行优先级的排列。
这个时期求一个字：稳
总结下：
软件项目是一个质量、时间、范围三个维度的博弈过程，在这个过程中只能保证两个，就像CAP理论，不可全得。
这是一个过程，不可以固定思维看待，要以动态的思维看待，从0到1，从1到2，从2到N，是一个变化的过程。
至于使用什么模式开发，要以适合项目和团队为标准，不可形式主义。
原文始发于微信公众号（夏壹分享）：增量与迭代
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/155076.html
