|
本周一进行团队第二个冲刺的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 ” ©著作权归作者所有 |
