敏捷实践之Stand-UP Meetting早会

本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；

虽然团队一直在推行敏捷实践，但是具体的实践应用到每个团队每个人身上还是要因地制宜，之前人少的时候，感觉团队的早会很准时，也能分享到一些信息； 后来渐渐的就变成向老大汇报任务了，早上干了啥，下午干了啥；还有种情况就是遇到一个问题讨论讨论时间就没控制了； 传统早会一般都是：昨天干了啥，今天要干啥，有什么问题？我们可能会加一项现在做哪张卡； 早会能帮助快速发现问题，共享团队的信息，促进团队的自组织和自立。今天看到一个人的见解，感觉还不错，转载分享下； 

目的

• 团队内信息共享同步，汇报当前项目进度；
• 提出遇到的问题或者阻塞，寻求帮助和解决方案

形式

• 老三俗：昨天(上个工作日)做了什么，今天要做什么，目前有什么问题 
• 新五雅：昨天(上个工作日)做了什么，今天要做什么，什么时候做完，是否delay，还有什么其他问题；

示例: 1. 我昨天完成了(或在做)A模块研发 2. 今天要做(或继续做)B模块研发 3. 预计XX天做完(或在XX前完成) 4. 没有delay(或比预估时间晚了XX天) 5. 没有问题(或者有XX问题，详见下节)

要点

• 声音洪亮；
• 时间控制，需要深度讨论的问题会后另外开会解决；
• 不是向任何人汇报。是开发团队内部的沟通会议，来保证他们对现状有一致的了解；
• 所有事情必须要有完成时间节点，是否delay，是否有什么问题；
• 建议每个人在早上上班后准备好自己的晨会发言内容；
• 如果一个功能模块的时间超过了一天，就要说清楚昨天和今天研发同一个模块的差异，例如昨天做了A模块的XX功能，今天继续做A模块的YY功能。错误示例：昨天做了A模块，今天继续做A模块
• 管理者同步当天或最近的里程碑内容及时间，如提测、上线、各种评审会议等

常见问题

上游delay型

示例： 设计稿或者接口delay，影响研发或者联调进度 解决方法： 晨会上明确上游时间交付时间，PM要清楚是否会影响整个项目，如需要加人或者向上汇报

技术难题

示例： 有个技术难题还无法解决 解决方法： 晨会散会后另外开会讨论技术问题寻求解决或替代方案，由提出者发起会议并邀请相关成员;

遗漏需求

示例： 发现需求文档里少了XX部分的需求或者说明 解决方法： 分配给对应的产品立即补充完整，要求对方给出完成时间

其它问题

解决方法： 首先确定是否能立刻解决，如在1分钟内给出解决方案，如果不行就在晨会散会后另外开会讨论，由提出者发起会议并邀请相关成员

参考：https://www.jianshu.com/p/80469932ff3e