这个Planning meeting就是工作安排的会议。

 

会前，托尼会把之前Grooming过的Task根据发布计划先拖进新的Sprint中。是的，他要先在Jira上创建一个新的Sprint，然后先拖好Task，按优先级排好序。

开会前，托尼还会用一个Excel表格统计每个人的工作时间，因为每周五下午要学习，所以要去掉一天，加上周一一天开会，这个也要去掉一天，周二上午是敏捷计划会，加上每天早上的站会，每个人最大的工作时间是其实7.5天。

会上，托尼会问大家这个Sprint有没有人要请假？如果请假，请几天，这也要先去掉，然后再开始安排工作。

其实，这个会议的时间也不长。

托尼一边用Excel，一边在Jira中点上一个Task，”BXX-xxx这个Task谁来做？要多长时间？“

“给我吧，1天！”史蒂文说。

“手工测试给我吧，半天！”爱米莉说。

“这个Task不用做自动化测试，我们的测试用例中已经覆盖到这个场景了。”我说。

“好，那我先删除这个自动化测试。那这个Task有没有什么风险？”

“我觉得没有什么风险！“史蒂文说。

“我也觉得没有什么风险。”爱米莉说。

“好，这个Task有UI上的改动，到时要做个Demo！”

托尼一边把Jira Item里对应的时间改掉，然后把Task分配给史蒂文和爱米莉。同时他还在Excel中统计，史蒂文的Task列上去，然后在另一列加上这个Task所需要的时间。然后，他又加上爱米莉的。

“好，下一个，BXX-xxx这个Task是做……的，这个我来做，我需要半天。"托尼自己也会领一些开发的Task做，然后也修改Excel中的统计信息。

每个Task都是这样被领走的，只是时间可能会有些调整。比如，一开始在Grooming的时候，有一个开发的Task估计时间是1天，但是后面是路易斯领的，因为他是新来的，还不熟悉，他就可能要3天，先给点时间熟悉产品和代码。当然，新同事的学习时间比较长，也会给他们不定期地做一些培训。

路易斯还说他这个Task的风险就是他不熟悉，所以这个时间也不一定能完成。为了应对这个风险，托尼说他可以先给路易斯讲讲这一块的产品功能和代码。然后路易斯有问题的话，也可以随时问他和史蒂文。

因为每个人的最大工作时间是7天半，所以到最后，可能拖过来的Task并不能全在这个Sprint中做完，那也没办法，只能把它们拖出去，等到下个Sprint再做。

那如果这个Sprint要做的Task比较少呢，我们就会加一些不是那么紧急的Task进来。

所以，到我们领完了Task之后，我们就会定下这个Sprint要Commit的Task有哪些，这些都是根据大的里程碑和发布计划来的。而这些要Commit的Task就是我们这个Sprint的目标，是整个Team的目标，虽然Task是分给不同的人去做，但是大家心里都有数，如果某个同事中途遇到什么问题，其他的同事要及时伸出援手帮忙解决，帮忙做。

敏捷计划会结束后，我们就回座位开始干活了。托尼会Start这个Sprint，这是在Jira上的一个功能。当然，他还会发邮件出来，把我们这个Sprint要做的内容都列在里面，让PM和架构师他们都知道。邮件中，不仅附带有每个Task的Jira链接，也有新的Sprint Retrospective的链接。

正常来说，我们这个Sprint就会按照我们计划会上计划的任务去做。但是有时候，也会出现一些变化，比如突然客户给提了一个Support Case，要给用户做一个hotfix，这个时候就会有一个开发人员马上暂停手上的工作，先解决客户的问题，测试人员也要在开发人员完成自测后进行一轮测试，然后再发给客户，让客户确定是不是可以解决他们的问题。

还有的时候，那个网页版的产品，PM会加些个紧急的需求，这时候，我们还是要按老一套的方法先由一个熟悉产品的开发人员先跟PM，架构师一起做Research，因为是紧急需求，所以开发人员也是要暂停手头上的开发工作，先做这个Research，Research完了可能马上就进入开发。

当然，这些紧急情况发生的话，原先的Commit就不可能再按时完成了，但这也是被允许的，这些都是由托尼跟PM谈好。