logo标签列表

看板/Scrum面板

project-managementagilescrumagile-processeskanban
29

我对其他人在公司中使用的物理看板/Scrum看板感到好奇。我知道由于敏感业务信息，您可能无法提供看板照片。我想知道您的看板长什么样，以及在典型的Sprint/迭代中，您如何组织用户故事和任务？

通常情况下，我在这样的地方工作，看板的组织方式如下，每个任务都有不同的区域：

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的任务都已完成并移到Ready for QA。
  • 所有UC-004和UC-005的任务都已完成，因此用户故事被移至Done。

这就像是一个有形的白板，涉及到人们与每个任务/用户故事（代表着便利贴）的互动。在每轮迭代之前创建电子版，并仅在迭代结束时更新，以反映当前情况。欢迎评论和批评 ：）

1
顺便提一下，http://stackoverflow.com/questions/1156667/kanban-vs-scrum 上有一些关于看板和Scrum之间区别的绝妙答案。 - Jeremy McGee
是的，这是对于两者差异的一个很好的回答 - 有些人确实会混淆它们，因此问题的措辞涉及到了用于两个过程的板子，我更关心的是物理进度板以及人们如何使用它... - Jonathan Holloway
11个回答
15

我们使用受 Henrik Kniberg 的著名 Scrum and XP from the Trenches 启发的东西，根据上下文进行调整（通常为：TODO，正在进行，待测试，完成）：

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

产品待办事项（PBIs）被打印成“物理卡片”（A5格式）用于冲刺计划会议（至少是最重要的）。一旦团队选择了下一个迭代的 PBIs，就将这些项目分解为任务/活动（在便利贴上）。会议后，所有内容都移至 Scrum Board 上，并建议使用胶带、图钉或磁铁。PBIs 按重要性排序，最重要的在板子的顶部，不太重要的在底部。团队应该首先处理最重要的项目，直到完成。首先，活动便利贴从左边移到右边。然后，PBI 跳到 Done 区域。未预料到的任务添加到“未计划项目”区域中（以便在燃尽图表中考虑它们）。未来的 PBIs 保持在“下一步”区域可见（如果在迭代期间完成了所有项目，我们从那里选择一个新项目）。非常简单。

这些实践允许通过视觉方式检测出问题，例如：

  • 堵塞的任务（即没有进展的任务），这些任务可能会成为障碍。
  • 团队按照错误的顺序进行工作，没有专注于最优先的项目，就像您的示例一样 :)
  • 过多的进行中的工作，但什么也没完成。
  • 未计划的项目正在破坏冲刺计划。

效果很好。

如果您想了解更多“看板导向”的内容，可以查看来自同一位 Henrik Kniberg 的文章 Kanban vs Scrum, One day in Kanban Land 和 Kanban and Scrum - a practical guide。这些都是非常棒的资源。

此外，如果需要更多图片，可以使用scrum+board, kanban, scrumban, scrum+kanban在Google Images上搜索。

这是一种很好的任务安排方式 - 类似于我使用过的...感谢提供书籍链接，非常感谢... - Jonathan Holloway
不用谢。很高兴你觉得它有用。实际上，我发现Henrik Kniberg在通俗化方面做得非常好，他的作品是非常值得推荐的东西。 - Pascal Thivent
9
这是我们在TargetProcess使用的看板。我们不按任务级别工作，只按用户故事和错误级别工作。有时我们会创建任务，但它们不会在看板上明确跟踪。
我们不评估用户故事和错误，但尝试将故事分成更小的部分（成功率参差不齐）。列是自说明的。我们在已测试列中累积项目，然后创建一个分支，进行冒烟测试并发布新版本。通常我们每两周发布一个新版本。
此外，该看板显示开发人员和测试人员的负载以及服务类别通过颜色编码。

TargetProcess Kanban Board

更新。现在我们有几个小团队，使用一个单一的看板来追踪http://www.targetprocess.com/3所有团队的进展。

enter image description here

6

alt text

Scrum /极限编程故事板。

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

工作出现在左二列，通过不同的完成阶段逐渐向右移动。

列名: 未开始，刚开始，一半完成，几乎完成，准备展示（已通过QA）

第一行专门用于修复错误 - 优先清除错误。

辛普森家庭中的角色代表团队的每个成员。他们被移动以便我们看到谁在做什么。

1
你的项目经理是由尼德·弗兰德斯代表的，对吧？ :) - Jonathan Holloway
不是 - 他有自己的个性。他选择了一个卡通形象，看起来比他实际年龄要大得多。一定是压力造成的！;-) - Dafydd Rees
"喜欢你的“快完成”栏目。=> “我们快完成了，只剩下10%。”" - Martin Wickman
是的 - 我也不相信“快完成”！ - Dafydd Rees
4
我建议您查看Eylean board。http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort 它具有直观的界面、统计数据和仪表板，可以满足您的所有需求。此外，它适用于任何流程，最重要的是非常易于使用。该板允许您使用行在一个板上表示多个项目。所有行可以同时可见，或者您可以从范围中删除选定的行。另一种解决方案可能是按类别分组和过滤任务-然后所有任务都可以在一个板和行上表示，但附加到不同的类别。
2
我对精益/看板非常热衷，我们已经在流程上进行了一段时间的迭代，最初是通过 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     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

这很接近于价值流映射，除了等待部署的部分外，这是一个修补措施，解决了QA在我们将其部署到服务器之前无法对该项进行QA的问题 - 我们在2周的迭代期间部署3/4次。
从在“信息辐射器”上映射价值流的经验中，我注意到它神奇地使人们专注于需要完成的实际价值增加工作，似乎加快了业务价值开发的速度并保持了动力。
希望这有所帮助！
2

我们正在一些不同的项目中尝试几种不同的看板结构。其中一个项目采用了我们可以使用的最基本的结构：

| (Sprint) Backlog | In Progress | Done |

尽可能地，我们尝试使用一张便签来代表一个故事中的开发和QA活动。
对于项目中的开发人员来说，以上结构似乎运行良好，但QA成员很难知道一个故事的开发工作已经完成，以便他们可以执行该故事的测试。我们发现自己将故事移动到“进行中”部分的“远侧”，以表示Dev工作已经完成，而QA可以接手这个故事。随着“In Progress”部分填满，这很快变得难以管理。
这导致另一个项目的第二次迭代板结构：
| (Sprint) Backlog | In Progress | Ready for Test | Done |

新增的“测试准备就绪”部分本质上成为了之前的“进行中”部分所在板块的正式一部分。表面上看，这应该让QA成员更加清晰地理解，但实际上仍然会引起混淆，因为人们对“测试准备就绪”有不同的解释（我不会在这里详细说明各种解释，以免冗长无聊）。
这导致我们在另一个项目中使用了最新版本的看板结构：
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

这与最初版本的简单的待办事项，进行中和完成部分相比，显然是一个很大的进步，但这似乎对团队很有效。他们清楚地了解将故事从板的各个部分移动到何处以及对于任何一个故事，它都清楚地说明了该特定故事在生命周期的哪个阶段。我们仅自当前冲刺开始使用此结构（我们已经进行了9天的10天冲刺），因此我们将在明天的回顾中更详细地探讨这种结构。我确定它并不完美，但如果它继续为试点团队工作，我们将尝试在我们组织的其他团队中推广它。

2
我们的白板分为以下列：
故事、未开始、需求/设计/开发*、同行审查、质量保证、完成
最高优先级的故事从上到下排列。每个故事可以有多个任务，所以我们使用大的便签纸来表示故事，小的便签纸表示任务。任务从左向右移动。每天我们都检查一遍，确保我们正在处理最高优先级的故事。
我们在每个任务上使用一个粘性白色标签，工作人员在上面放置他们的首字母缩写。当他们完成任务并将其移动时，会在旧的标签上覆盖一个新的白色标签，以表明它对任何人都是可用的。当所有任务完成后，故事也会移到“完成”列，并且在站立式会议上，所有已完成的工作都会被统计，并将其移到白板的顶部，为更多故事腾出空间。
我们还为故事和任务准备了彩色标签，以指示进展中的障碍（蓝色表示另一个团队的阻碍，红色请求Scrum Master的帮助）。我们在每次站立式会议上讨论路障。
当某个特定列中的任务过多时，我们可以看到并调整重心以完成更多任务。我们有意加入了审查列，以强调需要由非执行者进行审查的工作，以便将其提交到QA。
* 需求/设计/开发
2
实际上，对于进行中的工作看板的组织最好由团队根据您的情况和环境来确定。 （敏捷==自我管理。）
话虽如此，以下是我们在以前的团队中所做的事情，该团队是300多名开发人员努力适应敏捷和Scum的相对新手：
我们有两个看板 - 一个是用于即将到来的故事的索引卡，以便我们可以知道接下来会发生什么，另一个是当前冲刺的工作。我们当前冲刺看板上的列非常简单。
Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

在角落里有一个方框标注为已阻止。

每个故事都用便条纸来表示。

开发者们每个人都有一个小磁铁，他们在每天的站立会议上使用它来表示谁在处理什么。我们的团队很大（最多12人），所以这确实帮助我们弄清楚谁和谁搭档工作。

我们没有采用电子版本（没必要），虽然我们的产品负责人确实有一个Scrumworks系统需要他保持更新。我们尽可能远离那个系统！

你是否对用户故事进行了拆分，还是只是说明哪些开发人员正在处理哪些用户故事？ - Jonathan Holloway
@Jon：我们的Sprint周期是（咽口水！）一周，所以通常每个“故事”只有一个便利贴。实际上，我们经常将故事拆分为更小的任务，并为每个任务准备一个便利贴。然后在Sprint结束时，我们会确保故事完成。 - Jeremy McGee
0
我们公司采用了以下的组织架构。
Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

泳道被分配给特定的成员。每个成员在我们办公室有不同的工作，所以任务也各不相同。我们将要处理的工作添加到我们的待办事项中，然后如果接近截止日期，就将其移动到下一个迭代中。被阻塞的绿色任务用于需要每天工作的连续任务。红色卡片表示任务的重要性，并且必须尽快完成。 我们的看板允许我们自由合作，并在需要不同部门完成某些任务时将任务添加到彼此的泳道中。
我们使用KanbanTool（Kanbantool.com）来可视化我们的工作流程和管理项目。它非常直观和易于使用。我们团队的沟通得到了极大的改善。
0
我们的看起来相当类似。每个开发人员都有一列，我们有“完成”、“测试中”、“进行中”和“积压”等行。
我们使用实际的便利贴式笔记，随着每个阶段的进行而物理移动。
就我个人而言，我认为这个系统还有欠缺...
  • 手动移动便利贴一段时间后会变得很麻烦。我们的QA团队主要负责移动工单，而且要不断努力保持它们与TFS同步。
  • 便利贴只能移动那么多次，然后它们就不再粘了。如果一个工单从测试中退回并放入“进行中”，然后再次移回测试等等...很容易让它掉在地上。
  • 有时，便利贴的数量太多，令人不知所措。为了使便利贴能够稍微可见，必须将它们堆叠起来 - 我们将它们分层，以便我们可以看到每个便利贴的唯一标识符（尽可能）...但是，你有一堆10张便利贴，需要取出第5张，这样你就会迅速减少粘性，最终导致便利贴掉在地上。
  • 当工单最终掉在地上时，找出它们应该去哪里相当麻烦。那是开发人员A的工单吗？还是B的？它是在测试中吗？还是已完成？让我们回到TFS，查找这些工单，然后相应地移动便利贴。

个人认为，便利贴并不是这里的合适工具。有一些数字化工具可以完全无障碍地完成这种事情。我们使用团队基础架构服务器 - 我见过一些非常好的、强大的、免费的甚至开源的工具，可以与团队基础架构服务器进行接口，并实时管理所有这些。

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

1
有一些好的工具...但当人们试图在实时中保持电子和物理板同步时，我会有点困惑...对每个人的偏好取决于团队使用哪种工具感到舒适。 - Jonathan Holloway
我们的磁铁帮助保持了便利贴在白板上的位置。此外，使用额外粘性的那种。 - Jeremy McGee
Rob P: 你为什么要保留白板和电子版本呢？顺便说一下，另一个与TFS兼容的好工具是http://scrumforteamsystem.com/en/TaskBoard/Default.aspx。 - John Rayner
我理解白板和电子版本必须以某种方式保持同步。不幸的是，这很麻烦...因此，Sprint 的开始/结束应该作为同步时间。 - Jonathan Holloway
1
我发现当我们让所有人参加站立会议时，我们强制人们去做正确的任务（因为它们具有更高的优先级），因为这是公开的事情，否则人们会选择有趣的事情并把不太有趣的事情留给别人。此外，一目了然地看到所有事情也很方便。我发现，对于电子软件，不是每个人都会查看其故事板。当你每天看到白板时，你没有借口不做正确的事情。 - Sam
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接