敏捷项目管理简介
敏捷技术萌芽的产生已经有很长一段时间。事实上，敏捷价值观、原则和实践只是对常识的汇编。图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，但如果我在左前轮装上马车轮，那么如何才能让我的车和其他特斯拉跑得一样快速和高效？”答案当然是不可能。但如果你全盘采纳敏捷方法，项目成功的可能性更大。