看板组织开发新软件

Question

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

这种情况的最佳做法是什么？

Answer 1

首先，很少有团队为积压设置限制。看板建议正在进行的工作（WIP）限制。积压中的项目很少被视为“正在进行中”。

其次，考虑到你，或多或少，了解项目的范围，强迫自己人为地限制积压的项目数量是没有多大意义的。

同时你是对的，在积压中放几百件物品是没有意义的。董事会将过度拥挤，其实用性将大幅下降。

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

• 将史诗故事/功能保留在积压中，只有当您开始使用它们时，才能将它们分成详细的故事/任务。通过这种方式，您可以获得更少的项目，同时您仍然可以处理开发阶段的详细任务。

• 堆叠将成为应用程序相同部分一部分的故事。如果您已经拆分了范围，那么人为地隐藏这些信息是没有意义的。但是，您可以堆叠已连接或将同时完成的工作项。它使积压更清洁，一旦你开始构建项目，你可以很容易地将它们拆开。

• 暂存待办事项。如果您有一个粗略的计划，您的开发将如何进行，您可以有几个阶段的积压。早期的一个盒子，你可以存储你将要构建的所有功能（它甚至可以是连接到电路板的物理盒子），后来只能显示下一个时间段的工作。通过这种方式，您可以看到电路板上的物品较少，但从技术上讲，所有工作都在那里。

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

BTW：你可以在this presentation（幻灯片21）中看到其中几种技术的可视化。

Answer 2

我必须不同意：积压的限制是可能的。可能不在输入列中，但是例如如果进程具有一些优先级列，则最高优先级列可以包含限制，因此说可能不会推送到许多高优先级任务，因为WIP无法保持这样的速度并且它们将在那里停滞不前

Kanban board looks like this

Answer 3

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

我认为这是一个很好的策略，特别是对产品所有者而言。积压仅包含将在未来一段时间内开发的故事，而其他故事可能会出现在心灵地图或“心愿单”中。