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

3.2 Daily Scrum（每日站会）

Daily Scrum也被称为站会。之所以要站着开会，是因为会议的时长不得超过15分钟——酸疼的小腿会提醒每个人发言需简明扼要（听说还由此衍生出了“平板支撑”会）。通过每天正式的状态同步，可以让团队共享Sprint进展，并根据目标和实际情况调整计划，这也是Scrum的三大支柱（透明，检视和调整）在Sprint中每天中的具体体现。站会的参与者是Developers，PO和SM可选。但在初期，和其它Event一样，还是要由SM先给大家打个样。

事为先

很多文章或书籍建议每个人在站会上轮流回答三个问题：“昨天做了什么”，“今天计划做什么”，以及“遇到了什么阻碍”。这样的做法能让大家互相知道每个人的工作进展，但同时也存在以下两个弊端：

1，会失去对事情的整体进展把握。尤其是对于由多人协作的PBI，其状态会因多个汇报人的各自陈述而变得支离破碎、重复冗余。这同时也违背了要事优先的原则，不能保证重要的事情先被关注。

2，让人误以为会议的目的是每个人向PO或SM证明自己昨天没有偷懒。团队才是软件交付的最小单位，而不是个人，这是在体育竞技场上早已被证明的真理。通过解剖某一只鸟，很难得出鸟群如何飞行的结论；同理，过于关注个体绩效不仅毫无帮助，反而会增加管理成本，甚至让团队失去信任的根基。

所以，在实际工作中，我更建议按照事情来汇报进展。也有人建议，初期按人汇报，待团队成熟后再按事来。但目前为止，从一开始就按事来汇报我还没遇到过什么问题。

那具体该怎么汇报呢？按优先级来。我所在团队的通常顺序如下：

1，问题单（包括下游测试或者生产环境中发现的问题单）

2，被阻塞的事项（会经常被忽略，这也是为什么单独拎出来强调的原因）

3，常规PBI（内部也按优先级汇报）

“事为先”的理念是挺不错的，但仍然感觉的出来，你还存有一丝丝担忧：如果团队里确实存在一些“落后”分子，我们也要纵容吗？当然不。我们可以通过一些方法让Developers来自我检查Sprint的状态，并且时刻从中给予辅助和指导。

健康检查

按照事情将状态汇报结束后，你还需在站会中带领大家学会快速自查Sprint的健康状态。这里可以充分使用电子看板中自带的一些工具，包括过滤器、燃尽图等。

1，询问是否还有人没有汇报。如果有所遗漏，请解释原因，或者补充；

2，查看是否有人尚无处于“进行中”状态的子任务。如果有，请解释原因。原因无非有三：和其他同事结对编程；没有更新今天的计划；昨天划水了。

3，查看子任务中是否有处于“进行中”状态超过2天的。如果有的话，要么是当时Planning的时候PBI拆分的不够细，要么是隐藏着阻塞的因素等等，需要负责人给予解释（这也是改进的机会）。

4，检查当前状态与Sprint目标之间的差距，如有必要进行计划调整；然后别忘了回忆一下Sprint的口号（和目标相关），最好一起喊下。

5，查看是否有状态超过或未达到WIP的数量限制。WIP（work in progress）是Kanban中的术语，帮助快速识别工作流中的瓶颈。详见下一节“Scrum看板设计”。

6，查看完成率。完成率是完成工作量占计划工作量的百分比，通常我们认为一个Sprint的完成率在80%-120%之间是正常的。

7，查看燃尽图。通过燃尽图的实际斜率与理想斜率进行对照，根据差异分析原因，并看是否需要调整计划。

如果你采用的是电子看板，有些指标很容易就能获得。比如在JIRA系统里，我用Scrum看板查看上面的1-5项；使用“仪表盘”（Dashboard）查看6-7项。

Scrum看板设计

可视化是改善的起点，而看板是最重要的可视化工具。图11是我最近工作正在使用的一个看板（敏感部分因信息安全已进行马赛克处理）。

状态列：根据之前定义DoD时产生的价值流图，我们将工作流映射到不同的状态，每个状态对应着一列（“to do”, “In progress”, “In review”, “Resolved”, “Done”）。每个PBI的子任务（sub-task）就可以根据状态的变化在PBI的泳道中流动，直至整个PBI完成。图11中，因PBI列表过长，未将每个PBI展开，所以看不到子任务。

泳道：PBI从上到下按照优先级排列（从图中的PBI状态，也可以看出成员基本上也是按照优先级去领取任务的）。另外，为了突出Defects，将Defects从其他PBI列表中分离开来，放置在了单独的泳道中（见图11的“Other issues”）。

其他：JIRA上还提供了过滤器等强大的功能，可以快速筛查所需的信息，比如：超过两天无状态变化的任务等等。详细的可以查询JIRA帮助手册。

图11 Kanban实例

仪表盘

除了上节提到的一些指标以外，你也可以根据自身产品或项目的具体情况，利用“仪表盘”功能去关注一些其他定制化的指标。比如图12所展示的一些指标，包括：

Epic归属统计饼图；

PBI的循环时间或生命周期（Cycle time，即从建立到关闭的时长）；

Sprint启动后新增的Sprint PBI；

未完成的包含固定完成日期的PBI；

图11 仪表盘一（包含完成率，燃尽图，以及PBI类型统计饼图）

图12 仪表盘二（包含其他一些指标）

一些窍门

过于强调会议时长，有时会走向另外一个极端：大家因匆匆汇报状态，而无法同步足够详细的信息；或者在有成员进一步询问时被粗暴打断，错失澄清的最佳时机。这需要大家有足够的技巧才能做到良好的平衡。在初期，可以根据PBI的数量，限定每个PBI的最长汇报时间；当需要更多时间进行阐述或讨论时，建议将此记录在白板上提醒会后相关成员进一步行动。

通常我会定半小时的会议室，比站会的最长时长多出15分钟。原因有二：

1，需要大家都在的情况下宣布和提醒一些组织事项。因为时间短，没必要另外约会而打断大家的工作。

2，站会过后，往往会遗留些话题是大家感兴趣的，或者是需要讨论同步的。时间不长的话，趁热打铁效果最好。