从Scrum到ScrumBan-实例记录和分析

Posted 2021-04-25 大敏捷

ScrumBan简介

    就简单快速理解而言，ScrumBan是整合Scrum和Kanban的方法。在具体实践上，ScrumBan与Scrum最显著的差异是在计划方面。ScrumBan采用按需计划方式，迭代初次计划不需要严格确定迭代工作的范围，迭代中持续观测迭代待办列表的长度（在ScrumBan板的第1列），当迭代待办列表长度低于一定值时，就会触发计划活动。因此ScrumBan的计划活动（不一定是会议）每次耗时短，在一个迭代内，按需可能分多次进行。最近的3年，使用ScrumBan的趋势有明显的上升趋势。

A团队背景简介

  A团队开发维护的系统是大银行里面的一个后台系统，主要接受来自其它系统的各类请求，处理之后然后再发给下游系统，有界面部分，界面只供内部人员配置操作。这是一个典型的传统按组件分工的团队，在采用敏捷之前按照传统项目开展工作，也即是将关联的新功能或者修改组合为一个项目，与干系人协商确定预算和工期后正式启动开发，在绝大多数时间里，在同一时间需要处理多个项目。从2016年5月起，A团队启动敏捷转型，到2017年3月略有小成。

A团队敏捷转型简要历程

1.       2016年5月下旬启动敏捷转型，按Scrum角色安排，团队Lead兼任了Scrum Master，Product Owner由部门长兼任，根据之前计划的项目任务选择作为开始时的Sprint Backlog，选择3周为迭代长度，摸索进行了3个迭代。

2.       到2017年3月，经历了16个迭代，进行了多种尝试，下文对关键选择进行了说明。

A团队敏捷转型历程中的关键选择

对接原有项目-关于所有项目和团队事务

在开始时，一个朴素的做法是在新项目上启动敏捷迭代，在A团队的前三个迭代，选择了一个新启动的项目采用Scrum Sprint方式进行。在第4个迭代起，考虑到团队处理的所有项目是基于一个共同的code base, 如果老项目不切换到敏捷迭代方式，那么就是在老项目的瀑布流程上叠加新项目的Scrum，而新老项目总需要集成在一起，这个景象发展下去可能的总体效率也许比原来全部瀑布项目更低。因此决策把所有项目纳入到Scrum范围，将老项目的事务同样改写为Epic和Story，首先进入到backlog，然后选入到Sprintbacklog，显示在JIRA的名为ScrumBan的board上，以下称为ScrumBanBoard。在第5个迭代时做到了所有项目不分新老都在ScrumBan Board上展现。而对于团队其它事务，采用全面可视化的理念，试图同样反映到Sprint backlog，但当时不是所有团队成员的全部工作量都在开发维护的系统上，有部分成员兼顾其它系统事务，因此达成如下的分界线，如果成员的50%+以上工作量在A团队开发维护的系统上，那么该成员其它估计大于1天工作量的事务也需反映到ScrumBanBoard上。到2016年11月，经过调整，团队所有成员主要工作在A系统上，估算超过1人天的所有团队事务都需要反映到ScrumBan Board Board。最典型的例子是团队成员被强制要求在期限内参加企业内部网上课程学习，这样的事务被识别为一个故事在ScrumBan Board上。

关于子任务和子任务工作量

    识别用户故事的子任务以及估算其工作量是Scrum中常见的实践，累计所有子任务剩余工作量来绘制燃尽图也是Scrum中常见的做法。第4个迭代中为数13的故事没有完成，在第5个迭代中，团队对于大粒度的故事识别了子任务，试图跟踪推荐子任务来确保大粒度故事得以完成。而对于子任务的工作量，由于故事点估算已经假设前期一个故事点需要1人天来完成，团队认为没有必要再估计子任务工作量，而JIRA也提供了按故事点绘制燃尽图的功能，因此团队选择故事点作为燃尽图的单位。

    在经历了2个迭代的子任务识别之后，发现有2个主要不足：1，全部初始识别的子任务完成，并不意味着故事完成，子任务初始识别难以识别所有细节；2，子任务跟踪与故事状态变化没有直接联系，而且往往不在同一列上，反而不直观令人混淆；3，跟踪意义主要在团队成员的日常工作安排细节上，其跟踪价值不显著。因此结合系统功能开发特征，团队商量决定控制故事本身的颗粒度，故事点不超过5，而不再识别故事的子任务，识别故事经历的典型状态，第1版有：To do,Developing, Reviewing, Testing, Done；通过状态转移覆盖最典型的子任务，比如从“To do”到“Developing”的状态转移，相当于执行了故事启动开发的子任务；从“Developing”到“Reviewing”的状态转移，相当于执行了代码实现的子任务，依此类推。而不在状态转移里面的更多细节事务不再板上跟踪了。运行到现在，回顾主要的好处有：以状态转移覆盖最主要子任务，可以理解为抓住了关键故事增值步骤，舍弃识别跟踪其它子任务，简化了工作，在ScrumBan Board上只需跟踪单一级别的ISSUE（前期只有故事），进而提高了效率。

关于Velocity、Sprint范围和承诺

在A团队前面进行的迭代中，前3个迭代没有启用故事点，也没有进行工作量的细节估算，更多的是尝试迭代开发，在第4个迭代起开始使用故事点，开始建立对Velocity的观测，由于前期没有积累足够数据，因此难以对迭代范围和Velocity做出强承诺，另外一个因素是在过程中出现的紧急事务既难以预测，也难以拒绝。在Scrum刚开始，团队没有足够的信心来阻挡迭代中插入的此类事务。PO和POP理解团队当时的处境，没有强制要求团队按照Scrum推荐的计划会议第2阶段做出对迭代范围的强承诺计划。

在后续迭代运行过程中，就算在迭代周期缩短到2周之后，仍然出现多次迭代范围改变的情况。因为“采用了Scrum，所以在2迭代内拒绝响应紧急诉求”，这种理由难以对外解释为什么拒绝变化；另外一个原因是虽然只有2周，但团队仍然对2周的故事难以进行精准的预测。因为软件开发工作性质确实是有较大的创造性和不确定性。因此团队更多的采用精益看板思维来看待和应对这种情况，更加关注对外部的交付，对Epic的Lead Time开展了度量，试图缩短Epic的Lead Time，设置了2个Epic Lead Time，其1称为 Epic Lead Time，起始时间是Epic刚被识别的时候（无论是来自外部，还是内部），终点时间是发布上线，其2称为Epic CycleTime,起始时间是Epic首个开发迭代启动的日期，终点时间是技术发布上线。

积累了3个月的数据之后，团队在对外交流时，可以给出Epic所需要的预期时间，但这不同于原来瀑布下的上线里程碑安排。

应用二个级别的看板

    随着DevOps的建设，2016年12年A团队启动了持续集成，经过1个月的摸索，建立了称为故事流的方法，故事在一级ScrumBan Board上的流转与源代码分支和合并结合在一起，利用JIRA与GitHub的自动关联功能，实现了单一故事的精准跟踪（故事可追溯到代码本身、合并、评审）。这样ScrumBan Board上的流动有更加明确的DoD，WIP控制更加精准。

二级看板是Epic看板，是二级团队关注的焦点。二个级别的看板存在紧密联系，受限于工具的功能，Epic并不能根据其下故事流动情况自动级联流动，而手动跟踪Epic的体验是颇有成就感的一种体验，尤其是在把Epic移动到Done 时。

小结

体会上，ScrumBan的迭代安排带来了一个固定的节奏，让团队定期有所回顾和计划；而基于故事流动的计划和跟踪在实际交付上面也有很好的效果，Epic的更快交付让外部干系人返回了表扬。小颗粒度故事的流动对比故事+子任务组合跟踪效率更高，更加直接联系对外交付的价值。虽然牺牲了强承诺计划带来的更精准预测，但是团队在相对更加自如的环境下开展工作，在实际上产出量可能高于强承诺情况下的产出量。

---

本订阅号近期其它文章

3. 
   

4. 
   

5. 
   

有问题吗？