看板/Scrum板[关闭]

我们使用的灵感来自于著名的 Scrum and XP from the Trenches 来自Henrik Kniberg,根据上下文改编的专栏(通常为:待办事项、进行中、待测试、完成):

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

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

• 显示潜在障碍的停滞任务(即不移动的任务)
• 正在进行的工作太多,什么也没做
• 正在扼杀冲刺的计划外项目

效果很好。

Kanban vs Scrum , One day in Kanban Land 和 Kanban and Scrum - a practical guide 来自同一个Henrik Kniberg。也很棒。

而且,要获得更多图片,请尝试使用谷歌图片 scrum+board kanban , scrumban , scrum+kanban .

这是我们在网站上使用的看板 TargetProcess . 我们不在任务级别上工作,只在用户故事和bug级别上工作。有时,我们创建任务,但在黑板上没有明确跟踪它们。

列,然后创建一个分支,冒烟测试它并发布新构建。通常我们每两周发布一次新版本。

此外,该板还显示了开发人员和测试人员通过颜色编码加载和分类的服务。

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

Scrum/极限编程情节提要。

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

作品出现在左栏的第二个栏上,并在不同的完成阶段全面展开。

列名: 未开始,刚开始,中途,几乎完成,准备展示(通过QA)

第一行是专门为bug修复保留的,就像清除bug的固定优先级一样。

辛普森一家的角色代表了团队的每个成员。他们四处移动以便我们能看到谁在做什么。

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

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

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

我们有 二

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

在角落里放一个盒子给我 Blocked .

每个故事都有一张便条。

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

虽然我们的产品负责人确实有一个Scrumworks系统,他需要保持最新,但我们并没有为电子版而烦恼(没有意义)。我们尽可能地远离它!

我对精益/看板非常感兴趣,我们已经对我们的流程进行了一段时间的迭代,最初是通过JIRA中的定制工作流进行的,但考虑到企业版本中的管理复杂性,这并不是完全没有摩擦的。我们现在已经扩展了白板的使用,并决定在JIRA中重新编码之前,使用白板迭代一段时间。以下是我们的布局示例:

• 我们是6个开发者
• 当一个故事在dev中时,它就在dev的桌子上。同样地,在被审查、被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     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

mapping the value stream 除了等待部署部分,这是一个修复问题的黑客,在我们将项目部署到他们的服务器上之前,QA无法对其进行QA—我们在2周的迭代中部署了3/4次。

我从将价值流映射到 information radiator “它确实神奇地将人们的注意力集中在需要完成的实际增值工作上,这似乎加快了业务价值开发的步伐并保持了势头。

希望有帮助!

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

| (Sprint) Backlog | In Progress | Done |

上面的结构对于项目的开发人员来说似乎可以正常工作,但是QA成员很难知道一个故事何时完成了开发工作,以便他们能够为该故事执行测试。我们发现自己把故事搬到了故事的“另一边” 进行中 进行中 部分已满。

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

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

新增部分 准备好测试了吗 基本上成为董事会的一个正式部分,以前是董事会的“远端” 进行中 准备好测试了吗 意思是(我不会在这里用不同的解释让你们厌烦)。

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

这当然远远不是简单的问题 积压 , 多恩 第一次迭代的各个部分,但这似乎对团队很有效。他们清楚地了解在董事会的各个部分中移动一个故事意味着什么,对于任何一个故事,都可以清楚地了解特定故事在生命周期中的位置。我们从当前的冲刺开始(10天冲刺已经过去了9天)才开始使用这个结构,所以我们将在明天的回顾中更详细地探讨这个结构。我敢肯定,这并不完美,但如果它继续在试点团队中发挥作用,我们将尝试在我们组织的其他团队中推广它。

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

故事,未开始,需求/设计/开发*,同行评审,质量保证,完成

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

我们在每个任务上都使用一个白色的标签,工作人员在上面写上他们的姓名首字母。当它们完成并移动后,会在旧标签上放置一个新的白色标签,以显示任何人都可以拿起它。当所有的任务完成后,故事也被移动到“完成”列,在站立时,所有完成的工作都被汇总并向上移动到黑板上,以便在底部为更多的故事腾出空间。

我们可以看到,当一个特定的专栏中有太多的任务时,我们会转移重点以完成更多的任务。我们特意添加了review列,以强调在工作进入QA之前,需要由其他人(而不是做这项工作的人)对其进行审查。

*需求/设计/开发

我们的看起来很相似。每个开发人员都有一列,我们有“完成”、“正在测试”、“正在进行的工作”、“积压工作”的行。

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

• 手动移动帖子一段时间后会很痛苦。我们的QA团队主要负责票据的移动,并不断努力使其与TFS保持同步。
• 这篇文章真的只能移动很多次,然后它们就不再粘了。如果一张罚单从测试中发送回来,放在“正在进行”中,然后移回测试中,等等……它不需要花太多时间就可以落到地板上。
• 有时,单是大量的钞票就让人难以承受。音符必须堆叠起来,甚至可以在远处看到-我们将它们分层,这样我们就可以看到每个音符的唯一标识符(尽我们所能)…但是你有一个10个音符的堆栈,你需要从堆栈中取出第5个音符,你很快就减少了粘性,而粘性最终将以地板上的音符结束。
• 当票最终掉在地板上的时候,弄清楚它们应该去哪里是相当烦人的。那是开发商的票吗?还是B?这是在测试中吗?还是完成了?让我们回到TFS,查找那些票证,然后相应地移动帖子。

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

随着团队的进步,我们的董事会往往会不断发展。如果你有一个团队的话,我倾向于使用物理卡片板,因为根据我的经验,它鼓励更好的面对面交流。显然会有更多的开销,但是让团队一起工作是值得的。我看到的另一个物理板的优势是,它有助于业务参与。远程涉众不能只是登录并查看当前sprint的进展,并将事情从上下文中删除,因为有时卡片并不能说明全部情况。他们必须进行对话并来到董事会,这可能是有益的,因为事情可以得到解释,这也意味着可以鼓励他们帮助解决障碍。然而,这并不是物理板所独有的,但它有帮助。

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

我们公司的董事会结构如下。

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

车道被指定给特定的成员。每个成员在我们办公室有不同的工作,因此任务不同。我们将必须处理的内容添加到积压工作中,然后在接近最后期限时将其转移到下一个Sprint中。阻止的绿色任务用于必须每天处理的连续任务。红牌表明任务的重要性,必须尽快完成。 我们的董事会允许我们自由协作,如果我们需要由不同部门完成某些工作,我们可以通过泳道向彼此添加任务。