敏捷不是银弹

当前业界常陷入非黑即白的误区：要么过度神话敏捷的灵活性，要么固守传统瀑布的结构化。认为瀑布模型太古老、已经过时，将被敏捷开发模型完全取代。实际上，这种观点并不准确。每种模型都有其适用场景，瀑布模型在某些特定项目中仍然具有不可替代的优势。

数据揭示真相：Gartner研究显示，因强行套用纯敏捷而失败的项目占比达32%，核心痛点源于三点：

复杂需求失控：敏捷在需求高频变化时显现优势，但忽视架构设计会引发技术债爆炸；
团队能力断层：超68%转型团队因缺乏持续重构能力，陷入迭代效率递减困境；
质量风险盲区：Standish Group指出，纯敏捷项目代码缺陷率比混合模型高19%；

这说明：敏捷不是银弹，敏捷的核心价值是“优先级动态调节能力”，但是在软件质量控制、项目成本管理等方面仍依赖传统模型的支撑。

敏捷的主要价值

请看下图，这是一个敏捷价值的排序表，展示了敏捷模型的则重点。

请看图中最底下的一行“能够管理不断变化的优先级” 是敏捷模型最大的价值，其次是“项目可见性”、交付速度。

再请看图中第一行“降低项目成本”，是敏捷模型最不关心的也最不擅长的，其次是“软件可维护性”、“软件质量”。

图 x.x 敏捷的主要价值

传统模型适合的场景

传统项目（如航空航天软件、银行核心系统）
- 适合模型：传统模型（指：瀑布模型、V模型、迭代模型、增量模型）
- 原因：这类项目通常要求文档完备性和代码质量非常高。传统模型通过严格的阶段划分和详细的文档记录，确保每个环节都符合高标准。
需求明确的项目（如政府系统）
- 推荐模型：传统模型（指：瀑布模型、V模型、迭代模型、增量模型）
- 原因：当需求非常明确且不会轻易改变时，传统模型可以通过严格的阶段划分和文档记录，确保项目按计划顺利推进。
军工级软件
- 推荐模型：传统模型（指：瀑布模型、V模型、迭代模型、增量模型）
- 原因：军工级软件对质量和安全性有极高的要求，传统模型通过严格的阶段评审和文档记录，确保每个环节都符合标准。

敏捷模型模型适合的场景

变化快的项目（如互联网应用、电商APP、SaaS平台）
- 适合模型：敏捷模型
- 原因：这些项目的需求经常变化，业务方向也可能随时调整。敏捷模型强调快速迭代和持续交付，能够及时响应用户反馈并迅速改进产品。
内部工具类软件
- 推荐模型：简化流程的敏捷开发
- 原因：内部工具类软件对流程的要求相对宽松，可以采用更灵活的敏捷开发方法，提高开发效率。
10人以下的小型团队
- 推荐模型：敏捷模型
- 原因：小型团队灵活性高，沟通成本低，采用Scrum可以快速适应变化，高效完成任务。

软件外包公司与敏捷思维

如果你是软件外包公司的老板，并且接到了甲方公司的软件项目，并且是以赚钱为目标（尤其是以人天工时为报价基础的情况），那么你会发现敏捷模型并不适合你。由于国内软件外包公司的生存环境较为严苛，敏捷模型的一些核心理念与包外的实际环境存在冲突，因为它并不特别关注“降低项目成本”。

**1. 可工作的软件优先于详尽的文档，**敏捷思维强调“可工作的软件优先于详尽的文档”，即更注重实际可用的软件而非过度关注文档的完整性。然而，在软件外包项目中完整的文档对于项目验收至关重要。没有详尽的文档项目很难通过最终验收。

**2. 客户合作优先于合同谈判，**敏捷思维提倡“客户合作优先于合同谈判”，鼓励与客户的紧密合作而不是仅仅依赖合同条款。但在外包业务中，为了确保项目的顺利进行和成本可控，必须通过严格的合同条款来约束双方的行为，从而避免风险。

**3. 响应变化优先于遵循计划，**敏捷方法主张“响应变化优先于遵循计划”，灵活应对需求的变化。但对于外包公司而言，甲方的需求频繁变化会导致开发周期延长，增加人员工资等成本，甚至可能造成亏损。

**4. 欢迎需求变更，**敏捷思维中的“欢迎需求变更”原则，即使在开发后期也能灵活应对需求变化，为客户创造竞争优势。然而，在外包项目中，开发后期的需求变更可能导致项目延期，进而违反合同规定，带来赔偿责任。

探索试错型业务与敏捷思维

相比之下，公司内部在新兴业务方向上的探索则非常适合采用敏捷思维。例如，本公司决定每年在技术研发和IT建设上投入1000万元，用于新兴业务的探索与试错。其中600万元用于组建一个20人的技术研发团队，包括产品经理、UI设计、前端工程师、后端工程师、测试工程师和技术经理等岗位。基于北京的中间工资水平，假设每人每月成本约为2.5万元，每人每年的成本是30万元，20个人一年大约是600万元。

在此背景下人员与成本已经固定，团队不再关注成本，也就不再抵触需求变更。团队可以专注于新兴业务方向的探索与试错。他们只需明确眼前一两个月的工作内容，快速交付产品并收集用户反馈，在下一个迭代中持续改进。这种方式符合敏捷思维所倡导的快速迭代和持续交付原则，能够及时响应市场变化，提升产品的竞争力。

敏捷如何拯救一个项目

传统瀑布模型下的“不可能任务”：想象一下你在一个科技公司工作，团队一直习惯使用传统的线性开发方法（瀑布模型）。某天老板给你一个新项目：要在3个月内完成一个包含大约50个功能模块的应用程序。团队成员们面面相觑，心中默默念叨：“这怎么可能？” 确实，按照瀑布模型的方式来看，从需求分析、设计、编码到测试，每个步骤都必须严格按顺序进行。即使团队加班加点，也无法压缩这些必要的流程。于是，大家陷入了悲观的情绪中，觉得这个目标根本无法实现。

敏捷模型带来的转机：就在这时，一位同事提出了一个大胆的想法：“听说敏捷开发模型可以加快速度，不如我们试试看？” 于是，团队开始学习和实践敏捷方法。大家很快意识到，关键不在于改变时间表，而是在于重新审视那50个功能模块的价值。通过与利益相关者的沟通，团队发现并非所有功能都是必不可少的。一些低价值或伪需求被果断砍掉，最终剩下约30个核心功能。接下来，团队制定了两周一次的小规模迭代计划，每次迭代专注于5个功能点。这种灵活的工作方式不仅提高了效率，还让团队能够迅速响应变化——在实际开发过程中，需求确实发生了几次调整，但敏捷模型使他们轻松应对。三个月后，团队完成了6次迭代，成功交付了一个功能完备且经过多次测试的产品。最重要的是，这个产品已经经历了多轮优化，并在市场上获得了初步反馈。总结下来，正是敏捷思维帮助团队找到了一条可行的道路，在有限的时间内交付出了软件产品。

瀑布模型与敏捷模型各自的优点

瀑布模型的优势：

瀑布模型就像是精心规划的旅程，适合那些路线明确、目的地清晰的旅行。它要求我们在出发前就把一切都安排妥当，这样在旅途中就可以按部就班地前进。因此，对于那些需求明确、稳定、简单、易于理解的小型产品或项目来说，瀑布模型是非常有效的。例如，如果你要开发一个银行的核心系统或者军工级软件，前期的需求分析和设计至关重要，瀑布模型能确保每个步骤都得到充分验证，从而提高软件的质量和可维护性。

敏捷模型的魅力：

敏捷模型则像是探险之旅，更适合那些未知领域多、变化频繁的项目。它允许我们在行进过程中不断调整方向，随时根据实际情况作出最优选择。对于那些需求一开始不明确、新型、复杂的大型产品或项目，敏捷模型能帮助我们更快地推出最小可行产品（MVP），并通过不断的迭代和用户反馈来完善产品。比如，像微信这样的互联网应用，其市场需求和技术环境都在快速变化，敏捷开发模式能够让团队更灵活地应对挑战，抓住机遇。

探讨新模型

瀑布模型在某些需求明确、代码质量要求高且成本控制严格的项目中仍然有用。敏捷模型的特点是“不知道怎么干先干着”，快速交付并收集用户反馈和问题，在下一个迭代中改进。这并不意味着我们现在不知道未来也不知道，而是随着项目的推进逐渐明确需求。

单纯的瀑布模型和纯粹的敏捷模型都不是万能的解决方案。在实际项目管理中，大多数团队会灵活结合多种生命周期要素，以更好地实现项目目标。混合型软件开发生命周期模型将线性型、迭代型和敏捷型方法结合起来使用，以适应不同阶段的需求。这种方式既保留了传统方法的严谨性，又引入了敏捷方法的灵活性，特别适合那些需求复杂多变的项目。本书后续内容也将探讨制定适合自己团队的软件开发生命周期模型，暂且叫“混合模型”吧，帮助读者掌握如何根据实际情况灵活选择或组合使用不同的生命周期模型，从而有效推进软件项目的实施与管理。

传统 VS 敏捷