90天炼就斯巴达方阵（九）

4.5 继续补充

除了纪律以外，在Sprint2，聚焦Sprint目标、监控过程和进度，以及保持Sprint节奏，都是需要养成的良好习惯和意识，也是自我管理的坚实基础。刚好手头上有团队正在经历Sprint2，为本节提供了新鲜的案例说明。

Sprint目标

Sprint目标是Sprint的承诺。如果目标没有达到，那么也就意味着Sprint失败了。正因为如此重要，所以在逐条同步完PBI的状态后，大家还需要从整体的视角去看看离Sprint目标还有多少偏差和风险。

上周，我们举行了Sprint2的第一次站会。当按照会议议程走到检视Sprint 目标这步时，大家却发现，无人认领和Sprint目标相关的PBI。

“这是为什么？”

问题抛出来后，大家都陷入了沉思（这时，最好不要打断团队的自我反思）。片刻后，终于有人打破沉默给出了解释：

“因为要完成这些PBI，需要先完成优先级排在其下的几条PBI。“

“也就是和目标相关的PBI依赖于这些PBI？”我继续问道。

“……对！”

“如果是这样，被依赖的PBI，其优先级应该比依赖于其的PBI要高。对吗？”

“……对！”

得到肯定的答复后，在PO的授权下，我现场调整了优先级。

“那么，这些刚刚提高优先级的PBI也将属于和目标相关的PBI了。是吗？”

“是！”这次的回答非常斩钉截铁和异口同声。

“我们自己找到原因并进行了调整，非常棒！那请大家再想想，为什么当时在Sprint Planning会上，我们没有识别出这些依赖和正确的优先级呢？”

由于时间所限，我们没有继续展开讨论。但作为开放性的问题留给大家思考仍是有必要的。

“为实现目标，还有遗漏的任务吗？”

“我认为没有了。但站会后，建议大家留下来，对当前的工作安排重新讨论下吧，看看怎么才能加快目标的实现。”一位工程师答道。

“好，确实应该一起看看。”其他工程师纷纷响应。

团队协作和自我管理的氛围就这样显现了出来，有时候就只是需要一点催化剂，就像这个案例中的那几个看似不起眼的问题。

图26 Sprint目标漫画（来源于youtube.com）

在3.1节中我们曾讲到，好的Sprint 目标对于团队的聚焦和协作起着非常重要的作用。那么怎么才算是好的Sprint目标呢？没有标准答案，但我认为至少要满足以下四点：

1，符合SMART原则

2，聚焦于业务影响

“Sprint Backlog由 Sprint目标(为什么做)、为 Sprint 选择的 Product Backlog 条目(做什么)以及 交付Increment 的可执行计划(如何做)组成。“——如《Scrum指南》所说，Sprint目标需要能讲清楚这个Sprint之所以存在的理由。

3，激励团队协作

“Sprint目标还创造了连贯性和专注点，鼓励 Scrum Team 一起工作，而不是分开独自行动。“——《Scrum指南》

4，促进团队对其的所有权意识

“整个 Scrum Team 将共 同制定一个 Sprint Goal ” ——《Scrum指南》。即使PO在最初可以从业务角度对Sprint目标进行建议，但最终还是需要在和团队协商的情况下达成一致。而Developers一旦做下了对Sprint的承诺，就必须尽全力做到。

但是，也请时时牢记敏捷价值观之一——“可工作的软件大于详尽的文档”。不要为“写好”Sprint目标而过多耗费精力，只要团队内部能通过对话达成一致和清晰的理解，满足以上4条要求就可以了。

最后，还是列出一些比较常见的“反例”，请大家在实践过程中注意：

1，将部分PBI逐条列出作为Sprint目标

2，将完成所有的Sprint PBI作为Sprint目标

自我监控

4.1中讲到，在Sprint2，团队开始自行主持站会。但除了主持技巧外，团队还需学习如何进行自我监控，包括Sprint的过程和进度。相关工具已经在3.2节中进行了展示，下面就以真实案例来讲解如何让它们为我所用。

站会第一天，在集体浏览dashboard时发现，处于“in progress”的任务占据了整个Sprint的80%以上（如图27中的黄色区域所示，但图26显示的已经不是第1天的指标了，因为当时没想到截图存档）。这是极度不正常的，说明很多任务是在齐头并进，并没有出现“蜂拥而上”的情景，更不用提“单件流”了。而且这点从WIP数量也可以得到印证——WIP数量远超上限12（图28），说明不仅仅是齐头并进，还有可能存在一个人并行处理多个子任务的现象。

图27 Sprint“整体过程”示例图

图28 WIP显示

于是，这些异常指标指引着我们返回到看板进行仔细查看。刚才的猜测都一一得到了确认：

1，各自为战。没有一个PBI是两人或两人以上合作进行的。可以问问大家为什么没有合作？对Sprint目标的忽略也许就是原因之一。

2，有人并行多个子任务。这违背了Scrum的价值观之一——“专注”。深挖下去，发现这是由多种原因造成的：

1. 有子任务因为需等待评审而阻塞。对于这些子任务，通通打上了pending的标签，以及详细的描述，便于后面重点跟踪。
2. Produce Backlog中某些工作量小的PBI，被某位工程师擅自移到Sprint2中和其它子任务并行开发。这一点，其实在图27中的红色字体中也有所体现：2%的“scope change”。具体擅自增加了哪些PBI？可以在dashboard中的过滤器里获悉（如图29所示）。此时，需要你向大家再次强调：Sprint中的PBI，是在Planning会上大家一起协商达成一致的；如果有变动，必须提出来同团队再次商议并得到同意后方可进行变更。这里团队不仅仅是指Developers，还包括PO和SM（至少前期SM一定要参与）。

图29 Sprint PBI变动过滤器

严格保持Sprint节奏

保持稳定的节奏，对内可以节省协调成本，对外能够满足客户期望，建立信任。重要性不言而喻。所以，Sprint节奏定下来后，需要大家严格遵守直至形成生物钟。习惯的养成不可能一蹴而就，尤其是在有外部干扰的情况下，但起点是从自己重视开始。如果需要，SM可以帮助大家一起协调时间上的冲突。久而久之，团队内外才会尊重Sprint的节奏，并在安排一些会议或者任务上，有意识的避免与Sprint Events产生冲突。否则，Sprint框架便被置身于风雨之中，随时可被拆卸扔在一边。

下下周，有个非常重要的海外客户计划出差来中国，并打算利用其中的一整天时间和PO当面讨论产品细节。不巧的是，客户建议的时间刚好和下一个Sprint的Planning会议冲突。于是，PO考虑是否因此提前一天中止当前的Sprint，以便空出时间参与客户的讨论。我给的建议是：

1，向客户介绍我们正在运行Scrum的情况，包括为什么采取Scrum，Sprint的节奏，当前Sprint的目标和进展等，尽量详细，保持透明度；

2，说明提前一天终止Sprint对当前产品开发的影响，并询问是否可将会谈推迟一天，减少干扰。

最终，经过沟通，客户理解了团队为产品实现正在做的改进和努力，欣然推迟会谈，并表示以后也会积极配合Scrum的节奏。同时，PO也通过实践增加了如何管理Stakeholder的技巧和经验。这就是“正螺旋效应”，情况会越来越好。

在前期，你就像西西弗斯那样，不厌其烦的把道理跟团队讲述了一遍又一遍。但怎么讲都不为过，因为你和西西弗斯不一样的是，你的锲而不舍非常有意义：团队的“飞轮效应”已经开始越转越快！

图30 西西弗斯（来源于《经济观察报》）