在国内做咨询的这段时间里，前后帮助三个客户，在数十个团队做敏捷转型。在这个过程中，见到了不同思想的团队Leader，也遇到了能力参差不齐的团队成员，他们都面临着共同的问题：一方面有着自上而下的压力，却缺乏视野和自学能力，不知道自己究竟应该做什么；另一方面，敏捷的定义模糊且众说纷纭，自己又缺乏自主的独立思考能力，对怎么才算敏捷转型成功充满疑惑。

在被客户无数次的问及以上问题后，我自己也感到疑惑，因为即使在ThoughtWorks内部，这也没有标准答案，甚至我在面对不同客户时，会根据当前的目标产生不同的答案。因此我一直在不断思考一个问题：当下一个客户再问我类似问题的时候，我能不能有一个更明确，更体系化的答案。在和工作在各业务的同事交流后，我得到了一些答案，在此先做一些整理，分享给大家，期望引发后续的讨论。

团队敏捷转型的三个阶段

我们假设，敏捷转型的开始是瀑布式开发，我把这个阶段定义为Agile 0，根据我们的敏捷成熟度模型（AMM）里提及的最终形态定义为Agile 5，期间会经历三个阶段。

阶段一（Agile 0 - 1）：建立敏捷流程，缩短交付周期

这个阶段，引入迭代或者建立看板是重点，类似于下图：

（Scrum运作全景图）

这个阶段的主要目标，就是将需求的反馈、开发质量的反馈、以及改进周期缩短在一个迭代内（通常2-4周）。 为达到目的，Coach主要会做以下一些事（Actions）：

• 培训 - 给团队培训敏捷流程、各角色的职责，以及各种工具的使用（比如Jira）。
• 现场指导 - 先带领团队走完整的敏捷流程，通常会有几个迭代；然后观察团队自己执行流程，并帮助团队改进；最后不再参与这类活动。
• 需求梳理 - 指导PO和BA建立需求全景图（比如Story Map）、拆分Story、排优先级、和团队其他成员协作等；制定Story编写规范，Story价值流和建立Story看板。

这个阶段主要培养的目标，是Scrum Master或者类似的角色，让他们能了解敏捷流程的运作方式，并能带领团队在Coach不在场的情况下，依然按敏捷流程运作。

要走过这个阶段，有一些关键指标：

• 交付周期 <= 3周：如果是迭代开发，则应该每个迭代小于3周，并且每个迭代都Release；如果是用Kanban，则Story的Lead Time应该小于3周。
• 上线的已知缺陷数 = 0：有些企业会给缺陷分级，只要求把高优先级的修复，但是我们推动敏捷，要求质量不可妥协，因此需要转变客户的想法，让客户把缺陷修复放到高优先级。
• Finish Rate / WIP：如果是迭代开发，为了改变瀑布式开发硬塞需求的习惯，一定要控制Finish Rate大于80%。如果是看板，那就要控制到WIP，让每个人专注于一件事的完成。

有些人说为什么不从技术实践开始？设想一下在瀑布式开发中，开发团队几周甚至一个月才交一次版本给测试团队，在这种情况下，开发怎么会有动力写自动化测试？运维怎么会有动力做自动部署？需求没有妥协的空间，设计没有妥协的空间，导致团队的痛点永远是按时交付，质量一定会被牺牲掉的。因此只有先强制缩短交付周期，让团队痛点转移，才能改变开发人员对质量的观念。至于这个过程中导致的交付速率降低，我们会说：

• 在敏捷转型前期一定是有所付出的，然而你投入越多，进展就会越快，收益就会来的越早。
• 没有质量的交付不能称为完成，只能叫半成品或者次品。

由此我们来讨论第二阶段

阶段二（Agile 1 - 3）：引入技术实践，质量内建，减少返工

这个阶段的主要目标，是提升开发人员的质量意识，从而提升开发阶段产出的质量水平，减少后续环节的返工。用质量内建的话来说，在缺陷时就立刻修复。这样做的好处就是同时提高了质量和团队整体效率。 其实在软件开发中，生产过程随着开发结束而结束，随之而来的都是检查和传递，因此产品的质量实际是由开发阶段就确定的，如下图：

（Story的生命周期）

只有提升生产过程的质量，才能减少返工，提高效率，因此我们在这个阶段会引入技术实践，缩短质量验证的反馈周期，主要包括：

• 单元测试：单元测试的反馈周期最快，也在测试金字塔的最底层。要求开发人员编写单元测试，一方面可以提升开发人员的代码设计能力，提升代码质量，另一方面可以提升开发人员的质量主人翁意识，让开发阶段的交付物质量有所提高。
• 集成测试：包括API测试和组建测试、契约测试等。这依然是要求开发人员来编写，提高开发人员的能力和意识。
• UI自动化测试：如果是带页面的项目，这个阶段通常都会引入UI测试，一般会要求测试人员编写，这个阶段的主要作用是帮助团队提高回归测试的效率。
• CI：通过CI服务器，将以上测试定期运行，并可视化报告，让所有团队看到。同时要求团队第一时间修复CI。
• CD Pipeline：建立自动部署流水线到生产环境，并集成冒烟测试，E2E测试等自动化测试，同时实现回滚。
• Git：建立使用Git的规范，建立分支策略或者指导客户做纯主干开发，培训客户使用GIT高级功能，同时解决一些疑难杂症。
• Operation相关技术：指导客户实践蓝绿部署、云和容器、金丝雀发布等。帮助客户设计更好的部署架构和技术架构，同时帮助客户架构师做更好的决策。

这个阶段培养的主要目标就是开发，建立开发的质量意识，帮助开发写出更好的开发，培养开发处理复杂问题的能力。同时开阔团队视野，让团队成员了解更多的技术，学习如何利用新技术提升自己效率。

除了第一阶段的指标继续改进外，这个阶段我们会重点关注的一些指标：

CI相关指标：做CI的背后其实是为了培养团队能力

• CI触发频率 > 开发人员个数：确保开发人员每天每人有提交。
• CI通过率 > 80%：确保开发人员在提交代码前做了本地自检。
• 最近一周内的CI修复时长 < 8h：确定团队对CI有足够的关注，没有CI红过夜。

质量相关指标：

• 一次通过率 > 80%（或者迭代手动Test的缺陷数接近于0）：Story开发完成后，会对完成的功能做一轮手动测试。这时得到的缺陷数，代表了开发阶段的质量，缺陷数越少，说明开发人员的自动化测试和CI做的越好。一次通过率可以作为更高的要求，因为包括了后续的测试环境和生产环境中，产生问题的返工。
• 单元测试覆盖率 > 80%（大家不要纠结为啥是80%，你也可以改成79%，或者100%）：首先要确保单元测试的数量在持续增加，同时要有Code Review的机制来保证单元测试的质量。另外，如果覆盖率造假，那一次通过率一定不会得到改善。
• 测试金字塔：收集各层测试的数据，并关注是否是一个良好的金字塔，给个参考比例1:2:7。这里需要特别关注的一点，如果发现顶层测试数量太多，通常说明开发人员对自动化测试的关注不足，需要加大对单元测试和集成测试的推广力度。

交付相关指标：

• CD Pipeline的Cycle time < 1h：这个一定要严格控制，假设一个团队有8个开发，每人每天提交一次，那一天至少提交8次，如果Pipeline跑的太慢，就会影响到大家的代码提交。当然，你也可以把这个时间要求减少，只是我的经验里，有些部署环境复杂、UI测试写的有点多的团队中，1h完成已经是一件非常难的事了。
• 一个月内 Product Incident <= 1：差不多就是1年小于10个的标准，这个数字可以根据不同行业有不同要求，银行业通常会更严格，而创新互联网企业对线上事故的容忍度会更高。
• 其他SLA指标：比如服务可用率、响应速度、负载等，这些指标关系到的是部署架构和技术架构的设计和实现。

这个阶段会耗时比较长，因此会有两阶的跨度，第一阶是起步，往往会有教练带着团队做重构，写自动化测试Demo，定规范和总结最佳实践。到第二阶后，这些能力就由团队自己去传播了，教练只会偶尔参加一下Code Review来看看团队是否走在正确的路上。

小结：

总的来看，以上两阶段就是帮助客户建立流程，定义参与角色并找到适合的工具，然后通过度量追踪整个转型过程，并逐步引入敏捷实践来提升相关指标。

（敏捷转型内容示意图）

阶段三（Agile 3 - 5）：提升价值交付效率和响应力

到Agile 3为止，我们一直在告诉客户你要做什么，通过改变客户团队成员的行为，来改变他们的思想，特别是开发人员的质量意识和团队成员的能力。基于已有的成果，这个阶段的目标，就是培养成员的自我提升意识，团队的自我改善能力，并帮助团队建立自我改进的习惯。

因为团队专注于自我改进，因此大家会有自己的改进线路，不过无论如何，都会专注于以下几个方面：

• 更高级的能力建设：能进入这个阶段的团队说明已经具备了支撑快速变化业务的基本能力，因此可以推动更高级的能力建设，比如引入微服务、代码共享、特性团队等（这些能力也能在阶段三之前引入，但是只有在有了阶段二的基础后，才能真正做好）。
• 以Coaching为主：我们Teaching的内容会变少，Coaching的内容会变多，会让客户自己组织更多的分享，鼓励客户自学，并建立学习型文化。我们会和一些关键人物定期的做交流沟通，来帮助他们解决他们所面临的问题。
• 与业务走的更近：团队可以更好的理解业务，同时能给业务提供更有价值的建议，因此很多业务在决策早期就会引入技术团队的成员。另外团队也能更好的做出业务想要的东西。 在这个过程中，文化贯穿始末。因为团队能力变强，所以更容易建立业务和技术团队的信任，形成信任文化；因为团队养成了自我改善的习惯，所以更容易形成学习型文化；因为大家有信任、有能力，所以会打破原来的控制型文化，培育出创新型文化。这些文化的建立，能更好的帮助企业在未来保持良好增长。

这个阶段度量的内容会关注在响应力、创新上，这里给些参考：

• 交付周期 < 5d：这是响应力的象征。
• 假设验证率：这个指标可以用来考核PO，理论上学到的知识越多，这个数字就会越高。
• 其他业务指标：这时团队关注的是如何帮业务走向胜利，因此在软件开发时就会大量埋点用于业务分析。

总结

整个转型的过程，其实是行为改变思想，再通过思想影响行为的过程，当团队中的人员能力慢慢提升，思想也在随之改变，所有人都能对什么是正确的事作出更好的判断，继而走向持续改进的道路。所以如果定义团队转型成功，我认为就是帮助团队建立起了一群能自己做持续改进的自组织特性团队。 团队要经历这三个阶段必然是一个漫长的过程，很多钱多气粗的企业一定想知道有没有什么捷径，我的答案是有：敏捷转型的过程就是培养大家能力的过程，既然终点是所有人都拥有很强的能力，那为什么不在一开始就找这样的人来工作呢？

PS：

2005年，作为敏捷方法实践领头羊的ThoughtWorks走入中国，并将敏捷方法论首次引进中国。今天，我们想对中国企业敏捷实施情况做个总结报告，让更多人关注并加入敏捷实施的行列。本调查针对已经实施敏捷的中国企业，了解哪些实践比较普遍，在实施过程中有哪些困难。

我们将在2017年北京TID大会（7月18日）分享第一轮结果，参与填写本调查并留下邮箱的朋友，将会优于业界其他人收到最终报告。

更多精彩洞见，请关注微信公众号:思特沃克