本周一进行团队第二个冲刺的Review和Retro，在这次回顾中，我们发现在Scrum实践中，由于我们团队每个人几乎要负责两个以上的系统研发，其中又有老系统维护和新系统需求的优化，这就造成了团队成员在迭代中目标不一致。

因为Scrum更合适一个团队向着同一个目标冲刺，所以面对我们遇到的问题，在与我们的敏捷教练 - 杜伟忠探讨后，我们团队决定进行转型 ——　我们依然是敏捷团队，但是我们应用了一种更灵活的敏捷，看板模式。

那什么是看板呢？它与Scrum板有什么不一样呢？

1. Scrum规定角色，KANBAN没有

2. Scrum通过TimeBox进行迭代冲刺，KANBAN通过限制在制品进行流的控制

3. Scurm Backlog中的条目大小适合放入迭代，KANBAN可以跨越迭代

4. Scrum在迭代器不允许变更，KANBAN是等TO DO有空闲位置时在处理

5. Scrum板在每个迭代重置，KANBAN无所谓哪天 —— 没有冲刺的概念

6. Scrum规定跨功能团队，KANBAN支持专家和通才

7. Scrum规定评估和速率

为什么我们更适合KANBAN？

团队目标不一致，虽然团队相互依赖，但目标 不一致！所以，团队正适合以流的方式进行需求拉动式的敏捷。

我们如何进行转型？

虽然KANBAN没有明确的角色、工件和会议，但是团队的约定大于规定，我们还是沿用了Scurm中很多的方法。

1. 每天依旧进行早会，进行即时沟通反馈

2. 两周一个MileStone，进行Check —— 即Review&Retro

3. 由于看板没有迭代的概念，所以对每个Story都设定CheckPoint，在MileStone上进行演示交付

4. 由于看板不像Scrum板需要将Stroy拆Task，所以每日的燃烧时间直接记录在Story上

5. 对每个MileStone统计故事点，以评估团队速率。

大家一看，怎么看好像还是Scurm模式？其中的关键点转换：弱化了Sprint冲刺的概念，加强了每个泳道内限制在制品的限制。

我们如何进行会议？

1. Review 30min & Retro 60min

Retro包括四个环节：找问题 > 5 Why > 投票 > 行动

2. KANBAN Trainning 60min

3. Planning Meeting 120min

转载请并标注: “本文转载自 linkedkeeper.com ”  ©著作权归作者所有