关于敏捷，瀑布流，文档

昨日和朋友讨论了一些关于开发模式的问题。之前曾纠结于对敏捷开发来讲，文档是应该几乎不存在的东西，因为敏捷的核心似乎是拥抱变化，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）已经产出的时候，其实就可以开始进行快速的迭代了。对于模型方面来讲，常见的迭代即为调整参数，融合新的模型这种能相对较快地出结果的东西。