Project management 看板组织新软件的开发

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

---

对于这种情况，最佳做法是什么

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

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

同时，你是对的，在待办事项中放入几百项是没有意义的。董事会将人满为患，其效用将大幅下降

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

• 将史诗故事/功能保留在待办事项中，并仅在您开始使用它们时将其拆分为详细的故事/任务。通过这种方式，您拥有的项目要少得多，同时您仍然能够处理开发阶段的详细任务

• 将要成为应用程序同一部分的故事堆叠起来。如果已经划分了范围，那么人为地隐藏这些信息是没有意义的。但是，您可以堆叠已连接或将同时完成的工作项。它使积压工作变得更干净，并且，一旦您开始构建项目，您就可以完全轻松地取消堆叠它们

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

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

---

顺便说一句：您可以在（幻灯片21）中看到这两种技术的可视化。

Henrik Kniberg在其关于看板的免费书籍中描述了如何将WIP限制设置为积压工作，帮助您首先关注最重要的功能

---

我认为这是一个很好的策略，尤其是对于产品所有者来说。积压工作只包含将在下一阶段开发的故事，而其他故事可能在思维导图或“愿望列表”中。

我不同意：积压工作中的限制是可能的。可能不在输入列中，但例如，如果流程有一些优先级列，则最高优先级列可以包含一个限制，即不能执行许多高优先级任务，因为WIP无法保持这样的速度，它们将死死地挂在那里

---

谢谢您的回答，非常清楚！我还发现你是PM信息的好来源