看板/ Scrum板

Question

我很好奇其他人在他们公司中使用的物理看板/ Scrum板。我很欣赏因为敏感的商业信息，您可能无法提供董事会的照片。我正在寻找你的董事会看起来像什么，如何组织用户故事和任务，因为他们正在进行典型的sprint / iteration？

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

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 |

总结一下：

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

这是一个有形的白板，涉及人们与每个任务/用户故事交互（表示为便利贴）。在sprint / iteration之前创建电子版本，并且仅在与当前情况对应的sprint / iteration结束时更新。欢迎评论和批评：）

Answer 1

我们使用来自Henrik Kniberg的着名Scrum and XP from the Trenches灵感的东西，根据上下文调整列（通常：TODO，ON GOING，TO TESTED，DONE）：

alt text http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

产品待办事项项目（PBI）打印为Sprint计划会议的“实体卡”（A5格式）（至少是最重要的）。一旦团队为下一次迭代选择了PBI，项目就会分解为任务/活动（在便利贴上）。会议结束后，一切都在Scrum Board上进行，我建议使用磁带或图钉或磁铁。 PBI按重要性排序，最重要的是在董事会的最高层，在底层则不那么重要。团队应该首先处理最重要的项目，直到完成为止。首先，活动从左向右移动。然后，PBI跳转到完成。意外任务被添加到“未计划项目”区域（在燃尽图表中将其考虑在内）。未来的PBI在“下一个”区域中保持可见（如果在迭代期间完成所有项目，我们从那里选择一个新项目）。很简单。

这些做法可以直观地检测气味，例如：

• 显示潜在障碍的任务（即未移动的任务）
• 团队以错误的顺序做事，而不是专注于最优先的项目，例如你的样本：）
• 正在进行太多工作，没有做任何事
• 正在杀死冲刺的计划外物品

效果很好。

如果您正在寻找更多“面向看板”的东西，可以查看来自同一Henrik Kniberg的Kanban vs Scrum，One day in Kanban Land和Kanban and Scrum - a practical guide。很棒的东西。

并且，要获得更多图片，请尝试使用scrum+board，kanban，scrumban，scrum+kanban尝试Google图片。

Answer 2

以下是我们在TargetProcess使用的看板。我们不在任务级别上工作，只在用户故事和错误级别上工作。有时我们会创建任务，但不会在电路板上明确跟踪它们。

我们不估计用户故事和错误，但尝试将故事分成更小的（并取得了成功）。列是不言自明的。我们在经过测试列中累积项目，然后创建一个分支，对其进行冒烟测试并发布新版本。通常我们每两周发布一次新版本。

此外，该板还通过颜色编码向开发人员和测试人员显示负载和服务类别。

UPD。现在我们有几个小团队，并使用一个单板来跟踪http://www.targetprocess.com/3

中所有团队的进度

Answer 3

Scrum / Extreme编程故事板。

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

工作出现在左起第二位，并通过不同的完整阶段在整个过程中进展。

列名：未开始，刚开始，中途，几乎完成，准备展示（通过质量保证）

第一行专门用于修复错误 - 就像清除错误的固定优先级一样。

“辛普森一家”字符代表团队的每个成员。他们四处走动，所以我们可以看到谁在做什么。

Answer 4

我建议你看看Eylean董事会。 http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort 它可以满足您的所有需求，因为它具有直观的界面，统计信息，仪表板。它也适合任何过程，最重要的是它非常容易使用。该板允许您使用行在一块板上表示多个项目。所有行都可以一次显示，或者您可以从范围中删除选定的行。另一种解决方案可能是按类别进行任务分组和过滤 - 然后所有任务都可以在一个板和行上表示，但可以附加到不同的类别。 / p>

Answer 5

在实践中，最好将组织在制品工作委员会留给团队根据您的环境和环境来确定。 （敏捷==自我管理。）

那就是说，这就是我们之前团队所做的事情，这是300多名开发人员努力的一部分，对于Agile和Scum而言相对较新：

我们有两个电路板 - 其中一个带有索引卡，用于即将发布的故事，因此我们可以分辨出即将发生的事情，以及当前sprint的工作。我们在当前sprint板上的专栏只是

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

和Blocked角落的方框。

便条纸代表每个故事。

每个早上开发人员都有一个小磁铁，他们每天早上站起来表示谁在做什么。我们的团队规模很大（一次只有12人）所以这真的有助于找出谁与谁配对。

虽然我们的产品负责人确实拥有他需要保持最新的Scrumworks系统，但我们并没有打扰电子版（没有任何意义）。我们尽可能地远离那个！

Answer 6

我非常热衷于Lean / Kanban，我们一直在迭代我们的流程，最初是通过JIRA中的自定义工作流程，但鉴于企业版本中的管理复杂性，这并非完全无摩擦。我们现在已经扩展了对白板的使用，并决定使用白板迭代我们的过程一段时间，然后在JIRA中对其进行重新编码。以下是我们布局的示例：

• 我们是6位开发人员
• 当一个故事在开发中时，它就在开发人员的桌面上。同样经过审核，进行QA等等。这意味着电路板上的每张卡都代表了可操作的项目，并且还提供了相当准确的迭代进度快照。规则是，只有在特殊情况下，您的桌面上才能有多张卡。
• 我们已同意在Awaiting Review专栏中不要超过两张牌“堆积”。这保持了一定程度的“流动”。

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

这非常接近mapping the value stream，除了等待部署部分，这是一个解决QA无法QA项目的问题的黑客，直到我们在他们的服务器上部署它 - 我们部署3 /在2周的迭代期间进行4次。

我注意到，在“information radiator”上映射价值流时，我注意到的一件事是，它确实让人们真正关注需要完成的实际增值工作，这似乎跟不上商业价值发展并保持发展势头。

希望有所帮助！

Answer 7

我们正在试验我们正在运行的几个不同项目中的几个不同的电路板结构。一个项目具有我们可以使用的最基本结构：

| (Sprint) Backlog | In Progress | Done |

尽可能地，我们尝试使用单个帖子来表示故事的开发和QA活动。

上述结构对项目开发人员来说似乎没有问题，但QA成员一直在努力知道故事何时完成开发工作，以便他们可以执行他们对该故事的测试。我们发现自己将故事移动到进行中部分的“远端”，以表明开发工作已经完成并且QA可以接受该故事。当进行中部分填满时，这很快变得非常难以管理。

这导致另一个项目的第二次董事会结构迭代：

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

新添加的准备测试部分基本上成为了以前是进行中部分的“远端”的正式部分。从表面上看，这应该让QA成员更加清楚，但是这仍然引起了一些混乱，因为人们对准备考试的含义有不同的解释（我不会厌倦你这里有不同的解释。）

这导致了我们在另一个项目中使用的最新板块结构迭代：

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

这与第一次迭代的简单 Backlog ， In Progress 和 Done 部分相差甚远，但这似乎与为团队工作得很好。他们清楚地了解通过董事会的各个部分来讲述故事的意义，并且对于任何一个故事，它都清楚地描述了特定故事在生命周期中的位置。自从当前冲刺开始以来我们一直在使用这种结构（我们在10天的冲刺中已经过了9天），因此我们将在明天的回顾中更详细地探索这种结构。不完美我敢肯定，但如果它继续为正在试行它的团队工作，我们将尝试将其推广到我们组织的其他团队。

Answer 8

我们的白板分为以下列：

故事，未开始，请求/ Des / Dev *，同行评审，质量保证，完成

最高优先级的故事从上到下。 每个故事都可以有多个任务，因此我们使用一个大的postit用于故事，而较小的postit用于任务。任务从左向右移动。我们每天都会检查以确保我们正在处理最重要的故事。

我们在每个任务上使用粘性白色标签，其中工作人员将其首字母缩写。当它们完成并沿着一个新的白色标签移动它放在旧标签上以显示它可供任何人拿起。当所有任务完成后，故事也会移动到完成列，并且在站立时，所有完成的工作都会被计算出来并向上移动以在底部腾出空间以获得更多故事。

我们还为故事和任务添加了彩色标签，以指示阻止进展（蓝色表示来自另一个团队的阻塞，红色请求scrum master帮助）。我们谈论每个立场的障碍。

我们可以看到一个特定列中的任务太多，并将重点转移到完成。我们故意添加了审核专栏，以强调在完成质量检查之前，需要由其他人审核的工作。

*要求/设计/开发

Answer 9

我们看起来非常相似。每个开发人员都有一个列，我们有'Done'，'In Testing'，'Work in Progress'，'Backlog'的行。

我们使用实际的post-it风格的音符，我们在每个阶段都会进行物理移动。

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

• 一段时间后，手动移动它会变得很痛苦。我们的QA团队主要负责管理机票的移动 - 并且不断努力让它们与TFS保持同步。
• post-it真的只能移动那么多次才会变得不粘。如果一张票从测试中发回并放入“进行中”，然后又回到测试等等......它最终不会花费太多时间在地板上。
• 有时，大量的笔记势不可挡。必须将注释堆叠起来以便远程可见 - 我们将它们分层，以便我们可以看到每个注释的唯一标识符（尽可能最好）......但是你有一堆10个注释，你需要得到它排在第5位，你正在快速地减少粘性，这将以地板上的音符结束。
• 当门票最终落到地板上时，找到他们应该去的地方是相当烦人的。这是开发者A的票吗？还是B？它是在测试中吗？还是完成了？让我们回到TFS，查看这些票，然后相应地移动它。

就我个人而言，我不认为便利贴是适当的工具。有一些数字工具使这种事情完全无故障。我们使用Team foundation服务器 - 我已经看到了一些非常棒的，强大的，免费的，甚至是开源的工具，它们将与Team Foundation服务器进行交互并实时管理所有这些工具。

http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Answer 10

随着我们团队的进步，我们的董事会往往会加班加点。如果你有一个团队合作，我倾向于支持实体卡板，因为它鼓励我根据自己的经验进行更好的面对面交流。显然会有更多的开销，但让团队协同工作是值得的。我在物理板上看到的另一个优势是它有助于业务参与。远程利益相关者不仅可以登录并查看当前sprint中的进度，还可以将事情脱离背景，因为有时候卡片并不能说明完整的故事。他们必须进行对话并来到董事会，这可能是有益的，因为事情可以得到解释，这也意味着可以鼓励他们帮助解决障碍。然而，这并不仅限于物理板，但它有所帮助。

如前所述，我们的董事会随着团队需求而加班。通常我们从教科书scrum开始，但鼓励持续改进，通常最终得到scrumban解决方案。通过电路板可视化新工作流程可以反映这些变化。如果您有兴趣查看我们的hourglass scrum / Kanban board

，我最近写了一篇关于我们最新更改的帖子

我认为团队应该参与制作电路板，因为它可以帮助团队理解工作流程，而不是成为孤岛。此外，如果团队参与制作董事会，他们会更好地监督自己的流程，这有助于自我组织，因为这是他们投入的产品。

Answer 11

我们在公司采用了以下板结构。

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

车道被分配给特定成员。每个成员在我们办公室都有不同的工作，所以任务各不相同我们将我们要处理的内容添加到Backlog中，如果它接近截止日期，则将其移至Next Sprint。被阻止的绿色任务用于必须每天处理的连续任务。红牌表示任务的重要性，必须尽快完成。 如果我们需要由不同的部门完成某些工作，我们的董事会允许我们自由地合作并为彼此的泳道添加任务。

我们使用KanbanTool（Kanbantool.com）来可视化我们的工作流程并管理项目。它非常直观且易于使用。我们的团队沟通得到了极大的改善。