敏捷开发方法与团队协作指南（执行版）.docxVIP

敏捷开发方法与团队协作指南（执行版）

第1章敏捷思维重塑与角色定位

1.1从瀑布到敏捷：思维模式的根本转变

瀑布模型将项目视为一个线性、不可逆转的“建造过程”，强调在需求确定后才开始开发，一旦需求变更，整个项目需重新规划，这导致需求频繁变更是常态。而敏捷思维视项目为一个“构建过程”，核心在于快速交付可工作的软件并持续改进，它承认需求在开发过程中是动态演化的，因此必须采用“迭代开发”和“持续集成”的方式，将大项目拆解为可快速验证的最小可用产品（MVP）。瀑布模型假设需求在开始时就是完全明确的，但现实世界中，需求往往在开发早期甚至中期才逐渐清晰。敏捷思维要求团队在早期就通过原型演示（Prototyping）和快速反馈循环来验证假设，一旦验证失败，立即转向下一个方向，而不是继续投入大量资源开发错误的需求。

传统思维强调“一次性完成”和“最终交付”，认为质量在最后阶段通过测试来保证；而敏捷思维强调“持续交付”和“持续改进”，认为质量是在开发过程中通过每日站会、代码审查和测试反馈实时保证的，任何交付产品都必须是可工作的，且具备可进化的能力。在瀑布模式中，文档（如需求规格说明书、系统设计文档）是核心资产，一旦文档确定，后续开发即按文档执行；但在敏捷中，文档是辅助工具而非真理，需求文档、设计文档甚至测试文档都可以被推翻和重写，因为真实的需求往往隐藏在用户反馈中，而非纸面上。传统