软件以人为本4 - 敏捷2 - 拯救每日立会

题目源自《拯救大兵雷恩》。话说每日立会作为Scrum实施的先锋队，战斗在Scrum的最前沿。然而它孤军深入，面临覆灭的危险。如何拯救？

其实在上一篇博客中已经隐约提到了拯救的办法，估计各位看官并未注意。不过也不必担心，且让我慢慢道来。

1. 大兵-每日立会 

每日立会在什么时候变成大兵的呢？是在你觉察到的时候？不，比那早得多。

敏捷很火，如果你还没有在用，值得试试。因此在经过或多或少的培训后，A团队决定开始实施Scrum。在开始的时候，团队坚持以“暴露问题，沟通进度”为目标，坚持在固定时间固定地点，从不超过15分钟，只回答3个问题。团队成员们比较兴奋，咱们可以自组织了，咱们可以敏捷了。但热情并没有持续很长的时间，人们就开始抱怨。

ScrumMaster：“实施敏捷这么久了，怎么进度还没有提升，辜负了领导的期待啊。不行，我要更积极的参与。”于是SM同学开始催促监控任务的工作进度，慢慢的每日立会变成团队成员对SM的进度汇报会。会议时间越来越长，SM关注越来越多的细节。

团队成员：“天天3个问题，有啥意思。而且没有觉得有啥作用。会议时间越来越拖沓，跟我没啥关系。”团队成员迟到的人越来越多，热情丧失。

A团队很纠结，他们知道实施Scrum有成功的，也知道有放弃了Scrum的。但是放弃Scrum吧又不舍得，不放弃Scrum吧却又没有得到太大的好处。

2. 拯救每日立会 

2.1 最简单的办法

有个办法很简单，很有效。这个办法就是，找个有经验的敏捷教练。切，你这不等于没说吗，这方法谁不知道啊。

等等！为什么有经验的敏捷教练能够做到呢？

是教练藏私，没有把关键点出来？还是关键点没有被注意到？

是教练做的一切你做不到？还是你能做到，却没有想到要做呢？

2.2 次简单的办法

此方法是一种典型的套路，你看出来了吗？

1）将前文中的3条关于事和13条关于人的目标形成目标backlog进行唯一优先级排序，排完序后再分类。（图例中是我的排序与分类）

2）填写现有行为中造成不好影响的，并去思考发现具有好的影响的行为。

3）执行，每隔一段时间回到此backlog，重复上述行为。

 

建议的会上行为包括：

1）开始时以对目标backlog和每日立会认识最深的人做会议主持，让团队逐渐习惯每日立会的方式。然后轮换会议主持人，避免某人一家独大。后期逐渐取消会议主持人。

2）会前开开玩笑引入，氛围轻松点（注意可变化，不要太呆板）

3）使用白板，大家对白板，而不使用圆圈相对站立。

4）发言人向前一步，半转身（半对白板半对团队），然后发言。（让发言人自己书写、移动任务条，效果更好）

5）任务完成的好的，及时表扬（可设托，别老是一个人表扬）。

6）对暴露问题或担心的，在心里感激，然后可表现也可不表现（别表现感激，心里不感激）

7）对主动跳出来帮助别人的，心里感激，行为感激（不一定在会上，可在会下）

8）对进度不够满意，可用提问从团队成员引入，也可直接在会上提出，然后另起一个会与团队讨论解决方法。

9）会中控制气氛，如果顺利，多调侃，保持轻松氛围。如果不顺利，营造稍压抑但有希望的氛围。

10）会议结束后小的庆祝仪式，提升士气（注意可变化，不要太呆板）

11）会后拿出目标backlog，问问自己，今天的每日立会达成了几项目标？

3. 拯救每日立会 – 续 

上述实践能够完全解决每日立会的问题吗？抱歉，我的答案是否。

3.1 对事还是对人？

ScrumMaster或项目经理的工作还主要是对事，而不是对人，这是拯救每日立会的一大障碍。因为对事为主这种心智模式的存在，所以他经常在无意识情况下被心智模式控制行为。反思，需要深刻的反思，路还很长。

1）发现项目进展不大，控制不住介入

表面看是对进展的关心，实际行为展现的是对团队的不信任，伤害了团队共同目标、承诺。进一步高压的话，团队就连真话都不敢说了。

2）做决策的习惯

情不自禁的做决策，背后的心智模式是对别人的不信任。其行为表面是好的，用最正确的方法做事。实质是没有给团队成员犯错成长的空间，没有给团队成员足够的信任。结果会伤害团队互信气氛，让团队成员不情愿承诺。

3）看不见人的进步

满眼都是进度、障碍，人成了附属品。如何能够激励团队成员？如何知道哪些手段可帮助形成团队？

还包括过于追求每日立会的标准而忽视了其他目标。此处简单列出几项，不然的话正在看的ScrumMaster或项目经理不是要郁闷至死，呵呵。（将在以后覆盖心智模式）

3.2 怎样对人？

好吧，那就对人，那就仔细观察人的进步，但是ScrumMaster或项目经理将面对一个新问题，影响力技能。（将在以后覆盖影响力）

3.3 以事对人

这个一般人我还真不告诉他。在每日立会中有一个问题很难解决，就是关注其他人的工作这一问题，尤其是在刚引入每日立会的时候。

可以通过对工作重新设计解决该问题。下面是我的应对办法：

1）工作任务不细分

         至少一个QA和一个Dev，这样的话Dev和QA都会参与。

2）任务足够小

         很快就完成了，BA（或PO）需参与。

3）要求随机结对Review

         Dev完成后，随机找一个人进行结对Review。

对于还没有学会关注整体工作和其他人工作的团队，此方法效果不错。还可以和Code Review一起推进。

3.4 关联实践

1）如果计划会议做不好，团队共同目标的问题就比较空洞，成员也不太敢做出承诺。

2）如果回顾会议做不好，改善每日立会的可能性就很小，信任感难建立。

软件开发是一个整体，实践之间是相互影响的。需要在合适的时间将实践推行到合适的程度，而不要过于在意某一个实践是否合乎标准。（将在以后覆盖关联实践）

关于敏捷的下一节是《我不信奉Scrum，我信奉敏捷》。

关于人的下一节是《等我有了力量，结果就会不同》。