1、敏捷项目管理 陈宗斌 译 敏捷开发方法流行于那些发现传统瀑布法无法适应这个由改变、革新而驱动的世界的要求的企业。既然敏捷开发过程带来更好的结果，那么也能将这个方法应用于整个 IT 投资组合中。在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。 本书适合项目经理、投资组合经理、业务分析师、 PMO 成员以及执行经理等对采纳敏捷实践和投资组合管理感兴趣的人士阅读。 敏捷项目管理 前言 摘要：敏捷项目管理在一个企业中，朝向 敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，
2、也将探究其潜在的风险问题。本节为前言部分。 标签： 敏捷开发 敏捷项目管理 前言 如果你学过经济，就肯定了解制定战术计划和制定战略计划之间的区别。在 20 世纪 80年代，行动的战术窗口只是 3 5 年的计划，而战略计划则超过 5 年，最多可达 10 年。在 20世纪 90 年代，也就是信息时代起飞之后，变革的速率及其附加作用极大地减少了计划窗口的大小，而软件开发周期也减少了。到现在，我不认为还有以 20 世纪 80 年代的周期作计划的机构存在，尤其是在信息技术这一部分。实际上，我听到经理们讲这么一个笑话： “ 战术是今天所要做的，战略是为明天做 计划。 ” 如同许多笑话一样，笑话之中有真理。
3、 变革的速率影响着我们将来开发系统的方式，尤其是那些较大的系统。项目的时间表越长，项目范围成为战略的一部分的几率就越高。我们从过去许多经验中得知，一个花费了两年时间进行的项目的结果不一定会和我们对它的期待一致。传统项目的计划精确度非常粗糙，这是造成这种问题的原因之一。 为了解决这个问题，许多机构采用或试用敏捷开发方法 这是一种基于迭代 -增量开发的方法，它将项目的范围分解为更小的、可管理的块。从管理的角度看，这是一种理想方法，因为即使是最长的战略性项目也会有一个战术上 的组件：即将进行的迭代。而正是这个组件将使得执行官、项目经理以及项目团队得以掌好项目的舵，带领项目驶向并不精确的愿景。想转变为
4、敏捷方法并不是一件容易的事情。改变带来机会，也总需承担风险，敏捷开发的机会和风险均有不少。本书将探究敏捷方法为开发机构及其领导力带来的机会，也将探究潜在的风险问题。 我编写本书的动机之一是想把我的职业生涯内在项目团队内外所观察到的信息与大家分享。这些观察的结果有许多都能追溯到同一个根本原因：在机构内，我所目睹到的各个方面都缺乏信任。 在长期以传统方式管理的项目过程中，许多项目状态报告 （尤其是在项目早期阶段）过于乐观。首先，要让业务分析师或软件工程师知道他们的进度落后于时间表是一件极为困难的事情。在分析之前或在分析过程中，想知道总共有多少分析量是不可能的。如果不知道总量，我们如何知道现在的工作
5、正按部就班呢？而后在项目进行时，如果项目由于有新的发现而延期，但执行分析的人早已离开，他们已经转移到新的项目上了。 其次，长久以来，我们一直受到这样的教导：项目经理是负责人。他管理团队，指派任务并且承担整体项目成功的责任。所有这些压力以及所有这些期望都指向同一个人，这个人也负责项目的沟通交流工作。有 了这样的场景，我们怎么可能期望项目沟通交流是中立的？高级执行官如果要求每周多给出一份详细的状态报告，那么这不就已经是一种不信任的底层形式了吗？在我的职业生涯里，我不断看到这些机能失调和不信任的症状。 敏捷投资组合管理并不排除书面交流方式，但它确保沟通进行在执行中的项目所产生的现有敏捷指标的基础。敏
6、捷投资组合管理在项目团队和执行官之间建立了一个清晰定义的接口，而其建立在敏捷实践的基础上。这些实践建立在信任之上，并且会对任何朝向组织上的敏捷所作的转变带来正面的影响。 我将本书称为敏捷项目管理，因为这正是机构 中活动项目的投资组合，这些项目代表了企业的未来，无论是战术上的还是战略上的，也无论读者对这些术语的定义是什么。 “ 敏捷 ” 这个术语所强调的不仅是投资组合中的项目是敏捷项目，也强调投资组合是构建在敏捷实践之上，而且是动态管理的。本书展示了现代敏捷企业的透明性，它清晰地定义了交流通道，所以，本书既面向项目经理也面向执行官。 本书分为以下三个部分： 第一部分：敏捷与管理人员。这个介绍性的
7、部分是为想要了解敏捷软件开发在过去的几年中变得如此流行的原因的管理人员准备的。它讲解了在敏捷软件开发和敏捷项目管理中常用的最重要的敏 捷实践。 第二部分：定义、计划并衡量投资组合。第二部分是本书最大的一部分。它讲解了与敏捷投资组合管理有关的实践。本部分所包括的实践有编写指标，建立项目选择过程，评估资源以及计算投资回报。这些章介绍现代投资组合管理的实践。 第三部分：机构和环境。本书的最后一部分为如何把最流行的敏捷开发过程和敏捷投资组合管理编排在一起提供一些实际操作建议。它介绍了以 Scrum 方式管理项目适应投资组合管理过程的方式。另外，本部分也讲解了在敏捷机构中项目管理办公室（ PMO）的新角
8、色。 本书读者对象 本书主要面向项目经理、投资组合经 理、业务分析师、 PMO 成员以及执行经理等对采纳敏捷实践和投资组合管理感兴趣的人。我希望本书能够为读者确切地给出容易消化本主题的介绍内容，而且有足够的材料在整个企业中开展敏捷方法。 虽然技术读者不是本书的主要对象，但本书可以帮助他们理解、体会机构内不同层次的人员的动机，而且更好地理解项目的外部因素如何影响他们在企业中的工作。 除了能够为读者中的专业人士带来效益外，我希望本书也能够帮助正在攻读工商管理学位的学生理解在业内敏捷开发的重要性和影响。你们是明天的项目经理。 在线寻找更多内容 如果本书有新的补充材料或者 更新材料出现，我们将在线贴在
9、 Microsoft Press Online Developer Tools Web 站点上。读者可找到的材料包括本书内容、文章、勘误表、样章等的更新。这个站点很快就可以通过http:/ 来访问，而且会定期更新。 对本书的支持 我们尽力确保本 书以及本书的配套内容准确无误。如有修正或者变更，它们将出现在Microsoft Knowledge Base 文章中。 Microsoft Press 在以下 Web 站点提供对本书以及本书配套内容的支持： http:/ 问题和评论 与本书或者配套内容有关的任何评论、问题或想法，或者无法通过访问上述站点解 决的问题，请通过电子邮件将它们发送到： 或者
10、通过邮寄信件到： Microsoft Press Attn: Agile Portfolio Management Editor One Microsoft Way Redmond, WA 98052-6399 请注意， Microsoft 不通过上述地址提供软件产品支持。 致谢 我想感谢以下各位人士，他们在本项目的不同阶段为我提供的反 馈和深度评述实乃无价之宝。他们是： Denise Cook、 Marie Kalliney 和 Roman Pichler。 Roger LeBlanc 担任本书编辑，在我认为已经完成的情况下仍旧不停工作，为本书进行了多次重审，直到成书。 Steve Sagm
11、an 和 Lynn Finnel 编辑并协调了本项目，他们源源不断的好主意给本书带来了许多改进。如果没有他们的评论和热情，本书就不可能成形。感谢他们！ 要完成一个这样的项目，仅仅知道其方式是不够的。我的家人和朋友给了我所需的信心和支持：我的母亲 Ute 和父亲 Frieder、 我的姐姐 Iris，以及 Rainer L 歸、 Markus L 歸、 Torben L 歸、 Reinhold 和 Sieglinde Oppenl 妌 der、 Noreen 和 Charles Bramman、 Rita O 誈 ray、Christopher Bramman、 Gregory Bramman、
12、 Lauren 和 Richard French。还要特别感谢 Gerhard Mauz、 Markus Knierim 和 Marcus Zimmermann，这些朋友们让我一直关注于生命中最重要的东西。 敏捷项目管理 目录 摘要：敏捷项 目管理在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。本节为目录部分。 标签： 敏捷开发 敏捷项目管理 目录 译者序 前言 致谢 作者简介 第一部分敏捷与管理人员 第 1 章动机 .2 1.1 管理的期望 .2 1.1.1 迟到的变更 .3 1.1.2 需求瘫痪 .4
13、1.1.3 二义性 .5 1.1.4 需求太多 .5 1.1.5 需求太少 .6 1.1.6 变更控制委员会 .7 1.2 上市时间 .8 1.3 革新 .10 1.4 资金供给 .11 1.5 小结 .13 第 2 章敏捷软件开发 .14 2.1 定义 .14 2.1.1 敏捷是什么 .14 2.1.2 敏捷过程 .14 2.1.3 敏捷宣言 .17 2.1.4 敏捷联盟 .19 2.1.5 敏捷 项目领导力网络 .19 2.2 敏捷开发的关键实践 .20 2.2.1 迭代 -增量开发 .20 2.2.2 测试驱动开发 .22 2.2.3 持续集成 .24 2.2.4 面对面交流 .25 2
14、.3 敏捷项目中所需观察的事情 .25 2.3.1 结对编程 .25 2.3.2 每日例会 .26 2.3.3 与需求有关的故事 .27 2.3.4 团队工作室 .27 2.3.5 频繁发布 .28 2.3.6 自我组织的团队 .28 2.4 小结 .29 第 3 章项目管理 .30 3.1 传统项目管理 .30 3.1.1 工作分解结构 .31 3.1.2 甘特图 .32 3.1.3 关键路径分析 .34 3.1.4 项目报告 .35 3.1.5 对挑战的小结 .36 3.2 敏捷项目管理 .36 3.3 角色与职责 .39 3.3.1 角色 .39 3.3.2 责任 .41 3.4 小结
15、.46 第二部分定义、计划并衡量投资组合 第 4 章基础 .48 4.1 事实 .48 4.2 机构 .50 4.2.1 职能型的机构 .50 4.2.2 项目型的机构 .51 4.2.3 矩阵型的机构 .52 4.3 复合结构 .54 4.4 项目管理办公室 .54 4.5 术语和定义 .55 4.5.1 项目 .55 4.5.2 程序 .56 4.5.3 投资组合 .57 4.6 涉众 .58 4.7 目标 .58 4.7.1 太多项目 .59 4.7.2 项目很少能终止 .60 4.7.3 没有足够的资源可用 .60 4.7.4 缺乏指标 .61 4.7.5 没有愿景 .61 4.8 小
16、结 .62 第 5 章指标 .63 5.1 指标 .63 5.1.1 进展 .64 5.1.2 质量 .74 5.1.3 团队士气 .80 5.2 报告 .82 5.2.1 状态报告 .82 5.2.2 解释 .84 5.3 小结 .86 第 6 章投资回报 .87 6.1 目标 .87 6.2 增量 .88 6.3 财务模型 .91 6.3.1 回收期 .91 6.3.2 净现值 .94 6.3.3 内部收益率 .96 6.3.4 成本效益分析 .97 6.4 项目提供的效益 .97 6.4.1 正在减少的效益 .98 6.4.2 效益最后期限 .99 6.4.3 正在增加的效益 .99 6
17、.5 风险 .100 6.6 技术 .103 6.7 小结 .104 第 7 章项目投资组合管理 .105 7.1 对项目投资组合进行平衡 .105 7.1.1 避免一次从事过多项目 .106 7.1.2 在投资组合中平衡有风险的和值得做的项目 .108 7.1.3 使用有愿景的项目来平衡投资组合 .114 7.1.4 避免限制愿景并阻碍开发的小项目 .115 7.2 初始化一个项目 .116 7.2.1 实现收集思想的过程 .117 7.2.2 展示业务案例 .118 7.2.3 业务案例的评估 .120 7.2.4 收集并管理提议 .120 7.2.5 项目竞争：让最好的项目胜出 .123
18、 7.3 选择项目 .125 7.3.1 继续 /不继续 .125 7.3.2 项目的暂停 .127 7.3.3 加速项目 .128 7.4 小结 .130 第 8 章资源投资组合管理 .131 8.1 资源投资组合的平衡 .131 8.1.1 缺乏愿景 .132 8.1.2 项目太多但资源不够 .134 8.1.3 项目需要不同技能 .136 8.1.4 缺乏来自资源的反馈 .138 8.2 角色和资源池 .140 8.3 技能传授 .141 8.3.1 敏捷培训 .141 8.3.2 辅导 .143 8.4 全球化分布开发 .143 8.5 企业网络 .145 8.6 证书 .146 8.
19、7 小结 .147 第 9 章资产投资组合管理 .148 9.1 对资产投资组合进行平衡 .148 9.1.1 它首先是一项资产， 然后是个路障 .149 9.1.2 “ 基业长青 ” 是否是正面属性 .152 9.1.3 所有权的总成本 .154 9.2 小结 .155 第 10 章投资组合在行动 .156 10.1 投资组合仪表板 .156 10.2 一个示例场景 .157 10.2.1 第一次迭代 .158 10.2.2 第二次迭代 .159 10.2.3 第三次迭代 .160 10.3 小结 .162 第三部分机构和环境 第 11 章使用 Scrum 进行投资组合管理 .164 11.
20、1 Scrum 概述 .164 11.2 投资组合待办事宜 .167 11.2.1 项目投资组合待办事宜 .168 11.2.2 资源投资组合待办事宜 .169 11.2.3 资产投资组合待办事宜 .169 11.3 角色 .169 11.3.1 投资组合所有者 .170 11.3.2 投资组合队长 .170 11.3.3 投资组合经理 .170 11.4 活动 .171 11.4.1 投资组合冲刺计划会议 .171 11.4.2 投资组合 Scrum 会议 .171 11.4.3 投资组合冲刺回顾会议 .171 11.5 指标 .172 11.6 Scrum 证书 .173 11.7 小结
21、.174 第 12 章项目管理办公室 .175 12.1 敏捷项目管理的挑战 .175 12.1.1 敏捷 项目团队是赋予力量且是自我组织的 .175 12.1.2 敏捷过程是以经验为依据的 .177 12.1.3 里程碑监视与过程报告 .179 12.1.4 项目管理的最优方法 .179 12.1.5 定义敏捷 PMO 的角色和职责 .180 12.1.6 PMO 和投资组合管理 .181 12.1.7 为敏捷工作选择正确的工具 .181 12.1.8 开销和效益 .182 12.1.9 在敏捷环境中应用模型、标准和规则 .183 12.2 最大限度利用 PMO .183 12.2.1 辅导
22、 .183 12.2.2 员工配备 .184 12.2.3 培训 .184 12.2.4 手册和发布说明 .184 12.2.5 发布团队 .184 12.2.6 指标 .185 12.2.7 状态 .185 12.2.8 投资组合 .185 12.3 小结 .185 附录附加资源 .186 敏捷项目管理 译者序 摘要：敏捷项目管理在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。本节为译者序。 标签： 敏捷开发 敏捷项目管理 译者序 敏捷开发方法流行于那些发现传统瀑布开发方法无法适应这个由变更、革新驱动的世
23、界的要求的企业。在一个企业中，朝向敏捷方法的变更既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会，也将探究潜在的风险问题。 本书分为以下三个部分：敏捷与管理人员；定义、计划并衡量投资组合；机构和环境。阅读本书可以了解敏捷软件开发和敏捷项目管理中常用的敏捷实践以及 如何使用现代投资组合管理实践管理敏捷项目。本书也针对如何把最流行的敏捷开发过程和敏捷投资组合管理编排在一起提供了一些实际操作建议。 本书适合项目经理、投资组合经理、业务分析师、 PMO 成员以及执行经理等对采纳敏捷实践和投资组合管理感兴趣的人士阅读。 参加本书翻译的人员有：陈宗斌、戴锋、许瑛琪、王馨、陈婷、管学岗
24、、王新彦、金惠敏、张海峰、徐晔、张德福、张士华、张景友、易小丽、陈红霞、王开年、贾震、陆晓萍、金国良、俞群。 由于时间紧迫，加之译者水平有限，错误在所难免，恳请广大读者批评指正。 敏捷项目管理 本书赞誉 摘要：敏捷项目管理在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。本节为本书赞誉。 标签： 敏捷开发 敏捷项目管理 本书赞誉 本书讲述企业在投资组合管理应用敏捷方法丢失的环节。 Mike Cohn， Agile Estimating and Planning的作者 大型机构中存在的各种相互依赖关系会让想要朝
25、向敏捷方法前进的团队感到困惑，而Jochen Krebs 著的就是一本为他们解惑的书。本书应该位于那些有前瞻想法的各个层次的执行官和项目经理的书架上。 Peter Rivera， AOL Programming 执行创新和程序主任、高级副总裁 这本书给出了目前对敏捷方法的强烈讨论中被忽略的一个领域。许多机构在采用诸如Scrum 和 XP 这样的敏捷方法时会面临一些问题，其解决方案存在于有效的投资组合管理中，而 Jochen 成功地将这个主题展现在我们面前。 Sanjiv Augustine， Lithespeed 总裁、 Agile Project Management的作者、敏捷项目领导力网
26、络的合伙创办者 这本书绝对值得一读。 Jochen 简化了一个非常复杂的概念，并且给了我们一本既言简意赅又为敏捷投资组合管理提供非常实用 方法的书。 Robert Eagan，纽约某主要金融机构的全球项目管理主任 本书开垦了敏捷标准的处女地，它在程序和投资组合级别上为敏捷机构中的组织工作提供了特定的技术。随着大型 IT 机构对敏捷方法的广泛采用，许多机构发现自己过时的项目选择、预算和投资组合管理过程成为实现敏捷开发机构本应支持的完全有竞争力的效益的障碍。本书将为机构提供一些特定的选项，供机构考虑提升敏捷投资组合计划和管理实践的节奏和质量，以便与现代敏捷开发机构的速度相匹配。 Evan Camp
27、bell， Rally Software Development专业服务副总裁 在这本独一无二而且开标立范的书中， Jochen Krebs 为 IT 社区带来了创建并管理敏捷投资组合所急需的、实际的和全面的路线图。 Doug DeCarlo， Doug DeCarlo 集团负责人、 eXtreme Project Management: Using Leadership, Principles & Tools to Deliver Value in the face of Volatility的作者 我们终于看到了一本为 IT 领导者和业务涉众编写的实用的敏捷项目管理之书。 Jochen 对
28、敏捷实践的全面介绍涵盖了投资组合管理中的三个关键向量：项目、资产和资源的财政、过程和人员等方面。这是一本我会摆在案头的参考书籍，对于任何要进行敏捷战役的机构而言它都极为适合。它也是一本 CIO、 PMO 负责人和产品所有者必读的书。 Tiran Dagan， GE/NBC Universal 战略计划与分析部门主任 /契约负责人 在一个全球化、超级竞争的市场中，我们比以往任何时候都更需要找到持续识别、排序并执行软件项目的方法，这些方法能够像例行公事般地快速部署引人注目的产品与服务，并带来企业的革新和更好的 收益。已经出现的敏捷软件开发实践顺应了增长中的需要，而机构决策和管理方法则继续植根于那些
29、旧的教科书般的管理实践 紧抓大设计在先的资金提供与执行模型。本书成功地描绘了一个广泛的、实用的以及具有良好构想的框架。在一个由变更驱动的世界中，这个框架的构建是为了统一机构的思想和实践方式，以便获取最大的机构敏捷性并创造最大价值。我将把 Jochen 的书推荐给我所有的 CXO 客户阅读，因为他们希望能够对如何最好和有效地管理并利用对生存和系统性革新都如此关键的敏捷工程实践有更好的理解。 Brad Murphy， Valtech 北 美 CEO 第 1 章 动机 1.1 管理的期望 摘要：敏捷项目管理第 1 章动机，本章从企业和管理的角度揭示使用传统开发方法（也称为瀑布法）的企业要面对的共同挑
30、战。本节为大家介绍管理的期望。 标签： 敏捷开发 敏捷项目管理 第一部分 敏捷与管理人员 本书的第一部分是为想要对与敏捷软件开发有关的效益和动机有更多了解的管理人员而准备的。这里包括对敏捷是什么以及敏捷开发为什么尤其能在动态市场中很好工作的介绍。本部分的 3 章将为我们在第二部分更深入探究敏捷投资组合管理设立一个舞台。 这一部分的 3 章将从管理人员的角度来介绍敏捷方法： 第 1 章使用真实世界的示例、趋势和业务世界事实来说明敏捷开发最近得到如此多的关注的原因 。 第 2 章介绍用于敏捷项目的核心敏捷价值、关键实践和关键技术。 第 3 章展现敏捷项目管理人员的角色和职责以及与其涉众之间的关系，
31、还介绍了传统项目管理实践的挑战。 第 1 章 动机 在这个新千年开始的时候，出现了明显的市场全球化的趋势，尤其在信息技术（ IT）领域。即使是长久以来认为与这个趋势无关的本地 IT 企业家，也越来越多地感受到来自国际上的压力，认为必须拼价值和价格。而涉众（ stakeholder）们不仅仅期待用更少的金钱获得更高的质量，而且期待开发机构能够在更短的周期内更快地发布产品。对这个脚步飞快的环境进 行管理的需求、对适时将产品发布到市场的需求，以及对价格保持敏感的需求都是敏捷开发的动机。我们将探究在这个不稳定、不可知和不可预测的世界中，按传统方式管理的 IT 项目所要面对的一些挑战。本章从企业和管理的
32、角度揭示使用传统开发方法（也称为瀑布法）的企业要面对的共同挑战。 每个以传统方式管理的项目引起的挑战都会给开发机构带来重大风险。这些风险中有一些是如此难以抵挡，以致现代机构无法容忍它们的存在，甚至无法容忍那些用于降低这些风险的战略。 1.1 管理的期望 我有很好的理由使用 “ 期望 ” 这个词而不使用 “ 需求 ” 。需求 是一组业务规则和组织政策，它们与涉众所表达的需要组合在一起。期望包括需求，但它们不那么实际可见，也根本无法表达出来。然而，在项目的最终，对成功的衡量标准是期望，而不是需求。比如，一位业务分析师在将系统的详细需求整理成档时，他所给予的最大关注程度也许不会超出需求太多。而结果是
33、，这个系统的受众可能还是不 “ 喜欢 ” 它。项目是成功的吗？答案可能是 “ 是 ” 。系统是否做了用户想要的事情？极有可能不是。过于迟到的变更、系统的不稳定性以及需求的二义性持续地导致项目与原来的计划背道而驰，而这些现象正是一个项目无法符合期望的典型症 状。尽管开发人员对细节相当关注，但项目却无法取得成功，其原因在于要捕获整个涉众群的所有期望是不可能的。这种理想世界不存在。 1.1.1 迟到的变更 摘要：敏捷项目管理第 1 章动机，本章从企业和管理的角度揭示使用传统开发方法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍迟到的变更。 标签： 敏捷开发 敏捷项目管理 1.1.1 迟到的变
34、更 以传统方式管理项目的特征是：各个阶段由里程碑隔开，阶段与阶段之间通常需要有一个完成信号。这个完成信号标志着项目团队通过了里程碑，可以继续进入下一阶段的工作。与有法律约束的合同相似，一旦完成信号得到确认，就很难再转回项目前面的状态了。虽然这些合同的签署在许多 情况下合乎情理，它们让我们可以对特定的条件达成一致，但是在将其应用于软件开发环境的时候，这个模型却受到了挑战。我们看看这是为什么。 图 1-1 概要地描绘了传统软件开发方法，诸如需求、分析和设计、编码、测试以及部署这样的公共工程活动分成了各自独立的阶段。 （点击查看大图）图 1-1 迟到的需求变更 实施从一个阶段到另一个阶段的转移要通过
35、完成信号、批准并提交给下一个专业团队这几个过程。一旦进入下一阶段，前一阶段的工作就完成了，而这正是问题所在。 在 传统的过程中，每个项目只在过程中流过一次，最后以系统的部署作为结束。请想象一个需要两年时间完成的项目，它按如图 1-1 那样的阶段进行。当我们进入编码阶段时，我们的需求已经是 10 个月前的了。 16 个月之后，系统终于进入测试阶段。而正是在测试阶段中，人们发现之前没有发现的需求。如果在测试的时候这些需求还没有被发现，然后就对系统进行了部署，那才叫糟糕透顶。在部署之后，涉众将判断他们早先需求的实现情况。这个时候就会发现问题了，因为最初的涉众将在游戏的这个阶段回来。然而，到了现在想再
36、做变更就困难了。这有两个原因：一个是经 济原因，到目前为止这个项目已经花费了所分配的资源中的大部分；另外一个是结构和设计上的原因，它们在构建的时候根本就没有考虑这些需求。 以传统方式管理的项目好处虽然有许多，但它们有这个共同的问题 迟到的变更极难得到消化。当然，困难程度与引入变更的严重程度有关。我甚至见过因为一个需求的变更而造成整个项目完全失败的情况。这就是我经常在部署阶段之后增加一个叫做 “ 批评阶段 ” 的新阶段的真实原因。 请不要忘记传统模型是在 20 世纪 60 年代开发的，在那个时候统治 IT 王国的是大型计算机。在那个时代所使用的技术并不欢迎变更的到来。 那时候编程是过程化的、自上
37、而下的。如果需要变更，就需要重新编译并重新组装整个程序或系统。为了安全起见，每一次编译的成品都需要新的完全测试。这个模型为其特定的技术服务，人们英雄般地尝试一次性地把工作做好。 虽然开发机构已经采纳了新的、面向组件的技术，但是底层的开发过程仍旧经常使用相同的传统方法。正是这个过程反映了整个开发机构的文化。变更一种久负盛名的文化要比使用一种新的编程语言需要更多的能量。 相比之下，现代软件开发通常使用面向对象的技术。这些面向对象的系统是由更小的高度聚合、松散耦合的分块和元素组装起来的。 这使开发团队能够以更小的步骤和单元进行开发、测试并集成。由于新的可用技术的存在，我们现在处于一个可以关注现代开发过程及其管理方法的位置上。结果就是，敏捷开发和敏捷项目管理方法更早、更频繁地把变更带入，而且这些方法以小的、循序渐进的步骤来构建软件。
