(10)Scrum中的计划会议

今天我们来一起聊一聊Scrum中的计划会议。

那么，首先，scrum中的planning会议的目的是什么呢？

其实从本质上来说，scrum中的planning会议主要有以下几点

• 从PB（Product Backlog）中按照优先级选取这个sprint需要做的item
• 团队澄清user story/item的需求，并且决定是否将该user story拆分至更小
• 团队估计user story的点数（工作量）
• 团队可以根据实际情况决定是否将user story拆分成task来进行track
• 决定该sprint的目标和要deliver的user story（实际在这个地方，团队很大程度上是对PO的一个承诺，这个后面可以详细跟大家探讨一下）

那么从上面几点可以看出，实际上从sprint角度来分析，planning meeting主要做的就是==建立sprint backlog==, 并且将sprint backlog映射为在这个sprint里面team member的工作任务。

好了，既然我们知道了planning meeting的目的，那么都有谁来参加sprint backlog呢

其实所有跟正在开发的产品相关的干洗人都可以参加planning meeting,但是要在planning meeting之前确定参会人名单，并且根据不同干系人对项目的关系来决定他们在会议上的角色。这样才能确保planning meeting能够正常有序的进行，而不被意外因素所打扰。

那么怎么样来保证一个高效的planning meeting

1. scrum master要把握会议的进程，尽量保持团队的讨论集中在planning meeting的目的上。举个例子，团队成员往往会针对user story的一些细节问题讨论不止，但是planning meeting不是讨论需求细节的会议，所以这个时候SM要考虑是否介入讨论，将会议拉回到正确的轨道上来。
2. 估故事点的时候，尽量让所有团队成员都参与，尽管有可能某些团队成员并不真正参与这个故事，但也最好进行参与估点，这样能够确保团队成员的 参与性，防止会议成为几个人来做决定，其他人知识跟随者的情况。
3. 故事要被拆分成合适的大小，这样才能更好的估计故事点，“实现一个博客”和“实现一个可以登录的页面”哪个更好估计点数一目了然。
4. 团队要根据velocity和available来承诺给PO的delivery，如果是一个新的团队，无法用velocity来承诺，那么可以考虑根据团队的实际能力来进行预测。
5. 一定要跟团队align planning meeting的会议目的，建立团队成员对于这个会议的安全感，特别是在刚开始进入敏捷的时候，防止团队将这个会议单纯的考虑为跟团队leader做commitment。

那么一般下来planning meeting要用多长时间呢？

一般来说，对于4周的sprint，我们一般时间小于8个小时，2周的sprint需要不多于4个小时的时间，但是实际运行下来，往往团队会对于这个会议所需时间有一些要求，一般2周的sprint不超过2个小时为最好，如果时间过长，可能会造成会议过于拖沓，而且大家极易疲劳。
但是如果确实有需求没有澄清的话，还是要根据实际情况，尽量在站会上沟通清楚。

user story一定要拆分成task么

个人理解，user story要拆分成task的主要意义在于能够按照更小的粒度来对user story在一个sprint里面进行跟踪，并能够及时的解决对应出现的问题，而且从task一般用hours来进行估计的情况，可以更好的更新burndown chart等工具。所以可以根据实际情况来定，以两周的迭代来说，如果一个user story所需时间小于3天，实际上是可以不用拆分的，如果大于三天，根据经验会延期或者出问题的可能性很大，所以最好拆分一下。

团队在planning meeting上pick up的user story是承诺么

从新的scrum primer上，已经更倾向于用承诺来代替预测在计划会议上了，实际上这也是scrum在运行到现在的一个明显跟现实环境的妥协和改变，在最早的scrum简章里面，实际上是不想使用承诺这个词的，因为scrum对于变化的不确定性，还有故事的不可预估性，是不希望团队在每个sprint开始就对ＰＯ做出承诺，因为ｓｃｒｕｍ是希望团队在不停的改进和迭代中达到对于ｔｅａｍ交付能力的一个准确估值。但是实际上，在现实开发环境中，产品经理／ＰＯ往往希望团队一开始就进行精确估值，从而能够更好的控制开发进度和风险，所以这个就需要团队在估值的时候，实际上是某种程度对于ＰＯ的一个承诺，很难说这种改变是好还是不好，但是由于对于实际环境的适应，所以也不得不进行相应的改变。实际上在现在的ｓｃｒｕｍ中，有一些已经引入了一些管理的概念，这也是ｓｃｒｕｍ本身不短适应变化的一种体现吧。

计划会议不仅仅是在每个sprint开始的时候才进行，在整个产品/项目开始的时候可以有项目计划会，release开始的时候也可以有release planning(grooming)来建立整个release的backlog。当然了在不同的层次，planningmeeting所需要的时间和关注的重点也不一样，需要大家注意和调整。