Scrumban看板管理︱解析Scrumban从理念到实践
2022-11-05
来源：翰德恩业务敏捷 ，作者翰德恩翻译组
费的时间可以替换为质量控制检查。如果一个工作项的不合格，那么它将被退回，并对重复发生进行其根本原因分析。
四、卸下训练轮
如果你已经在发展中走到了这一步，你可能会意识到Scrum最初的机制已经不再对你有什么帮助了。在你建立一个更优化的解决方案时，Scrum是一个很有用的支架，可以将团队凝聚在一起。在某些时候，你可以蜕去茧，让拉动式系统展开翅膀，飞起来。
超越Scrum的第一步是将计划和发布周期分离开来。可能会有一个合适的节奏来批量处理特性以便发布，也可能会有一个合适的节奏来让人们一起计划。如果我们有一个更精简、更拉动式的规划方法，那么这两个节奏就没有理由相同了。你的运维团队可能想要一个月发布一次，你的产品经理可能想要建立一个每周的排序节奏。没有理由不迁就他们。
一旦你打破了时间盒，对待办事项列表的构建就将变得更精简。敏捷意味着响应需求的能力。待办事项列表应该尽可能经常地反映当前对业务环境的理解，也就是说，待办事项列表应该是由事件驱动的。基于时间盒的待办事项计划就是这样，事件是一个计时器，但一旦我们这样看待它，我们就可以想象其他类型的事件，使我们能够更快地响应的优先级。因为我们的系统已经展示了拉动（pull）和工作流，所以提高的响应能力不会影响我们当前的效率。
我们要尝试解决的问题是:
理想的工作计划过程应该总是为团队开发提供接下来要做的最好的事情，不多也不少。
超出此范围的进一步规划不会增加价值，因此这是浪费。scrum风格的时间箱式计划通常提供了比挑选下一个工作项所必需的更多的待办事项，因此，它是不必要的清单，是不必要的浪费。
对于计划活动的调度，我们可能要考虑的下一个事件是订购点的概念。订购点是触发订购新材料流程的库存水平。当我们接受来自待办事项列表的项目进入流程时，待办事项列表将减少，直到剩余的工作数量下降到订单点以下。发生这种情况时，通知会被发出给到负责的各方，让他们组织下一次计划会议。如果我们当前的待办量是10，我们的吞吐量是1/天，我们将订单点设置为5，那么这个计划将大约每周进行一次。
如果人们很难安排或需要一些准备时间来区分优先级，那么一周做一次可能是合理的。然而，如果它们比这更容易获得，那么我们可以把订购点设得更低。如果计划人员能在一天内做出反应，那么也许我们可以把订货时间定在2。如果订单点是2，那么可能没有必要保持10个待办。也许我们可以把待办的数量减少到4个，并在这个过程中减少6天的交货时间。
这种进化的最终状态是拉动，或按需排序。如果计划者能够足够快地做出一个好的决策，并且在批量的优先级决策中没有规模经济，那么待办的规模只需要为1。当工作指令被开发团队授权时，计划团队就被告知开始选择下一个工作。这种工作授权和信号的循环是拉动的基本机制。如果计划团队的反应足够快，那么开发团队将永远不会停滞。如果响应中有一些变化或延迟，那么可能需要积压到2来防止延迟。但2仍然比10小得多，也更精简。或20，或者50，这是我经常看到的情况。
同样的逻辑也可以应用于发布节奏。对于发布有一个最佳的节奏，我们应该首先尝试找到这个节奏，然后尝试改进它。我们努力的结果最终将是功能按需交付。即使在这个层次上，我们仍然有一个相当基本的看板系
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
