敏捷项目管理-(美)施瓦伯著-Scrum_Project_Management

敏捷项目管理 陈宗斌 译 敏捷开发方法流行于那些发现传统瀑布法无法适应这个由改变、革新而驱动的世界的要求的 企业。既然敏捷开发过程带来更好的结果，那么也能将这个方法应用于整个 IT 投资组合中。 在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机 构及其领导力带来的机会和回报，也将探究其潜在的风险问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。 本书适合项目经理、投资组合经理、业务分析师、PMO 成员以及执行经理等对采纳敏捷实践和 投资组合管理感兴趣的人士阅读。 敏捷项目管理 前言  摘要：《敏捷项目管理》在一个企业中，朝向敏捷方式的改变既带来机会也带来风险， 本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。 本节为前言部分。  标签：敏捷开发 敏捷项目管理 前言 如果你学过经济，就肯定了解制定战术 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 和制定战略计划之间的区别。在 20 世纪 80 年代，行动的战术窗口只是 3～5 年的计划，而战略计划则超过 5 年，最多可达 10年。在 20 世纪 90 年代，也就是信息时代起飞之后，变革的速率及其附加作用极大地减少了计划窗口的 大小，而软件开发周期也减少了。到现在，我不认为还有以 20 世纪 80 年代的周期作计划的 机构存在，尤其是在信息技术这一部分。实际上，我听到经理们讲这么一个笑话：“战术是 今天所要做的，战略是为明天做计划。”如同许多笑话一样，笑话之中有真理。 变革的速率影响着我们将来开发系统的方式，尤其是那些较大的系统。项目的时间表越 长，项目范围成为战略的一部分的几率就越高。我们从过去许多经验中得知，一个花费了两 年时间进行的项目的结果不一定会和我们对它的期待一致。传统项目的计划精确度非常粗糙， 这是造成这种问题的原因之一。 为了解决这个问题，许多机构采用或试用敏捷开发方法—这是一种基于迭代-增量开发的 方法，它将项目的范围分解为更小的、可管理的块。从管理的角度看，这是一种理想方法， 因为即使是最长的战略性项目也会有一个战术上的组件：即将进行的迭代。而正是这个组件 将使得执行官、项目经理以及项目团队得以掌好项目的舵，带领项目驶向并不精确的愿景。 想转变为敏捷方法并不是一件容易的事情。改变带来机会，也总需承担风险，敏捷开发的机 会和风险均有不少。本书将探究敏捷方法为开发机构及其领导力带来的机会，也将探究潜在 的风险问题。 我编写本书的动机之一是想把我的职业生涯内在项目团队内外所观察到的信息与大家分 享。这些观察的结果有许多都能追溯到同一个根本原因：在机构内，我所目睹到的各个方面 都缺乏信任。 在长期以传统方式管理的项目过程中，许多项目状态报告（尤其是在项目早期阶段）过 于乐观。首先，要让业务分析师或软件工程师知道他们的进度落后于时间表是一件极为困难 的事情。在分析之前或在分析过程中，想知道总共有多少分析量是不可能的。如果不知道总 量，我们如何知道现在的工作正按部就班呢？而后在项目进行时，如果项目由于有新的发现 而延期，但执行分析的人早已离开，他们已经转移到新的项目上了。 其次，长久以来，我们一直受到这样的教导：项目经理是负责人。他管理团队，指派任 务并且承担整体项目成功的责任。所有这些压力以及所有这些期望都指向同一个人，这个人 也负责项目的沟通交流工作。有了这样的场景，我们怎么可能期望项目沟通交流是中立的？ 高级执行官如果要求每周多给出一份详细的状态报告，那么这不就已经是一种不信任的底层 形式了吗？在我的职业生涯里，我不断看到这些机能失调和不信任的症状。 敏捷投资组合管理并不排除书面交流方式，但它确保沟通进行在执行中的项目所产生的 现有敏捷指标的基础。敏捷投资组合管理在项目团队和执行官之间建立了一个清晰定义的接 口，而其建立在敏捷实践的基础上。这些实践建立在信任之上，并且会对任何朝向组织上的 敏捷所作的转变带来正面的影响。 我将本书称为《敏捷项目管理》，因为这正是机构中活动项目的投资组合，这些项目代 表了企业的未来，无论是战术上的还是战略上的，也无论读者对这些术语的定义是什么。“敏 捷”这个术语所强调的不仅是投资组合中的项目是敏捷项目，也强调投资组合是构建在敏捷 实践之上，而且是动态管理的。本书展示了现代敏捷企业的透明性，它清晰地定义了交流通 道，所以，本书既面向项目经理也面向执行官。 本书分为以下三个部分： 第一部分：敏捷与管理人员。这个介绍性的部分是为想要了解敏捷软件开发在过去的几 年中变得如此流行的原因的管理人员准备的。它讲解了在敏捷软件开发和敏捷项目管理中常 用的最重要的敏捷实践。 第二部分：定义、计划并衡量投资组合。第二部分是本书最大的一部分。它讲解了与敏 捷投资组合管理有关的实践。本部分所包括的实践有编写指标，建立项目选择过程，评估资 源以及计算投资回报。这些章介绍现代投资组合管理的实践。 第三部分：机构和环境。本书的最后一部分为如何把最流行的敏捷开发过程和敏捷投资 组合管理编排在一起提供一些实际操作建议。它介绍了以 Scrum 方式管理项目适应投资组合 管理过程的方式。另外，本部分也讲解了在敏捷机构中项目管理办公室（PMO）的新角色。 本书读者对象 本书主要面向项目经理、投资组合经理、业务分析师、PMO成员以及执行经理等对采纳敏 捷实践和投资组合管理感兴趣的人。我希望本书能够为读者确切地给出容易消化本主题的介 绍内容，而且有足够的材料在整个企业中开展敏捷方法。 虽然技术读者不是本书的主要对象，但本书可以帮助他们理解、体会机构内不同层次的 人员的动机，而且更好地理解项目的外部因素如何影响他们在企业中的工作。 除了能够为读者中的专业人士带来效益外，我希望本书也能够帮助正在攻读工商管理学 位的学生理解在业内敏捷开发的重要性和影响。你们是明天的项目经理。 在线寻找更多内容 如果本书有新的补充材料或者更新材料出现，我们将在线贴在 Microsoft Press Online Developer Tools Web 站点上。读者可找到的材料包括本书内容、文章、勘误表、样章等的更 新。这个站点很快就可以通过 http://www.microsoft.com/learning/books/online/developer 来访问，而且会定期更新。 对本书的支持 我们尽力确保本书以及本书的配套内容准确无误。如有修正或者变更，它们将出现在 Microsoft Knowledge Base 文章中。 Microsoft Press 在以下 Web 站点提供对本书以及本书配套内容的支持： http://www.microsoft.com/learning/support/books/ 问题和评论 与本书或者配套内容有关的任何评论、问题或想法，或者无法通过访问上述站点解决的 问题，请通过电子邮件将它们发送到： msinput@microsoft.com 或者通过邮寄信件到： Microsoft Press Attn: Agile Portfolio Management Editor One Microsoft Way Redmond, WA 98052-6399 请注意，Microsoft 不通过上述地址提供软件产品支持。 致谢 我想感谢以下各位人士，他们在本项目的不同阶段为我提供的反馈和深度评述实乃无价 之宝。他们是：Denise Cook、Marie Kalliney和 Roman Pichler。Roger LeBlanc 担任本书 编辑，在我认为已经完成的情况下仍旧不停工作，为本书进行了多次重审，直到成书。Steve Sagman 和 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、Lauren和 Richard French。还要特别感谢 Gerhard Mauz、Markus Knierim和 Marcus Zimmermann，这些朋友们让我一直关注于生命中最重要的 东西。 敏捷项目管理 目录  摘要：《敏捷项目管理》在一个企业中，朝向敏捷方式的改变既带来机会也带来风险， 本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。 本节为目录部分。  标签：敏捷开发 敏捷项目管理 目录 译者序 前言 致谢 作者简介 第一部分敏捷与管理人员 第 1 章动机............2 1.1 管理的期望.............2 1.1.1 迟到的变更...........3 1.1.2 需求瘫痪............4 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.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 小结...............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 小结...............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.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 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.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.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 小结..............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 辅导............183 12.2.2 员工配备..........184 12.2.3 培训............184 12.2.4 手册 华为质量管理手册 下载焊接手册下载团建手册下载团建手册下载ld手册下载 和发布说明.......184 12.2.5 发布团队..........184 12.2.6 指标............185 12.2.7 状态............185 12.2.8 投资组合..........185 12.3 小结...............185 附录附加资源............186 敏捷项目管理 译者序  摘要：《敏捷项目管理》在一个企业中，朝向敏捷方式的改变既带来机会也带来风险， 本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。 本节为译者序。  标签：敏捷开发 敏捷项目管理 译者序 敏捷开发方法流行于那些发现传统瀑布开发方法无法适应这个由变更、革新驱动的世界 的要求的企业。在一个企业中，朝向敏捷方法的变更既带来机会也带来风险，本书将探究敏 捷方法为开发机构及其领导力带来的机会，也将探究潜在的风险问题。 本书分为以下三个部分：敏捷与管理人员；定义、计划并衡量投资组合；机构和环境。 阅读本书可以了解敏捷软件开发和敏捷项目管理中常用的敏捷实践以及如何使用现代投资组 合管理实践管理敏捷项目。本书也针对如何把最流行的敏捷开发过程和敏捷投资组合管理编 排在一起提供了一些实际操作建议。 本书适合项目经理、投资组合经理、业务分析师、PMO 成员以及执行经理等对采纳敏捷实 践和投资组合管理感兴趣的人士阅读。 参加本书翻译的人员有：陈宗斌、戴锋、许瑛琪、王馨、陈婷、管学岗、王新彦、金惠 敏、张海峰、徐晔、张德福、张士华、张景友、易小丽、陈红霞、王开年、贾震、陆晓萍、 金国良、俞群。 由于时间紧迫，加之译者水平有限，错误在所难免，恳请广大读者批评指正。 敏捷项目管理 本书赞誉  摘要：《敏捷项目管理》在一个企业中，朝向敏捷方式的改变既带来机会也带来风险， 本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。 本节为本书赞誉。  标签：敏捷开发 敏捷项目管理 本书赞誉 本书讲述企业在投资组合管理应用敏捷方法丢失的环节。—Mike Cohn，《Agile Estimating and Planning》的作者 大型机构中存在的各种相互依赖关系会让想要朝向敏捷方法前进的团队感到困惑，而 Jochen Krebs 著的就是一本为他们解惑的书。本书应该位于那些有前瞻想法的各个层次的执 行官和项目经理的书架上。—Peter Rivera， AOL Programming 执行创新和程序主任、高级 副总裁 这本书给出了目前对敏捷方法的强烈讨论中被忽略的一个领域。许多机构在采用诸如 Scrum 和 XP这样的敏捷方法时会面临一些问题，其解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 存在于有效的投资组合管理中， 而 Jochen 成功地将这个主题展现在我们面前。—Sanjiv Augustine，Lithespeed 总裁、《Agile Project Management》的作者、敏捷项目领导力网络的合伙创办者 这本书绝对值得一读。Jochen 简化了一个非常复杂的概念，并且给了我们一本既言简意 赅又为敏捷投资组合管理提供非常实用方法的书。—Robert Eagan，纽约某主要金融机构的 全球项目管理主任 本书开垦了敏捷标准的处女地，它在程序和投资组合级别上为敏捷机构中的组织工作提 供了特定的技术。随着大型 IT 机构对敏捷方法的广泛采用，许多机构发现自己过时的项目选 择、预算和投资组合管理过程成为实现敏捷开发机构本应支持的完全有竞争力的效益的障碍。 本书将为机构提供一些特定的选项，供机构考虑提升敏捷投资组合计划和管理实践的节奏和 质量，以便与现代敏捷开发机构的速度相匹配。—Evan Campbell，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 对 敏捷实践的全面介绍涵盖了投资组合管理中的三个关键向量：项目、资产和资源的财政、过 程和人员等方面。这是一本我会摆在案头的参考书籍，对于任何要进行敏捷战役的机构而言 它都极为适合。它也是一本 CIO、PMO 负责人和产品所有者必读的书。—Tiran Dagan，GE/NBC Universal 战略计划与分析部门主任/契约负责人 在一个全球化、超级竞争的市场中，我们比以往任何时候都更需要找到持续识别、排序 并执行软件项目的方法，这些方法能够像例行公事般地快速部署引人注目的产品与服务，并 带来企业的革新和更好的收益。已经出现的敏捷软件开发实践顺应了增长中的需要，而机构 决策和管理方法则继续植根于那些旧的教科书般的管理实践—紧抓大设计在先的资金提供与 执行模型。本书成功地描绘了一个广泛的、实用的以及具有良好构想的框架。在一个由变更 驱动的世界中，这个框架的构建是为了统一机构的思想和实践方式，以便获取最大的机构敏 捷性并创造最大价值。我将把 Jochen 的书推荐给我所有的 CXO 客户阅读，因为他们希望能够 对如何最好和有效地管理并利用对生存和系统性革新都如此关键的敏捷工程实践有更好的理 解。—Brad Murphy，Valtech 北美 CEO 第 1 章 动机 1.1 管理的期望  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍管理的期望。  标签：敏捷开发 敏捷项目管理 第一部分 敏捷与管理人员 本书的第一部分是为想要对与敏捷软件开发有关的效益和动机有更多了解的管理人员而 准备的。这里包括对敏捷是什么以及敏捷开发为什么尤其能在动态市场中很好工作的介绍。 本部分的 3章将为我们在第二部分更深入探究敏捷投资组合管理设立一个舞台。 这一部分的 3 章将从管理人员的角度来介绍敏捷方法： 第 1 章使用真实世界的示例、趋势和业务世界事实来说明敏捷开发最近得到如此多的关 注的原因。 第 2 章介绍用于敏捷项目的核心敏捷价值、关键实践和关键技术。 第 3 章展现敏捷项目管理人员的角色和职责以及与其涉众之间的关系，还介绍了传统项 目管理实践的挑战。 第 1 章 动机 在这个新千年开始的时候，出现了明显的市场全球化的趋势，尤其在信息技术（IT）领 域。即使是长久以来认为与这个趋势无关的本地 IT 企业家，也越来越多地感受到来自国际上 的压力，认为必须拼价值和价格。而涉众（stakeholder）们不仅仅期待用更少的金钱获得更 高的质量，而且期待开发机构能够在更短的周期内更快地发布产品。对这个脚步飞快的环境 进行管理的需求、对适时将产品发布到市场的需求，以及对价格保持敏感的需求都是敏捷开 发的动机。我们将探究在这个不稳定、不可知和不可预测的世界中，按传统方式管理的 IT 项 目所要面对的一些挑战。本章从企业和管理的角度揭示使用传统开发方法（也称为瀑布法） 的企业要面对的共同挑战。 每个以传统方式管理的项目引起的挑战都会给开发机构带来重大风险。这些风险中有一 些是如此难以抵挡，以致现代机构无法容忍它们的存在，甚至无法容忍那些用于降低这些风 险的战略。 1.1 管理的期望 我有很好的理由使用“期望”这个词而不使用“需求”。需求是一组业务规则和组织政 策，它们与涉众所表达的需要组合在一起。期望包括需求，但它们不那么实际可见，也根本 无法表达出来。然而，在项目的最终，对成功的衡量标准是期望，而不是需求。比如，一位 业务分析师在将系统的详细需求整理成档时，他所给予的最大关注程度也许不会超出需求太 多。而结果是，这个系统的受众可能还是不“喜欢”它。项目是成功的吗？答案可能是“是”。 系统是否做了用户想要的事情？极有可能不是。过于迟到的变更、系统的不稳定性以及需求 的二义性持续地导致项目与原来的计划背道而驰，而这些现象正是一个项目无法符合期望的 典型症状。尽管开发人员对细节相当关注，但项目却无法取得成功，其原因在于要捕获整个 涉众群的所有期望是不可能的。这种理想世界不存在。 1.1.1 迟到的变更  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍迟到的变更。  标签：敏捷开发 敏捷项目管理 1.1.1 迟到的变更 以传统方式管理项目的特征是：各个阶段由里程碑隔开，阶段与阶段之间通常需要有一 个完成信号。这个完成信号标志着项目团队通过了里程碑，可以继续进入下一阶段的工作。 与有法律约束的 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 相似，一旦完成信号得到确认，就很难再转回项目前面的状态了。虽然 这些合同的签署在许多情况下合乎情理，它们让我们可以对特定的条件达成一致，但是在将 其应用于软件开发环境的时候，这个模型却受到了挑战。我们看看这是为什么。 图 1-1 概要地描绘了传统软件开发方法，诸如需求、分析和设计、编码、测试以及部署 这样的公共工程活动分成了各自独立的阶段。 （点击查看大图）图 1-1 迟到的需求变更 实施从一个阶段到另一个阶段的转移要通过完成信号、批准并提交给下一个专业团队这 几个过程。一旦进入下一阶段，前一阶段的工作就完成了，而这正是问题所在。 在传统的过程中，每个项目只在过程中流过一次，最后以系统的部署作为结束。请想象 一个需要两年时间完成的项目，它按如图 1-1那样的阶段进行。当我们进入编码阶段时，我 们的需求已经是 10 个月前的了。16 个月之后，系统终于进入测试阶段。而正是在测试阶段中， 人们发现之前没有发现的需求。如果在测试的时候这些需求还没有被发现，然后就对系统进 行了部署，那才叫糟糕透顶。在部署之后，涉众将判断他们早先需求的实现情况。这个时候 就会发现问题了，因为最初的涉众将在游戏的这个阶段回来。然而，到了现在想再做变更就 困难了。这有两个原因：一个是经济原因，到目前为止这个项目已经花费了所分配的资源中 的大部分；另外一个是结构和设计上的原因，它们在构建的时候根本就没有考虑这些需求。 以传统方式管理的项目好处虽然有许多，但它们有这个共同的问题—迟到的变更极难得 到消化。当然，困难程度与引入变更的严重程度有关。我甚至见过因为一个需求的变更而造 成整个项目完全失败的情况。这就是我经常在部署阶段之后增加一个叫做“批评阶段”的新 阶段的真实原因。 请不要忘记传统模型是在 20 世纪 60 年代开发的，在那个时候统治 IT 王国的是大型计算 机。在那个时代所使用的技术并不欢迎变更的到来。那时候编程是过程化的、自上而下的。 如果需要变更，就需要重新编译并重新组装整个程序或系统。为了安全起见，每一次编译的 成品都需要新的完全测试。这个模型为其特定的技术服务，人们英雄般地尝试一次性地把工 作做好。 虽然开发机构已经采纳了新的、面向组件的技术，但是底层的开发过程仍旧经常使用相 同的传统方法。正是这个过程反映了整个开发机构的文化。变更一种久负盛名的文化要比使 用一种新的编程语言需要更多的能量。 相比之下，现代软件开发通常使用面向对象的技术。这些面向对象的系统是由更小的高 度聚合、松散耦合的分块和元素组装起来的。这使开发团队能够以更小的步骤和单元进行开 发、测试并集成。由于新的可用技术的存在，我们现在处于一个可以关注现代开发过程及其 管理方法的位置上。结果就是，敏捷开发和敏捷项目管理方法更早、更频繁地把变更带入， 而且这些方法以小的、循序渐进的步骤来构建软件。 1.1.2 需求瘫痪  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍需求瘫痪。  标签：敏捷开发 敏捷项目管理 1.1.2 需求瘫痪 相比于那些可以实现的迟到的需求变更（虽然很费劲），有些需求由于过于动态或存在 矛盾而根本无法解决。在需求总是变化，大家疲于对大的技术规格达成一致的情况下，项目 团队将根本无法找到需求阶段的出口在哪儿。让受困于这种事件圈子中的人感到灰心的是， 除了文档以外项目团队无法达成任何明确的进展。 在涉众和业务分析师们尝试解决歧义问题并完成一个足够稳定的需求范围以便完成这一 阶段的过程中，珍贵的时间和资源白白浪费了。这种现象在动态行业中尤其常见，这些行业 的变更速率非常高；另外在革新项目中也很常见，这种项目的需求起伏无常。比如传媒业和 广告业以及金融业就属于这种动态业务领域。对于这样的情况，需求可谓朝令夕改。 在这种类型的环境中工作尤其让人感到灰心，因为所有参与方都清楚地知道工作没有进 展。团队处于这种状态的时间越长，就越需要更好的激励才能让他们回到正轨。基本上，需 求瘫痪的问题归根结底只有一个原因：想让需求“确定下来”。 1.1.3 二义性  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍二义性。  标签：敏捷开发 敏捷项目管理 1.1.3 二义性 向团队中的三个成员询问他们最喜欢的比萨饼是哪种，他们谈到的饼可能完全不同。其 中一人可能喜欢薄的、脆的，而不是厚的；另一个人可能喜欢半圆型的，而不是一块一块的； 而第三个成员可能选择带红色调味汁的比萨饼，而不是白比萨饼。不把需求说清楚就为这三 个人制作一张饼无异于买彩票。当我们谈及诸如比萨饼这样的日常事务时，似乎不需要任何 解释。Gause和 Weinberg使用一个简单的句子说明了这个例子：“玛丽有了只小羊羔。”这 里的“有了”有可能以许多不同的方式错误地进行解释。她可能怀了只羊羔，拥有一只羊羔 或者实际上吃了一只羊羔都是可能的解释。 在管理需求期望时也有相同的问题。对于手边的主题，每个人的记忆图像都不同。就如 当你说“明天的天气将很不错！”会让人们有不同的记忆图像那样，对于“系统生成一张发 票”这样的句子也一样。有些人会想到一张纸，其他的则认为发票会以电子的方式记录。结 果就是，完成的系统也许可以按文档的规范工作，但却不是按用户心中所想的那样工作。如 果用户是实际的顾客（比如，在线购物者），消除二义性就必须是最高优先级的工作。二义 性代价高昂。比如，Barry Boehm 就有这样的评估：如果在需求阶段所修正的二义性的成本比 率为 1，那么在测试阶段发现二义性所造成的修正成本将是这个值的 15～40 倍；如果在部署 阶段之后应用程序或系统开始运行时发现二义性，则成本将高达 40～1000 倍。请记得，这些 统计与传统方式管理项目有关。 敏捷开发将保持用户的参与，经常要求涉众按他们的记忆图像对成果进行确认。于是， 敏捷开发消除了二义性及其价格标签上的巨大数字。 1.1.4 需求太多  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍需求太多。  标签：敏捷开发 敏捷项目管理 1.1.4 需求太多 许多 IT 项目团队非常严肃地对待需求规范。我在职业开始的时候也是这样的。然而，当 我与业务用户实际操演之后，我发现需求经常只是个人的愿望列表。这些愿望列表经常是以 个人的工作惯例为基础的个人需求。我与一些涉众交谈，了解他们为什么对某些需求那么坚 持。当我与其他涉众讨论这些需求时，我们发现陈述这些需求的涉众实际上使用的是过时的 公司政策。你能想象如果我们将这样的需求当成绝对的需要并且加以实现会是个什么样子 吗？我们在这个案例中发现了这样的问题，但我确认我们在不知情的情况下在其他地方实现 过这种类型的需求。教训就是：要商定需求，进行投票，让涉众与你一起工作并保持让他们 参与。 涉众们需求很多，但他们实际需要的是什么？当对所谓的需求规格按优先级排序时，我 们将发现，许多需求可有可无，或者完全超出范围之外。如果给这些功能进行评估，就会发 现这个情况特别真实。要记住，需求必须是涉众们的公同需要。而有些需求可能只来自一位 涉众，这样的需求必须和其他涉众进行协商，得到他们的接受和确认。对功能的开发要耗费 时间和金钱。不仅如此，有些功能根本不值得开发—它们只会占用更重要功能的宝贵时间。 许多传统项目会完成对需求的优先级排序和过滤这一步骤。遗憾的是，这一步骤只执行 一次。一旦某些需求被认为超过项目的范围，以后要想把它们加入到范围内将会相当费劲。 你在本书中自始至终都将看到开放范围的需求管理在敏捷项目管理中的强大之处。你也 将看到，真正的需要总能在最终系统中找到自己的位置。 1.1.5 需求太少  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍需求太少。  标签：敏捷开发 敏捷项目管理 1.1.5 需求太少 到目前为止我们所有与需求管理有关的问题都有一个积极的方面：我们有需求可以开始。 要么有太多需求，需要应付二义性，需要集成并解决迟到的变更，要么需要应付需求瘫痪。 接下来我们要讨论的场景可能是传统项目面对的最糟糕的情况：需求太少。具有讽刺意味的 是，需求太少是敏捷开发非常善于对付的问题。 需求的缺乏对传统项目有巨大的影响。首先，最初的项目范围不能反映涉众真正的需要。 其次，评估出来的范围会导致内部的变更控制搅动（change-control churn），因为涉众最 终会表达出他们的需要。我们将变更控制搅动看成是在低质量需求基础上的大量变更。这也 包括对先前批准的变更所作的变更。最后但并不是不重要的一点：范围受限于在项目的第一 部分所表达的需求。所以，许多新发现的需求都是为实际项目之后的所谓改进项目而收集的。 这些改进项目对于一个机构而言非常重要，经常是没有它们就无利可图。换言之，改进项目 包含“真正的”需求，释放了真实的潜能。我可以想象得出有多少业务潜能隐藏在那些位于 “待命”列表的项目中。 如果需求太少，那么要想获得早期或初始的评估，或者对计划进行迭代，都将会是个挑 战。然而，事实是，需求终究会出现。在项目要结束的时候需求才出现，这会是传统项目面 对的最糟糕的情况。这种情况经常发生在虽然刚刚交付了第一个或主要的版本，而项目团队 却得继续为新版本工作时。最可能的情况是，团队所做的、所修补的是一开始没想到的事情。 作为结果，项目团队按照一张高级的想象的功能列表工作，这就为其他需求问题开了方 便之门—尤其是二义性和迟到的变更。需求太少是动态市场中的传统项目典型的情形。在动 态行业中，涉众的时间通常过于有限，所以讨论会必须是简短的，而且业务分析师无法给出 足够的时间来探究需求的细节—即使是那些在项目启动时最重要的需求。 敏捷项目不追求建立一个完美的需求集合，但你将看到这个模型在开发生命周期的初期 动态地吸纳新发现的重要需求的方法。作为结果，敏捷项目的计划将在项目的早期就能够包 含新识别的重要需求。 1.1.6 变更控制委员会  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍变更控制委员会。  标签：敏捷开发 敏捷项目管理 1.1.6 变更控制委员会 为了解决以传统方式管理项目带来的需求管理问题，机构建立起所谓的变更控制委员会 （Change Control Boards，CCB）。如这个名字所表明的那样，这是由一些将变更的发生控 制在项目范围内的人组成的。所谓变更可以是对现有需求的变更，也可以是在项目早期或后 期出现的新需求。这个委员会通常由几个战略项目团队成员组成（比如，项目经理、架构师、 主任业务分析师等），它按不同案例决定每个变更请求。CCB 讨论变更请求，提出行动计划并 进行投票表决。 变更控制委员会需要大量投资。变更控制委员会不仅需要组织召开会议，也需要抽出可 观的时间来准备会议（澄清变更请求、执行风险评估、获得当前范围的一致理解并执行管理 任务）并集中注意力完成会议。后一项任务需要对决策重新进行沟通并澄清在范围上的改变。 最可能的是，最初的决策将导致在项目团队内召开更详细的会议，并且可能会有出现突然的 会议讨论。 对于承认变更控制委员会的必要性的机构而言，这是其朝向采用更现代的工程过程所迈 出的第一步。这表明机构正在开始接受改变。不过，要决定变更控制委员会是应该每周开一 次还是每两周开一次会就能适应动态的要求，对开发人员和业务分析师来说都很难。我们将 在后续章节中讨论敏捷项目如何将变更控制机制直接集成到开发过程中，使之成为一种日常 活动的方法。  1.2 上市时间..............8 摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方法（也 称为瀑布法）的企业要面对的共同挑战。本节为大家介绍上市时间。  标签：敏捷开发 敏捷项目管理 1.2 上市时间 启动一个项目是对未来的投资。项目需要时间，也消耗资源，而且在大多数情况下项目 的主办方期望项目的回报能超过成本。换言之，应该把项目当成常规投资来看待。比如，IT 系统应该让信息传递得更快，而且必须非常善于自动实现缓慢的、手工的业务过程。对于任 何机构而言这是 IT 项目有巨大的投资潜力的原因之一。在识别了机会、确定投资数量之后， 项目就启动了。在理想世界中，项目得以执行，系统得以交付，我们收到了来自解决方案的 效益。实际上却没这么简单，因为每个项目都有风险。有一些风险十分基本并且显而易见， 对于本书其他部分所讨论的内容而言这些风险都是最基本的。所以，让我们来探究其中的一 些风险。 技术问题对解决方案所造成的瓶颈会比最初所期待的更严重。在业务案例中，期待的应 用程序性能可能要比估算的低 50%。在市场上部署这样的解决方案将让边际利润缩水，而更糟 糕的是，它可能起反作用。举个例子来说，考虑一个与新的证券交易系统有关的性能问题。 每秒执行的事务更少就意味着利润更少，顾客可能投向其他具有更好基础设施的券商来进行 他们的业务。围绕这个场景更大的问题是：“如果我们知道系统要慢 50%，那么这个项目还会 不会有人来做？”答案是可能不会。 大多数公司都有竞争，他们不是在其市场中孤军奋战。启动一个项目就会引入新的成本 中心。只有交付的项目才会对公司的价值有所增加，并且将公司带到一个独特的或更好的位 置上，也许能够赚更多的钱。不过，公司能收获效益的时间有限，因为竞争对手很快就会赶 上（见图 1-2）。 （点击查看大图）图 1-2 上市时间和时间有限的效益 我们假设有一家公司宣布了一种可以治疗特定病毒感染的药物。由于其市场价值的提升， 该公司的股价也许会飞涨。华尔街的银行家们买入的是未来，因为驱动股票价值的是这家公 司的潜力。现在，证明自己并把许诺的产品推向市场就是这家公司的责任了。随着项目一天 天延期，就可能被其他机构先拔头筹。赛跑从此开始了。 软件开发与此没太多区别，即使较大机构中的内部项目可能不存在与上述例子中相同明 显的竞争，但通常也不会预先对公众发布。而 IT 项目所作的斗争在于业务通常先于 IT。这是 自然的，但这却是一个挑战。因为我们可以看到，在内部，业务小组会与 IT 部门进行竞争。 让我们想象一下这种场景。一家机构通过让销售代表直接与客户一起工作的方式提供特 定服务与产品。然后，有位业务分析师发现顾客 80%的订单是周期性的并且是相同的。于是就 启动了一个 IT 项目，旨在将这个订购过程自动化并对其加速。实现现有业务过程的自动化是 软件项目的典型场景。做好了决定并分配了资金之后，就要为开发人员计时了。这些类型的 项目的问题在于，IT 项目一直都在追随业务的愿景而很少领先于业务。 随着 IT 项目的时间流逝，业务也在演化。最终所交付的完成的系统可能再也无法为业务 需要服务。比如，竞争对手也有相似的想法并且在项目开始之后不久就发布了一个相似的系 统。于是项目团队就不能忽略这样一个事实：这个项目在内部可能按照正确路线进行，但却 落后于市场时间表。 1.3 革新  摘要：《敏捷项目管理》第 1 章动机，本章从企业和管理的角度揭示使用传统开发方 法（也称为瀑布法）的企业要面对的共同挑战。本节为大家介绍革新。  标签：敏捷开发 敏捷项目管理 1.3 革新 2006 年，在线电影租赁公司 Netfix在 NPR 宣布，只要有人能将他们的电影推荐系统改进 至少 10%就给予 100 万美元的奖金。一年以后，到了 2007 年 11 月，仍旧没有人赢取这项现金 大奖。 从许多角度来看，将这样的奖励方法公之与众都是一家公司革新其业务的新的、独特的 手段。下面我们通过与按传统方式执行的项目作比较来看其如此创新的原因所在。 首先，这家公司承认公众在为 Netfix 的顾客推荐电影这项工作上可以做得更好。Netfix 也承认它自己无法解决这个问题，这是一个巨大的心理因素。想想有些公司在涉及知识产权 问题时的保护态度吧。这个例子所涉及的问题要比仅仅从顾客那里收集反馈和想法多得多。 这一比赛是要求提供解决某特定问题的聪明的方案。 其次，Netfix 采用了与开源开发类似的方法，而不是将解决方案外包给承包商。每个人 都得到了邀请，都能有所贡献，但有一个很大的不同：赢家将获得很慷慨的奖金。Netfix 使 用了全球工程师网络的力量来解决问题，而不是把自己限制在少数几个合作伙伴中。 再次，公司已经在内部对这个功能定了量—因推荐而实现 10%改进所增加的收入以及增加 的客户满意度足够支付这一大笔奖金。 最后但并非不重要的一点，这个示例也为竞争对手展示了 Netfix 致力于改进其系统中的 一个元素的决心以及所关注的顾客服务领域。有了这个声明，革新就转向公开。 作为回报，这个奖励为 Netfix 带来铺天盖地的宣传和争论，我相信这与整个比赛本身一 样有创意。甚至，从该公司开放的愿景和创新所吸引的人们中，公司可能获得新的业务机会。 革新需要创新，以及持续不断地对现有业务过程进行重新思考。可是能在现代业务过程 中应用的新技术可能仍旧在婴儿期。20 世纪，IT 在将企业内手工的、乏味的信息交换工作进 行自动化的同时，也培养了新一代的对 IT 系统有高度期待的专业人士。Netfix 的示例表明， 人们所探讨的正在从以技术为动机的开发转向以业务为动机的解决方案。 大多数机构依