从Scrum到Kanban的团队之旅

翻译 | 高钰淋

本文翻译自《From Scrum to Kanban–A Team’s Journey》，以第一人称视角讲述了移动广告公司Marchex的团队Kanban过渡经历，从改变更机，到过渡过程，再到实践经验，但愿能给你们带来一些关于团队敏捷实践的启发。

Marchex是一家移动广告技术公司，2014年团队从支持一个已经运行了7年以上的产品转变去开发一个全新产品，当时Scrum实践的效率并不高，想要成功执行sprint计划愈来愈难，因而公司决定从Scrum转换到Kanban，看看它是否有助于缓解团队在sprint计划中出现的一些问题。

有关Scrum和Kanban的区别，可阅读《Kanban VS Scrum：哪一个是最好的敏捷项目管理框架》

Marchex和敏捷

为了使团队的变动最小化，咱们在从一个产品过渡到下一个产品时，尽可能保持基本的Scrum结构，但事实证实，这个计划并不像咱们所但愿的那么顺利。

Marchex对敏捷并不陌生，整个产品组织都以某种形式采用了敏捷，不过有些方法上的不一样。2014年，在咱们过渡到Kanban以前，个人团队看起来像是XP + Scrumban的组合。咱们采用了一些标准的XP实践，例如TDD、DailyStandups、结对编程、演示和按期回顾。咱们还使用白板经过看板跟踪咱们的sprint进度。到了2014年夏天，咱们开始采用新的敏捷范例。

向Kanban过渡的动机

不熟悉的领域和技术

第一个面临的问题是咱们的故事定义和故事点的准确性。例如，咱们有一组关于建立新服务的故事，其中一个故事被定义为为这个新服务建立一个API。这个故事的接受标准是模糊的，即建立一个客户端应用程序能够用来获取和推送数据的API。一些流程会被概括在一个状态中，难以准确识别进度，好比团队与内部客户交谈，设计解决方案等，在整个故事中所有属于“处理中”这一状态。再者，咱们没有之前的数据比较来帮助咱们使用准确地判断故事的大小，因此咱们的sprint计划中常常有未完成的故事。由于一个又一个sprint的故事都没有按计划交付，让团队十分受挫，日复一日，周复一周看着一样的故事处于一样的状态，让人感受陷入了困境。

波动积压

另外一个问题是咱们不稳定的任务积压。对于从瀑布式转换到敏捷的团队，一周冲刺彷佛是短暂而紧迫的。然而，咱们发如今不断发展的新产品开发业务需求中，每周的冲刺时间过长。咱们的业务开发团队实时与潜在客户讨论产品，并进行反馈，相应的，咱们也必须不断调整产品需求列表的优先级，因此有时感受咱们天天都在改变优先级。

在这种环境下，sprint计划显得过于笨拙，再也不适合咱们的业务需求。因此在sprint边界的刚性、不断变化的backlog和不断发布特性加强和健壮性的需求之间，须要一个新的范例。

变动需求

在几回回顾以后，咱们发现本身没法完成sprint计划，因而开始寻找如何缓解这些问题的方法。咱们将电子Scrum板移到站立空间的一个大白板上，使任务更加显眼。另外，个人团队从一个单独的开发团队(主要是独立工做)变成了三个团队中的一个，3个团队都被要求开发和交付这个新产品。

我采访了一位协做团队的开发人员，问她对Scrum到看板的转变有什么见解。她说她更喜欢看板风格有两个缘由：团队只关注待办事项列表中最重要的1或2个故事，当它们完成时，就会转移到下一个故事。第二是她喜欢从积压的故事中挑选最重要的故事，而后完成工做。她还提到，他们团队的过程更容易管理，由于故事范围很小。在与她交谈以后，我肯定了团队的正确方向。

不须要改变的事情

当咱们考虑脱离Scrum时，咱们坚信有一些实践对团队来讲仍然是有效的。众所周知，Scrum是一种组织项目的方法，而XP实践主要是如何开发代码。XP的拥护者常常采用Scrum+XP。一样，咱们决定继续使用XP实践，而使用Kanban做为结构：

• 结对编程——2014年团队采用告终对编程方法，咱们发现，在采用新的Scala语言和学习搜索范式时，这两种方法是成对的。编程是保持团队生产力的必要条件，咱们天天都在会上安排你们组队，尽可能一组人一块儿合做直到完成一个故事。
• 测试驱动开发——几乎全部的新开发都是经过测试驱动开发建立的，咱们认为这种实践仍然是开发软件的最佳方式。
• 回顾——这是一个永远不会消失的敏捷标准实践，它是咱们持续改进质量的方法。
• 故事点——咱们改变了咱们的故事点定义，但仍坚持使用点来估计故事的大小。咱们会讨论一个故事，就接受标准达成一致，而后经过小组投票分配点数。

过渡过程

我与团队讨论了迁移到Kanban的概念，并组织了一个Lean Coffee (leancoffee.org)风格的会议，以征求反馈并解决团队的关注点。

精益咖啡风格的会议经过要求参与者提交讨论主题，明确地征求每一个人的反馈，而后经过分组投票肯定优先级。会议中你们认为最大的问题是故事的规模，若是全部的故事都更小、更一致，Kanban将工做得更好。在那次会议以后，咱们决定采用如下流程来支持咱们的新看板模型：

• 每周一次1小时的会议计划。
• 每周五进行1小时的回顾。
• 若是咱们在周中(也就是下周一计划会议以前)故事量开始减小，咱们会在每日站立会(daily standup)上作一个小计划。
• 新的故事点“度量参考”：1个故事点=1/2的理想工做日为一对程序员。之前，咱们的量表是1个故事点= 一对程序员的理想工做日。这种缩减的规模帮助咱们保持咱们的故事更小，由于5点故事意味着它应该在大约2.5天内完成，而不是5天。
• 若是在计划过程当中，咱们给一个故事分配了超过8个点，咱们会把它分红2个或更多的故事。
• 每日站会将专一于讨论故事状态，并将它们移动到Kanban上，而不是绕着圈子给出状态。这意味着咱们的周期更短，更专一于眼前的任务。这一变化彷佛是咱们转向Kanban的天然延伸，由于它强调了Kanban对工做和循环的重视，时间更为明显。
• 咱们在迭代期间进行结对。咱们不必定天天都会改变，尤为是在故事进行到一半时，但咱们天天都要讨论到每一对。考虑到咱们的团队规模，只花了一两分钟。
• 咱们保留了第16分钟的概念——也就是说，若是有人想更深刻地讨论某个问题，咱们会把它写在白板上，而后把它放在第16分钟的讨论中。在讨论完板上的故事状态和分配对以后，咱们在第16分钟讨论项目。
• 团队中每对开发人员的WIP为1，即6名开发人员“开发中”的WIP为3。咱们还为“QA”列指定了一个WIP为3。

咱们在sprint边界完成了从Scrum到Kanban的过渡，也就是说，咱们完成了当前的sprint，在下一次计划会议上，咱们建立了一个新的故事点“度量参考”，并开始像Kanban团队同样进行计划。这意味着咱们只须要为下周的故事设定范围和计划，由于计划是在周一上午进行的。

对小故事的更改解决了咱们现有的一个问题——还没有指定的故事。经过讨论范围较小的故事，咱们天然也倾向于收紧接受标准，因为咱们的故事是8点(4天)或更少，因此咱们以更小的粒度讨论了故事的目标。

例如，与简单地为新服务建立API的故事不一样，新故事被分解为更小的故事，如初始化、发布、验证、日志记录和最后定稿。

在为每一个较小的故事处理咱们的验收标准时，因为范围更小，咱们的验收标准在范围和粒度上也变得更加适中。例如，为日志记录的故事建立接受标准变得很是具体，相反，为建立API的故事建立的接受标准的类型要模糊得多。的确，创造更小的故事也意味着创造更多的故事，因此建立一个好的故事层次结构对于确保更大的特性获得充分的实现也很是重要。故事层次结构一般用于在范围更广的故事下组织子故事。更普遍的故事一般被称为“史诗”。使用这种机制，咱们能够围绕大量较小范围的故事建立一些顺序。最后咱们可以在不到一个小时的时间里轻松地计划一周的工做量，这比咱们以前的3h要少不少。

每周的sprint计划会议，有人曾经深情地称之为“伤眼的日子”。不过，公平地说，咱们之前的sprint计划会议也包括回顾。如今，咱们每一个星期五都有一个单独的回顾，把计划和回顾分红两个会议比一个更容易接受。每周会议，咱们使用白板开始新的Kanban生活，没有调整列名。

列名分别为：

在开发	准备好QA	QA	准备好发布	完成

几周后，咱们开始使用电子板来进行咱们的测试和计划，方便团队更容易看到backlog。此时，咱们在现有的5列的左边增长了4列：

New	Bucket	Backlog	On Deck

• NEW=新故事
• Bucket =无序积压
• Backlog=优先级列表
• Start =团队认为已经准备好实现的故事，即良好的验收标准和分配好故事点。

过渡很是顺利，在9个月以后，团队仍然对看板范例感到满意。计划更加及时，故事更短，也更容易处理，任何大于8点的故事都必须分解的规则迫使咱们将故事保持在小范围内。咱们成功从Scrum转向了Kanban。

此外，咱们还发现，为范围更小的故事编写接受标准能够更容易地编写更具体的、不那么模糊的接受标准。换句话说，咱们的故事定义更加严格。在转换以前和以后，咱们历来没有作过关于生产力的A/B比较，可是团队感受更有生产力，士气也获得了提升，由于咱们可以看到天天的进展。此外，咱们与项目经理的沟通也获得了改善，由于他对状态变动和完成一个功能须要多长时间有了更好的了解。

持续学习

有几个因素使咱们的过渡至关顺利。

经验丰富的团队领导

在咱们从Scrum过渡到Kanban以后，角色变化最大的人是项目经理(扮演Scrum Master的角色)。在整理积压的工做时，他必须至少领先团队一步，考虑团队不断变化的业务需求，有足够好的验收标准来为“Bucket”添加更多的故事，以防处理中的故事在咱们下一次站会以前完成。

做为项目经理的另外一个挑战是管理转换自己，他指导团队采用新的实践，并帮助督促你们坚持下去。

成熟的敏捷组织

另外一个使咱们的转换更加顺畅的因素是组织已经拥有敏捷经验,团队的大多数成员都是经验丰富的敏捷实践者。团队会时常进行回顾，在回顾中咱们讨论了当前流程的执行状况，并根据须要进行流程更改。因此一个基本的范例转换对咱们来讲并不像对一个尚未实践敏捷的组织那样可怕。

看板培训

在咱们向看板过渡的前一年，整个开发组织都经过了由Modus Cooperandi提供的看板培训。了解了精益和看板的概念，如在制品(WIP)、周期时间等。因此当咱们的团队开始讨论看板的采用时，咱们对一些词汇的含义已经很熟悉。

保持每周的节奏

每周一次的节奏有助于咱们构建新的Kanban。咱们每周都有回顾，因此若是出现问题，咱们能够对咱们的流程作一些小的调整。周一计划一周的工做，周五回顾一周的工做，这有助于保持良好的节奏。即便咱们取消了冲刺，保持每周的时间表仍然颇有意义。

结果

在咱们进行了9个月的转换以后，咱们在Kanban方面的实践愈来愈熟练，咱们的业务需求仍在频繁地变化，可是团队效率很高，而且持续稳定地发布新功能，同时，JIT（及时）计划也使咱们全部的会议都更加高效和富有成效。敏捷有许多不一样的实践方法，每一个团队有本身的路径，但愿咱们的经历能对你有用。

关于Choerodon猪齿鱼敏捷管理实践的相关文章，点击蓝字阅读 ▼

• 猪齿鱼敏捷管理实践（一）需求管理
• 猪齿鱼敏捷管理实践（二）冲刺管理
• 猪齿鱼敏捷管理实践（三）敏捷会议

关于Choerodon猪齿鱼

Choerodon猪齿鱼是一个开源多云技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台经过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

Choerodon猪齿鱼已开通官方微信交流群，欢迎你们添加Choerodon猪齿鱼微信(ID:choerodon-c7n)入群

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：choerodon.io
• 论坛：forum.choerodon.io
• Github：github.com/choerodon
• 码云：gitee.com/choerodon