摘要：
10年前第一次听说每日站立会议，觉得很酷，于是我们马上就实践了！开始两三周效果不错，因为新鲜事物嘛，但没多久新鲜感就木有了，慢慢变成“walking dead”，每次开会就是一群僵尸在开会，项目工作变成僵尸大战项目，或者是项目经理大战僵尸。本文在之前一篇关于每日会议文章的基础上，继续为大家分享！
看此文之前，建议先看看之前的文章：“敏捷实践:比每日会议更疯狂的半日会议！”
链接：http://www.cnblogs.com/umlonline/archive/2011/12/30/2307375.html
前文回顾
前文再续书接上一会，上次我们提到：
“敏捷开发绝对不是今天计划明天的工作的，要保证每一次迭代都能成功，那么工作就必须落实到每一天。每日会议是保证计划有力执行的重要手段，将项目的情况每天都可视化地展现在所有项目成员面前，让我们一天一个脚印、踏踏实实地将项目做好。”
也提到：
“说到底开会只是一种形式，问题是我们开会的目的是什么？如果不用开会能用更简单有效的办法达到开会的目的，那么开会干嘛？回到这个原点，我们自然就会处理很多项目中的问题，让会议更加有效甚至不需要会议！”
我突然觉得我有点象神仙在谈理想了，我说的这些境界可能短期内无法做到，我们必须回到现实，本文给出一些循序渐进的做法，并且针对常见的每日例会疑难杂症给出一些建议。我们可以先进入每日例会的初级阶段，然后用半年左右的时间逐步过渡到高级阶段，而终极形态我从来没有真正可以完全做到，估计将来也不太可能做到，我们了解一下就可以了。
每日会议的初级阶段
案例分享：用户故事看板前的每日站立会议
某会议室有一张很大的白板，上面贴面了小卡片，卡片上记录的是用户故事。最左边的用户故事是“todo”的，中间的用户故事是“doing”的，右边的用户故事是“done”的。“doing”和“done”的用户故事都写着负责人，而只有部分“todo”的用户故事写着负责人。每天，项目小组会围着一个半圆，在这个白板前面讨论最近24小时做的事情，规划和调整将来24小时要做的事情。每位成员都能重复发言和仔细聆听，相互尊重和交流意见。会议结束前大家还会完成一圈，把手都握在一起，齐声说：加油！整个过程大家精神高度集中，所有人的语速都比较快，10-15分钟就结束战斗。
之前我一直认为如果每日会议做成今天规划明天的工作，这其实仍然是原始的工作模式，我认为项目应该有中长期的大致规划，而至少近期1-2周的工作应该是细化和明确的。这个项目小组有当前Sprint的大致计划，但近期1-2周的计划暂时无法做到很具体，于是他们采用“今天规划明天”的工作模式。
我是这个项目小组的敏捷教练，他们的工作方式我非常赞赏，以下几点是可以供我们学习：
1）每日会议最好围着“用户故事看板”来开，用户故事要分成以下几类：todo、doing、done。
2）每一位都需要精神高度集中，充分发言和仔细聆听。
3）如果实在不能细化近期1-2周的工作，那么也不必强求，可以每天持续细化。
每日会议的高级阶段
相对于原始的工作模式，如果能做到初级阶段已经是一个很大的进步！
不过我们的项目总是有交付压力的，如果某个Sprint的工作不能做到尽量细化，那么我们就难以保证这个Sprint能不能按期按量按质交付，我们也难以预测将来会怎样。所以每日会议的高级阶段应该是这样的：
1）当前Sprint的计划应该尽量明细，至少要做到近期1-2周的工作时细化的，落实到人头上的，可检查的。
2）每日会议讨论重点不是今天干了啥明天打算干啥，而是每一位对照计划和自己实际的完成情况，交流影响当前进度的问题、风险等。
3）每一位为其他成员提供解决这些问题或风险的线索，会中不具体讨论解决办法，而是会后相关人员继续沟通。
但是要做到近期工作细化是有难度和前提的：
1）需要我们具备比较强的需求分析能力，能在初期就充分拆解用户故事，把握全部或者是大部分用户故事的细节；
2）需要我们在掌握需求的基础上，能尽早做好软件的架构设计，想好所有或者至少是大部分的技术难点实现办法；
说明一下，上面提到的“初期”并不是指项目整个周期的初期，而是指当前的Sprint。我们一般没有办法在整个项目的初期就能确定整个项目的需求和设计方案，但我们需要在某个Sprint的初期就能基本确定当前Sprint的需求和设计。
每日会议的终极形态
这个“终极形态”其实就是武学上的最高境界——无招胜有招！每日会议终极形态就是没有会议！
上一篇文章提到：
“有朋友在群中提到，他们项目基本不需要开会，因为平时就把问题给解决了！
我觉得这实在是太牛了！说到底开会只是一种形式，问题是我们开会的目的是什么？如果不用开会能用更简单有效的办法达到开会的目的，那么开会干嘛？回到这个原点，我们自然就会处理很多项目中的问题，让会议更加有效甚至不需要会议！ ”
我做过的项目还真的有很多会议，但都是很有效果和效率的会议，我估计将来我也无法做到“无招胜有招”的境界，但我们需要记住开会并不是为了开会，只要能达到目的，我们就采取最简单最直接的办法。“简单和有效”是我们的重要工作原则。
每日会议的“疑难杂症”
下面列一些疑难杂症及解决建议，这些症状是初级阶段之前可能会出现的症状。
1）项目中是“木头人”太多，除了项目经理，其他人都不说话。
改善建议：让大家轮流做每日会议的主持人。
2）SCRUM Master不懂具体需求和技术，每天都是他来主持会议。
改善建议：每日会议是“自组织团队”自己开的，SCRUM Master在一边旁观就可。
3）敏捷教练“书生治国”，只关注理论和敏捷的条条框框，不切合工作实际，每日例会上只顾搞漂亮的燃尽图。
改善建议：项目经理学习相关敏捷知识后兼任敏捷教练，活学活用，不要拘泥于形式。原敏捷教练应该到研发第一线去做具体的研发工作（注意不是敏捷教练的工作哦），获取实践经验。
4）会议中大家只是口头说某某用户故事做完了，但实际完成情况有没有底，事实上程序员的工作质量你懂的……
改善建议：通过测试的用户故事才叫完成了，测试工程师是每日会议的重要角色。
上述给出的改善建议都是“战术”层面的，但很多症状的根本原因是公司体制、团队文化、考核机制的问题，这个时候要改善问题需要从“战略”层面动手术。
曾经有人问过这样的问题：他们团队的人就是不积极不主动，怎样弄都不行！我教了好几招，他说都试过了，但就是开始有点效果，后面很快就恢复“正常”了。我相当郁闷，为什么了？后来才了解到这是“弱矩阵”的管理架构！
类似的问题也出现在“外包人头”的团队上。什么叫“外包人头”？某些大公司为了所谓的降低成本，不直接招聘员工，而是通过人头外包的方式向合作方租用员工。这些被外包的员工其实是很惨的，想让他们自组织自管理基本是没戏的。
如果你们公司是“弱矩阵”，或者你们有“外包人头”的情况，实践各种敏捷实践的时候就会有诸多问题，这些问题需要“战略”层面来解决，但战略层面的事情，往往不是我们能左右的。敏捷实践是需要土壤的，欢迎参考下面为你推荐的“神马是敏捷”系列文章。
有些事情我们可能是有心无力的，在自己的能力范围内做好事情，真诚地对待每一位小伙伴，做到问心无愧就OK了！
本文对具体一种敏捷实践为大家分享，如果你对敏捷还不是很理解，建议先看看“神马是敏捷？”系列文章（共4篇）。
第一篇链接：http://www.cnblogs.com/umlonline/p/3450032.html
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人