我的敏捷历程 —— 兼评《敏捷整洁之道 - 回归本源》

我个人最早接触敏捷是在上大学时，在《程序员》杂志上看到一本书——《解析极限编程》——的推介。当时我只是“幼稚”的从字面意思去理解：极限编程就是一种新式的编程方法（其实这么说也没错，对了一半）。

工作后，非常幸运，所在团队的 leader 对敏捷开发推崇备至。在技术层面，单元测试、*结对编程*是我们在工作中最常采用的两项敏捷实践，在项目管理层面，我们并没有采用任何敏捷实践（我有点记不清了）。过了一段时间，团队 leader 在某次技术大会上接触到了 Scrum 且被成功洗脑（他原话 😁）。之后，我们团队就走上了实践 Scrum 的康庄大道。Product backlog、Sprint 、站立会议、燃尽图 、计划扑克、演示会议 、回顾会议 被我们“玩”的风生水起。我有幸被 Leader 指定为 Scrum Master，但不幸的是，我对 Scrum Master 的理解太肤浅，导致自己最后变成了“站立会议 Master”😂。这个阶段的敏捷实践加深了我对敏捷开发的认知，变成了敏捷开发的坚定拥趸。

之后，我进入第二家公司，试图将敏捷开发的理念带入团队。但，无果。

而后，我进入第三家公司，并成为一个小型团队的 Leader。推进团队敏捷转型便成了水到渠成之事。在团队内，我主要的推动实践是 Scrum，而想要推行 Scrum ，必然对技术团队的合作方——QA 团队、PM 团队——有影响，那……就拉他们一起转型，当时真是以无所畏惧的心态“强推” Scrum。结果是，我们做的不错！整个节奏理顺并运行起来之后，我们只要按照节拍来进行就好，到了某个时间节点该做什么都按照 Scrum 框架的设定来进行，有了一点点自组织团队的味道。当时，在我的脑袋里有一个极端的念头：只有敏捷才是项目管理的唯一正确方法。

现在，我逐步放弃了“唯敏捷正确”的观点。我观察在传统瀑布模式下，团队成员依然可以很快速的开发和交付。

我反思自己这些年的敏捷经历，得出一个小小的结论：没有敏捷技术内核的敏捷过程，只是一种表象的敏捷。这句话怎么理解？简单说 Scrum + XP 才是完整的敏捷，只推进 Scrum，而不采用诸如 TDD、持续集成、结对编程等技术实践，敏捷会慢慢陷入一种僵化状态——会有大量的技术相关的 Story，可能还会有大的技术重构——这些其实严格意义上讲，都是不应该出现的。

最近读到的一本书，其主旨与我上述的想法不谋而合（其实是我自己领悟的太晚，这本该就是敏捷的本意😂）。

《Clean Agile - Back to Basics》中文名为《敏捷整洁之道 - 回归本源》，从本书的命名上就可看出这是 Bob 大叔 Clean 系列的新作品（这个系列的其他几本书我也读过），书中提到的敏捷的价值观、方法论大多我都耳熟能详，有些甚至烂熟于心。但还是不乏振聋发聩之声，记录如下。

第一点，敏捷的定位。书中写道：敏捷是帮助小型软件团队管理小型项目的一个小型行为准则。并且，作者对大型组织中的敏捷持完全否定的态度：根本没有所谓的大规模敏捷。对于大型团队，作者建议先将其拆分为小团队，之后在小团队上应用敏捷，最后再用业已成熟的方式把这些小团队组织起来就可以完成大规模敏捷。干大事靠的不是大团队，而是靠若干解决小问题的小团队之间的协作。

第二，生命之环 Circle of Life 。生命之环由外、中、内三层环构成，描述了完整的敏捷本质及核心。外层环展示了面向业务的实践，实际上相当于 Scrum 流程。这些实践为软件开发团队与业务沟通的方式以及业务和开发团队管理项目的原则提供了框架。这些实践包括：计划游戏 Planning Game、小步发布 Small Release、验收测试 Acceptance Tests、完整团队 Whole Team；中层环是面向团队的实践，这些实践提供了开发团队在团队内进行沟通和管理的框架和原则。这些实践包括：可持续节奏 Sustainable Pace 、 代码集体所有 Collective Ownership 、 持续集成 Continuous Integration 、 隐喻 Metaphor；内层环是技术实践，用以指导和约束程序员，来确保得到最高的技术质量。这些实践包括：结对 Pairing 、 简单设计 Simple Design 、 重构 Refactoring 、 测试驱动开发 Test Driven Development ; 在作者眼中，生命之环所代表的的极限编程就是敏捷本质核心的原型，也是最好的代表。生命之环也与我在前面提到的自己的经验总结是一致的。

第三，关于交付日期。作者写道：交付日期的选择都是出于重要的商业理由，交付日期一旦选定就将被冻结，谈判交付日期没有意义。在这点上，我个人是受到一些启发的：实际工作中，技术团队很讨厌 PM 给出需求后“顺手”敲定一个所谓的“上线日期”，研发同学会对这个日期做出强烈反应，会感受到被冒犯，因为这个上线日期可能会极大的压缩研发同学的开发时间，导致时间过紧、压力过大、加班严重、身体疲劳等等一系列问题。所以，除非老板高压，通常上线日期是根据整个研发周期来确定的。作者对锁定交付日期的肯定态度给我一点启发：如果 PM 提出的上线日期是有商业理由的，是有业务价值的，那这个日期是可以进行讨论甚至可以锁定的。

第四，项目管理铁十字。软件项目的基本原理由质量、速度、成本、完成四要素来构成，在实际工作中，只能同时满足任意 3 个元素，没办法 4 个元素全要。优秀的项目经理理解这 4 个属性是共同作用的且会推动一个项目变得足够高质量、快速、低成本，尽量按需完成。

其实，虽然我司市值在中国互联网在前三名内，但在我司肉眼可见的范围内，大范围采用敏捷实践的团队少之又少。但站会会议、单元测试、重构、持续集成等技术，已突破敏捷的范畴作为单独的技术实践被很多团队采用。我相信，会有更多敏捷实践逐步被采纳，而最终，所有的开发团队都将是敏捷团队。