敏捷项目管理通常会提到一个关键环节，每日15min站立会议。
常用于同步三个问题：
1.昨天的进展
2.今天的计划
3.当前遇到的问题及所需协助
目的是为了团队一起确认实际进展是否符合预期计划，如果不符合及时干预调整，以便更好的达成计划。
现实中，却时常看到开发同学对于每日站立会议充满抗拒，原因大多是：
1. 不理解敏捷管理模式，单纯看做是浪费时间的开会；
平日里如果问开发最不喜欢的事项，估计十之八九就是开会或者写文档；这类事项的属性会让人有惯性抗拒，类似条件反射式的拒绝接受；
2. 不理解信息一致的重要性：
按传统的任务管理方式，TL把事项拆分成具体任务A/B/C，指派给不同人员，不同开发人员接受到子任务后只负责完成子任务即可，不关心其他子任务进展；这种管好自己的一亩三分地即可的思维与敏捷团队的开放式owner思维反差较大，特别是传统流程下工作久的同事，短期内比较难接受新的模式；
敏捷管理倡导的是信息一致，角色互换。每个人既可以是product owner，也可以是project owner，从虚拟身份上不再局限于岗位属性，这种定位更容易培养出全能人才，站在更广的层面看问题。而站立会议更容易通过较短的时间快速达成信息一致，降低很多沟通不到位的风险。
针对这种情况，相对有效的解决办法建议如下：
1. 自上而下全面培训敏捷流程，尤其是product owner、project owner、scrum master、developer等角色，都需要充分理解这种管理思维，接受并认可这种模式；
2. 敏捷团队的规模需控制：如果每天早上20来人开个站立会议，估计每人一句话就半小时过去了，自然会被看做浪费时间，所以应尽量按事项维度把人员做拆分，划分为事项小组，专项开早会，高效且信息有效，自然更容易被团队接纳这种模式；
3. scrum master把控会议内容及会议时间，不发散：站立会议上的发言不应该扩散，如要深入探讨的问题可以会后再进行，尽量在短时间内完成信息同步即可；
据我个人经验，在项目高速推进的过程中，根据事项的每日早会确实能避免很多沟通问题，尤其涉及多端人员配合的情况，信息不同步是大忌，很容易产生依赖阻塞；而站立会议可以明显降低此类风险。所以，只要高效且有效，相信在实际工作中还是会产生良性循环，被大家认可和接受。
