敏捷转型策略路线图案例解析︱敏捷软件开发

设计敏捷转型的路线图
 
很多企业没有设计明确的敏捷转型路线图，走一步看一步，这样容易导致在前进的道路上方向不明确，动力不足，因为在任何时候人们都可能认为已经敏捷了，转型结束了。有了明确的路线图，让人们非常清楚当前我们处于哪个阶段，不要对已经取得的转型效果满足，因为使命没有完成，我们还需要迈向下个阶段。
 
如果对于只有几个团队的小型创业公司，也许不需要设计什么组织转型路线图，这几个团队沿着第一章介绍的Doing Agile→Thinking Agile→Being Agile三个台阶走就可以了。但是对于中、大型规模的企业，由于团队数量多，组织结构复杂，所有团队不可能齐步走。因此除了这三步之外，还需要有个大致的方向路线，牵引整个企业向前迈进。本文介绍的转型策略，适合于这类企业。一般来说，企业所经历的敏捷转型大致遵循这样的路线。  
阶段一：团队级敏捷
团队级敏捷，指的是以5-9人的小团队为单位开展敏捷转型。大部分企业想尝试敏捷转型，一般来说，都从选择一或几个团队开始试点。每个团队各自独立交付产品，彼此之间不一定需要有关联。当试点有效果后，组织往往会继续拓展敏捷转型的范围，鼓励更多的团队加入敏捷的阵营。
 
团队级敏捷的实践一般有以下：
 
TDD（Test Driven Development:测试驱动开发
Scrum或看板方法
持续集成
涌现式架构设计
领域驱动开发
BDD（Behavior Driven Development: 行为驱动开发)
自动化测试
结对编程
 
如果单个敏捷团队可以独立发布产品，他们可能会进一步尝试一些工程技术实践，比如：
 
自动化运维
微服务
持续交付流水线    
 
但是，对于那些由多个团队协作交付的大型项目来说，即使每个团队都在开展敏捷实践，对于整个项目未必能够看到明显的收益和效果。因为，大型项目关心的是整个版本、产品的交付效率和质量，团队与团队之间需要互相配合才能交付整个产品。
同时，对于每一个团队来说，在他们尝试敏捷的过程中，必然会碰到一些与敏捷相抵触项目流程、管理、和协作方式，为团队的效率构成枷锁，而这又是在团队能够改变的范畴以外。
 
案例
某通信企业的一个产品线，其底层协议通信部门共有3个Scrum团队，他们每个团队已经实践Scrum一年的时间，每个团队搭建了CI（CI: Continuous Integration持续集成）系统，开始了自动化测试。
 
此外，处于该产品系统架构上层的单板软件层，由另一个部门交付，他们有6个Scrum团队，每个团队尝试Scrum也有几个月的时间，也在实践CI持续集成、自动化测试、TDD测试驱动开发、结对编程等技术实践。这6个Scrum团队从底层协议通信的3个Scrum团队获得协议通信代码后，与自己的单板软件代码集成后，作为单板软件整体发布出去。
 
由于这6个Scrum团队依赖那3个底层协议通信团队，若交付出对客户有价值的产品，在整个产品线的项目组织结构里，这9个团队缺一不可。单独任何一个Scrum 团队交付的内容都不单独产生价值。
 
而这几个团队虽然自己都在运行Scrum，但是互相之间的协同、对齐没有统一的机制来运作，每个Sprint都出现上层单板的A团队在等待底层协议B团队的一个组件就绪，导致A团队交付延期。
 
该产品线度量了Scrum试点前后的TTM(TTM:Time To Market上市周期时间)，虽然每个团队都在做敏捷转型，但是整个产品的TTM没有明显缩短。
 
对于这样的组织，就需要发展到更上一层的敏捷：产品级敏捷。
 
阶段二：产品级敏捷
在一般的中、大规模企业，一个产品的创意从无到有，再到上市为止，可能经历如下阶段