如何达成第一阶段的团队级敏捷

FYIRH

团队级敏捷，指的是以5~9人的小团队为单位开展敏捷转型。一般来说，大部分企业想尝试敏捷转型，都从选择一个或几个团队开始试点。每个团队各自独立交付产品，彼此之间不一定需要有关联。当试点有效果后，组织往往会继续拓展敏捷转型的范围，鼓励更多的团队加入敏捷的阵营。

团队级敏捷的实践一般包括：

9 B; `  {% ^9 I: t

• Scrum或看板方法；
• 持续集成；
• 涌现式架构设计；
• 领域驱动开发；
• 行为驱动开发；
• 自动化测试；
• 结对编程；
• 测试驱动开发。
  5 [. O  \1 [/ s; [

+ [, j6 E# V" B  t1 T0 |2 g! T3 L

如果单个敏捷团队可以独立发布产品，他们可能会进一步尝试一些工程技术实践，比如：

, C# K4 [5 h7 k( ?- L

• 微服务；
• 持续交付流水线；
• 自动化运维。
  6 P, S! Y; S4 y4 b1 P7 `2 ~. m. q" F

0 p  e, L( S: g6 p

但是，对于那些由多个团队协作交付的大型项目来说，即使每个团队都在开展敏捷实践，也未必能够看到整个项目明显的收益和效果。因为大型项目关乎的是整个版本、产品的交付效率和质量，团队与团队之间需要互相配合才能交付整个产品。

同时，对于每一个团队来说，在他们尝试敏捷的过程中，必然会碰到一些与敏捷相抵触的项目流程、管理和协作方式，这对团队的效率是一层枷锁，而这又是团队很难改变的。

一家通信企业B的一个产品线的底层协议通信部门共有3个Scrum团队，每个团队都已经实践Scrum一年的时间，每个团队都搭建了持续集成（ContinuousIntegration，简称CI）系统，开始了自动化测试。

此外，处于该产品系统架构上层的单板软件层，由另一个部门交付。他们有6个Scrum团队，每个团队尝试Scrum也有几个月的时间，也在进行CI持续集成、自动化测试、TDD测试驱动开发、结对编程等技术实践。这6个Scrum团队从底层协议通信的3个Scrum团队获得协议通信代码后，与自己的单板软件代码集成后，作为单板软件整体发布出去。

由于这6个Scrum团队依赖那3个底层协议通信团队，所以若要交付出对客户有价值的产品，在整个产品线的项目组织结构里，这9个团队缺一不可。单独任何一个Scrum团队交付的内容都不能产生价值。

而这几个团队虽然自己都在运行Scrum，但是没有确保彼此之间用步调一致的机制来运作。每个Sprint都出现上层单板的A团队在等待底层协议B团队的一个组件就绪的情况，导致A团队交付延期。

1 y8 `8 a5 |  R" b+ T  `/ I" _! t

该产品线度量了Scrum试点前后的上市周期时间（TimeToMarket，简称TTM），虽然每个团队都在做敏捷转型，但是整个产品的TTM没有明显缩短。

. Q5 |7 E4 c$ S5 N  f* I1 G

对于这样的组织，就需要发展到更上一层的敏捷：产品级敏捷。

, Z) I+ K5 D) p5 q