看板和scrum_从Scrum到看板

最新推荐文章于 2022-10-28 14:50:14 发布

danpu1174

最新推荐文章于 2022-10-28 14:50:14 发布

阅读量227

点赞数

文章标签：敏捷开发 java 大数据项目管理人工智能

原文链接：https://www.javacodegeeks.com/2014/05/from-scrum-to-kanban.html

版权

看板和scrum

从我们从Scrum转到看板的那一年起，这一个月已经过去了。我觉得现在是时候回顾这一变化的影响了。

我们的Scrum

我经历了两个实践Scrum的工作环境，但仍然有很大的不同。因此，如果我们从分享我们的Scrum实践开始，它可能会更有价值。

迭代

我们的迭代为时2周。我对持续时间很满意，因为一周的时间太短了，无法编写任何有意义的故事，而一个月的时间太长，无法计划或进行回顾。

我们的迭代从第一个星期一早上的回顾开始。中午之后的第二天，有迭代计划。在其余的迭代中，我们会根据需要进行编码。

我们的产品负责人要求我们在迭代的最后一个星期三进行两轮演示，即软演示，我们可以在开发机或Stage环境中展示新开发的功能。在迭代的最后一天，我们假设对UAT环境进行最终演示，以使故事被接受。

敏捷强调适应变化，但我们仍在进行T + 2规划（前面有两次迭代）。通过这种做法，我们非常了解至少要提前一个月交付或进行哪些工作。如果有紧急工作，将重新计划迭代，并将某些故事推回到下一个迭代。

日常生活

我们的日常生活始于早晨警报。过去，一些古代编码员制定了在办公时间使用闹钟的规则。敲响警铃后上任的任何人都将向团队基金捐款1美元。这笔资金可用于举办回顾性户外活动或购买咖啡。老实说，我喜欢这个主意，即使它有效地使我的月收入减少了22美元。

15分钟后，我们又为每日起床量发出警报。这个短暂的时间应该用来阅读电子邮件并赶上一夜之间发生的事情。我们的团队位于亚洲，但正在与欧洲和美国的项目利益相关者积极合作。这就是为什么我们需要这个简短的电子邮件检查会话来保持有意义的状态。

这实际上不是Scrum的做法，但是与大多数其他公司环境一样，我们需要在一天结束时填写时间表。使用时间表，我们可以跟踪花费的时间与估算的工作量，并以此来计算速度。

的角色

根据Scrum的指定，我们拥有开发团队和产品所有者。在我们公司中，产品负责人称为能力经理。目前，我们的管理层正在讨论是否应该将Capability Manager划分为两个角色，一个角色专注于产品的技术方面，另一个专注于业务方面。

我们没有Scrum管理员，而是我们的Release Manager。这个角色有点混乱，因为它在任何实践中都不会出现。在我们的环境中，发布管理器的工作方式更像传统的项目管理器。并非我们拥有的所有项目都具有Release Manager，但对于一些规模较大的项目，Release Manager可能会非常有用且非常繁忙。我们大多数产品是
SAAS应用程序和一些成功的产品可以在全球拥有100多个客户。 Capability Manager可以专注于产品功能，并让Release Manager处理故事计划，客户期限和较小的自定义。

关于Release Manager的工作是否需要技术背景，因为他们需要进行迭代计划，并且还有一些故事与技术相关，因此，还有另外一个讨论。

工具类

我们在日常生活中混合使用Excel电子表格，Jira和Rally 。

在转到Rally之前，Jira是过去的剩余工具。现在，我们仅使用Jira来跟踪支持记录和缺陷。

Rally是用于敏捷实践的在线平台，内置了对迭代，故事，缺陷，发布，积压等的支持。

即使有了这些工具，我们也无法避免使用过去的电子表格来跟踪团队资源（团队资源管道）并进行资源计划（资源矩阵）。

由于资源匮乏，我们仍然拥有多任务团队，这些团队同时处理很少的项目和很少的产品所有者。发行经理需要定期坐下来，为接下来的几次迭代讨价还价。

精神

正如我的一位朋友经常说的那样，Scrum的重点更多是精神，而不是实践。我完全同意这一点。应用Scrum的目的更多是要以Scrum的心态做事，而不是严格遵循书面惯例。就个人而言，我觉得我们在Scrum上的应用非常好。

首先，在团队协作中，我们将尽最大努力避免使其看起来像进度报告，而是信息共享和协作会议。有时，站立会比默认情况下持续15分钟以上，这是因为开发人员会花时间在现场阐述想法和进行讨论。发布经理或产品负责人不参加我们的日常活动。

我们的回顾是一场封闭活动，仅涉及团队成员。除非我们打电话给他们询问信息，否则发行经理和产品负责人都不会加入我们。每个团队成员轮流担任主持人。回顾的格式不固定。主持人的想象力决定了我们将为回顾做些什么。其余的只是坐下来，放松一下，等待下一步会发生什么。
计划会议包括任务分配和扑克风格评估游戏。由团队来重新估计（我们估计故事仍在积压中的一次），验证假设，然后安排并提交故事以很好地适合团队资源进行此迭代。有时，我们会进行一次小型辩论，以评估团队成员的估计之间是否存在较大差距。

为什么我们搬到看板

您可能想知道我们的Scrum是否运作良好，为什么我们搬到看板。好吧，这不是我们团队的决定。 Kaban始于英国总部，并扩展到其他地区。但是，与Scrum合作并不是一帆风顺的，让我与您分享我们面临的一些问题。

迭代结束时的资源利用率

这个问题在我们的办公室可能不是很严重，但是在其他地区却是一个大问题。由于技术上的困难，有时估计工作量很大。这在迭代结束时留下了很大的空白。如果差距足够大以安排另一个故事，那可能会很好，但在大多数情况下，事实并非如此。这产生了管理层想要解决的生产率低下的问题。他们希望消除迭代将消除这一虚拟差距，并使开发人员专注于交付工作。

迭代承诺带来的压力

通过致力于迭代中计划的故事，我们承受着交付它的压力。这些故事的开发时间预计为2周，但我们通常需要更快地交付它们，以配合周三的软演示和周五的最终演示。

更糟糕的是，我们的Web服务团队在其他地区，我们需要提前一天提高部署票证才能完成工作。如果部署票证失败，我们还需要一天重新部署。结果是我们是否发展得太快而无法按时完成任务，或者我们遵循估算，然后错过了承诺。

另一个担忧是评估和承诺开发人员不太了解并且仍然会因错过承诺而受到惩罚的压力。这形成了防御性思维定势，开发人员将尝试在他们所做的任何估计中包括安全缓冲区。

那我们看板

当我们搬到看板时，生活没有太大不同。为了好，我们有预算购买大屏幕。不好的是，我们不再进行迭代计划。但是，我们仍然在第一个星期一早上进行回顾。

看板

现在，我们在Rally中打开看板委员会以跟踪我们的开发进度。

我们用7列创建看板，以反映我们的工作流程

无（等于积压）
任务分配
建造
同行评审（仅在阶段部署之后）
部署到UAT
验收（故事由产品负责人签名）
部署到现场

产品所有者在积压中创建故事，这些故事将由Release Manager拖到Tasking列中。之后，开发团队有责任将此故事移至“部署到UAT”专栏中。之后，产品所有者有责任进行验证并接受。如果有任何反馈，则故事将返回到“建筑”列。否则，它会被签名并准备部署到生产环境。当发行经理要将接受的功能部署到Live环境时，这取决于发行经理。

作为看板练习，我们希望限制多任务处理并为每列设置容量阈值。配对时，我们的团队中有8位开发人员，每列的阈值假定不超过4。但是，这比说起来容易，因为故事通常受外部因素的阻碍，我们需要做其他事情。