看板团队的Scrum入门教程

尤Yeret

Scrum方面

简短的描述

如何应用看板

承诺

人们个人承诺尽最大努力实现Scrum团队的目标。

致力于使用看板来提高您的绩效，以可持续的方式交付持续的价值流。

勇气

Scrum团队成员有勇气做正确的事情，解决棘手的问题。

你可能会说看板与勇气无关，因为它是渐进的，不需要太多改变。然而，如果你尝试过限制在件工作，跨价值流协作，或者从利用思维转向流思维，你会同意勇气对于看板的成功至关重要。

焦点

每个人都专注于Sprint的工作和Scrum团队的目标。

对于看板实践者来说，专注是很自然的事情。限制在制品是指整个团队在价值流中工作，专注于一些事情，而不是将团队分散得太分散。

另一个联系是看板帮助你关注重要的约束、瓶颈和其他流程问题。

开放

当我们一起工作时，我们同意

对工作和执行工作的挑战持开放态度。

如果我们真的想要看板来改善我们的工作，那么在相同的价值流中，对事物的位置、我们需要什么以及我们的改进想法保持开放的态度是至关重要的。否则，它只是一个花哨的可视化系统。事实上，如果我们不开放，看板甚至不会像那样有用。

使用看板，对于如何做事和使用改进模型，我们也有很多选择。

尊重

Scrum团队成员相互尊重，视彼此为有能力、独立的人。

在看板系统中工作的人应该将自己视为一个相互尊重的有能力且独立的社区。2022世界杯国家队排名

看板也反映了尊重人性的价值，通过寻求可持续的、健康的流动，通过承认他人的观点，通过不断寻找更好、更合适的做事方式。

Scrum方面

简短描述(根据Scrum指南)

如何应用看板

Scrum团队

Scrum的基本单位是一个小团队，即Scrum团队。Scrum团队由一名Scrum管理员、一名产品负责人和开发人员组成。在Scrum团队中，没有子团队或层次结构。它是一个有凝聚力的专业人员单位，一次专注于一个目标，产品目标。

Scrum团队是跨职能的，这意味着成员拥有每个Sprint创造价值所需的所有技能。他们也是自我管理的，这意味着他们在内部决定谁做什么，什么时候做，以及如何做。

自组织在看板中以多种方式可见。看板中的工作是拉而不是推。使用看板的一组人同意明确的策略，使成员能够围绕工作做出分散的、自组织的决策。他们还会自我组织，以协作方式进行改进，而不是让别人为他们“管理改进”。

在看板系统中工作的每个人/团队都有责任为伟大的流程和高质量的价值交付做出贡献，不仅仅是在他们所在的看板领域，而是从整个价值流的角度。

看板没有规定跨价值流的跨职能团队进行重组。话虽如此，许多实施看板的组织意识到，创建一个自主的跨职能团队对工作/价值流更好。

大多数组织倾向于创建一组更小、更简单、相对自主的看板系统，而不是跨越多个传统组件/子系统团队的大型看板网络

开发人员

开发人员是Scrum团队中致力于在每个Sprint中创建可用增量的任何方面的人。

开发人员从产品Backlog中选择要包含在当前Sprint中的项目。

开发人员计划必要的工作，以创建满足完成定义的增量

在看板中明确谁是看板系统中实际拉动工作的人，并授权他们确定何时/如何拉动工作并完成工作，这是很有用的。使用“开发人员”角色可以提供清晰度，并确保“拉”vs“推”

产品负责人

负责将增量交付的价值最大化的唯一个人。他们通过管理产品待办事项列表来做到这一点。产品待办事项列表管理包括许多产品负责人可以委托给开发团队的活动，但产品负责人仍然负责。

你有这些症状吗?

• 努力塑造多个利益相关者的需求
• 感觉团队陷入了分析瘫痪，试图弄清楚下一步该做什么
• 无法对某个想法说“不”或“现在不行”
• 缺乏责任感和产品方向

如果是这样，您应该认真考虑分配一个产品负责人。

Scrum Master

负责确保Scrum团队理解并实施Scrum框架的个人。Scrum Master还致力于消除开发人员可能遇到的任何障碍。

从看板的角度来看，为团队确定一个“过程教练”是一种有用的实践，无论你称他为Scrum Master、看板流程经理还是敏捷教练。在精益中，经理被期望成为过程的领导者。虽然看板中没有规定，但许多经理/领导承担了“过程领导者”的角色。Scrum在管理者应该扮演的角色上是中立的。

Scrum方面

简短描述(根据Scrum指南)

如何应用看板

冲刺

sprint是Scrum的核心，在这里，想法转化为价值。

它们是一个月或更短时间的固定长度的事件，以保持一致性。一个新的Sprint在前一个Sprint结束后立即开始。

实现产品目标所需的所有工作，包括Sprint计划、每日scrum、Sprint评审和Sprint回顾，都在Sprint中进行。

看板建议大多数团队有节奏地进行计划/补充、交付和过程回顾。

这种节奏不是强制性的，可以“按需”执行这些活动。然而，大多数团队只是在节奏上做得更好。

Sprint是一种特定的节奏，其目的是让跨职能团队一起工作以完成预期的工作。他们专注于在承担新工作之前完成工作，而这些新工作将危及团队的目标——本质上，就是在每个Sprint结束时“清理桌子”。这鼓励了协作，但对于看板团队来说可能会感到不自然和浪费，特别是如果他们已经通过关注流程和在制品限制下持续工作而获得了协作和群集效应。

Sprint计划

Sprint计划通过规划要为Sprint执行的工作来启动Sprint。这个最终的计划是由整个Scrum团队的协作工作创建的。

Sprint计划涉及以下主题:

为什么Sprint有价值?

这个Sprint可以做什么?

如何完成所选择的工作?

已经建立了有效工作流程的看板团队应该仔细考虑Scrum Sprint计划可能带来的好处。

通常，看板团队不会在评估上投入太多，而是更喜欢及时地分解工作。因此，这些团队将专注于为什么Sprint是有价值的，以及可以做什么，并在整个Sprint过程中演进“如何”。

Sprint计划的一个关键好处是，它确定了一个合理的工作量，从而避免把我们自己分散得太分散。换句话说，这是一种限制在制品的形式。好的看板团队已经限制在制品了，尽管是以不同的方式。

团队从举办Sprint计划活动中获得的另一个好处是作为一个团队一起制定一个Sprint目标。见下文。

每日例会

每日Scrum的目的是检查Sprint目标的进展情况，并根据需要调整Sprint Backlog，调整即将到来的计划工作。

每日Scrum是针对Scrum团队开发人员的15分钟活动。为了降低复杂性，它在Sprint的每个工作日的同一时间和地点举行。如果产品负责人或Scrum Master正在积极地处理Sprint Backlog中的项目，他们将以开发人员的身份参与。

优秀的看板团队每天在看板板前召开计划会议，作为他们的第一级反馈循环。Scrum和看板在这次会议的高层目标/目的上没有什么不同。

当涉及到会议的运作时，可能会有一些分歧。

看板团队通常关注工作流程，而不是做工作的人。他们从右到左研究流动问题。

Scrum指南强调的一个每日Scrum方面是对Sprint目标的关注，以确保战术决策与总体任务最好地保持一致。看板团队将受益于这种更高层次的关注，而不仅仅是特定工作的即时流。

冲刺评审

Sprint评审的目的是检查Sprint的结果，并确定未来的调整。Scrum团队向关键利益相关者展示他们的工作结果，并讨论产品目标的进展。

Sprint评审本质上是反馈循环的一个例子。看板团队可能只需要在需要的时候这样做，只要一些可交付的内容准备好进行审查。然而，经验表明，有一个节奏通常更容易让正确的利益相关者在房间里，总体上更高效和有效。

Sprint回顾

Sprint回顾的目的是计划提高质量和效率的方法。

Scrum团队检查上一次Sprint在个人、交互、过程、工具以及他们的“完成”定义方面的进展情况。所检查的要素通常随工作领域的不同而不同。书中明确了导致他们误入歧途的假设，并探究了它们的起源。Scrum团队讨论在Sprint过程中什么进展顺利，遇到了什么问题，以及这些问题是如何(或没有)解决的。

大多数看板团队也会进行回顾。同样，有些团队按需执行，但大多数团队将受益于规则、简单性和可预见性。

Scrum方面

简短描述(根据Scrum指南)

如何应用看板

产品待办事项列表

产品待办事项列表是一个紧急的、有序的清单，列出了改进产品所需要的东西。它是Scrum团队所承担的唯一工作来源。

看板团队在其面板左侧维护的不同队列可以被视为产品待办事项列表的可视化。看板团队限制了产品待办事项列表的大小和深度。

拥有一个有限的产品待办事项列表不应该意味着维护另一个不符合产品待办事项列表的待办事项列表项。这意味着积极地确保产品待办事项列表是相关的、可操作的，而不是一个包含所有要求的完整列表。

产品待办事项列表细化

产品待办事项列表细化是将产品待办事项列表项分解并进一步定义为更小更精确的项的行为。这是添加详细信息(如描述、顺序和大小)的持续活动。属性通常随着工作领域的不同而不同。

看板团队决定如何改进backlog。他们可以在现成故事的库存低于阈值时及时这样做，或者他们可以使用节奏。

承诺:产品目标

产品目标描述了产品的未来状态，可以作为Scrum团队制定计划的目标。

产品目标是Scrum团队的长期目标。他们必须在开始下一个目标之前完成(或放弃)一个目标。

看板可以帮助团队实现良好的流程。如果没有正确的目标，这种流程是无用的。Scrum产品目标可以提供这样的清晰度，它超越了看板上流动的特定票据/项目的短期目标。

Sprint Backlog

Sprint Backlog由Sprint目标(为什么)、为Sprint选择的产品Backlog项目集(什么)以及交付增量的可操作计划(如何)组成。

Sprint Backlog是开发人员制定并为开发人员服务的计划。它是开发人员为了实现Sprint目标而计划在Sprint期间完成的工作的高度可见的、实时的图像。因此，在整个Sprint过程中，随着了解到更多信息，Sprint Backlog会不断更新。它应该有足够的细节，以便他们可以在每日Scrum中检查他们的进度。

看板团队可能针对他们关注的整个目标有一个基于内容的积压，或者类似于Scrum的面向时间框的积压。

看板和Scrum的相似之处在于，实际的日常计划出现在工作中，而不是在详细的预先计划中。这两种方法都包含不确定性和持续的学习和反馈。

承诺:冲刺目标

冲刺目标是冲刺的唯一目标。尽管Sprint目标是开发人员的承诺，但它提供了实现它所需的确切工作的灵活性。Sprint目标还创建了一致性和重点，鼓励Scrum团队一起工作，而不是单独的计划。

对Sprint目标的承诺提供了一致性、焦点和目标的稳定性，当团队面临使许多产品待办事项项(pbi)不相关或增加新的pbi需要考虑的“风向变化”时，这些目标将引导团队。

许多看板团队使用史诗或特性的完成作为“目标”，但是将目标的完成与节奏对齐还有一个进一步的优势。

定义一个更细粒度的目标，在Sprint的时间框内，将增加焦点和一致性。

这种一致性可以将团队成员的注意力从高效地完成他们自己的工作转移到至少每个月都能产生重大价值的团队中。

增量

增量是实现产品目标的具体垫脚石。每个增量都是添加到所有之前的增量并经过彻底验证，以确保所有增量一起工作。为了提供价值，增量必须是可用的。

在Sprint中可以创建多个增量。增量的总和呈现在Sprint评审中，从而支持经验主义。然而，增量可以在Sprint结束之前交付给涉众。Sprint评审不应该被认为是释放价值的大门。

工作不能被认为是增量的一部分，除非它满足完成的定义。

看板并没有明确提到有一个潜在的可交付的增量。

看板团队在这里有几个选择:

• 使用类似scrum的Sprint增量
• 在完成具有市场价值的更高级别项目(如“功能”级别)时进行增量。
• 在完成每个产品待办事项列表/卡片时增加一个增量。
• 具有基于高度成熟的持续集成/持续部署能力的持续可用增量。这是比较困难的，但可以使整个Sprint边界的流程更加顺畅。

承诺:完成的定义

完成的定义是当增量满足产品所需的质量度量时对其状态的正式描述。

当产品待办事项列表项满足完成的定义时，增量就诞生了。

完成的定义通过向每个人提供对作为增量的一部分已经完成的工作的共享理解来创建透明度。如果一个产品待办事项列表项不符合完成的定义，它就不能发布，甚至不能在Sprint评审中呈现。相反，它将返回到产品待办事项列表以供将来考虑。

完成的定义是显式流程策略的一个例子。看板团队使他们当前的过程策略明确，并随着时间的推移而发展。这与Scrum的观点完全一致。

看板系统的工作流定义应该包括“完成”的清晰定义。