序  言

谈起敏捷，很多人并不陌生，可能你的公司依旧在使用瀑布开发模式，可能已经转型为敏捷或者DevOps，也有可能正在处在这个转型期。不可否认的是，这个开发模式已经越来越热，甚至很多在几年前接触到但是抵触敏捷开发模式的公司，现在也慢慢的开始转型。从互联网公司到银行，从欧美公司到国内企业。

本人在上述三种“可能”的公司里都工作过，也帮助过一些公司从瀑布模式转型敏捷，有了一些经验。工作之余喜欢思考，这里就和大家分享一些个人的想法和遇到的事情。希望大家多多指教，互相交流。

如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目  录

序  言.. 1

1   概述... 2

2   什么是Sprint目标... 3

3   如何制定Sprint目标... 4

4   如何使用Sprint目标... 5

5   案例：T小队的困惑... 6

1          概述

之前对Sprint目标理解有限，更注重一些形式，包括四大事件，然而在真正的项目中遇到了一些问题，迭代总是完不成等等。在思索的同时，刚好徐毅老师给提了个建议，团队重新审视一下什么是Sprint目标。笔者基于自己的理解，又回想过去的企业案例，写下此文，和大家分享一下。

2          什么是Sprint目标

我们先展示一下Scrum 指南上对此的解释。

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

这里我们可以看到几点。

i.Sprint目标是在Sprint计划会议上得到的。我们都知道在计划会议上，产品负责人会先澄清需求然后和团队讨论出本次Sprint哪些需求，当梳理完需求后，产品负责人根据优先级，定下Sprint目标。

ii. Sprint目标并不等价于Sprint待办列表。列表项是基于优先级，以及团队在这个Sprint中可以付出的工作量选出的，而Sprint目标是产品负责人在本次Sprint中最希望能得到的，它经常小于等于Sprint待办列表。Sprint列表项是团队承诺的，但是我们更要关注目标，因为这个优先级更高。在实际工作中，如果真是受到某些干扰完不成所有的Sprint待办列表项，我们要把有限的精力拿来完成目标。

iii.Sprint目标的内容是什么构成的不是最重要的，它的目的是来促使开发团队一起工作而不是分开独自做。我们传统的瀑布开发，是项目经理安排好谁做哪些任务，然后自己根据计划去做就行了，合作这件事儿，更多的是等到了某个人需要别人帮助的时候才会开始。敏捷环境下，我们更强调的是协同、合作，开发人员、测试人员在一起为了一个共同的目标使劲，当开发完毕，测试人员可以立刻开始测试，团队的注意力都在这个目标上，会让我们更高效。

iv. 开发团队必须在工作中时刻谨记 Sprint 目标。如果团队的某个成员那里出现技术或者资源问题的时候，由于Sprint目标是团队的，其他成员更容易会主动来帮助完成目标。而不是任务卡在该成员那里很久，然后才慢慢解决，导致在制品持续时间过长，产生浪费，交付的还慢。

3          如何制定Sprint目标

首先，产品负责人应该知道当前Sprint最需要完成的功能是什么，然后根据团队的能力来定。比如Sprint待办列表项是团队本次迭代工作产出量的80%，那么目标应该小于等于它。如果目标定的过大，就会出现两种情况，要么第一个Sprint开始团队就完不成目标，造成目标没有意义，要么前几次Sprint团队赶目标累得要死要活，最后丢掉了敏捷提倡的高效、不加班这个可持续性发展。

在每个Sprint期间，我们是不建议更改目标的。但是每个Sprint做目标的时候，我们要根据上一个Sprint的完成情况调整我们做目标的方式。比如之前做的目标太大，每次都完不成，那么我们这次就要根据比较计算，调小一些，使得Sprint目标能在团队完成的范围内。

那么，在Sprint过程中，增加了需求，是否改变目标。我们都说Sprint过程中不提倡更改待办列表，但是有时就会遇到必须加的情况。那么我们在更改待办列表的时候，首先评估一下是否会对我们Sprint目标的完成造成影响。如果是的话，那么优先级是怎样，产品负责人你来决定。如果总是出现Sprint中更改或增加需求导致Sprint目标受影响，那么这就是问题了，我们要反思一下为什么会出现这种情况。举个例子，有个公司，老板兴冲冲的准备让公司转型敏捷，结果公司上下并没有真正的领会敏捷的精髓，产品负责人不能在Sprint开始的时候确定一个Sprint中需要完成的需求，随便放一些需求当做待办列表。然后在Sprint执行过程中，借拥抱变化之名，随意增加新的Backlog，将正在开发的Backlog移出当前Sprint。大家可以想想这样会造成什么结果？就是团队目标不明确，明了也没用，反正过程中会改，然后团队又混混沌沌的做工作，没有方向和信念。

最后，我们不能为了应对目标，降低了质量。Sprint时间盒的作用下，大家节奏感很强，比如周五是Sprint的最后一天，周四下午了需求才做起来，大家为了“完成”Sprint目标，开发人员编代码速度飞起，也不搞接口测试了，测试人员拿到产品时时间也不够了，索性不回归测试了，最后验收功能的时候各种Bug。表面上看我们在参加评审会议之前完成了需求，实际上按照敏捷的思想，完成的定义是你这个需求完成相关要求的测试，质量达标才行。

4          如何使用Sprint目标

首先，我们通过这个目标，让团队有个方向性。就像之前我讲看板方法的时候提

到的例子，一些曲别针用绳子串到一起，如何能快速的通过一个狭小的缝隙。答案就是我们去拉动它，这样团队的目标一致，都冲着它使劲，聚焦于它，最终使得我们实现了快速交付。

      其次，在Sprint评审会议的时候，我们首先要拿出来之前制定的目标是什么，是否完成了这个目标。如果完成了的话，团队可以选择个庆祝的方式；如果没有的话，团队要在回顾会议上总结原因并化为行动方案。由此可见，两个结果都会激励团队在之后的Sprint中，更专注于目标，并为之行动。

5          案例：T小队的困惑

下面给大家带来一个之前在客户现场遇到的案例，我们称之为T小队吧，一起看

看T小队在Sprint中遇到了什么样的困惑，又是如何解决的。

      这是T小队转型敏捷做的第一个Sprint。团队由前台开发、后台开发以及手机端安卓开发、IOS开发组成，做的是一个互联网产品，主打手机端，由于资金有限，团队没有测试人员。由于是转型敏捷后的第一个Sprint，所以团队也是在摸索着工作，开Sprint计划会议，团队领了任务，开始开发活动。到了Sprint最后一天的时候，我发现一个现象，整个团队氛围很轻松，上午的时候成员都跑到楼下超市买零食休息了，除了那个唯一的安卓开发人员小A，就他一个人还在努力的干活，直到评审会议召开之前，小A才勉强完成工作，同时也是团队Sprint需求的最后工作做完了。

      在本次Sprint回顾会议上，小A主动说起了这个情况，我们也才知道背后的故事。团队构成比例不协调，手机端三个开发，一个安卓两个IOS，在这种情况下，同样的需求，小A承担的工作是别人平均承担的两倍，所以最后造成了大家都干完了活去休息了，小A为了完成需求就得独自一人坚持工作，身体疲惫的同时心理也不痛快。这是一家小公司，老板的资金无法多招人来解决问题，最终还是得团队讨论个方案。团队成员在听到小A的心声之后，也展开了讨论。团队发现，他们忽视了Sprint目标的意义。在敏捷里，虽然每个人自己领取自己的任务，但是是团队对Sprint目标做出了承诺，也就是说，其他人只看到自己完成了自己的任务后就休息了，并没有发现小A这里有风险，最终可能会导致Sprint目标完不成，这就是所有成员的事儿了。

      最终讨论的结论是，下个Sprint起，如果小A这边工作还是比较多的话，IOS开发人员在自身能力不够同时做安卓开发的情况下， 可以帮助去做代码评审以及UI的测试，减轻小A的压力，让团队能够顺利的完成目标。

      之后的Sprint我没有再去参与了解T小队的工作状况，但是我知道，他们现在找到了让团队朝一个方向努力的那个目标了。