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

简短的声明（译者注：即Sprint目标），并对其做出承诺。这将成为Sprint中所有工作的重点。

 

 

 

整个Scrum团队共同创建Sprint目标。产品负责人自然会指导Sprint目标的创建，因为他或她对实现产品愿景的下一步以及如何能够创造出最大价值最有发言权。Scrum团队应该把Sprint目标当做总是能够触手可及的事物一样做出承诺。（译者注：最后这一句的原文是“The Scrum team should commit to the Sprint goal as something always within reach.”因为这一句关系到对Sprint目标的准确理解，因此标注原文以便对照参考。）

 

开发团队每个Sprint通过构建产品增量来实现Sprint目标。

 

Sprint目标怎么用？

 

Scrum团队可以依据Sprint目标来为Sprint选择PBI，但从某种意义上说，Sprint目标甚至比单个PBI的总和更重要。Sprint目标在PBI之间建立连贯性（译者注：而不是一堆散落的PBI），这有助于创造有价值的产品增量。一个初始化Product Backlog的好方法是就是将其表达为包含许多Sprint目标的列表，由产品负责人和开发团队一起随着时间的推移将其渐渐细化为PBIs。

 

自主团队的成员必须能够自我管理，以完成他们的目标，而由开发人员进行排序的工作计划（Developer-Ordered Work Plan，Scrum Pattern之一，将在单独的文章中介绍）指出，开发团队必须能够自由地以他们认为合适的方式安排他们生产阶段的工作。Sprint目标是产品负责人用于影响开发团队潜在工作顺序的唯一机制（通过Sprint目标所传达的重要性来推断紧迫性）-- 当然，只有在得到开发人员同意后才可以。

 

在Sprint计划会期间，Scrum团队确定他们希望在Sprint结束时实现的目标；简而言之，这就是Sprint目标存在的意义。开发团队使用Sprint Backlog来定义如何完成这个Sprint目标的细节。如果开发团队认为他们不能完成Sprint目标，就应该和产品负责人一起对Sprint目标再次斟酌。Sprint计划会的一个关键产出就是，开发团队应该能够解释如何完成Sprint目标，以及如何知道自己已经实现了这个目标。解释的能力来自于对未来工作的透彻理解，这就提高了团队在Sprint中实现Sprint目标的概率。

 

开发团队对Sprint目标做出承诺。这个Sprint目标可以帮助开发团队众志成城，并有助于建立利益相关者对团队的信任。

 

Sprint目标对团队应该是可见的；例如，把它放在Scrum 板或其他信息雷达上。

 

为支持Sprint目标的实现，在Sprint期间，开发团队要确保Sprint Backlog一直反映最新的工作状况。Sprint Backlog的进展（比如在Sprint 燃尽图上显示的）就像Sprint期间足球场上的进展一样：虽然每一码的进展都会使球更接近终点，但价值是在球门上（译者注：球门和目标的英文是相同的，都是“Goal”，一语双关！）。有时也有可能在没有完成所有SBI的情况下完成Sprint目标（以某种方式）。这有助于团队处理突发事件，并使开发人员在每日Scrum会中灵活地改变他们的工作计划（译者注：在目标不变的前提下）。举个例子：突发的阻碍会威胁到开发团队交付完整的Sprint Backlog。在这种情况下，团队会自动采用Sprint目标作为 "B计划"，而不需要花费很长的时间重新规划。卡耐基梅隆大学[1]的一项研究报告指出，提前为中断做准备的团队比没有提前准备的团队要好14%。为中断做准备的团队比不做准备的团队完成一个不间断的任务间隔要快43%。这是一种为计划外的事情做准备的心态：当它们发生时，团队可以转到一个新的配置来处理它们，不需要外部辅导。

 

理