Project management 看板/Scrum板

我很好奇其他人在他们公司的物理看板/Scrum板上使用了什么。我很感激，由于敏感的商业信息，您可能无法提供董事会的照片。我想了解一下你的董事会是什么样子的，以及在典型的冲刺/迭代过程中，你是如何组织用户故事和任务的

通常情况下，我在一个地方工作过，每个地方的董事会组织如下

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

因此，总结如下：

• UC-001的任务正在由团队的一名成员（Bob）执行。Todo列中等待其他人执行的任务列表，但这可以由团队的另一名成员执行，该成员与Bob协调完成工作
• 对于UC-002，支付服务任务已完成，QA的自动测试工具已完成，允许他们在没有UI的情况下测试服务。如果测试失败，将引发错误，并将其与支付服务任务一起移回QA阶段
• UC-003的所有任务均已完成，并已转移到准备进行QA
• Uc-004和Uc-005的所有任务都已完成，因此用户故事已移至完成

---

这就像一块有形的白板，让人们与每个任务/用户故事（以便笺形式表示）进行交互。电子版在冲刺/迭代之前创建，仅在冲刺/迭代结束时根据当前情况进行更新。欢迎评论和批评：）

在实践中，最好让团队根据您的情况和环境确定在建工作委员会的组织敏捷=自我管理

也就是说，这是我们在我之前的团队中所做的，这是300多个开发人员工作的一部分，对于敏捷和Scum来说是比较新的：

我们有两块板块——一块是为即将到来的故事准备的索引卡，这样我们就可以知道接下来会发生什么，另一块是当前sprint的工作

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

在角落里有一个方框，用于显示被阻止的

每个故事都有一张便条

开发人员每个人都有一块小磁铁，他们在每天早上的站立会议上用它来表示谁在做什么。我们的团队规模相当大（一度约12人），因此这确实有助于确定谁与谁配对

虽然我们的产品负责人确实有一个Scrumworks系统，他需要保持最新，但我们没有为电子版本而烦恼（没有意义）。我们尽可能远离它！
我们的看起来相当相似。每个开发人员都有一列，我们有“完成”、“正在测试”、“正在进行中的工作”、“积压工作”的行

我们使用实际的post-it风格的注释，当它经过每个阶段时，我们会进行物理移动

就我个人而言，我发现这个系统缺乏


手动移动post会在一段时间后变得很痛苦。我们的QA团队主要管理票据的移动-这是一个持续的努力，以使它们与TFS同步
帖子真的只能被移动很多次，然后它们就不再粘了。如果一张罚单从测试中发送回来，放在“进行中”，然后再移回测试中，等等……它不需要花很多时间就可以在地板上结束
有时，笔记的数量是巨大的。笔记必须堆叠起来，甚至可以在远处看到-我们将它们分层，以便我们可以看到每个笔记的唯一标识符（尽可能好）…但是你有一堆10个音符，你需要从中取出第5个音符，你会很快地减少粘性，最终这些音符会落在地板上
当票最终掉在地板上时，找出它们应该去哪里是相当烦人的。是开发人员A的票？还是B的票？是在测试中？还是已经完成了？让我们回到TFS，查找这些票，然后相应地移动帖子

个人，我不认为POST注解是合适的工具。有一些数字工具使这类事情完全无故障。我们使用Team Foundation Server，并且我见过一些很棒的、健壮的、免费的、甚至开源的工具，它们将与Team Foundation Server接口并管理所有THA。这是给你的，实时的
我们使用的灵感来自亨里克·克尼伯格（Henrik Kniberg）的名著，专栏根据上下文进行改编（通常为：待办事项、进行中、待测试、完成）：


产品待办事项（PBI）打印为Sprint计划会议（至少是最重要的会议）的“物理卡片”（A5格式）。一旦团队为下一次迭代选择了PBI，项目将被分解为任务/活动（在便笺上）.会议结束后，一切都在Scrum板上进行，我建议使用磁带、图钉或磁铁。PBI按重要性排序，最重要的在板的顶部，不太重要的在底部。团队应先处理最重要的项目，直到完成。首先，活动从左到右移动。然后，tPBI跳转到“完成”。意外的任务被添加到“计划外项目”区域（在燃尽图中考虑它们）。未来的PBI在“下一个”区域保持可见（如果所有项目都在迭代过程中完成，我们从中选择一个新的）。非常简单

这些做法允许目视检测气味，例如：


显示潜在障碍的停滞任务（即不移动的任务）
团队以错误的顺序做事，不关注最重要的项目，如您的样本：）
正在进行的工作太多，什么也没做
正在扼杀冲刺的计划外项目

效果很好

如果你正在寻找更多“看板导向”的东西，也许可以看看，来自同一个Henrik Kniberg。也很棒的东西

及

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

| (Sprint) Backlog | In Progress | Done |

| (Sprint) Backlog | In Progress | Ready for Test | Done |

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working