那些年被坑过的 Daily Meeting.pdfVIP

那些年被坑过的Daily Meeting Daily Scrum ，每日站会，作为敏捷中的仪式之一，也体现出其专业性、不可亵渎性。仪 式感，可以让团队成员保持正规以及紧密的围绕在项目目标上。 基本规则 1. 准时开，准时开，准时开！重要的事情说三遍！今天开了明天不开，团队也不会重 视，也不会有节奏感。 2. 全员参与集体负责，SM ，开发，测试都要参加，站会是非常好的信息同步的时 机，要了解其他人做了什么，需要有什么配合的。 3. 发言时长，通常来说15分钟（也有可能会20分钟左右，根据团队情况），避免对细 节的讨论。 4. 解决障碍项，有困难的同事，要及时提出，也要落实解决方案（具体的解决方案细 节，站会之后讨论）。 GitChat 5. 优化发言内容，如果你说的都是没有意义的，那就不说。挑重点说。 流程 1. 到约定时间，团队集中围绕在白板前，一般围成个半圆形。 2. 成员开始分享：我昨天做了什么，只要讲对应的任务就行了，言简意赅。 3. 边讲边挪动便签到对应的列，从doing放到done列表。 4. 讲述今天打算完成什么，同时把卡片从todo列表，放到doing列表。 5. 分享昨天工作过程中遇到的障碍或者问题，需要协助的地方。如果这个问题可以很 快；解；决的就马上解决，不能马上解决的确定由谁进行跟进解决。 6. 团队成员重复2-5的步骤。 是不是很简单？站会是各个组织是最容易操作的一件事。但是越容易实施的事情，越容 易出错。它就三个问题：“我昨天做了什么” ，“今天打算做什么” ，“遇到什么困难”。 我们在实施的时候，会把这几个问题稍微变化一下： 1. 昨天完成了什么？ 2. 今天打算完成什么（加入了deadline ：今天打算完成什么事情，而不能说“今天打 算做什么” ，针对拖延症最好的方式是给一个任务加上一个里程碑节点，即 Timebox。否则，这个活我可能一直是打算做，一直是没做完）。 3. 遇到什么困难或者有什么分享的？ 这三个问题，谁都会回答，有什么难的呢？但理想很丰满，现实却是一团糟：时间太 长、无效发言、开小会、玩手机、争执…… 以下从常见的场景出发，分享这些常见场景中的问题，怎么处理。 开成了汇报会：团队围成圈，PM在中间，然后问：“小王，你按照3点格式汇报一下昨天 的工作”。小王：”我昨天做了xxxxx…… ，今天打算做xxx ，目前遇到问题是：xxx” GitChat 解决思路 Daily Scrum不是汇报会，团队自组织的形式来分享、同步每天的工作状态。很多时 候我们项目出现风险，大多数由于沟通问题导致，所以多分享多交流，同步信息才 是最主要的思想。 SM或者PM不应该站在团队的面前，一旦你这么做了，你就是焦点，团队自然就认 为工作应该向你汇报。这时你应该离开白板，离开团队的焦点和中心。让团队自己 成为焦点。谁分享的时候，就让谁站白板面前。团队成员才是这个会议的主人，而 非SM或者PM。 要让团队成员养成自主移动任务卡片的习惯，SM不要帮忙移动。 变成了分享会： “我昨天终于把xxx问题搞定了，主要是xxx问题，然后我xxxx……”5分 钟过去了，团队一脸懵逼的带着崇拜的眼神听着大牛在做技术分享… 解决思路 给团队梳理站会的流程及要点。每个团队成员都有指定的时间来完成3个传统的问 题。技术细节，会后交流或者有时间做个技术分享也可以。 带个秒表，每个人说完就计时，强化大家的时间观念。 以后再超时，可以采用下图的方式来开会，我就不信你们还能超时。 GitChat 没什么说的：我昨天做这部分的开发，今天继续做这部分开发，没什么问题。下一个团 队成员也基本是这么回复。 解决思路 将任务的粒度拆分小一些，比如不超过1天的工作量。工作太多，团队不知道当前 的进度如何，也就会带来进度的风险。有可能我昨天完成了1% ，今天结束了，我 只完成了10% ，很多时候进度延期，就是这么导致的。到底是100-100还是50-50 ， 还是0-100 ，谁都不知道。 SM也要发挥出问题引导的技巧。比如提醒一下大家或者直接抛个问题：“你有