敏捷开发:看板 vs. Scrum板
您目前处于:敏捷  2013年12月02日

本周一进行团队第二个冲刺的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 ”