29

我很好奇其他人在他们的公司中将什么用于物理看板/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) 进行。待办事项列中正在等待其他人完成的任务列表，但可以由与 Bob 协调完成工作的团队中的其他成员提取。
  • 对于 UC-002，支付服务任务已完成，并为 QA 完成了自动化测试工具，允许他们在没有 UI 的情况下测试服务。如果测试失败，则会引发错误并与支付服务任务一起移回 QA 阶段
  • UC-003 的所有任务都已完成并移至准备好进行 QA。
  • UC-004 和 UC-005 的所有任务都已完成，因此用户故事已移至完成。

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

4

11 回答 11

15

我们使用来自 Henrik Kniberg 的著名Scrum 和 XP 的灵感，列根据上下文进行调整（通常：TODO、ON GOING、TO BE TESTED、DONE）：

替代文字 http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

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

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

  • 显示潜在障碍的卡住任务（即不移动的任务）
  • 团队以错误的顺序做事，而不是专注于最重要的项目，比如你的样本:)
  • 正在进行的工作太多，什么都没做
  • 扼杀冲刺的计划外项目

效果很好。

如果您正在寻找更多“面向看板”的东西，也许可以看看Kanban vs Scrum，One day in Kanban Land和Kanban and Scrum -来自同一个 Henrik Kniberg 的实用指南。东西也很棒。

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

于 2009-11-27T20:22:18.957 回答
9

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

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

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

TargetProcess 看板

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

在此处输入图像描述

于 2012-04-19T21:48:38.887 回答
6

替代文字

Scrum / 极限编程故事板。

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

工作出现在左数第二列，并通过不同的完整性阶段全面推进。

列名：未开始、刚刚开始、半途、几乎完成、准备展示（通过 QA）

第一行是专门为修复错误而保留的——就像一个固定的、清除错误的优先级。

辛普森一家的角色代表团队的每个成员。他们被移动了，所以我们可以看到谁在做什么。

于 2009-11-27T22:08:44.637 回答
4

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

于 2014-02-14T08:04:33.777 回答
2

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

也就是说，这就是我们在我之前的团队中所做的，这是 300 多名开发人员努力的一部分，这对于敏捷和人渣来说相对较新：

我们有两块板——一块带有即将发生的故事的索引卡，这样我们就可以知道即将发生的事情，另一块带有当前 sprint 的工作。我们在当前冲刺板上的专栏很简单

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

和角落里的一个盒子Blocked。

便利贴代表每个故事。

开发人员每个人都有一个小磁铁，他们每天早上在站立时使用它来表示谁在做什么。我们的团队非常大（大约 12 人），所以这确实有助于确定谁与谁配对。

尽管我们的产品负责人确实有一个 Scrumworks 系统，但他需要保持最新状态，但我们并没有为电子版本而烦恼（没有意义）。我们尽可能地远离它！

于 2009-11-27T06:41:38.407 回答
2

我们的白板分为以下几列：

故事、未开始、Req/Des/Dev*、同行评审、QA、完成

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

我们在每项任务上使用一个粘性白色标签，工作人员在其中写上他们的姓名首字母。当他们完成并移动它时，一个新的白色标签会放置在旧标签上，以表明任何人都可以拿起它。完成所有任务后，故事也会移至“完成”列，在站立时，所有已完成的工作都会汇总并向上移动，以便在底部腾出空间容纳更多故事。

我们还为故事和任务设置了彩色标签，以指示进度受阻（蓝色表示来自另一个团队的阻碍，红色表示请求 Scrum Master 协助）。我们在每次站立时讨论障碍。

我们可以看到一个特定列中何时有太多任务，并转移重点以完成更多任务。我们特意添加了审查列，以强调工作需要在提交给 QA 之前由其他人进行审查。

*要求/设计/开发

于 2009-12-04T16:12:00.587 回答
2

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

  • 我们是 6 名开发人员
  • 当一个故事在开发中时，它就在开发者的桌子上。与被审查、被 QA 等一样。这意味着板上的每张卡片都代表和可操作的项目，并且还提供了迭代进度的相当准确的快照。规则是，只有在特殊情况下，您的办公桌上才会有一张以上的卡片。
  • 我们已经同意在“等待审核”列中“堆积”的卡片不超过两张。这保持了一定程度的“流动”。

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

除了等待部署部分之外，这非常接近于映射价值流，这是一种解决问题的方法，即 QA 在我们将其部署到他们的服务器上之前无法对项目进行 QA - 我们在一次部署期间部署了 3/4 次2周迭代。

从将价值流映射到“信息辐射器”上，我注意到的一件事是，它确实神奇地将人们集中在需要完成的实际增值工作上，这似乎加快了业务价值开发的步伐并保持上涨势头。

希望有帮助！

于 2009-11-29T14:55:16.267 回答
2

我们正在运行的几个不同项目中尝试几种不同的董事会结构。一个项目具有我们可以使用的最基本的结构：

| (Sprint) Backlog | In Progress | Done |

尽可能地，我们尝试使用一个便利贴来代表故事的开发和 QA 活动。

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

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

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

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

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

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

这肯定与第一次迭代中简单的Backlog、In Progress和Done部分相去甚远，但这似乎对团队来说效果很好。他们清楚地了解将故事移动到董事会的各个部分意味着什么，对于任何一个故事，它都能清楚地了解特定故事在生命周期中的位置。自当前 sprint 开始以来，我们只使用过这种结构（我们从 9 天到 10 天的 sprint），所以我们将在明天的回顾中更详细地探索这种结构。我敢肯定，它并不完美，但如果它继续为正在试用它的团队工作，我们将尝试在我们组织的其他团队中推广它。

于 2009-12-03T15:31:12.137 回答
0

我们的看起来非常相似。每个开发人员都有一列，我们有“完成”、“测试中”、“正在进行的工作”、“待办事项”的行。

我们使用实际的便利贴样式笔记，当它经历每个阶段时，我们会实际移动。

个人觉得系统不够用。。。

  • 一段时间后，手动移动便利贴会变得很痛苦。我们的 QA 团队主要管理工单移动 - 并且不断努力使它们与 TFS 同步。
  • 便利贴实际上只能移动这么多次，然后它们就不再粘了。如果一张票从测试中发回并放入“进行中”，然后移回测试等，等等......它不需要太多就可以在地板上结束。
  • 有时，大量的笔记让人难以抗拒。笔记必须堆叠起来才能远距离看到——我们将它们分层，这样我们就可以看到每个笔记的唯一标识符（尽可能地）......但是你有一堆 10 个笔记，你需要得到从堆栈中排到第 5 位，您正在迅速降低粘性，这将以地板上的音符结束。
  • 当票最终落在地板上时，找出它们应该去哪里是相当烦人的。那是开发者 A 的票吗？还是乙？它在测试中吗？还是完成了？让我们回到 TFS，查找那些票，然后相应地移动便利贴。

就个人而言，我不认为便利贴是这里的合适工具。有一些数字工具可以让这类事情完全没有麻烦。我们使用 Team Foundation 服务器——我见过一些非常棒的、健壮的、免费的，甚至是开源工具，它们将与 Team Foundation 服务器交互并为您实时管理所有这些。

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

于 2009-11-27T06:44:38.290 回答
0

随着我们作为一个团队的进步，我们的董事会往往会随着时间的推移而发展。如果您与团队并置，我倾向于使用实体卡片板，因为根据我的经验，它通常会鼓励更好的面对面交流。显然有更多的开销，但让团队一起工作是值得的。我看到的物理板的另一个优势是它有助于业务参与。远程利益相关者不能只登录并查看当前 sprint 中的进展，然后断章取意，因为有时卡片并不能说明全部情况。他们必须进行对话并加入董事会，这可能是有益的，因为事情可以得到解释，这也意味着可以鼓励他们帮助解决障碍。然而，这并不是物理板所独有的，但它会有所帮助。

如前所述，我们的董事会会随着团队的需求而不断发展。我们通常从教科书式 scrum 开始，但鼓励持续改进，通常以 scrumban 解决方案结束。这些变化通过看板可视化新的工作流程来反映。我最近写了一篇关于我们最新变化的帖子，如果你有兴趣看看我们的沙漏 scrum/看板板

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

于 2013-04-01T09:57:50.317 回答
0

我们在公司采用了以下董事会结构。

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

通道分配给特定成员。每个成员在我们办公室都有不同的工作，因此任务也不同。我们将必须完成的工作添加到待办事项列表中，然后在接近截止日期时将其移至 Next Sprint。被阻止的绿色任务用于必须每天处理的连续任务。红牌表示任务的重要性，必须尽快完成。如果我们需要由不同部门完成某些事情，我们的董事会允许我们自由协作并向彼此的泳道添加任务。

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

于 2013-11-14T13:11:53.767 回答