刚刚开了Sprint1的计划会议，原计划是两个小时，一个半小时就结束了，虽然不是在时间上纠结，但是心里还是有些不太放心。唯一安慰自己的就是，毕竟是第一次嘛，还有Sprint也是允许失败的（不准找借口！！）
按时到会，是大家都应该遵守的规则，但是遗憾的是两个主要的Team Member都迟到了。为了以示提醒，我们就临时用便签写了“I'm Late”，让他们自己贴在身上显眼的位置。
会议开始，首先有Product Owner介绍了本次Sprint要完成的Story，把基本的要求做了比较详细的陈述。Product Owner做完陈述后，竟然冷场了。Team Member竟然没有提出任何问题，虽然我一再提示，有问题要尽早问，以免误解了需求。几分钟，终于有人开口提出了问题，不过这个问题不是关于Story本身，而是深入到了具体的实现细节。我还没有开口，Product Owner就说“我想这个关系到了具体实现的问题”。Product Owner提出了4个Story，由于刚开始并没有确定优先级，在讨论过程中，我们为每个Story定了优先级，其中最大的是100，其他分别是80，50，30。
第一部分一个小时的会议，不到30分钟就结束了。“隐患”已经埋下了。
接下来，当然就是分解任务了。这时其中一个Member（一下用S代替）说到“我对这个完全没有概念，不知道怎么做？应该怎么样估算时间呢？”于是我问他：“你是否对需求完全理解？”他沉默了几分钟后，就Story的一些细节询问了roduct Owner。我补充说：“如果你不理解怎么做，那么就需要调研，你可以把调研作为一个Task来完成。虽然时间不好估计，但是你总是还要有一个时间的。”这时，另外一个Member（下以后用W代指）就另外一个Story问道“我和服务器之间不需要交互吧？”Product Owner就问道“如果没有交互，那么这个Story中的数据如何同步呢？”S惊呼道：“哇，哇，这样任务量就大多了！这两周不可能完成呀！”我说：“那为什么刚开始没有问清楚需求呢？”S争辩道：“我以为……”我打断：“不要说以为，你一定要和Product Owner确认是否是他想要的需求。否者就会偏离，会做无用功。OK, 既然现在这个在这个Sprint中做不完，你们考虑分解，还是和Product Owner协商在下一个Sprint中做呢？”S据理力争说：“我感觉可以先把服务器端实现了，可以做几个任务”，他一一详述。于是Product Owner问道：“你如何给我Demo？”S：“我从数据库中，导出数据给你看。”Product Owner：“你给我数据，我怎么知道你是否完成了逻辑呢？最多只能算是你代码的单元测试。”S想了一下，也同意了大家的观点。最后，Product Owner同意放到下一个Sprint完成这个Story。
在经过上面的波折后，任务被很顺利的分解。以“人天”为单位，估算了工作量。这个环节并没有出现什么问题。
90分钟的讨论后，Sprint 1的计划结束了，我旁边的白板已经贴满了这次Sprint的任务便签。
