看板组织新软件的开发

Question

在我们的团队中，我们正在评估使用看板作为软件开发的组织工具。开发阶段将需要大约6个月的时间，团队由5人组成。我们将与客户达成一致的所有功能需求、业务规则和用例作为输入-换句话说，宏观需求。我们将把故事中的这些规则转换为看板的“原子”流程单元。看板本身将被用作绩效评估工具和进度路线图。看板“规定”每个阶段都有固定数量的故事，但由于软件是新的和复杂的，“故事”可能会有数百个-所以我猜在开发开始时将所有的故事都放在积压中不是一个明智的举动。

对于这种情况，最佳实践是什么？

Answer 1

首先，很少有团队设置积压的限制。看板建议进行中工作(WIP)限制。待办事项很少被认为是“正在进行中”。

其次，考虑到你或多或少知道项目的范围，强迫自己人为地限制待办事项的数量是没有多大意义的。

同时，你也说得对，把几百个项目放在积压中是没有意义的。董事会将人满为患，其有效性将显着下降。

组织积压的典型策略包括：

• 将史诗般的故事/特性保留在积压中，并仅当您开始使用它们时才将它们拆分为详细的故事/任务。通过这种方式，您拥有的项目要少得多，同时您仍然能够处理开发阶段的详细任务。
• 堆叠故事，这些故事将成为应用程序的同一部分。如果你已经分割了你的作用域，那么人为地隐藏这些信息就没有意义了。但是，您可以堆叠已连接或将同时完成的工作项。它使积压工作变得更干净，一旦你开始构建项目，你就可以非常容易地将它们拆开。
• Staging backlog。如果你有一个粗略的计划，你的开发将如何进行，你可以有几个阶段的积压。早期的一个是一个盒子，你可以在其中存储你将构建的所有功能(它甚至可以是一个连接到电路板上的物理盒子)，而后面的一个只显示下一段时间内的工作。这样一来，你在棋盘上看到的项目就更少了，但从技术上讲，所有的工作都在那里。

当然，只要看起来合理，混合所有这些想法是可能的，甚至是鼓励的。

顺便说一下:你可以在this presentation中看到其中几种技术的可视化(幻灯片21)。

Answer 2

我必须不同意:积压的限制是一种可能性。可能不在输入列中，但例如，如果进程有一些优先级列，最高优先级列可以包含一个限制，从而表明一个人可能不会推入许多高优先级任务，因为WIP无法保持这种速度，它们将挂在那里。

Kanban board looks like this

​

Answer 3

Henrik Kniberg在他的关于看板的免费书籍中描述了如何将WIP限制设置为backlog有助于首先专注于最重要的功能。

我认为这是一个很好的策略，特别是对于产品所有者来说。Backlog只包含即将到来的时期要开发的故事，而其他故事可能在思维导图或“愿望列表”中。