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

3.3 Sprint（冲刺）

Sprint是将创意转化为价值的环节，也是Developers进行自我管理的活动范围。初期，Scrum Master（后面简称SM）除了在团队内部更多的起指导作用外，同时还需多关注组织架构方面的调整和优化。

团队指导

SM的职责包括领导、指导、教练、PO与Developers沟通的桥梁，以及团队的守护者等等。在团队初期，也就是图2塔克曼模型中所示的“形成期”，需要SM能提供更多的指导。

指导首先从座位开始。我们知道，无论是在量子世界，还是在生活职场中，都存在着“观察者效应”——被观察者无时无刻不被观察者所影响。但不观察，就很难知晓真切的情况，也就难以提出正确的问题从而找到解决方案。幸运的是，对于这个两难的问题，BBC拍摄野生动物纪录片的记者们已经帮我们找到了答案。他们往往会和动物们共同生活好几年，直到动物们完全忽略他们（包括那些各种奇怪的仪器）的存在，才下决心开启第一个镜头。SM也应该像这些值得尊敬的记者们一样，坐到Developers中间去（但“野生动物”这个比方不太好，如果你有更合适的例子，请告诉我）。除非特殊原因做不到，比如说座位不够——我找不到更合理的理由了，那么就到产品的开发现场多走动，也就是大野耐一提倡的“现场管理”。总而言之，MBS（Management by Sitting around）要好于MBW（Management by Walking around），而MBW要远远好于只是从PPT或者报表中获取信息。

图13 野生动物拍摄（来源于https://121clicks.com/）

在前期，你面对的可能大都是些纪律和规范性问题，需要进行针对性的培训，或者明确的说明。比如说如何召开有效的会议，如何区分任务和用户故事这两种PBI类型，如何履行承诺，如何拆分PBI等等。要注意的是，尽量不要频繁打断每个人手头上的工作，召集大家来听你“训话”。充分利用站会后的15分钟时间，一次不够，就多次。如果这个问题属于某人独有，而又影响到团队的合作，建议一对一的沟通。并不是所有的问题都急于当场解决(也许现在不是最佳时机；也许当其他问题解决后，问题自然就消失了；甚至可能后面一直都不需要解决)。这是一个平衡取舍的过程，取决于你的经验和洞察力。所以SM既需要解决问题的能力，也需要与问题共存的能力。 无法忍受这样矛盾的人，也将很难适应SM的岗位。

独立解决问题的能力对于团队更重要。“授人以鱼，不如授人以渔”，在风险可以承受的情况下，尽量将大问题拆解为小问题，向团队成员示范如何解决。最好的情况是向团队示范如何找到根因，能预防问题的发生。比如说在处理对外的依赖性问题上，团队在第一次遇到时通常会手足无措，你可以根据具体情况指导大家按以下步骤解决：

1，先看看内部架构是否可以做优化，或者重新考虑解决方案，从技术上排除依赖。

2，第1步走不通，再向PO提出。由PO向被依赖的团队PO进行申明，并就优先级和排期达成一致；同时，PBI根据依赖可进一步拆分（至少可拆分为不需要依赖而自行开发的部分，以及与依赖部分的集成任务两个），并调整Sprint的PBI列表。

3，Developers可以在“打桩”的情况下继续实现被拆分出来的新任务。

第二次再遇到此类问题时，SM就不需要直接插手，而是采用支持的方式，让团队自行寻找解决方案并进行尝试。直至可以完全委任给团队自行处理。这也是团队走向“自我管理”的必经之路。

图14 授人以渔（来源于https://mazhangcheng.artron.net）

控制好火候的另外一个秘诀就是“无人求助不出手，出手不邀功”。世界上没人愿意总是被别人指导，那会显得自己很愚蠢或无能。只要问题不是特别紧急或重要，那就等对方察觉并求助后再给予帮助吧，否则不仅没有效果，还有可能因为话太多遭人嫌弃，不利于后续的合作。“无人求助不出手”即符合全局思维，也符合约束理论，当然也需要SM拥有“能与问题共存”的修养。同理，也很少有人会主动承认自己有问题，所以SM应时刻夹着尾巴做人，保持低调（当你产生不安全感时，该亮剑的时候也不要犹豫）。即使问题是因为你的建议而得以解决，也要甘于做背后的英雄，把成就感留给团队。“有我”和“无我”之间的摇摆有时候会让你发疯，这时你可以停下来问问自己：你的价值是如何体现的？——团队的成长和绩效。

团队在初期的每一点进步要不吝溢美之词。第一次通过协作完成PBI，第一次在内部进行知识分享，第一次突破个人的技能筒仓，第一次对Sprint规划发表个人意见，第一次自行排除障碍等等，都值得公开表扬和鼓励。

排除干扰

对于新的团队，外部的干系人（stakeholders）也需要指导，而且迫切程度有时候并比内部更高。

在之前的创业经历中，我遇到过市场部的兄弟经常会直接来找工程师安排“紧急”任务，打乱原有的Sprint节奏，而且理由往往都很难“拒绝”——争取一个高潜力用户。

首先，团队内部需达成一致：

1，所有的任务都只有一个来源——PO，或者他的授权者；

2，如果违反了第1条，影响到当前Sprint的进度，工程师当负全责（这也隐含了说，如果在不影响进度的情况下，你友情赞助是没问题的；但当然也不能违反其他纪律，比如说在无跟踪的情况下修改代码或者配置等）；

3，当工程师从PO之外接到任务请求时，需告知对方正确的沟通渠道——联系PO；

紧接着，主动联系市场部进行沟通，互相了解对方的诉求。市场部接受了我们的建议；同时，为积极配合市场部的工作，我们也根据经验值在Sprint预留了缓冲来处理紧急事务。至此，双方进入了一个比较友好的平静期。

同时，我把市场部提的每一个紧急需求都通过工具打上了独有的标签。大概三个月后，我再把这些紧急需求单独进行了一次梳理和分析，发现其中没有一个给公司带来过真正的经济效益，反而因为多次中断当前工作而给公司带来了经济浪费。这些数据反馈给市场部后，既帮助他们提高了工作质量，另外，这种“紧急”任务也越来越少。

最后，因为团队开发的高效，我们逐渐取得市场部的信任，市场部也非常欢迎我们固定每周的排期和交付节奏。结合其它方面的改进和磨合，双方的合作达到了真正的“协作”境界。

图15 排除干扰（来源于www.baike.baidu.com）

上面这个例子是我精心挑选出来讲给你听的，所以不管怎样结局还算完美。但现实并不总是这么可爱，否则也体现不出SM的价值，因此你还得多具备些对干扰说“不”的本领：

1，“不”，我们有优先级更高的事情；

2，“不”，现在来不及了；

3，“不”，除非你让（这里插入不可能的事情）……发生；

4，“不”，下一个Sprint，或者下一个Release再说；

5，“不”，这样并不会起作用；

6，“不”，绝不！

对于有些干扰，实在推脱不掉的，那就尝试忽略它吧，“他狂任他狂，清风拂山岗”。忽略不掉，也推脱不掉的，那SM就辛苦下，帮助团队挡挡，能做的就尽量帮着做了吧，比如说一些繁琐的文档或者流程等等。

组织架构

组织架构的不合理设置会阻碍团队的敏捷性。比如说拥有测试技能的成员在另外单独的测试团队，或者开发前期阶段没有运维团队成员的参与等等。这些在初期，SM就应该注意，并及时向组织高层反馈进行调整。