双轨Scrum

Posted 2021-04-25 ShineScrum捷行

◆ ◆ ◆ ◆

2017新年快乐

HAPPY NEW YEAR

◆ ◆ ◆ ◆

Kam Zaman
Reed.co.uk 

这篇文章的目的是让读者了解我如何在以前工作的地方实施双轨Scrum。关于双轨Scrum的大肆宣传已经有很多，但关于如何将其付诸实践的文章却不多。我希望这篇文章能给您一些关于如何将双轨Scrum相关概念应用于您工作场所的提示。

什么是双轨Scrum？

 它是一个框架，在这个框架里，产品开发团队持续探索什么是客户真正的需求，并且使用证据和原型去验证这些需求。一旦一个想法或需求得到验证，这个需求则以用户故事的形式表示，并被添加到产品待办列表中。

双轨Scrum主张产品负责人/产品经理，首席开发者，和UX / UI人员经常地把时间花在探索空间上，而团队中的其他人集中精力完成交付。因此，简言之，双轨Scrum有两个轨道（产品探索轨道(product discovery)和产品交付轨道(product delivery)），各有重点但目标一致：构建客户喜欢的产品。理论上听起来不错，但在实践中很难找到合适的平衡点。

我认为值得注意的是，想要采用双轨 Scrum的驱动力来自产品团队。这是他们想要的工作方式，我和其他的交付经理帮助产品团队在公司中实施这一变化。同样值得关注的是，从执行层面到市场人员，每个人都知道这是我们将要采用的工作方式。重要的是，他们理解我们的流程，也清楚他们怎样融入到这个流程中。这正是ScrumMaster、交付经理和敏捷专业人士可以对团队和干系人真正有所帮助的地方。

当我第一次阅读关于双轨 Scrum文章的时候，我很疑惑如果首席开发者总是忙于探索，双轨Scrum是如何倡导"精通"，"自治"和"目标"这些价值观的？这是否意味着在交付轨道上的其他人只是成为一个用户故事的消费者，且对他们如何感知要开发的功能很少有发言权？

我们做了什么？

我们希望交付团队的成员能灵活地轮岗到探索团队，就这一点我们达成一致意见。我们的技术堆栈是复杂的；在团队中我们有比通才更多的专家，技术上，将交付团队的成员自由地轮岗到探索团队中对于我们是有意义的。

我们决定团队中将有两个待办列表。探索待办列表中包含需要被验证的假设条目，这些条目需要被弄清楚是否有一些应该进入交付轨道，被交付团队中的工程师开发出来。我们验证假设的方法包括做AB测试、查看数据、直接和客户交谈、以及故事地图等。交付轨道仍然有自己的产品待办列表，一旦假设得到验证，在交付待办列表中就会创建一个或多个故事，这些故事通过链接，与探索待办列表中的条目相对应，这样我们就可以将故事链接到它们的来源。我们那样做很重要，是因为一旦一个功能进入交付轨道被开发和发布，我们就要重新检查探索待办列表条目，以进一步验证我们是否已经解决了最初识别的问题。这是非常重要的，因为只是探索一个问题，将用户故事推入到交付轨道中并不是终点。即使对于那些探索轨道中已经开始和已经推入到交付轨道中的条目，我们也需要不断地探索。

Scrum团队的主要目标是满足客户的需求。 我们发现，我们常用的Scrum发布周期，从识别一个想法到实际发布它，至少需要六个星期。 双轨 Scrum为我们提供了不同的视角去看待我们的产品开发流程，在那里我们安排专门的人员在探索轨道中工作。 我们不希望整个开发团队中出现沟通障碍，所以办法之一是通过精化会议促进探索轨道和交付轨道的人员沟通。 当我们感觉探索待办列表中的假设条目得到验证时，我们希望能够获得交付团队的反馈，而且我们不想等待六个星期，才能获得交付团队的验证假设。 我们都同意，为了让用户的故事更饱满，我们在每日站会后将有30分钟的精化会议。 然后从上午11点开始，交付团队独自在交付轨道上工作。

这里需要注意的一点是，我们在团队中有三个技能组，这允许我们能够将交付团队中的人员灵活地轮岗到探索团队。 我们有每日交付站会，并且每个人都参加（包括在探索轨道工作的人员）。 我们注意到，因为我们与交付团队去验证了我们的假设并精化了故事，交付团队不需要来自PO或UI / UX人员的大量输入。 我们还举办了探索站会，并鼓励交付轨道工作的人员来听听正在讨论的内容。

本文由ShineScrum翻译，王子君审核

英文原文

长按识别左侧二维码，阅读英文原文

2017年课程安排

点击下方“阅读原文”，可获取课程详细介绍

现在报名更享受“新年优惠”哦！