在Sprint Backlog测量吞吐量在哪里
与此同时,博姿公司推出了看板指南Scrum团队2018年,其4流指标在Scrum社区获得了更多的声望。亚博一百送一百它帮助Scrum团队摆脱一个新的视角关于如何管理产品待办事项列表中的待办项的流(PBIs)通过sprint backlog到生产环境中。
其中的一个指标,吞吐量,被定义为“单位时间完成的工作项的数量”。这个定义侧重于测量的项目,它不提供指导在哪里来衡量你的吞吐量工作流。我发现这可以成为一个问题的Scrum团队的价值和应用在他们的团队“完成”的定义。
根据Scrum指南,“完成”的定义是用来评估工作完成后的产品增量"。所以只要吞吐量是衡量当PBIs在生产和完成“完成”的定义?或者它应该测量当开发PBI递给了另一个团队/组?
作为导游不提供指导,我想提供三种情况我遇到过在过去。在这篇文章中,我描述我测量吞吐量PBIs时基于移动开发团队领域之外的责任。
每次接近生产
在我的第一个场景中,我们有一个Scrum团队,船几乎每天做PBIs到生产环境中。sprint backlog的工作流程是这样的:
为了更好地理解他们的sprint backlog工作流,每个列的下面是一个简短的描述:
- 准备:PBI sprint期间准备工作。它满足sprint目标或被认为是重要的开发团队。
- 在发展:PBI编码。
- 点评:工程代码评审通过拉请求等任务完成。代码合并到主分支。
- 等待部署:分段列PBIs保存从几分钟到几小时。CI / CD工具集可能帮助他们自动化这个过程。
- 完成:PBI是在生产环境中。
在这种情况下,他们的“完成”的定义是相当接近的Scrum指南。我建议他们测量吞吐量在“完成”列上。
另一个团队行动完成生产工作
在我遇到第二个场景中,我们有相同的工作流程如上,但有强烈的差别在“等待部署”列。在这个组织,另一个团队(例:下文团队)负责Scrum团队的工作转移到生产环境。
所以当PBI搬到“待部署”,这实际上意味着另一个团队将组织并将它移动到生产环境。Scrum团队构建标准化的“包”,然后进入生产由其他团队预定的日期和时间。
在这种情况下,我建议测量吞吐量PBIs出来的“审查”列。一旦PBIs“等待部署”,Scrum团队很少控制他们。不包括Sprint Backlog的“等待部署”列也可以选择继续关注PBIs Scrum团队所能控制的。另一方面,Scrum团队可能需要留意的PBIs“待部署”专栏,因为他们可以告知他们的阿宝PBIs被转移到生产的状态。
更多的工作下游
在第三个场景中,我发现它在大型组织更关注当下。在这种情况下,会发生更多的工作在PBI编码后的开发团队。换句话说,在PBIs下游有更多的工作。我看到在过去的例子有:
- 质量保证团队测试PBIs由Scrum团队开发的。
- 接受/业务测试由最终用户和/或中小企业批准PBIs。
- PBIs属于一个更大的整合,完成季度为例。
- 培训完成一整套PBIs之前搬到整个池的用户。
在第三个场景中,我建议测量吞吐量PBIs出来的“审查”列。在我看来,这就是Sprint Backlog的开发团队。在这一点上,他们的工作就完成了。作为他们PBIs可以在几周内投入生产,等待下游工作要做,Scrum团队测量吞吐量PBIs搬到生产没有意义。
结论
本文的目标是帮助读者斗争与测量吞吐量在正确的地点在他们的工作流程。正如我们所看到的在上面的场景中,我建议测量吞吐量Scrum团队的工作结束。这可以迷惑当我们应用“完成”的定义,因为它邀请Scrum团队评估他们的工作完成后的产品增量。这会误导人们总是测量吞吐量当PBIs进入生产。
虽然DevOps哲学桥下游Scrum团队内工作领域的行动,因为遗留系统的组织,我相信会有情况的Scrum团队必须放手PBIs才能投入生产。在这种情况下,我觉得这是很重要的有一个共同的理解,我们应该衡量Scrum团队的吞吐量。
如果你有兴趣学习更多关于看板在另一个上下文中,访问KanbanGuide.org。