一、 团队改进前概况

属于技术平台产品团队，产品属于公司核心产品部件。团队成员包括产品经理1人，开发8人，异地测试3人，运营1人。

团队工作特点：

1. 并行多个产品的版本在开发；

2. 需要与其他产品组有较多的技术协同工作；

3. 有大量的紧急外部用户反馈需要响应；

4. 有内部紧急需求需要及时实现；

5. 存在异地团队（开发在北京、测试在西安）。

团队转型之前面临的问题：

1. 迭代计划外临时任务插入较多，且优先级很高，影响迭代计划不能按时完成。

2. 任务完成标准不是很清晰（开发和测试任务分开）

3. 迭代过程中，虽然站会也会暴露进展风险，但是计划调整的很少

4. 开发、测试、需求很多时候两两达成了一致，三方信息的同步不及时

5. 任务估点不太准确，过程中无调整

6. 临时发版较多，对现有迭代计划造成冲击

7. 产品版本规划不清晰，不了解具体的版本内容

团队转型之前的研发现状：

1. 团队在走2周的迭代，迭代计划完成率低下；

2. 产品新特性开发和用户反馈处理工作交织进行，团队手忙脚乱；

3. 团队成员不停加班。

二、 团队改进后效果

团队改进历程

精益敏捷转型历时8个月后，团队完成精益Kanban开发、用户故事、版本规划、产品Backlog梳理的导入和实践，团队的精益研发规则能够独立运转。

团队阶段改进成效

1. 产品版本由改进前1个月临时发1次版提升到平均1个月有规划发2次版；

2. 产品版本BUG解决率由80%提升到100%，BUG总遗留率由18%降到2%；

3. 团队交付速率由4点/工天提升到8点/工天，提升1倍；

4. 特性用户故事平均交付周期由16天降至8天，提升1倍。

三、 改进启发

当产品已经正式上线运营了较长时间，已经存在大量的外部用户，研发团队同时需要并行解决大量紧急的用户反馈和计划中的产品新特性的实现的时候，对于这种软件产品处于运营与新特性开发并存的阶段，精益Kanban方法和SCRUM相比，可能Kanban方法会更适合于这种应用场景。

Kanban方法实施中，很多团队使用的都是物理看板。但是在产品生命周期较长，有远程异地团队，需要自动强大的度量功能作为改进助力的团队而言，电子看板的支撑就显得尤为重要。

本案例就是针对处于运营与新特性开发并存阶段的研发团队，通过使用JIRA工具系统化完成精益Kanban开发核心实践的实现，进而形成团队较成熟研发规则，并获得一定改进成效的实例。

本案例成功的意义主要有两点：一是系统化使用JIRA电子看板在公司一线的产品团队验证了精益Kanban开发方法的可行性；二是对产品已经上市，新特性开发和反馈处理工作并存的团队如何更加精益管理研发过程提供了解决方案。

JIRA工具系统化支持了Kanban五大核心实践的实现，具体如下：

1. 可视化价值流。JIRA实现了团队从需求创建到产品版本发布的全价值流；定义了3大类工作项类型，并针对不同类工作项设计了不同的工作流；多角度定义了看板的泳道。

2. 显式化规则。团队定义了看板列标准，实现了4类服务等级协议的设置。显式化了系列团队规则。

3. WIP限制。看板列定义了WIP数量的约束，并在工作流中有效调整。

4. 管理流动。基于PDCA理念，产品驱动开发，团队定义了发布规划会议、计划会议、Kanban每日站会、总结回顾会完整的管理反馈环。

5. 建立反馈、持续改进。通过管理反馈、看板反馈等各种反馈的建立，团队能够快速发现存在的问题；团队采用过程分析定性获得问题产生原因，度量统计能够更精准定位团队的问题，并支撑问题分析；通过有依据的改进行动指导持续提升团队。JIRA在度量统计方面提供了强大的功能，强力支撑了团队的持续改进工作。

本案例的团队在改进前进行敏捷迭代开发，改进后采用Kanban流式开发。在这里我们不禁有一个疑问： 这个团队在使用Kanban后有明显的改进成效，能够说明流式开发更优于迭代开发（SCRUM）吗？

对于两种模式的适用场景，一般认为，迭代开发较适用于新产品的特性开发；流式Kanban开发适用于交付周期不固定、技术探索性较多、研发和运维相互交织等研发场景较复杂的项目。那么除此之外，这两种模式在哪些方面会对团队有不同的影响呢？

从团队认知角度来看，SCRUM具有更清晰的框架；从团队接受角度来看，Kanban因为其渐进性更容易被接受、被消化，团队转型成本也较低；对于SCRUM中时间盒的使用，无论从计划上还是从适应性的调整上，都需要团队有较高的能力；Kanban虽然没有明确的时间盒限制，但是Kanban的持续改进对团队的自驱力要求更高。个人认为，条条大路通罗马。不管是SCRUM还是Kanban，都能应对团队的精益敏捷转型。从教练角度，Kanban因为其灵活性实施推广会较复杂一些。

团队的精益敏捷转型是个复杂的工作，SCRUM或者Kanban只是提供了框架，具体采用哪些实践，还需要根据团队面临的问题，来系统化选取实施。作为教练，应该跨越方法论的壁垒，按需选取实践，持续优化工作流，做到产品研发全周期转型的覆盖。