1.2 传统开发流程的局限性

在过去二十年或更长的时间中，传统的、非敏捷的瀑布式软件开发模式通常依赖于一个严格的模式化开发流程。通常认为瀑布模型是Winston W. Royce在1970年提出的软件开发模型（虽然他并没有使用瀑布waterfall这个单词）。这种方法源自传统工业生产，严格遵循预先计划的需求、分析、设计、编码、测试和部署的步骤顺序进行，每个步骤都有严格分工，由不同的技术人员分别执行。执行步骤的成果作为衡量进度的途径，例如需求规格、设计文档、测试计划和代码审阅等。但随着各种新兴技术的蓬勃发展，特别是在产品快速迭代的需求背景下，这种传统开发流程的局限性日益明显：

1．自由度低，缺乏灵活性

传统模式在项目早期即作出承诺，基于稳定的目标进行阶段性的开发，这种方式自由度低，应对突发情况时缺乏灵活性。众所周知，需求会随着时间而变化，经常出现开发人员努力在设计前完成文档，在编写代码前完成设计，最后却因为需求有变化而不得不完全推倒重来的情况，不仅大量工作被浪费，甚至导致对后期需求的变化难以应变，代价高昂。

2．缺陷发现晚，无法及时反馈

传统流程一般在开发阶段接近尾声时才开始测试。虽然在这个阶段进行测试相对容易，但是一些在早期的单元测试中可以轻易发现的缺陷可能要到最后阶段才会发现，增加了被遗漏的风险。

由于缺陷发现得很晚，如果要解决问题，则有可能导致错过发布的最后期限，再加上手工测试效率低下，任何一次代码变更或缺陷修复对产品的影响都无法迅速反馈给开发人员。随着发现的缺陷越来越多，开发人员只会对变更没有信心，失去持续完善的动力。

3．协同合作缺失，容易引起团队冲突

传统流程中每个步骤都有严格分工，不同阶段的技术人员与上下游的工种往往沟通较少，甚至对产品本身的理解也存在差异。例如，开发人员和测试人员在思维和工作方式上的不同，使得他们对软件需求和测试场景的表述发生歧义，从而引起双方的沟通问题。而这些理解上的差异如果直到测试阶段才被发现的话，则实在太晚，此时双方的冲突与指责对解决问题没有任何帮助。

4．产品质量无法保证

传统流程中常见的一个场景是在项目后期将要交付的阶段，技术人员仓促地从开发环境构建转为脚本配置，而长期在开发环境内依靠手工管理，构建脚本的时候就可能会遇到各种各样的问题，例如接口没有定义、配置文件丢失、组件不工作等。为了解决这些问题，技术人员不得不把主要精力放在软件构建上，结果时间成本越来越高，产品质量无法保证，甚至出现产品无法按时交付的情况。