同时使用看板和Scrum

最后发布时间:2022年5月23日晚10:10
托马斯•本森
7回复
作者
消息
2021年3月18日下午12:20

我了解到,当一个团队在使用看板时,团队仍然可以使用Sprint事件(每日Scrum、Scrum回顾、Scrum回顾和Scrum计划)。在我的一个团队中,我们使用看板板工作了很长一段时间。我们希望开始将看板的使用与两周sprint的工作结合起来。这样做的原因是,通过使用看板而不使用sprint,我们错过了紧迫感:没有那么大的压力来真正完成工作。你们当中有人有过这种组合的经验吗?还是说这根本不可能,也根本不明智?

2021年3月18日下午12:29

是的,你当然可以将Scrum与看板结合使用。事实上,PSK1证书就是基于这个过程的。

下面的页面有Scrum与看板指南的链接,以及考试的建议阅读:

//www.ertascelikyapi.com/professional-scrum-with-kanban-certification

2021年3月18日12:57 pm

这样做的原因是,在没有sprint的情况下使用看板,我们错过了紧迫感:实际上完成工作的压力没有那么大。

在哪里完成的工作实际来自哪里?谁希望价值能尽早、频繁地释放出来,并在经验观察的基础上进行检查和调整?

虽然看板策略确实可以使用Scrum来实现,但是使用sprint来建立一种错误的紧迫感不会长期证明是有回报的。你可能得到的只是一个快速的糖兴奋。

2021年3月18日下午02:38

在Scrum中使用看板是完全有可能的。Scrum是一个足够轻的框架,所以看板的应用增加了一些额外的指标和方法来使用这些指标来支持Scrum事件。的Scrum团队看板指南是一个很好的起点,而Daniel Vacanti的书可预见性的可操作敏捷度量什么时候完成添加一些好的数据。

使用看板板来可视化工作流(并且可能限制正在进行的工作)只是看板的一部分。看板包括测量正在进行的工作量、吞吐量、工作项老化和周期时间,以提供对工作流有效性的洞察。当团队满足Sprint计划、每日Scrum和Sprint回顾的目标时,这些度量可以为他们提供支持。

用sprint来创造一种“紧迫感”的想法似乎是错误的。这并不是Sprint节奏的本意。有时间框的Sprint是限制团队限制正在进行的工作的一种方法,尽管没有应用看板工具那么严格。然而,更重要的是,它增加了一种可预见性。工作产品的交付有一个最小的节奏,团队与关键涉众同步的固定时间,以及用于回顾和过程改进的有保证的时间框。这并不是要在最后期限内给工作增加紧迫感或压力,而是要有计划、有规律地进行反思和调整。

2022年5月17日晚08:27

我们有一些产品待办事项清单项目,它们代表着我认为会被认为是简单工作的工作……也就是说,它会落入史黛西图的简单区域。在高层次上,这项工作涉及到将现有的数字请求表单转换为我们正在使用的新的数字工作场所工具。因此,我们知道要转换什么以及如何执行转换工作。

这项工作是总体产品路线图的一部分。关于产品路线图的其他工作是通过正常的Scrum框架完成的。

我已经和产品负责人讨论过这个工作,他觉得通过看板跟踪这个转换工作可能会很好。我在Scrum.org上做了一些研究,也阅读了《Scrum团队看板指南》。我有点困惑的地方是,在Scrum中,在我们的Sprint计划会议中,我们会估计可以拖到下一个春天的工作。考虑到这项工作不会存在于sprint中,而是在看板上被跟踪,是否有人对此有任何指导/指示应该)做什么?

提前道歉。我是一名新的Scrum Master,刚入职一个月左右,所以提前感谢您的耐心。

2022年5月18日上午06:57

他认为通过看板来跟踪这种转换工作可能会很好

关于这项工作,有什么值得追踪的呢?是否有立即可用的转换项目的吞吐量?

2022年5月18日上午10:37

我有一些想法和问题。

如果这个“简单的工作”和你在Scrum中做的其他工作是同一产品的一部分,那么它仍然应该在相同的产品Backlog中是透明的,即使有多个团队在做同一产品。

我不确定你说的“跟踪这个转换工作”是什么意思?如果目的是了解进展,当它完成时,你可以使用Sprint目标或产品目标(如果它需要多个Sprint),并使这些目标可衡量?

另一个想法。你的产品待办事项列表是你在Scrum中的计划。也许产品负责人会把这个“简单的工作”有序地安排下来。通过将这些工作分组,可以使正在进行的工作和剩余的工作变得透明,并且可能在Sprint Review中成为一个很好的对话

在Scrum中,在我们的Sprint计划会议中,我们会估计可以拖到下一个春天的工作。

一个小提示:“冲刺计划”开启了当前的“冲刺”,我们并没有在“冲刺计划”中为未来的“冲刺”做任何工作。你可以使用产品待办事项细化来理解未来的Sprint工作。

Scrum在

2022年5月23日晚上07:56

伊恩/克里斯。谢谢你的反馈。我和产品负责人聊过了,我现在清楚多了。所以,简短的概要是,我想多了。(-:只是为了和你们这些绅士们结束这个循环,因为你们很友好地回复了:

我们的产品目标是使用一种将在我们组织内实现的新技术创建一个一站式请求系统。我们目前有一个遗留系统,用户可以利用它来请求企业内部的各种服务。然而,那些遗留的请求将转到新系统,因此,需要一些转换工作,以使它们在新的系统/基础设施中可用。这些工作被视为早在我们Scrum团队及其产品目标形成之前就已经存在的技术债务。转换遗留请求所需的工作量各不相同,是一项持续的工作。因此,在我们各自的Sprint Planning会议中,我们不会将代表转换工作(技术债务工作)的任何pbi拉入各自的Sprint backlog中。相反,我们将专注于非技术债务工作,但使用看板的“拉”概念,允许开发人员在sprint中有“空白”时拉入转换卡。当然,开发人员会在AzDO中用正确的冲刺#标记PBI,这样我们就可以回去看看为了度量目的完成了什么。我想我困惑的地方是我在想PO实际上想要为这项工作维护一个文字/独立的看板。

希望这是有道理的。如果这听起来像是专家/经验丰富的人所担心的事情,我欢迎您的反馈。