Scrum实例 - 冲刺未完成的故事

Posted 2021-04-25 敏捷变革中心

作者 | Michael K Sahota

译者 | 陈旭，BoB

授权出品 | 敏捷变革中心

冲刺未完成是指团队无法按期交付预先承诺的特性。本文介绍其原因及如何才能帮助团队摆脱类似的困境。

故事人物

• Steve - ScrumMaster也是这个故事里的英雄

• Paula - 产品负责人（PO）

• Tonia - 质监员（QA）

• Brad - 业务分析员（BA）

• Lan - 程序员

Steve发现Product Backlog并未由产品负责人和团队进行讨论和估算。团队按照Steve的建议，推迟了一次冲刺来进行Product Backlog的改进会议。

结果是Product Backlog顶部的所有用户故事都与产品负责人进行了适当的讨论，过大的故事被拆分成了较小的故事，所有故事都经过评估。他们现在已经完成了冲刺规划并启动冲刺，为世界上最小的在线书店开发功能。

刚开始冲刺时看起来还不错

在冲刺计划会议之后，团队已经承诺了五个故事。他们的整体冲刺目标是让客户的书可以被送达到客户手中：

• 作为图书买家，我想将我的书添加到我的购物车中，这样我就可以购买它 - 故事点：13

  
  

• 作为图书买家，我想告诉亚马逊我想把我的书运到哪里，这样我就能从一个方便的地方收到它 - 故事点：8

  
  

• 作为图书买家，我想看看我的书的运费和税金的价格，这样我就可以知道我对价格是否满意 - 故事点：3

  
  

• 作为图书买家，我想选择我的支付类型（万事达卡，Visa，AMEX，或PayPal），这样我就可以支付我的书 - 故事点：3

  
  

• 作为图书买家，我想快速支付我的书的费用，这样我就能想要的书买回家 - 故事点：13

  
  

• 作为图书买家，我希望收到一条确认信息，这样我就可以看到购买成功 - 故事点：2

这个团队马上就开始了前四个用户故事的工作。Tonia（团队质监员）前几天和Brad（业务分析员）一起工作，他们澄清了验收标准，Tonia设计了她的测试用例或测试计划。当验收标准不明确时，他们会与（产品负责人）Paula联系以获得最佳答案。

…但很明显，这些都是他们正在解决的大问题。

到了星期一，也就是冲刺的第五天，Tonia 已经完成了所有的工作，并渴望有一个应用程序来测试。事实上，她想知道为什么她还没有看到任何东西。由于缺少应用程序来测试，而且她发现团队还有其他事情要做，直到星期三（第7天）她终于有了第一个故事（将我要买的书添加到我的购物车中）进行测试。因为这是一个很大的故事，技术上很复杂，所以一天的大部分时间都是为了准备好运行测试。不过，到当天结束时，她发现了十几个问题，并将它们告知了团队的业务逻辑程序员Lan。

“将我要买的书添加到我的购物车中”显然还没有准备好。与此同时，另一个较小的用户故事堆积在Tonia面前，使她无法跟上测试。

到冲刺结束时，（产品负责人）Paula只接受了两个完整的用户故事：“查看我的带运费和税的书的价格”和“选择我的付款类型”；42个故事点中只有5个点被完成了，其他的都未完成。

冲刺出了什么问题？

大多数团队在开始使用新方法时都会遇到困难。我们故事中的英雄们为他们自己制造了三个问题：太多进行中的工作；过度承诺；和流水线。

太多进行中的工作

在冲刺的第一天，团队开始同时处理四个条目。这分散了团队成员的注意力，并减慢了所有条目的工作速度。首先，这个结果似乎有违直觉-我们期望条目启动的越多，所有的工作就可以完成的更快。然而，丰田在其精益生产系统方面的经验以及在“精益和敏捷量化的影响”研究中相似的经验表明，进行中的工作（WIP）越多，团队能完成的条目数量就越少，并有更高的缺陷率。

由于我们可以收集到的数据是相关的（例如，进行中的工作（WIP）越多，团队能完成的条目数量就越少），因此我们可以推测原因。更多的WIP将导致：更多的多任务处理、更少的聚焦时间、更多的交接以及对协作的限制。这些结合起来会伤害吞吐量和质量。

你们是否会限制正在进行的工作（WIP）数量？

过度承诺

每个团队都会对故事点所代表的有各自的理解，因此不会有共同的数字。在帮助人们进行评估时，我提供了一个帮助校准的指南：对于一个“2”或更小的故事，团队应该选择他们认为代表整个团队工作效能的1/5到1/10的东西。我还建议团队选择一个更大的条目，可能需要团队在一个完整的冲刺内完成并称之为'13'。大于'5'的条目通常具有足够的模糊性，以便团队在尝试工作之前将其拆分，这样他们就能更真实地了解所需的时间。

如果我们故事中的英雄们遵循了这个指导原则，那么他们就会知道他们的过度承诺相当大，并且实际上永远无法完成该冲刺。

流水线

最后一个问题是一个更先进的概念，一个团队在他们的前几个冲刺中不太可能准备好解决这个问题，但随着时间的推移，他们应该意识到这一点。该团队仍然使用传统的工作方式，每个任务都由专家角色按顺序完成。这可能适用于预先确定结果并且所有内容都可以排序的问题，但它通常不适用于软件开发或任何其他知识领域。

在Scrum中，团队跨职能工作，可以更好地学习和适应不断变化的环境。

然而，Steve的团队仍在学习这一点。Tonia，Brad和Ian都有他们的专业，并且在冲刺期间，做一些不属于他们专业领域的工作。这也称为Scrummerfall，对于以Scrum组织来说很常见，因为它通常是他们工作方式的最大转变之一，并且需要时间来进行这种转换。

这样做的结果是Tonia是唯一个进行QA测试的人，而团队的其他成员则忙于其他事情，尽管QA显然需要关注和帮忙。从长远来看，这意味着团队必须等待更长时间才能获得有关给定用户故事的反馈，从而阻碍他们学习并将反馈整合到未来冲刺中的能力，最终使整个项目的变更成本更高。

您的团队是否也在这些挑战中挣扎？

像许多仍在学习实践Scrum的团队一样，Steve的团队在早期的冲刺中并没有把一切都做好。然而，他们致力于从中学习，并且坚持这样做，使自己向一个高绩效团队更近一步。如果您发现您的团队或组织存在这些障碍，并且想要学习如何更好地处理它们，可以考虑参加一个我们的研讨会，在那里您将实际学习应对挑战的解决方案，以及如何帮助您的团队学习并开发潜力。

Scrum 实例是一个叙事风格的系列博客，旨在对人们，特别是新任ScrumMaster在接触Scrum的最初几年提供帮助。

双CST授课-Certified ScrumMaster 

(CSM中文认证课) 

- 北京（还剩3位早鸟票）

时间: 2019.7.12-2019.7.13

https://yihuode.io/activities/788

Certified Product Owner

(CSPO中文认证课)- 北京（还剩5位早鸟票）

时间: 2019.7.14-2019.7.15

https://yihuode.io/activities/790