看板和scrum_看板是新的Scrum

看板和scrum

也许是我一直在初创公司度过的时光，但是尽管我非常珍视Scrum的想法背后的自组织团队和不断的反馈，但我不禁感到看板代表了敏捷的新高度，为我们提供了更多的灵活性并从中吸取了教训我们从精益中学到了东西。

Scrum

很多人倾向于认为敏捷意味着 Scrum –您知道它的发展过程：

而且我认为Scrum有很多优点。 它提供了清晰的结构， 这个团队需要做的（Sprint Backlog中），让他们专注于得非常好（积压固定冲刺的持续时间），然后让球队确定获得该工作的最佳方法完成。 它甚至为他们提供了一名教练（ScrumMaster），他的工作是确保他们拥有所需的东西，并摆脱障碍。

我喜欢它的反馈循环，用于不断检入，确保我们按计划进行，并且-当发现不符合要求时-根据需要进行调整：每天进行快速（最多15分钟！）会议以使团队同步，每个客户进行演示冲刺，定期进行团队回顾。 正如肯·施瓦伯（Ken Schwaber）所说，软件太复杂了，无法完全避免失败，为什么我们还是要这么做，因为失败是我们学习的方式！ 相反，我们需要的是一个框架， 该框架使我们能够尽快识别故障，以便我们可以从中学习并进行相应的调整（请参阅： 查找故障的框架 ）。

Scrum的限时Sprint长度问题

我渐渐不喜欢 Scrum的是它的限时冲刺。

与创业公司合作，Scrum的冲刺几乎总是太长 。 如果您的冲刺时间太长，那么发布就很少了（延误了收入），并且团队不得不等待太长时间才能适应不断变化的客户需求。 这很浪费，因为这意味着您将继续使用过时的信息。

另一方面，如果sprint太短，则需要将大型功能任意地分拆成较小的任务，这些任务对客户自己没有用，并且会混淆团队正在尝试实现的目标（请参阅： 看板开发过分简化 ） 。

我认识到Scrum的定长冲刺的优势在于可预测性。 如果我们使用长度一致的冲刺，则可以定义团队的速度来预测每个冲刺可以传递多少个故事。 或者，就像Scrum的规范一样，我们可以说：“在X发行之日，我们将提供这么长的功能列表。”

但是，由于相同的原因，我认为两周突然太长了 ，这种可预测性已不再现实。 技术进步越快，使我们能够快速构建和演示功能，它使客户改变想法的速度越快，它使我们学习和适应的速度越快，事物的变化就越快。 我们可以通过真正地使软件适应正确的解决方案来响应这些更改。 或者，我们可以盲目地忽略此信息，并顽固地继续前进，因为我们的冲刺尚未结束。

看板

看板使用不同的调度方法来应对这些挑战。 而不是时间盒装冲刺工作（看板没有冲刺），有多少功能团队可以在给定时间上工作看板看跌期权限制。

功能一旦完成，就会发生两件事：

1. 该功能可立即发布到生产中（团队希望这样做）
2. 该团队可以开始任何的下一个优先级最高的产品工作。 即使该项目是今天才学会的！

以下是看板板的示例，该板用于直观地跟踪每个功能的状态：

每列代表要素的状态，并且在每列下方（红色）是在任何给定时间允许处于该状态的要素的最大数量。 列的名称可以对团队有意义，但是您通常会在“待办事项”列中使用其他功能。 接下来，您将有1列或多列表示这是正在进行的工作（在这里，我们有开发，测试和发布）。 最后是“完成”列。

您不想在列数上太疯狂，否则您也会遇到效率低下的问题，但是将工作分为几个不同的州可以从看板中获得更多的优势：

1. 您可以根据团队的能力为不同学科指定不同的工作负载能力
2. 你得到你的团队的工作流程的可视化，实时状态，所以你可以不断地为他们发生 （他们有机会复合前）优化过程以及消除瓶颈（或其它问题）。

结果是更多的反馈，并且能够更快地适应该反馈。

不断发展的实践

我仍然相信Scrum包含了很棒的想法-例如自组织团队和不断的反馈-我们不应该只丢掉洗澡水。 但是，这些相同的想法仍然可以与看板的计划配合使用（请参阅看板和Scrum ）。

因此，我认为，敏捷方法的发展（与敏捷方法论一样）一直在从最有意义的实践中汲取灵感。 看板用于调度，Scrum用于自组织和反馈循环，以及XP （具有Lean Startup ！的一些新实践 ）用于技术实践 。

图片来源： Mountain Goat Software的 Scrum流程 ，看板： 看板和Scrum –充分利用Henrik Kniberg和Mattias Skarin

参考： 看板是来自The Hacker Chick Blog博客的JCG合作伙伴 Abby Fichtner 的New Scrum 。

翻译自: https://www.javacodegeeks.com/2013/05/kanban-is-the-new-scrum.html

看板和scrum