从Scrum到看板

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

我们的Scrum

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

迭代

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

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

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

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

日常生活

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

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

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

的角色

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

我们没有Scrum管理员，相反，我们有发布管理器。 这个角色有点混乱，因为它在任何实践中都不会出现。 在我们的环境中，发布管理器的工作方式更像传统的项目管理器。 并非我们拥有的所有项目都具有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。但是，这比说起来容易，因为故事经常受外部因素的阻碍，我们需要做其他事情。

规划

没有迭代计划了。 相反，只要“任务”列中有新故事，我们就会进行计划。 这个故事既要由一对负责，也要由一对来评估，而不是收集整个团队的意见。

有点不自然是由于我们的多任务处理性质，一对直到部署到UAT才遵循Tasking的一个故事。 为了解决这个问题，我们经常需要回到执行任务的团队来寻求解释。

演示版

我们仍然需要估算，但是没有固定的演示时间。 在团队与版本经理之间的例行会议上，最常被问到的问题是“您今天有什么要演示的吗？” 最受欢迎的答案是“不”。

估算值

中止Scrum时，我们还将中止Story Point Estimation。 我们仍然将花费的精力与估算的精力进行计数，但这仅供参考。 从去年起，按双日移动回估计了。

我们的感觉

那么，经过一年的看板练习后，我们感觉如何？

我认为这是一种混合感。 从好的方面来说，您所担心的事情更少，对保持的承诺更少，并且更加专注于发展。 此外，我们每天早晨都有大屏幕可供观看。

但是，事情并不都是美好的。 我不知道我们是用错误的方式看板还是看板只是自然而然的事情，开发人员从头到尾都不会遵循一个故事。 一个人可能会按照他的技能设定来编写故事，其他人最终会完成工作。

而且，我觉得看板对待每个开发人员都是平等的，事实并非如此。 如果“建筑专栏”中有一个故事并且您有空，那么无论您是否熟练，都必须接受该故事。 它妨碍了团队的生产力。 但是，也可以肯定地将其视为看板在开发人员之间培养技能和知识共享。

迁移到看板还导致开发人员将更多时间花在故事开发上。 没有压力要求交付，但是也存在过度交付具有特征的货物的趋势，这些特征未包含在“验收标准”中。

对我们来说，对于Release Manager，他们似乎对过渡并不满意。 缺乏迭代只会使他们的计划变得更加模糊和困难。

翻译自: https://www.javacodegeeks.com/2014/05/from-scrum-to-kanban.html