【PM】关于敏捷，瀑布流，文档

引子

昨日和朋友讨论了一些关于开发模式的问题。以前曾纠结于对敏捷开发来说，文档是应该几乎不存在的东西，由于敏捷的核心彷佛是拥抱变化，encourages to be rapid and flexiable. 而在这其中，文档属于最“重”的东西，应该是被快速的站会所取代的。而瀑布流偏偏相反，完整的文档记录，严格的设计，开发，测试流程是对于我来说的第一印象。但我在公司中看到的实际是，你们在PRD中写的是敏捷下的Story List，总体的开发流程却更像是瀑布流：有着严格的设计、审核、开发流程。

所以，我在思考一个问题，公司里究竟是敏捷仍是瀑布流？为何会有两种形式并存的情况？

敏捷 (Agile)

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
--- wikipedia

从定义来看，重点在于需求或解决方案不肯定的状态下，经过敏捷的开发方法来完成项目。因此说，这其中的文档也好，站会也好，都只是实现这一目的方法，而非必要的条件。对于中大型公司来说，因为项目规模一般会愈来愈大，须要有很强的拓展性，因此良好的文档对于之后的发展来讲是必要的。同时，清晰的文档也有利于之后对于开发流程上的反思和迭代，经过强化流程来缩小人员带来的不肯定性和风险，进而减少错误发生的几率。这应该是公司理想的状态，即任何人均可以替换。

瀑布流(waterfall)

The waterfall model is a relatively linear sequential design approach for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.
-- wikipedia

重点在于单向性，即更少的迭代和灵活性。与敏捷相反，瀑布流所适应的场景多为需求或解决方案较为肯定的状况下，个人想象中更像B端产品的开发模式（常见的如各种软件开发商或外包）。
根据个人经验来说，还有一种状况可能也会用到瀑布流，就是research方面较重的时候，很难迭代起来，至少在初期的时候是这样。例如，开发涉及到ML方面的模型时，咱们须要把各个模型一点一点的开发训练出来，这一块是顺序性的，并且初期的建设很费时间，就只能先作好一个计划，一步一步地来进行开发了。固然，到了后期模型彻底创建好，最小价值产品（MVP）已经产出的时候，其实就能够开始进行快速的迭代了。对于模型方面来说，常见的迭代即为调整参数，融合新的模型这种能相对较快地出结果的东西。

总结

• 开发模式无所谓好坏，总有一些人会以为瀑布流过于老旧，敏捷才是王道。其实非也，咱们更应该从需求和质量控制能力出发，看看咱们的需求是不是明确的，质量控制是否有很高的要求，再来作决定。
• 敏捷=996？，我我的认为敏捷是一种模式，而非是工做方式，因此朝九晚五也能够敏捷，996并不必定能带来更高的团队进度效率，这是PM和管理人员我的能力的问题，也取决于业务的竞争压力
• 敏捷!=无文档，尤为对于大公司和互联网这种迭代注定不少的公司来说，文档有助于从此的发展，同时也可以有效抵消人员流动性比较大的问题，因此敏捷下仍应该有文档
• 敏捷能够与瀑布流并存，上课的时候咱们的tutor是一位有几十年开发管理经验的IT顾问，他跟咱们的建议是，模型和后端部分能够作瀑布流，前端能够作敏捷来不断地知足客户的需求。我认为这是一个很不错的点子，团队能够根据不一样部分的需求变化频率来部署不一样类型的模式，而不是要让敏捷与瀑布流“你死我活”。