《精益产品开发：原则、方法与实施》—敏捷实践体系

敏捷实践体系

实践上，迭代交付模式是敏捷开发的核心要素，它使更早交付和更灵活应对变化成为可能。然而，迭代交付模式与瀑布开发模式的区别，使很多过去可行的实践变得不再可行。

要落实敏捷开发方法，需要构建与之匹配的团队组织方式、开发管理方法和技术实践体系。例如，Scrum 提供了迭代管理和持续改进的框架，极限编程则奠定了早期敏捷开发技术实践的基础。在实施过程中，敏捷的实践体系不断完善，针对不同问题形成了较为完备的实践集。

•      如何管理迭代交付过程呢？对应的有 Scrum、特性驱动开发和极限编程中的管理实践等迭代管理框架。

｜  第 1 章

•      每个迭代交付什么？怎么规划？对应的有用户故事、用户故事地图和产品待办事项等敏捷需求实践。

•      怎样组织团队才能让他们直接面对用户的需求？对应的有跨功能、跨职能和自组织的敏捷团队组织方式。

•      如何在迭代模式下，更有效地组织需求澄清及验收过程？对应的实践有实例化需求、行为驱动开发或验收测试驱动开发等实践。^[5]

•      怎么应对持续增加的集成和回归测试？对应的实践有自动验收测试及持续集成等。

•      如何在迭代模式下保障设计的一致性和持续演进？对应的实践有代码共有、简单设计、测试驱动开发、持续重构和领域驱动设计等。

图 1-11 总结了敏捷实践以及它们要解决的问题，这并不是 终完整的实践列表，敏捷实践是在解决问题的过程中不断成长的。

图 1-11　敏捷实践及其应对的问题

我并没有把微服务架构、容器技术等 新的技术实践包含在内，是因为它们已经被 DevOps 的框架所容纳，后面介绍 DevOps 时还会提到它们。当然，你也可以把 DevOps 看成敏捷的延续或升级。重要的是不忘初心，记住敏捷的业务目标：更早地交付价值；更灵活地应对变化。

小结

相对作坊式的软件开发，传统软件开发方法进步明显，但也问题重重，更满足不了软件

从传统向敏捷软件开发的演进  ｜  业日益提高的对及早交付和灵活应变的要求；敏捷产品开发的业务目标是为了更早地交付价值和更灵活地响应变化，理解业务目标，让我们更容易达成一致的理解，也为针对性地实施具体敏捷实践提供了依据。

本章要点

•  传统的软件开发方法诞生于上世纪 60 年代末的软件危机，它借鉴了传统工程管理的思想和方法。

•  对传统开发方法的反思从未停止过，上世纪 90 年代各类轻量级软件开发方法开始形成，发布于 2001 年的《敏捷软件开发宣言》汇总了这些轻量级软件开发背后的价值观和原则。

•  敏捷开发的业务目标是更早地交付价值和更灵活地应对变化。

•  敏捷开发实践应该服务于业务目标。

常见问题

 问题：敏捷适用于所有组织吗？

^{(欧兰辉手绘)} 回答：敏捷首先是目标，而不是具体的方法。作为目标，提升组织及早交付价值和灵活应变的能力，这当然是正确的，也是所有组织想追求的。只不过，不同类型的组织对这一目标的迫切程度不一样。

如果从事移动互联网产品的开发，敏捷和迭代交付就是必然之选，是这个行业的基本模式。不这么做，你根本无法参与市场竞争。相对传统的行业，对敏捷的需求要弱一些，但趋势也十分明显。如电信设备提供商在全面云化和网络虚拟化的冲击下，不得不面对互联网厂商的竞争，因而应用敏捷开发实践的需求也越来越强烈；过去认为传统的金融行业，面临互联网金融的颠覆，就更不必多说了。

 问题：传统组织变得敏捷会有哪些困难，应该怎么做？

回答：使用传统开发方法的组织，其组织文化、团队结构、技术手段、流程工具还有考评和认可体系都会向传统方法优化，所以要想变得敏捷，会遇到各种问题。各个问题之间相互关联和牵扯会进一步放大问题，比如流程变了，考评和认可体系却没变，或者反之，都会造成组织无法运转顺畅。

｜  第 1 章另一方面，技术基础设施和遗留代码也可能成为变得更敏捷的障碍。这些从传统变得敏捷过程中遇到的问题，都会表现为敏捷的弱点，也是我们需要正视的问题。

实施敏捷很困难，这是一个事实。组织要想清楚要不要变得敏捷，对这个问题的肯定回答已经成为大部分组织的共识，因为它关系到组织的竞争力，甚至生死。如果变得更敏捷是组织的选择，那么接下来就是如何正确实施，正视和应对变革过程中的困难，并找到一条相对有效的和便捷的变革路径。我们在本书第 II 部分和第 III 部分讲的精益方法和实施，可以为实现敏捷变革提供一个有效的路径。

注释

1.        严格来说，PMP 相关的方法并非软件产品开发方法，它的适用范围是所有工程项目，但 PMI 的项目管理知识体系在 IT 和软件开发项目中被广泛采用，是相当一部分 IT 项目管理的基础。

2.        参见 http://t.cn/RMCHhyo。

3.        参见 http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf。

4.        参见 http://agilemanifesto.org/。

5.        实例化需求、行为驱动开发以及验收测试驱动开发所解决的问题以及实践都非常类似，有时被认为是同一实践的不同名称，只不过强调的方面各有侧重。比如，实例化需求偏向于强调用实例沟通澄清需求的过程，而验收测试驱动开发，偏向于强调完整的操作流程和协作方式。