InfoQ 访谈了 Spotify 的运维工程师 Mattias Jansson。Spotify 是一家为桌面计算机和智能手机提供流音乐服务的公司，旨在为用户提供各类无延迟的音乐专辑。Spotify 公司在内部的运维团队中采用看板（Kanban）方法，Mattias Jasson 向运维团队推荐了看板方法。 InfoQ 曾经多次推荐过看板方法，但主要是从软件工程的视角介绍看板方法。Jasson 在与 InfoQ 对话中详细地阐述了 Spotify 的运维团队在尝试使用以看板方法为基础的工作方法应对日常的工作压力所取得的经验。
Q：你们团队在最初使用看板方法时遇到了哪些问题？
我们 Spotify 的运维团队有 7 名成员，需要处理各种不同的任务。我相信这种情况是每一个运维团队都面临的。这一刻你在设计一个要花费很多钱的新网站，下一刻又要为开发人员修改防火墙规则。
当我们开始尝试看板方法的时候，这种情况导致了一个问题：有些故事卡片描述了一个耗时几个月的项目，而其它的故事卡片只是个需要 15 分钟就能搞定的小任务。为这些卡片给出合适的估算大小也很困难：例如更新一台服务器上的应用程序库时会不会影响到看似不相干的领域？还有些时候写下故事（story）的详细内容也是件痛苦的事，因为有些故事实在太小，以至于修复这个问题的时间比写故事的时间还要短。
但我试着超越自己。
在尝试采用看板方法之前，我们注意到虽然在解决问题上是把好手，但不能做长期的计划：只是被动而不是主动地解决问题。一大堆从其它部门派过来的“紧急任务”总是干扰我们的内部项目。我们经常因为众多来自人和系统的干扰而频繁地切换工作情境（context）。我们意识到公司的成长速度已经超过我们的适应能力了。
这听上去挺可笑，我们团队的主要问题是可扩展性（scalability），而不是我们的流服务（虽说这也是另外一个非常有意思的故事），但不管怎么说无论团队还是工作方法都没有为公司成长的需要做好准备。
Q：那么你们是如何解决这个问题的呢？
我们决定远离办公室开几个会，坐下来讨论实际在做的事情。通过这些讨论，我们对取得的成果和今后的目标有了清楚的认识（希望如此）。下面是一些我们问自己的问题：
- 我们实际在做什么样的事情？我们花在各类工作上的时间各是多少？
- 有没有可能把我们的工作用合理的方法归为不同的领域？
- 我们的任务从哪里来？我们自己发起工作吗？还有其它来源吗？如果有，是谁？
- 我们如何彼此分享知识？
- 我们如何保证运维开发所需的时间？
- 是不是有可能减少我们切换工作情境的时间？
- 还有很多…
在我们开会讨论之后（包括计划的和临时的会议），得出了结论，那就是可以通过引入一个“团队守门员（goalie）”角色使团队更高效地完成工作，这个“团队守门员”负责捕获各种临时的工作请求并将其合理分类：小任务立即处理完成，把大一些的任务写成故事卡片。有了团队守门员的好处是：
- 更高效有力地为其它部门提供服务
- 在我们团队内部传播知识
- 减少团队其他成员切换工作情境的情况
我们决定至少在开始使用看板方法的阶段尽量保持简单。我们的方法是：
- 设立了三个垂直的泳道：待办（todo）、进行中（doing）和完成（done）
- 作为上面的补充，我们还在看板上为两类主要的工作划分了两个水平的泳道：普通任务和暂不明确的故事（多数我们主动发起的工作都在后者中）。将暂不明确的故事分开后，我们能够确保这些暂不明确的故事最终能够做完。
- 我们的故事只分为三种大小（就象 T 恤尺码一样）：小、中和大。小的工作和任务是估计一天之内能完成的。大小为中的任务乐观估计半周能够完成。估计为大的工作是可能需要花一周才能完成。我们忽略了“实际的”估算，因为多数情况下这种估算是浪费人力。
- 我们给待办泳道设定了一个较小的并行任务限制值（WIP - Work In Progress）”，因为我们把普通任务和暂不明确的故事分在两个不同的水平泳道中。我们一周（或当 todo 泳道空了的时候）才向里面放入新的故事，以此保证我们内部的长期的任务能够完成。
- 进行中的并行任务限制值我们定为比运维团队的人数少 1，因为那个人是团队守门员。为了鼓励小组成员一起完成故事，我们还考虑进一步减小并行任务限制值，不过那是在我们熟悉了看板方法之后。
那么更大的任务怎么办？嗯，其实我们把所有超过一周才能完成的任务称为“项目”。这些项目需要更多的描述，因此我们用 wiki 记录详细信息，同时把项目分为若干从小到大的故事。然后我们把这些故事放入 backlog 中，通常是在“暂不明确”的泳道中。
后来，我们意识到我们还得支持快速问题，为此在待办和进行中加入了第三个水平的泳道。这个泳道的并行任务限制值设为 1，因为我们希望少用这个类别。
Spotify 运维团队使用的 Kanban 截图
Q：从关注于软件开发的看板方法到关注于运维的看板方法，你们对看板方法做了哪些调整？
其实并没有太多改变，因为看板方法本身就是一种非常简单的系统。我想说的是，看板方法在所有组织中都需要改造，无论其类型如何，我们使用看板的方式可能和传统的软件开发环境稍有不同。
一个运作良好的软件开发团队通常只有一个故事的来源：可能是产品开发部门，他们和开发小组领导或和所有开发团队成员一起定义每个故事。这种情况下，一个可以预计的结果是，所有的故事某种程度上是“同构体”，就是说这些故事的大小类似、书写方式也遵循某种通用的标准。
一个典型的运维团队会有许多任务的来源：从个别的开发人员、产品开发团队、其它部门到运维团队自己产生的任务。这对运维团队来说是个问题，因为所有这些来自外部的任务都会干扰我们计划的长期项目，每一个运维团队成员都面对这个问题。对于运维团队内的资深工程师来说这个问题更加突出。
更糟糕的是，我们希望尽快从这些干扰中解脱出来，因此我们经常忘记记录所做的改变，或者通知小组内的其他同事。
仅仅引入看板方法而不去处理这些经常性的外部工作是不能解决我们运维团队面临的干扰过多的问题的，所以说适当的改造是必要的。
我们团队的改造方式是，就像我刚才提到的，每周设置一个专人作为“团队守门员”，有了这个“团队守门员”我们就能真正地应用看板来管理我们的日常工作，因为团队守门员为团队处理掉了所以琐碎的干扰。
开发团队和运维团队另外的一个区别是，我觉得相比开发团队，运维团队自己产生出的任务或者计划的内部项目比较少。我们的问题是，发现在为任务排优先级的时候，来自外部的任务总是优先于我们自己的内部工作。一方面这是因为助人的本性，另一方面是外部的问题通常都很具体。
就像为早先说的一样，我们按照 David Anderson 的建议，在看板中加入了“暂不明确”的故事类型。我们把 8 个并行任务限制值平均的分配到两个泳道上，这样我们就能保证有一半的人手在做“暂不明确”的故事。到目前为之，这在我们团队运作得很好。
Q：你是怎么发现看板方法的呢？
几年前，在我加入 Spotify 之前，听说了敏捷和精益方法，非常想在我的团队中试一下。但是我们是支持和运维团队，不能很好地使用 XP 和 scrum。
后来，大约是 2 年前，Henrik Kniberg 向我介绍了看板方法。我们只是试验了一下但并没有真正用在工作中。回想起来，我觉得因为没有花时间去分析我们的工作，所以浅尝辄止。
结果在 Spotify，我和同事及运维主管讨论了看板方法，然后决定试一试。
Q**：在Spotify你为什么选择看板方法进行运维管理？**
我们选择看板方法是因为它灵活而且实施成本相对较低。结果是，我们工作方式上很小的改变极大的提高了工作效率。
Q**：你有没有尝试过看板方法之外的敏捷实践，比如scrum或XP等等？**
Serum 嘛，没有，因为我们的工作流程很难按照 scrum 的方式安排。
没试过 XP，但我想我们精心地选择了一些实践，比如结对编程。当我们对系统基础设施做出重大调整时，通常结对工作。
Q：开始使用看板方法时，你有没有接受过一些培训？
是的。除了读 Henrik Kniberg 关于看板方法介绍的书之外，我们中的一些人参加了一个 David Anderson（“看板之父”）主办的为期两天的课程。课程非常有启发性，如果有机会的话，其他人也应该去听。
我们也参加了一个由 Mary Poppendieck 主持的晚间研讨班。她谈到了精益软件开发，虽然这些主题没有立刻适用于运维团队，不过确实很有启发性！
Q：你们用什么工具来管理看板？为什么选择它们？
我们试用过 AgileZen，一个优秀的、漂亮的看板工具，不过它不支持水平泳道，这对于我们来说是个限制。
在发现 LeanKit Kanban 后，我们就从 AgileZen 迁移过来了，因为 LeanKit Kanban 不仅支持水平泳道，而且你还能更自由地定义自己的看板。我们还用自己的 wiki 来描述项目。
Q：你们用了多长时间让这个看板流程运转起来？
大约花了一个月，包括分析我们团队的情况，发现团队任务的来源、瓶颈等等，还包括在用 AgileZen 实现了看板后培训团队成员。
当然，因为看板流程本身是不断演进的，在运转起来之后，看板流程不断给我们新的视角让我们不断将新发现融入流程中。从这方面来说，我们永远无法“完成”解决方案而不再需要任何调整。
看着看板方法引导我们团队走向何方是件有意思的事情，问题是我一年后如何回答这些问题。
Q：你对看板方法有多满意？你是不是认为看板方法值得所有运维人员关注？
是的！我们对看板方法非常满意。看板方法让我们在没有对日常工作进行重大改变的情况下让团队变得更敏捷。我们注意到等待时间在变短，完成了更多的内部工作，同时服务的部门对我们的工作更满意。
Q：对看板方法感兴趣的人，你有没有推荐的资源？
- http://en.wikipedia.org/wiki/Lean_software_development ——每个人都值得读，至少是精益基础和原则的部分
- David Anderson 的" Kanban, Successful evolutionary change for your technology business "
- Henrik Kniberg 和 Mattias Skarin 的" Kanban and scrum, making the best of both "（可以从 InfoQ免费下载）
- LimitedWIPSociety.org ——收集了 Kanban 布道师提供的学习资料
- AgileZen.com ——基于 web 的看板工具
- LeanKitKanban.com ——另一个基于 web 的看板工具
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论