让敏捷回归本源——读《敏捷整洁之道》有感

两天时间一口气读完Robert C. Martin大师的新作（2020年7月出版）《敏捷整洁之道》，最直观的感受是大师对于敏捷的乱象（软件行业，也许不仅仅是软件行业，对于敏捷乱七八糟的解读和实践）终于看不下去了，出手写了这本书，让敏捷回归本源，清清楚楚的解释了敏捷到底是什么，以及我们应该如何去实践敏捷。

 

1. 如何理解《敏捷宣言》

提到敏捷，很多人想到的，或者可以说出来的，是“敏捷宣言”。”敏捷宣言“是对于敏捷言简意赅的概括，是一种价值观。大师在本书开篇第一章阐述了“敏捷宣言”的产生：当年17位大师齐聚雪鸟，他们具有多年软件行业的开发经验，历经了各种成功交付或失败交付的项目洗礼，他们将自己多年的经验进行沉淀，历时两天讨论，对于如何更快更高质量交付符合客户需求的软件，总结了软件开发的核心规律，最终提出了“敏捷宣言”。

"敏捷宣言“不是停留在纸面上的，如果我们要去实践敏捷，需要理解”敏捷宣言“背后更深层次的内容。大师在1.3.1 讲解了项目管理的”铁十字“，“即质量、速度、成本、完成，你只能任选3个，没法4个全要，也就是可以要求高质量、快速、低成本，这样的话项目就做不完。也可以要求低成本、快速地完成项目，那样的话，质量一定不会好。”

我想，凡是管过软件项目的同学，一定会深深的认同大师的总结，我看完这句话时，心里就在说“太对了”。每次带项目，或者看别人的项目，都是在这四方面做权衡。因为不愿意再权衡，我们把四个全要的期望寄托于“敏捷”，希望敏捷是可以实现这四方面的良药，一剂下去，奇迹发生，项目可以低成本、快速地、高质量地按时交付。大师一针见血的提出，“敏捷是一个框架，帮助开发人员和管理人员进行务实的项目管理，但是这种管理不是自动的，并不能保证经理做出恰当的决定，即使在敏捷框架内，也完全有可能错误地将管理项目并将其推向失败。”

2. 敏捷全貌的一般规则

1）团队速率：开发团队每周完成的工作量，度量单位是“故事点数”。

2）燃尽图：显示了在下一个主要里程碑之前还剩下多少故事点数。

3）冻结的交付日期：交付日期一旦选定就将被冻结，因为交付日期的选择是出于重要的商业理由。

4）瀑布开发模式：分析问题，设计解决方案，按照设计实现。这也许是对的，但是并不再适合目前复杂的软件开发。

5）敏捷开发模式：敏捷项目始于分析，但分析永远不会结束。项目从开始到结束的每一次迭代，都会包含分析、设计和实现。

6）速率的获取：经过四到五次迭代后，我们会发现“一个迭代可以完成多少故事”的数据虽然在每次迭代都不同，但是平均来说会处于相对稳定的速率，以此可以更好地判断何时能完成项目。

7）敏捷产生数据：敏捷产生数据，管理者们使用这些数据来推动项目达到尽可能好的结果。

8）再回到管理铁十字：调整范围是唯一可以做的事。

 3. 敏捷本质的核心——生命之环

大师在这本书中，选择极限编程的实践来讲解敏捷，他认为在所有敏捷过程中，极限编程是定义的最好、最完整、最不混乱的。生命之环是罗恩、杰弗里斯描述极限编程实践的一幅图，如下图所示：

1. 面向业务的实践：开发和业务沟通的方式和开发管理项目的原则

• 计划游戏：如何将项目分解为特性、故事和任务
• 小步发布：团队以小块的方式开展工作
• 验收测试：为特性、故事和任务提供“完成”的定义，向团队展示了如何制定明确的完成标准
• 完整团队：软件开发团队由许多不同的职能人员组成，包括程序员、测试人员和管理人员，他们都朝着同一个目标一起工作。

 2. 面向团队的实践：提供了开发团队在团队内进行沟通和管理的框架和原则

• 可持续的节奏：可以防止开发团队在完成任务之前过快地消耗资源和精力
• 代码集体所有：确保团队不会将项目分割成一堆知识孤岛
• 持续集成：使团队专注于频繁地进行反馈闭环，以随时了解他们目前的进展
• 隐喻：创造并传播关于待开发系统的词汇和语音，以便团队和业务部门进行交流使用

3. 技术实践：指导和约束程序员，来确保得到最高的技术质量

• 结对：使技术团队技术分享知识、及时审查和实时协作，推动团队不断创新并保持正确性
• 简单设计：指导团队避免精力浪费的实践
• 重构：鼓励对所有工件进行持续的改进和完善
• 测试驱动开发：技术团队在快速推进的同时得以保持最高质量的安全绳

这本书后面的每个章节都对以上实践进行了详细的讲解。在此，不过多的赘述。

4. 大型组织中的敏捷

大师在书中多处强调“敏捷是帮助小型团队管理小型项目的一个小型行为准则。”，敏捷是为中小型团队服务的，对于中小型团队，敏捷很有效。那么大型组织中实施敏捷怎么办？

目前有不少针对大规模敏捷的框架，SAFe，LeSS， Scrum of Scrum等等，大师表示没有实施过，也没办法评论。但是他明确了大型团队的问题是所有社会、所有文明共同的问题，而且从我们现在的文明来看，这个问题似乎解决的不错。如何组织大型团队的答案就是将开发人员组织成小型敏捷团队，然后运用标准的管理和运筹学技术来管理这些团队，不需要特殊的规则。

去年学习了SAFe，也参加了相关的workshop，对SAFe有一些了解。相比较于Scrum，SAFe框架定义了一些规则和活动，比如PI planning, SOS，来协调Scrum团队的活动。另外，SAFe框架吸取了精益思想，建议企业从业务价值流出发，通过梳理价值流，确定敏捷发布火车。这些都是统筹计划，正如大师所说，大规模敏捷是在使用敏捷解决了小型开发团队的问题，利用科学管理来解决。

5. 软件工艺

书中翻译成匠艺，不过我更喜欢用工艺这个词语。大师在书中详细讲解了"生命之环”的各个实践，强调实施敏捷的开发团队，除了应用spring planning, 站会，看板这些实践外，需要重视软件工程实践，如TDD，重构，结对编程，持续集成等等，因为“能够一天多次向生产环境部署软件，同时又不影响系统的整体稳定性，团队需要掌握极其高超的技术与工程实践”。

本书如清晨的一缕阳光，拨开混沌的敏捷迷雾，将敏捷的本源阐述的清清楚楚，回归敏捷的本质和初衷——向客户尽快交付可以工作的软件。为了达到这个目标，软件开发团队要知道敏捷运行的规则（拆分用户故事，估算，燃尽图，站会，看板等等），更重要的是开发人员需要运用工程实践，为自己的代码负责，为开发的软件负责，这才是真正实践了敏捷。