从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 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
作者：Marchex
出处：Choerodon
欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。