软件工程之美5讲——敏捷开发到底是想解决什么问题？
软件工程之美5讲——敏捷开发到底是想解决什么问题？
什么是敏捷开发
也就是说，当你开发做决策的时候，遵守了敏捷开发的价值观和原则，不管你是不是用 Scrum 或者极限编程，那么都可以算是敏捷开发。
敏捷开发想解决什么问题？
瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。
敏捷开发和瀑布模型的差异
直到近些年，我完整的在日常项目中反复实践敏捷开发，才逐步领会到瀑布模型和敏捷开发的一些差别。这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践，Scrum 主要用来管理项目过程，极限编程重点在工程实践，而看板将工作流可视化。我将基于 Scrum 和极限编程的实践，来对比一下敏捷开发模型和瀑布模型的差异。
- 敏捷开发是怎么做需求分析的？
瀑布模型的一个重要阶段就是需求分析，要有严谨的需求分析，产生详尽的需求分析文档。而敏捷开发的需求，主要是来源于一个个小的用户故事，用户故事通常是写在卡片上的一句话，在 Sprint 的开发中，再去确认需求的细节。比如一个用户登录网站的需求，在用户故事里面就是一句话：作为用户，我想登录网站，这样可以方便浏览。好处是减少了大量需求文档的撰写，可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。
3. 敏捷开发是怎么做架构设计的？
瀑布模型在需求分析完了以后，就需要根据需求做架构设计。而在敏捷开发中，并不是基于完整的用户需求开发，每个 Sprint 只做一部分需求，所以是一种渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计。这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象，产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构。
5. 敏捷开发怎么保证项目质量？
瀑布模型在编码完成后，会有专门的阶段进行测试，以保证质量。在敏捷开发的 Sprint 中，并没有专门的测试阶段，这就依赖于开发功能的同时，要编写单元测试和集成测试代码，用自动化的方式辅助完成测试。相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的。微软的 Windows 就是个很好的例子，在 Windows 10 之前，Windows 的开发模式是传统的类瀑布模型，有很长一段测试的时间，质量有很好的保障，Windows 10 开始，采用的是敏捷开发的模式，每月发布更新，稳定性要稍微差一些。
4. 敏捷开发是怎么发布部署的？
瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境。测试验收通过后，发布部署到生产环境。在敏捷开发中，这种持续构建、持续发布的概念叫持续集成，因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。持续集成是一个非常好的实践，极大的缩短和简化了部署的流程，而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。
该不该选择敏捷开发？
可以肯定，敏捷开发是一种非常好的软件开发模式。但在应用上，也确实需要满足一些条件才能用好，例如：
团队要小，人数超过一定规模就要分拆；
团队成员之间要紧密协作，客户也要自始至终深度配合；
领导们的支持。
敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。所以在选择敏捷开发这个问题上，你先要参考上面这些条件。因为敏捷开发对项目成员综合素质要求更高，做计划要相对难一些。如果团队大、客户不配合、领导不支持，再好的敏捷方法也很难有效实践起来。
