在我们的团队中，我们正在评估将看板用作软件开发的组织工具。5人团队的开发阶段大约需要6个月。我们将所有与客户商定的功能需求、业务规则和用例作为输入——换句话说，就是宏观需求。我们会将故事中的这些规则转换为看板的“原子”流程单元。看板本身将用作绩效评估工具和进度路线图。看板“规定”每个阶段都有固定数量的故事，但由于软件是新的和复杂的，“故事”可能会有数百个——所以我想把所有故事都放在积压中发展不会是明智之举。
对于这种情况，最佳做法是什么？
问问题
462 次
3 回答
1
首先，很少有团队为积压设置限制。看板建议在制品 (WIP) 限制。积压的项目很少被认为是“进行中”。
其次，考虑到您或多或少知道项目的范围，强迫自己人为地限制积压项目的数量没有多大意义。
同时你是对的，把几百个项目放在积压中是没有意义的。董事会将人满为患，其有用性将大大下降。
组织积压的典型策略是这种情况包括：
将史诗般的故事/功能保留在待办事项中，并仅在您开始处理它们时将它们拆分为详细的故事/任务。这样，您的项目就会少得多，而您仍然能够处理开发阶段的详细任务。
堆叠将成为应用程序同一部分的一部分的故事。如果您已经拆分了范围，则人为隐藏此信息是没有意义的。但是，您可以堆叠已连接或将同时完成的工作项。它使积压工作更清洁，一旦您开始构建项目，您就可以完全轻松地将它们拆开。
分期积压。如果您有一个粗略的计划，您的开发将如何进行，您可以有几个阶段的积压工作。早期的一个是一个盒子，您可以在其中存储您将构建的所有功能（它甚至可以是一个附在板上的物理盒子），而后来的一个则显示仅在下一个时间段内工作。这样，您在板上看到的项目更少，但从技术上讲，所有工作都在那里。
当然，只要看起来合理，混合所有这些想法是可能的，甚至是鼓励的。
顺便说一句：您可以在此演示文稿中看到其中一些技术的可视化（幻灯片 21）。
于 2012-10-13T19:37:50.540 回答
1
我必须不同意：积压的限制是可能的。可能不在输入列中，但是例如，如果进程有一些优先级列，最高优先级列可以包含一个限制，因此可能不会推送许多高优先级任务，因为 WIP 无法保持这样的速度，它们将在那里挂起.
于 2013-03-19T08:29:28.153 回答
0
Henrik Kniberg 在他关于看板的免费书中描述了如何将 WIP 限制设置为积压工作有助于首先关注最重要的功能。
我认为这是一个很好的策略，尤其是对产品负责人而言。待办事项仅包含即将开发的故事，而其他故事可能在思维导图或“愿望清单”中。
于 2012-10-13T20:28:58.223 回答