接上一篇《Scrum实践记录（一）：Scrum概览》，这篇讲一下迭代前期的两个工作，重点是计划会。
零、前期准备
最开始SM要去找PO确定本次迭代的以下内容：
1、具体目标（所有的后续工作，计划都是基于这些目标去拆分的）
2、迭代周期
3、站会、演示会、总结会具体时间（站会每天开，演示会、总结会迭代最后一天）
一、用户故事+任务拆分
前期主要是PO整理需求并梳理成用户故事，把需求拆分为一个一个用户故事后，研发团队会根据用户故事（需求）拆分各自的任务（card），任务的记录形式没有强制限制，可以使用便签纸或Excel等具备记录功能的工具，当然为了后续方便大家同步进度建议采用专业的工具，我们团队使用的是YouTrack（JetBrains出品10人以下免费使用），其实便签纸也是很方便的一种形式可以直接粘在白板上，当然要有硬件条件支持，这个阶段是全员参与的，拆分完毕后，SM组织开计划会。
二、计划会
参与人员：PO、SM、研发团队
计划会的目的是要每个人都要清楚拆分出来的任务（card）的具体工作内容，统计工作时间，预估每项任务的工作时间，确定团队在本次迭代要完成的工作量。
会议分为三个阶段：统计工作总时间—预估任务时间—根据情况增/减工作
统计工作总时间
统计工作总时间主要为了让大家清楚本次迭代我们可用来实际工作的时间总和，由SM使用Excel（用笔算也行）统计本次迭代周期内部是否有会议，有的话占用多少时间，统计迭代内是否有明确的人员请假情况，然后按公式：
人时=迭代天数6总人数-请假时间-会议时间
统计出来每个组的时长，后端、前端、测试 如：
迭代周期是两周（10天），后端有4个人有一个请假两天，前端2个人，没人请假，有一个培训会全员参加，占用2小时，则计算如下:
后端：1064-26-24=220
前端：1062-2*2=116
预估任务时间
计划会上由拆分任务的人员向大家解释任务内容，其他人根据自己的理解给出自己认为合理的工作时间牌，时间牌只有大、中、小和“？” 四张（每个团队可以自己定义，但最好不要直接使用真实的连续数字），不直接使用数字的目的是方便大家统一意见，而且大家更容易给出大概的答案而不是具体数字。至于大、中、小对应的具体时间我们采用 6、4、2的对应方式即“大”对应的就是需要6个小时的工作时间，“？”是比较特殊的一张牌，留给不了解具体业务及对应的工作难度的人使用。
牌的形式也很开放，网上能买到专门的牌，当然也可以像我们一下每个人发4张便签纸 自己写一下（这时刚开始的解决方案，后来我专门做了个出牌的web页面，大家在手机上操作就可以了），计划会的流程是这样的：
要注意出牌的时候大家先用是自己选一张牌，扣在桌面上，都先完后统一亮牌统计结果，如果有两个结果会让讲解人再作补充说明，或者出牌的人说一下自己先牌的理由，然后大家再出一次牌（第二次一般不会又是两个答案，如果是就再来一次）。
出牌得出的结果换算成时间记录在任务（card）上。
根据情况增/减工作
预估完任务时间后按分组统计任务时长，如：
后端：260小时，前端：80小时
再根据提前统计的工作总时间：
后端：220小时，前端：116小时
一比较发现后端多了40个小时的任务没有人做，而前端少了36个小时的任务，于是就要PO根据情况对后端的任务进行删减（当然不是真的把任务删除而是放到backlog里，下一迭代完成），并添加一次前端要完成的任务。
最终达到一个基本的平衡点即可，很难100%的保证预估的时间和真实的工作总和一致（也没有必要非得一致）。
备注
1、实际工作时长不会那么理想 所以要提前把可能会被占用的时间留出来
2、SM可能同时是研发团队的一员，如果是那么他每天要占用2个小时来做SM相关工作，因此在统计工作时长是要把这部分时间考虑进去
3、计划会的最后一步是大家把自己明天要完成的工作从Open栏，拖到In Progress栏，表示我接下来要开始的工作
本文链接： http://blog.jisuye.com/2018/10/22/scrum_2/
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！
