我们这样实践Scrum敏捷每日站会
By 老彦
孔子说 性相近，习相远。我们人类性情都差不多，而每个人的习惯千差万别。我不认为敏捷能改变任何人，而是一群有共同积极价值观的人走到一起，在实施敏捷后，可以把各自的潜能激发出来。
众所周知，每日站会的真正价值在于确保团队能持续地为当前的迭代的“承诺”而努力。每日站会并不是状态汇报，而是信息分享和调整协作。一个成熟的团队可以用不同的方式和关注点来开站会，与此同时团队也继续在改进中使用敏捷。
我和一个由9位成员的团队一起工作，我们在一起工作至今已经近8个月了。在我加入团队之前，大部分成员对于敏捷是完全不熟悉的。我们可以在15分钟的框架内完成每日站会，这样也更高效。在过去这段时间，我们在每日站会中尝试了不同的方法，目的在于在个人和团队磨合成长的同时，为我们的日常工作建立一个积极的氛围。我们认为真正重要的是：文化和人。
每日站会是什么
每日站会是指团队每天早上投入一天的工作前，进行的15分钟以内的会议。主要目的是给团队沟通每日承诺和迭代目标进展的机会。Scrum Master， Product Owner和团队成员都需要参加每日站会。当被问到我们敏捷团队在每日站会上讨论什么的时候，通常是团队成员围绕三个主题：
- 昨天，我们是否达成了目标？每个人的做了什么？还有哪些差距？
- 今天，为了达成迭代的目标，我们的新目标是什么？每个人打算领取什么工作？
- Sprint目标现在还有多大差距？是否可能延迟？哪些问题和障碍需要解决？
敏捷开发团队是一个跨职能团队，而且不是所有人都是全栈工程师。完成一个故事的开发和测试，往往需要多个人员来协作完成。例如：一个典型的web开发故事，通常需要前端开发工程师、后端开发工程师和测试工程师来协作完成。
敏捷站会有以下作用：
1）对齐目标：互相同步信息，专注于当前迭代目标和近期的相关工作；
2）相互协作：尽快交付工作成果，减少半成本，发现障碍，通过协作消除瓶颈让价值流动。
每日站会的七大特点
同样的时间和地点
每次在相同的时间和地点召开会议能让会议成为团队习惯，更容易开起来。
每天按时召开
如果会议每天都晚五分钟开始，那么准时到场的成员将在一年中浪费20个小时来等待会议开始。
十五分钟以内
站立有助于我们保持时间意识和专注，从而使会议保持简短有效。
识别而不解决问题
遇到需要进一步讨论的话题，站会中不展开，可以约定在站会结束后立即讨论。且仅限于解决问题所需的团队成员。
专注有限主题
团队成员说明自上次站会以来的完成了什么、下一次站会将会完成什么工作、以及是否存在会阻碍他们工作进展的问题。
整个团队同执行
站会由团队成员轮流发起，并共同主持执行。敏捷站会不是一个状态汇报会，参与者提供状态是为了能让团队分享信息和发起可能的协作。
整个团队参与
团队中的每个人都应该参与。团队之外的人应被允许旁观会议。但不鼓励他们在会议期间参与讨论，除非团队成员向他们询问建议。
站会结束前，如果旁观者有问题或意见，部分团队成员可以留下来解答。
每日站会为什么
每日站会的目标
除了是Scrum的有机组成部份以外，每日站会的目的是要频繁检查团队在迭代中的进展如何，尽快反馈。在会议中，团队成员能够提出当前遇到的问题，会后讨论合适的解决方案。每日站会通过互相共享工作进展，使团队成员之间拥有更高的协作度。在极高的透明度之下，PO/PM就能够了解产品进度和用户故事的完成情况。
每日站会，是团队自组织检视迭代进展的协作机制，其主要为了：
- 检查迭代目标的完成状态；
- 暴露问题和障碍，使问题和障碍得到及时应对和解决；
- 计划当天的团队目标和领取工作任务。
我们迭代进展的衡量基准，是“已完成的故事”的故事点数。通常，故事的完成标准，至少是通过测试或PM初步验收。
通常我们会使用燃尽图来分析迭代进度的情况。包括以下要素：
- 横轴，是时间轴，单位是迭代天数；
- 纵轴，是剩余工作量，单位为故事点；
- 进度曲线（蓝色），体现了截止目前，迭代还剩多少故事点数没有完成；
- 参考线（红色），是分析迭代进展是否正常的参考基准。
如果进度曲线位于参考线上方，则表示进度已经延期。为了控制迭代的进度风险，我们希望能够尽快地完成一个个故事的开发和测试，以便使燃尽图上的进度曲线处于正常状态。每日站会关注的核心焦点是“本次迭代故事的完成情况”以及如何“尽快完成剩下的故事”。
为什么要回答三个问题？
提出三个问题的目的是让团队专注在当前的工作上，并强调在接下来的8小时内我们需要提升专注度和协作。
每日站会怎么开
每日站会的目标是“尽快完成故事”，其组织形式应该是：
- 通过用户故事来回顾和计划工作；
- 根据燃尽图来检查进度情况。
我们的每日站会的实践是这样的：
0）发起每日站会：团队成员每天轮流主动发起，保持对自组织站会的主人翁心态。
1）回顾和计划：
- 团队每人把昨天完成的用户故事在敏捷看板上移动到“Done”的位置，并简单沟通完成的情况；
- PM和团队对今天要做的故事进行优先级排序选择，并简单澄清。原则上当天站会中准备用户故事点的总数不超过团队开发人员的平均产能之和，故事完成后可以从待办中再拿新的故事；
- 测试小组把通过测试的用户故事移动到"UAT"的位置，供PM选择进行初验；
- 是否有阻碍用户故事推进或者影响本次迭代目标实现的障碍，我们写一张障碍卡片并贴在“障碍”栏目。
2）任务领取：
- 团队成员每人或结对领取当日选中的用户故事；
- 团队成员共同承担当日测试小组发现的问题并按约定时间修复；
- 开发负责人最后分配未被领取的用户故事或工程技术改进工作；
- 直到所有团队成员的工作均以排满；直到所有的障碍都已经有了应对措施。
3）信息发布：
-
每日站会发起人给敏捷看板拍照并发到敏捷团队微信群；
-
WIKI上，更新燃尽图，迭代进展情况。如果迭代进度曲线严重落后于参考线，则意味着迭代目标的达成风险较大。这种情况下，我们可能要组织召开一次迭代的重计划会议，确认剩下的工作如何进行调整；
-
Redmine(购买了敏捷插件)上，更新电子敏捷看板，其信息与物理看板一致，并有统计和图表供参考。
可以参考的实践
尊重团队约定
站立会是在每个工作日的同样地点站着开的会议，需严格按照约定执行。站立会原则上是团队最高优先级的事，没有经过团队认可的特殊原因，成员不得缺席迟到。
注重团队仪式感
可以把站立会看作是每天的开工仪式。从站会开始，成员实现对交付的承诺。早上是个不错的时间，比如早上9:00开始，如需请假要在站会的前一天晚上在团队微信群提前说明。
每日目标明确
每日站立会，每个与会成员都需确保当天的工作目标是清晰的。这个职责通常都落在SM身上，他能根据每位成员表述的内容和抛出的障碍，判断是否所有成员都清楚当前关注点。如果发现有成员对目标不够清晰时，需及时说明。
站姿决定态度
所有人站立围成一圈，每日站会是团队交流会议，发言的人要面向所有站立会成员，每个与会者都是在互相汇报和交流。
障碍有出口
每日站会中抛出的障碍，当没有人主动提出协助时候，SM要引导团队认领或引入团队外支持，可以是在会后安排讨论会议，群策群力提供合适的方案，也可以是让问题升级，务必确保抛出的“障碍”在站会上有解决途径。
欢迎有原则的“刺头”
对于团队约定，一定要有执行力，有效的执行力需要每个团队成员共同的努力和坚持。欢迎一发现问题，就立刻有人站出来指出，并让当事人做出对应的改进。
打造价值共同体
每日站会是量度团队在迭代中进度的工具，同时也是量度团队对敏捷理解程度标杆。
| 团队价值 | 高效能模式 | 高效能例子 |
|---|---|---|
| 自组织 | 团队成员高度投入互相的对话交流中 | 团队成员从任务版上获得任务, QA和开发一起工作 |
| 专注 | 团队成员专注在当前最重要的任务，以及当前最紧急的障碍上 | 团队成员互相监督, 会在别人跑题的时候提醒：“我们在会后再讨论吧。” |
| 开放 | 团队成员互相提供帮助，也不怕请求帮助；在站会中保持良好的节奏；不需要额外的开始信号 | “我怎么帮助你呢？ 你怎么帮助我呢？ 我们在会后来讨论一下吧。” |
| 承诺 | 对于领取的任务，团队全力以赴达成目标 | 相关成员全力投入，确保对接模块的开发今天完成 |
| 勇气 | 勇于暴露和面对困难, 当需要的时候勇于接受和拥抱变化 | 如果燃尽图没有像它应有的样子的话，应该有人勇敢地提出来 |
| 尊重 | 团队成员, SM, PO互相尊重; 认同每日站会的价值 | 所有参与者准时参加，并且控制好会议时间 |
站会是组织内实施敏捷的一环，可以反映出转型中的许多问题。最根本的，如何打造价值共同体，才是我们需要反思的。当敏捷团队的所有人价值观是一致的，团队有统一的目标，站会也可以足够高效有序。一个敏捷团队站会采用的情况，可以反映出团队或组织的敏捷成熟度。站会没有最佳实践，每个团队碰到的问题和面对的场景是不一样的。领会敏捷是聚焦团队价值，构建价值共同体的团队才是敏捷转型的要义。
无论团队成员是何种分工，只有产品做成了，团队所有成员的价值才被认可，如果产品没有成功，团队即使很优秀，对组织而言，都只是成本中心。