一文搞懂Scrum Pattern︱敏捷软件开发

中。这种实践拓宽了团队和企业的专业知识基础，并且也让团队不会惊讶于需要掌握某些新学科。

 

随着团队整合新的经验，他们会对产品有新的想法。变化将会非常迅速（而且必须允许它迅速）。变化将是常态，而不是例外。这需要小规模的组织，因为在小规模的组织中，每个人都知道正在发生什么：这些组织能够拥抱变化、跨专业工作、定期交付价值，用一个词来形容就是：敏捷。

 

03一个游戏

 

组建几个小团队，在游戏中竞争制作和飞行纸飞机。每个团队成员一次只能做一个折叠动作，然后必须换到另一个飞机上。任何飞机都不得有超过15个折痕。它必须至少有15厘米长，8厘米宽。它必须有一个至少2厘米宽的钝头。要成为优质产品，测试员测试时，飞机必须水平飞行3米。测试员对每架飞机只能测试一次。

 

试试这个游戏，并应用Scrum Pattern（提示：蜂拥模式）来优化在一分钟长的Sprint中生产的优质飞机的数量。

 

你已经为Sprint做好了准备，现在你正在开Sprint计划会，进行迭代计划。

 

Sprint目标有多重要？

Sprint的目标是为利益相关者交付价值。然而，简单地按照一个SBI（Sprint Backlog Item，Sprint待办事项；例如：任务）清单来做，不一定就能创造出最大的价值。如果团队按照单个任务或交付物来制定工作计划，就很容易在生产阶段（Production Episode，Scrum Pattern之一，将在单独的文章中介绍）选择单个待办事项，孤立地进行工作。如果这样的话，创新就被稀释了，因为创新是由对工作持有不同视角的个体进行互动而产生的。当工作孤立进行时，就像无形的办公隔间，可能会阻碍大家持续交流各种见解（这些见解不仅对一个开发人员，而且对许多开发人员甚至对整个团队来说都很重要）。没有充分的互动和沟通，团队合作就会受到影响。

 

 

团队可能需要部分重新规划正在进行的Sprint，以确保团队在Sprint结束时可以向利益相关者交付价值。随着时间的推移，团队会对工作有新的见解，可能会识别出新的工作，这时团队应该对计划做出相应调整。如果团队还是按照原来的计划行事，可能就无法创造出最大的价值。还有一种常见的情况是，在Sprint中途，团队感觉明显无法完成Sprint Backlog中的每个SBI，这通常是由于完成SBI所需的工作比预想的要多。此时团队仍然希望尽一切所能交付价值，这可能就需要通过重新规划来实现。重新规划Sprint的工作需要深思熟虑，并且需要时间。

 

另一种情况是，团队需要关于“如何实现一个PBI（Product Backlog Item，产品待办事项）”的重要技术知识，以便之后能够更有信心地开发它。比如开发人员（甚至是产品负责人）可能需要一个技术原型来验证一个建议的架构，或者了解一些技术的性能特点。这样的工作我们也把它做成一个PBI，不过这一类PBI的目标是帮助团队获取更多的知识，而不是完成一项功能。这样的技术原型是一种探索性的工作，耗时存在不确定性，因此它往往会处于Sprint成功的关键路径上，即它的完成与否关系到Sprint目标是否能够达成。（译者注：这样的PBI，我们称之为Spike，即探针。）

 

在某些情况下，最大的价值可能不是简单地实现一个PBI。例如，对团队来说，最大的价值是增加每个Sprint所能带来的经济收入，而团队只是用一个PBI来实现这个价值。另一方面，有时Sprint的大部分价值主要来自于很多PBI中的一个关键PBI。

 

因此：

Scrum团队为Sprint期间所要创造的价值书写了