如火如荼的Agile浪潮席卷各地，公司同样也开始在各地进行Agile实践。如今正在进行的一个重要项目是基于Linux的开发项目，按照agile的scrum实践框架在运行，有些实践和问题很值得思考。
Standup Meeting 大家真的理解其作用？
作为Agile实践中最富特色的Daily Standup Meeting，在整个敏捷过程中扮演着非常重要的作用。但实践中我们会发现一些现象值得思考。
1.不专注的听众导致问题被遗漏或反复
A：我这边有一个类需要B提供支持，在UT完成后我们的内容要进行集成.....问题是—%￥￥#，但……%￥—.
B：不好意思，需要我作什么来着？那个问题不是昨天我们讨论过了吗？
A: 不是昨天那个问题，是这个问题.......
如果这种场景几乎每周都会遇到那么1~2次，大家作何感想？
2.不专业的表达导致糟糕的沟通效果
A：我遇到一个问题，在linux下出现了的，我查了一下网络，发现就一条记录提到该问题。于是我在网站咨询了半天，但没有人回答我。目前我还在研究中，感觉非常困难，之前没有遇到过这样的问题，搞不清楚到底是什么原因。
B：问题是什么？你在说啥？
A：问题是某个类编译不通过，但没有详细报错信息，查不出来到底是什么原因导致的。真的很倒霉哦，遇上这种问题，搞了我几个小时，还是没有解决。没有办法，估计我得加班了。我怀疑是C负责的那个模块的问题！另外，我申请我这个任务Delay，真的太难，事先没有预计到。
C：我这边有什么问题？
B：。。。。。。。
能说，不一定代表会表达。在Daily Meeting上你有无遇到这样的情况？
3.不专心的讨论导致二个世界
异地会议，经常遇到VC两端的人员各自讨论各自的话题。
A地：关于问题Q是这样的，听一下张君的意见。。。。。。。
B地：哎，那个事情E是怎么回事，咱们乘机说一下。。。。。。
热火朝天的各自讨论了几分钟，某一位看了一下表："时间到了，咱们会后电话再详细说吧！！！"
A地主持人： B地的同事，刚我们讨论问题Q的意见，你们听到没有？就按照张君的意思办吧！
B地一片茫然： 什么结论？
上面的3个现象可能描述得有点极端，但基本上我们都遇到过，同时，这种现象也许是每一个成长期的团队都会遇到，本不值得单独拿出来说事，但一旦该现象存在于意图使用Agile思想或Agile实践的团队中，那么就意味着一个非常严重的问题。
面临这样的问题，我们该怎么办呢？下面分享一点实践心得
1、充分理解Standup meeting的作用和目标，再培养基础的会议管理技巧和职业素养。
每日立会作为Scrum中的一个关键实践，它首先基于个体自我管理的思想诞生，围绕着“昨天我做了什么，今天要做什么，遇到了哪些问题需要大家帮助”来进行组织和展开。其作用还是在于及时反馈进度和问题风险，通过每天及时沟通来及时发现风险，消除项目隐患。因此，该会议依然属于一种管理性的工具，更多地作用是起到潜移默化的进度监控和任务Push。
对于每个成员而言，通过会议可以了解到：1）项目组大家都在做什么，是否跟自己的任务有关联；2）我能获得哪些有用信息，我能给出别人什么帮助？3）问题是什么？解决的计划是什么？
但每日立会不能成为一个讨论会，这里的信息需要严格控制范围，比如技术分享的信息、问题讨论的内容都不宜在这种会议上展开。其本质还是一种管理会议而非分享会。一旦我们明白了这一点，那么会议管理的技巧就比较好把握。Srume Master应当引导团队围绕着会议目的来思考，每个人站在自身的角度去考虑：我应该如何做才能达成会议目标？慢慢地，大家自己就会不自觉在会议过程中提出问题：
“你昨天的目标达成了吗？”
“有什么产出我可以用的？”
“问题现象如何？在什么条件下发生的？”
“问题的后果是怎样的呢？”
“今天的目标清楚吗？做到什么程度？”
“这个问题是跟谁谁相关，可能需要谁来协助！”
在团队的成长期，必须具备足够的耐心，通过引导式的问题来逐步统一大家的思考方式和表达方式，逐步建立逻辑性更强的会议表达习惯。
2. 分析自己团队的实际情况，因地制宜解决，千万别往Agile理论上寻求解决办法。
理论跟实践之间永远是一对纠缠不清的生死冤家。传说中理论指导实践，其实更多时候实践是一个平衡，一个不那么理想但能维持运转的习惯。