引子
昨日和朋友讨论了一些关于开发模式的问题。之前曾纠结于对敏捷开发来讲，文档是应该几乎不存在的东西，因为敏捷的核心似乎是拥抱变化，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顾问，他跟我们的建议是，模型和后端部分可以做瀑布流，前端可以做敏捷来不断地满足客户的需求。我认为这是一个很不错的点子，团队可以根据不同部分的需求变化频率来部署不同类型的模式，而不是要让敏捷与瀑布流“你死我活”。
