自 2003 年 Mary 和 Tom Poppendieck 的著作出版以来，看板已经成为软件开发领域中一种流行的方法。然而，在各种敏捷方法和实践中，它所占的份额从来都只有几个百分点。Scrum 及其定制化版本占据了主导地位。

看板已经占领了一个小市场，那里不需要应对具有挑战性的目标，采用的是“快速尝试/快速失败”的方法。通常，它会被提供各类服务的团队所使用。看板的另一个典型应用是那些处于维护模式或非常成熟的产品，只需要以适当的速度稳步增加新功能。另外，看板也经常被那些喜欢在不太具有挑战性和比较轻松的氛围中工作的团队所选择。这里的关键是开发人员的技能水平和/或员工整体的积极性。

事实上，Scrum 和看板在高压和低压环境下都很有效。然而，由于时间限制和详尽的计划，作为一种方法，Scrum 给开发人员带来的压力比看板更大。

在与我的讨论中，许多积极进取的高级开发人员表示，看板中缺少了承诺和专注，而他们希望保持高标准高要求，为的是能够一次次地享受了不起的成就。与此相反，Scrum 带来了时间盒和冲刺目标，很好地满足了他们的这种愿望。遗憾的是，软件开发并不总是意味着具有挑战性的目标，很多时候还需要处理无聊的任务、维护和增加零散的小功能。开发人员在试图确定冲刺目标时，经常会遇到困难，并且认为时间盒是一个相当恼人的限制，在运行 "非目标驱动 "的冲刺时，会造成不必要的开销。

Scrum 是为了应付错综复杂的问题（开放式系统，正确的方法是 "试一试，看一看"），在处理高难度（封闭式系统，完全可分析）甚至简单的问题时并不那么好用。看板可以很好地解决高难度问题，但是它并不是为那些不确定性很高的系统设计的，在那样的系统中，"尝试并失败/成功 "的方法更有意义。开放式系统的一个很好的例子是，一家公司刚刚形成自己的产品定位，并试图通过与客户的紧密合作来确定自己在市场上的位置。 而一家已经存在多年的、稳定的公司，拥有相同的客户和产品，只是在这里那里增加微小的功能，可以被认为是一个近似封闭式的系统。

为了克服敏捷方法的这些限制，同时保持其优势，我们提出了目标驱动看板。我们以看板为基础，用一些元素来加强它，以帮助开发者理解主要目标，关注它们，并做出承诺。同时，他们也可以轻松地处理那些难以确定目标、集中精力并做出承诺的任务。

看板价值、原则和实践的改良

自然，要想成功，我们就需要解决不同层面上的挑战。

首先，除了看板通常的价值之外： 

• 了解组织内的工作模式以及改变它的方法

• 一致同意持续改进

• 尊重当前的职责和角色

• 人人皆具领导力

• 以特定方式获得某些结果的流程

• 通过流程优化实现以客户为中心

• 保持所有层面的透明度，包括状态、风险、机会和决策

• 平衡观点、能力和各方面的意见，保证目标的达成

• 协作寻找解决方案，鼓励持续改进

我们建议增加两项：

• 实现既定目标的承诺

• 专注于实现目标所需完成的工作

其次，在看板原则上，除了下面这几项标准原则之外：

• 从你现在在做的事情入手

• 一致同意致力于增量的渐进式变革

• 尊重当前的流程、角色、职责 &职位

• 鼓励所有层面的人员发挥领导力

我们引入了一条新的原则：

• 选择下一个目标

最后，对于看板实践，除了以下各项之外：

• 可视化工作流

• 可视化不可见的东西：工作、工作流、风险等

• 限制在制品

• 实现拉动系统

• 监控、度量、优化，确保流程顺畅、快速

• 使流程决策显性化

• 流程如何运转，工作如何完成

• 完工定义、团队章程等

• 实现反馈循环

• 包括内部和外部反馈

• 包括但不限于：站立会议、交付审核、运营审核、风险审核等

• 协同改进，尝试进化

• 通常由 WIP 和反馈循环触发

• 需要团队成员达成共识

我们新增了如下做法：

• 为商定的目标设定一个自愿的最后期限，并为这些活动分配时间

• 在实现目标的过程中避免任何分心

• 达成目标时进行庆祝

看板价值扩展

承诺实现目标

目标是团队制定计划并为之奋斗的标靶。它可以是一个产品目标，解决技术债务，研究或学习。

该目标是团队的一项任务。在进入下一个目标之前，必须先完成这项任务。

专注于实现目标所需完成的工作

团队专注于实现目标所需完成的工作。团队要避免可能延迟甚至妨碍目标实现的事情。

重点是以团队利益和活动为中心。

看板原则扩展

选择下一个目标

每当团队上一个目标达成，并感到可以接受新的挑战时，就选择下一个目标。

选择下一个目标有助于团队铺就自己的道路，从一项成就到另一项成就，保持高标准，激励团队成员，让他们自由地找到为组织成功做贡献的最佳方式。

看板实践扩展

为商定的目标设定一个自愿的最后期限，并为这些活动分配时间

团队可以为实现商定的目标设定一个期限。这有助于团队集中精力进行与目标相关的活动，并给人以必要的紧迫感。

最后期限规定了完成目标的最晚日期。团队会尽一切努力去实现它。

时间分配有助于团队确保目标和相应的最后期限可以实现。这需要适当评估所需完成的工作和当前具备的技能，至少从表面上看是如此，还需要了解谁可以为目标的哪一部分做贡献，同时牢记团队成员各自的知识组合和技能水平。还必须将工作预测与团队能力指标做个比较，防止团队过度投入和出现倦怠的危险。

时间分配确保目标和最后期限可以实现，同时为额外/不可预见的任务留出适当的生产能力。时间分配是自愿的，不是从外部强加给团队的。

在实现目标的过程中避免任何分心

几乎所有团队都经历过在计划活动之外做“额外”工作的强大压力。这可能是来自利益相关者的额外需求，例如，与售前或新合同有关的需求，现有客户的紧急需求，缺陷修复，支持其他团队等。务必与团队的所有利益相关者达成明确的协议，以便他们知道团队的下一个目标，知道最后期限，并清楚地了解团队的能力可以满足他们的需求。

避免分心是很困难的。团队应该确定好如何处理这个问题，例如，是否制定一个明确的原则，每个团队成员都应该遵守，或者引入守门员的角色。

达成目标时进行庆祝

通过庆祝团队的成就提高团队成员的自豪感，增强团队成员的自信心，激励他们取得更大的成就，并促进团队的进一步发展。

庆祝活动让团队有机会准确地指出什么是有效的，这样他们未来就可以重复那样的做法。

经常回顾

当目标实现后，承认哪些地方做得好，以及我们如何能做得更好，为进一步改进提供了可能。

当目标没能实现时，了解发生了什么以及有助于达成下一个目标的措施就极其重要了。

目标驱动看板方法的关键在于能够并且愿意识别和追求挑战性目标的团队。 

注意：该方法并不将目标强加给团队。

前提条件：

• 团队希望能够自由地设定具有挑战性的目标，并享受实现这些目标的乐趣，同时不受时间盒和（有时间盒的）冲刺目标的限制。

• 正在践行看板或有丰富的看板知识。

• 熟悉目标驱动看板对看板价值、原则和实践的扩展。

• 讨论他们看到的、不同来源的各种目标：产品管理、架构师、其他团队、技术债务等。

• 选择要实现的下一个目标。

• 为实现目标商定一个现实但具有挑战性的最后期限，同时要考虑到所有其他情况，例如，额外的维护任务、缺陷、中断、其他团队的需求等。

• 在实现目标的过程中要避免分心。

• 达成目标时进行庆祝。

• 回顾性地审视实现目标的路径，并根据需要商定相关的调整。

• 可以暂停一段时间，如处理临时性的任务、修复缺陷、维护等。

• 重复这一过程实现下一个目标。

团队可自由选择下一个目标。

这是提升团队自主性、自我效能感和积极性所需要的。了解自己未来的道路并得到充分支持的团队会取得最好的成果。强迫团队实现某些目标会产生负面的影响。

团队可自由选择实现目标的最后期限。

最后期限是由团队根据目标的复杂性、不确定性、胜任能力和技能以及团队的能力来选择的。迫使团队在一个不现实的最后期限前完成工作，将导致过度投入，可能引发倦怠和整体的不愉快，破坏这里所提出的方法。

不以目标是否实现作为衡量团队及团队成员绩效的标准。

根据他们选择的目标来衡量团队的表现，将不可避免地导致团队选择非挑战性的目标，计划安全的时间缓冲，抱怨分心，通过所有手段对引入的 KPI 进行整体补偿，来达到安全目的。

团队可以在任何时候停止设定目标，继续使用纯粹的看板。

重要的是，当这里提议的方法明显不适合团队/组织/环境等时，要有选择靠边站的自由。

目标驱动看板实战

目标驱动看板应用是在一个团队中进行的。最初，该团队使用 Scrum。由于业务性质，该团队有相当比例的任务依赖于其他团队和不同的利益相关者。因此，该团队一直无法及时完成这些任务。自然，这导致了挫折感，于是团队决定改用看板。这解决了问题。但随着时间的推移，团队成员开始觉得他们就像是一个“功能工厂”，缺乏挑战。这样，目标驱动看板就诞生了。

在得到管理层的支持和产品管理部门的同意后，团队选出了他们的第一个目标。很快他们就发现，需要重新规划其他的功能和任务，因为团队必须重新聚焦到商定的目标上。这就需要对目标进行粗略的估计，了解团队的能力并与利益相关者达成进一步的协议。

在实现目标的过程中，团队必须应对各种挑战，因为门槛很高，团队必须一起进行整体设计和开发。这使我们更好地了解了每个团队成员的优势和劣势，并触发了团队成形过程。

目标完成后，团队与利益相关者一起庆祝了目标的实现，并得到了应有的赞赏，这将他们的积极性提高到了一个非常高的水平。

当然，他们回顾了所做的工作，并就更好地评估未来的目标以及决定用于其他功能和任务的能力达成一致。这有助于从利益相关者那里获得更多的支持，因为透明度高，可预测性好。

随着时间的推移，在从一个具有挑战性的目标到另一个目标的过程中，团队经历了不同的成熟阶段，最终学会了如何作为一个有机体而不是一群人，选择方向，做出决定，并成为一个真正的自组织团队。

这里介绍的方法是一个形式化描述，旨在使开发人员在寻找更多挑战时不会受到不合理的限制。你需要试验并思考，它如何在你目前的环境和限制下发挥作用：团队成员的技能水平、团队成熟度、产品和任务的性质以及适当的管理支持。更重要的是：要想成功，团队成员应该是真的非常希望进行尝试，理解他们要走的这条道路，以及他们愿意为之努力的目标。然后，神奇的事情就会发生了！

参考阅读：精益软件开发：敏捷工具箱

参考阅读：看板入门|完全指南

作者简介：

Anastasia Galeeva 是一位在敏捷转型方面经验丰富的 Scrum 大师，她致力于保证敏捷流程、活动和工件，并将 Scrum 的价值观带入生活中：承诺、勇气、专注、开放和尊重。

Mikhail Serebrennikov 是一名敏捷教练，曾担任工程经理、开发人员和架构。Mikhail 擅长帮助公司发展高绩效的敏捷团队和组织，并以可预测的交付成果为支撑，专注于战略方向。

原文链接：

Goal-Driven Kanban