下载掌阅APP，畅读海量书库
立即打开
本章内容要点：
▶ 理解为何项目管理需要变革；
▶ 理解敏捷项目管理如何变为敏捷产品管理；
▶ 了解有关敏捷产品开发的内容。
敏捷描述的是一种项目管理的思维方法，该方法聚焦于商业价值的尽早交付、产品和产品开发流程的持续改进、范围的灵活性、团队的投入，以及能反映客户需求且经过充分测试的产品交付。
在本章，你将了解敏捷流程为何在20世纪90年代中期作为一种软件开发的项目管理方法而出现，以及为何敏捷方法论吸引了项目经理、投资于新产品和服务开发的客户以及投资于产品开发的公司高管层的注意力。尽管业务敏捷在软件产品的开发上很流行，但是敏捷价值、原则和技术实际上可以应用于许多行业和领域，而不仅仅是软件行业。本章也解释了敏捷方法论超越项目管理传统方法的优势。
项目需要事先规划，在定好的时间、工作量和计划下去完成它。项目有其目的和目标，并且通常必须在限定的时间和预算内完成。
如果你正在阅读本书，那么你可能是项目经理、项目发起人、项目团队成员，或者在某些方面受项目影响的人。
敏捷方法是对项目管理现代化需求的一种响应。为了理解敏捷方法如何革新产品开发，你有必要了解一些项目管理的历史和作用，以及当前项目遇到的问题。
项目自古以来就广泛存在。从中国的长城到蒂卡尔的玛雅金字塔，从印刷术的发明到互联网的出现，人们通过各种项目取得了或大或小的成就。
众所周知，项目管理作为一门正式的学科出现于20世纪中期。在第二次世界大战前后，全世界的研究人员在计算机制造和编程领域取得了巨大进展。为了完成这些项目，他们开始建立正式的项目管理流程。第一个流程是以美国军方在第二次世界大战中使用的逐步制造模型为基础。
人们在计算领域采用这种逐步制造流程是由于早期与计算机相关的项目严重依赖于硬件，当时的计算机体积庞大，足以塞满一整间屋子。相对而言，软件在整个计算机项目中只是很小的一部分。在20世纪40至50年代，计算机可能装有数千枚真空管，但只有不到30行的程序代码。20世纪40年代，在这些最初的计算机上使用的制造过程是众所周知的瀑布式项目管理方法论的基础。
1970年，一位名叫温斯顿·罗伊斯（Winston Royce）的计算机科学家为电气与电子工程师学会（IEEE）写了一篇名为《管理大型软件系统的开发》（Managing the Development of Large Software Systems）的论文，描述了瀑布式方法论的阶段划分。术语“瀑布”是后来被命名的，尽管有时阶段名称的叫法不同，但本质上和罗伊斯最初的定义是差不多的：
（1）需求；
（2）设计；
（3）开发；
（4）集成；
（5）测试；
（6）部署。
在瀑布式项目中，只有在前一个阶段完成之后，你才能进入下一个阶段——因此它被形象地取名为“瀑布”。
这叫技术支持
纯粹的瀑布式项目管理（也就是在开始下一步之前必须完成上一步）实际上是对罗伊斯建议的误解。罗伊斯其实已经认识到这种方法的内在风险，并建议在多次迭代中进行开发和测试，以创建产品。但该建议被很多采用瀑布式方法论的组织所忽视。
在2008年被基于敏捷技术的改进方法超越之前，瀑布式方法论是软件开发领域中最常用的项目管理方法。
自20世纪以来，计算机技术已经发生了巨大的变化。许多人手腕上就有一台“计算机”，比起人们刚开始应用瀑布式方法论时所使用的最大、最昂贵的机器，这台“计算机”具有更强大的功能、内存和性能。
同时，使用计算机的人也发生了变化。人们为普通大众生产了硬件和软件，而不是只为少数研究人员和军方生产只有最少量程序的如庞然大物般的机器。在许多国家，几乎所有人每天都在使用平板电脑或者智能手机。软件应用于我们的汽车、家用电器和住房中，提供给我们日常的信息和娱乐。甚至幼儿都在使用计算机——我朋友两岁大的女儿使用智能手机几乎比她父母更熟练。人们对于更新、更好的软件产品的追求是永恒的。
不知何故，当所有的技术都在发展的时候，唯独流程依旧停滞不前。软件开发者仍在使用20世纪50年代以来的项目管理方法论，而这些方法源自20世纪中期以硬件为主的计算机制造流程。
当今，传统型项目的成功总会遭遇范围膨胀的问题，即在项目中引入了不必要的产品特性。看看你每天使用的软件产品吧。比如，我们现在正在打字的字处理程序就具有很多特性和工具。即便我们每天都在用该程序进行写作，也只是使用其中一小部分特性。程序中有相当多的工具我们从未使用过，也没想过要用，我们甚至不知道还有其他人曾使用过它们。这些很少有人使用的特性就是范围膨胀的结果。
范围膨胀出现在所有类型的软件中，从复杂的企业应用到每个人都在使用的网站。如图1-1所示，斯坦迪什集团的研究表明，范围膨胀是普遍存在的，有80%被要求开发的特性不经常或从未被使用过。
图1-1中的数字显示了时间和金钱的巨大浪费。这种浪费是传统项目管理流程不能适应变化的直接后果。项目经理和干系人知道项目中期的变更不受欢迎，因此，项目初期是他们获得潜在所需特性的最佳时机，所以他们要求：
>>他们所需要的一切；
>>他们认为他们可能需要的一切；
>>他们想要的一切；
>>他们认为他们可能想要的一切。
图1-1显示的统计数据就是产品特性膨胀的最后结果。
图1-1实际使用到的被要求开发的软件特性
资料来源：斯坦迪什集团，2017
软件项目的成功与失败
软件行业遭遇了传统项目管理方法论的发展停滞。2015年，一家名为斯坦迪什集团的软件统计公司针对美国10 000个项目的成功率与失败率做了一项研究，研究结果如下。
●29%的传统项目彻底失败。这些项目在完成前被终止，且在产品交付上没有任何结果。总之，这些项目没有交付任何价值。
●60%的传统项目面临挑战。这些项目虽然完成了，但是实际的成本、时间、质量或这些要素的综合与期望存在差距。项目在时间、成本和未交付的产品特性上的实际结果与期望值的平均差距远超过100%。
●11%的项目是成功的。这些项目按最初期望的时间和预算完成，并交付了所期望的产品。
在美国，仅花费在产品开发上的数千亿美元中，就有数十亿美元被浪费在未能部署任何功能的项目上。
使用过时的管理和开发方法所导致的问题并非无足轻重。因为这些问题，每年要浪费数十亿美元。2015年，因为项目失败所导致的损失达数十亿美元，这相当于世界上数百万份工作的损失。
在过去的30年中，人们在项目工作中已经意识到传统项目管理日益增长的问题，并着手建立更好的模型。
敏捷技术萌芽的产生已经有很长一段时间。事实上，敏捷价值观、原则和实践只是对常识的汇编。图1-2展示了敏捷项目管理的历史，最早可以回溯至20世纪30年代沃尔特·休哈特（Walter Sherwart）在项目质量方面的计划—执行—学习—行动（PDSA）方法。
1986年，竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在《哈佛商业评论》（Harvard Business Review）上发表了一篇名为《新的新产品开发游戏》（The New New Product Development Game）的文章，竹内弘高和野中郁次郎在文章中描述了一种快速、灵活的开发策略，以满足快速变更的产品需求。该文章第一次将Scrum这个术语与产品开发相关联（Scrum指的是英式橄榄球中的球员队形）。Scrum逐渐演变成旨在向客户交付价值的最常用的敏捷框架之一。
2001年，一组软件和项目专家聚在一起讨论他们项目成功的相通之处。该小组创建了敏捷软件开发宣言（通常称为敏捷宣言），一份对成功的软件开发所需的价值观的声明。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观：
个体和互动高于流程和工具；
可工作的软件高于详尽的文档；
客户合作高于合同谈判；
响应变化高于遵循计划。
也就是说，尽管右项有其价值，但我们更重视左项的价值。
*敏捷宣言Copyright ® 2001：肯特·贝克（Kent Beck）、迈克·毕多（Mike Beedle）、阿利·冯·贝纳昆（Arie van Bennekum）、阿利斯泰·科克伯恩（Alistair Cockburn）、沃德·坎宁安（Ward Cunningham）、马丁·福勒（Martin Fowler）、詹姆斯·格兰宁（James Grenning）、吉姆·海史密斯（Jim Highsmisth）、安德烈·亨特（Andrew Hunt）、龙·杰弗里斯（Ron Jeffries）、乔恩·科恩（Jon Kern）、布莱恩·马里克（Brian Marick）、罗伯特·C·马丁（Robert C. Martin）、史蒂夫·梅洛（Steve Mellor）、肯·施瓦伯（Ken Schwaber）、杰夫·萨瑟兰（Jeff Sutherland）、戴夫·托马斯（Dave Thomas）。
此宣言可以任何形式被自由地复制，但其全文必须包含上述声明在内。
图1-2敏捷项目管理时间线
这些专家创建了敏捷12条原则，用于支持敏捷宣言所倡导的价值观。我们将在第2章列出这些原则并更加详细地描述敏捷宣言。
敏捷作为产品开发的术语，是对聚焦于人、沟通、产品和灵活性的方法的一种描述。如果你刻意去找敏捷方法，那么你是找不到的。但是所有有助于实现敏捷的方法（如水晶方法）、框架（如Scrum）、技术（如用户故事需求）和工具（如相对估算），它们都具有一个共同点：遵循敏捷宣言和敏捷12条原则。
小贴士大用途
敏捷宣言的签署者之一马丁·福勒（Martin Fowler）写道，他们曾讨论过许多词语来命名这场变革，例如轻量级法、适应法以及其他表达，直到最终决定将“敏捷”作为他们所追求的对变化的适应性和响应性的最佳描述词。
其他的同义词还有韧性、灵活和健康。谈及敏捷，我们就会想到健康。健康的组织和团队亦是敏捷的、有韧性的、灵活的以及响应迅速的。
敏捷方法基于经验型控制法——一种根据项目中的现实观测而做出决策的流程。在软件开发方法论的环境下，经验型控制法对开发新产品、优化和升级项目是有效的。在对最新工作成果进行频繁且直接的检查时，如有必要，你可以做出快速调整。
>>充分透明：每一位敏捷项目成员都知道即将做什么以及项目进展如何。
>>经常检查：投资于产品和流程的人应该定期评估该产品和流程。
>>即时调整：对细小问题做出快速调整，如果检查表明你应当做出改变，那么你要立即改变。
为了适应频繁的检查和即时调整，敏捷项目按照迭代的方式（把整个项目分解成更小的片段）运作。敏捷产品开发涉及的工作类型与传统瀑布型项目相同：创建需求和产品设计、开发产品特性、记录已完成的特性和原因、持续集成新的特性。你要测试该产品、修复存在的问题，并部署产品以供使用。然而，你无须像瀑布型项目那样，要为所有产品特性一次性完成这些步骤，相反，你需要把项目分割成多个迭代，迭代也称为冲刺（Sprint）。
图1-3展示了线性瀑布式项目和敏捷项目的区别。
图1-3瀑布与敏捷项目对比
不开玩笑！危险！
把传统项目管理方法和敏捷方法进行混合使用，就好比在说：“我有一辆特斯拉Model S，但如果我在左前轮装上马车轮，那么如何才能让我的车和其他特斯拉跑得一样快速和高效？”答案当然是不可能。但如果你全盘采纳敏捷方法，项目成功的可能性更大。
按照定义，传统项目是指为实现商业论证中计划的特定收益而进行的临时性的团队工作。项目启动是我们对项目了解最少的阶段，然而它却是要确定项目预算、进度计划和预期价值的阶段。当项目结束时，项目团队解散，对项目不熟悉的运营团队被留下来支持客户和产品。如果还有额外的工作需要完成，则需要启动新的项目，组建新的团队，并且他们必须重新熟悉产品架构。项目通常在可交付物投入生产后结束，由其他团队对后续运营工作提供支持并评估项目对业务的影响。
如今，产品被认为是长期性的、创造价值的资产，需要永久性团队以迭代的方式对其进行细化、设计、开发、测试、集成、归档、支持，直到实现商业成果。一个高绩效团队要不断检查和调整产品，直到客户的问题得到解决。此外，团队还会保存来之不易的产品开发知识。团队和客户合作创造价值要高于遵循书面的规定。
我们越来越意识到项目驱动的方法限制了对客户价值的尽早和经常交付。然而，当采用敏捷方法进行产品开发时，你会专注于价值的交付而非对进度和成本的严格监控。当组织根据以下公式决定何时转变优先级时，能最有效地交付价值：
AC+OC>V，即实际成本+机会成本>价值
当开发产品额外需求的实际成本与未开发其他投资机会的机会成本之和超过剩余产品需求的预期交付价值时，开发团队需要转向开发更有价值的投资机会。
管理项目和开发产品之间存在三个主要的区别：
>>产品从稳定的、长期的甚至永久性团队中受益最多。
>>产品不仅可以是短期资产，还可以是长期资产。活跃的产品从未真正完成，因为它们需要维护和改进。
>>产品是项目组合的一部分，旨在实现价值的最大化，而不是遵循规范。
永久性团队优于临时性团队
生命周期长的产品最好是由长期的甚至永久性团队进行开发和维护。团队在一起迭代开发新架构并且提升能力和绩效的时间越长，团队就越能理解客户需求，对团队的可预测性就会变得更强。聚焦于项目的团队在特定的一段时间内聚在一起工作，项目结束后，就各自奔向新的项目。当项目结束时，团队总结的经验教训可能不适用于下一个项目，因为人员、技术和客户极有可能是不同的。稳固的永久性团队能够实现信息透明、自我检查和自我调整（经验过程控制）。
小贴士大用途
永久性并不意味着敏捷产品团队不会改变，团队成员的职业抱负受到限制。然而，团队中的人事变更确实是一个特例而非惯例。那些因个人能力提升而变得更有价值的团队成员，会获得职业发展的机会。理想情况下，永久性团队成员表现得更像一个家庭，而不是一个只针对一个项目的、临时的团队。
产品是长期的资产而非项目可交付物
产品开发是有风险的，因为不确定性因素无处不在。但正是不确性因素才使得敏捷产品开发成为理想的方法。传统项目的任务是在固定的时间期限内完成特定的系统可交付物，然而敏捷产品开发是通过构建可使用的、功能完善的产品增量，并在产品开发过程中不断收集和实现客户反馈来不断迭代，以减少不确定性因素。这样，产品就成了对标客户需求、解决问题的资产。活跃的产品从未完成，因为它们必须被加以维护和改进。
在时间、金钱和人员上的投资，特别是在当下资本支出的策略下，可以将产品转化为既能提高营收又能节约成本的可折旧资产。将产品开发看作是资产创造而非成本支出，可以转变人们的观点。通过敏捷产品开发持续交付客户价值，增加了获得额外资金的可能性。
这叫技术支持
资本支出（通常被称为“CapEX”）是指公司用于购买、升级和维护实物资产（如房产、建筑、工厂、技术和设备）的资金。CapEX通常被用于开展公司的新项目或投资。
追求价值高于遵循规范
早期失败是敏捷的主要特征。敏捷团队热衷于通过冒险来创造客户价值。就像科学家一样，他们提出一个假设，在真实的世界中进行测验、评估结果，然后调整假设并再次测验。他们一遍又一遍地重复这个过程，每次迭代都使产品更接近客户的需求。敏捷团队不再遵循大量文档化的规范，而是力求获得客户的真实反馈。在敏捷产品开发中，产品功能的优先级是由对要解决的问题最熟悉的人决定的。
在本书中，你将看到敏捷产品开发如何比传统方法运作得更好。敏捷方法能够创造出更成功的产品。在前面专栏“软件项目的成功与失败”中，我们提到斯坦迪什集团做过一项研究，该研究发现尽管29%的传统项目彻底失败，但是采用了敏捷方法后，这个数据下降到只有9%。敏捷产品开发失败率下降的原因是敏捷团队在频繁地检查进展和客户满意度的基础上对产品进行即时的调整。
下面是敏捷产品开发方法优于传统项目管理方法的一些关键之处。
>>项目成功率：在本书第17章，你将了解为什么在敏捷产品开发中，项目的灾难性失败风险几乎能降低至零。通过对商业价值和风险进行优先级排序，敏捷方法能在早期便确定项目是成功的还是失败的。敏捷方法中对产品开发的全程测试能帮助你尽早发现问题，而不是在花费了大量的时间和金钱之后再去发现问题。
>>范围蔓延：在第9章、第10章和第14章，你将看到敏捷方法如何在产品开发的全程中适应变化，把范围蔓延的可能性降至最低。按照敏捷原则，你能在每次冲刺开始的时候增加新的需求，而不需要干扰开发流程。通过全面地开发高优先级的特性，你能阻止范围蔓延威胁到关键的功能。
>>检查和调整：在第12章和第16章，你将详细了解在敏捷产品开发的过程中如何定期检查和调整工作。通过从完整的开发周期和交付可工作的功能中获得频繁的反馈，敏捷产品开发团队能够在每个冲刺中改进他们的流程和产品。
透过本书的许多章节，你将知晓业务敏捷性如何帮助你获得对产品成果的控制。尽早并经常测试，根据需要调整优先级，使用更好的沟通技术，定期演示并发布产品功能，如果你能做到这些，就能够对各种因素进行微调控制。