开一场高质量的Scrum计划会议
开一场高质量的Scrum计划会议
- 一、计划会议的目的
- 二、计划会议要点
- 三、计划会议常见问题及解决方案
一、计划会议的目的
计划会议是Scrum里面非常重要的一项活动，是一个Sprint的开始，计划会议的作用：澄清需求，评估、修订工时，明确迭代工作目标，减少迭代周期内外界对敏捷团队的打扰。
一场高质量的计划会议，是团队高效协作，迭代工作目标顺利达成的重要基础。
二、计划会议要点
在开计划会议时，需要关注的是：
1.在计划会议召开前，是否提前完成需求收集与梳理，优先级是否明确。
2.是否完成任务拆分，放入迭代计划中的任务DoD是否清晰。
在团队开始敏捷转型前期，建议在计划会议之前，增加一次产品梳理会。如果团队已完成敏捷转型，产品梳理会和计划会议可以一起开，一起开的情况下，产品负责人或有产品角色的人，应该已明确需求的背景，价值，以及用户及使用场景。如果可以，最好能有产品路线图，页面原型这些东西，这在很大程度上可以帮助团队更好的理解需求，提高需求理解的一致性。
三、计划会议常见问题及解决方案
（一）用户故事粒度比较大
影响
一个sprint结束时，团队不能按照用户故事完成交付，开发的功能不能产生业务价值。
解决方案
用户故事粒度较大一般有两个原因：
1.经过初步评估用户故事可以在一个sprint完成，感觉没有必要继续拆分。
2.故事复杂，无法拆分。
根据IVEST原则，一个用户故事应该足够小。如评估后如果发现一个故事需要大于迭代周期的二分之一以上的时间才能完成，建议对故事做进一步拆分。
粒度比较大用户故事一般分为两种情况：复合故事、复杂故事。复合故事一般由多个小故事组成，可以按照功能做进一步拆分，比如会员管理这个复合故事，可以按照增删改查等功能进行拆分。复杂故事一般是一个很大且不容易拆分的故事，如果一个复杂故事因为不确定性而复杂，可以将其分解为多个故事，比如拆分成：调研故事、开发故事。需要注意的是，调研故事、开发故事一般放在不同的迭代里。
（二）用户故事拆分时，感觉无从下手
好的用户故事应符合INVEST原则，但在实际操作过程中往往难做到Size Appropriately和Testable这两点。很多团队经常会面临故事过大无法拆分，或者故事拆分方式不正确，无法在每个迭代结束的时候交付预期价值的情况。在尝试拆分用户故事时，在遇到无从下手的情况时，可尝试Mike Cohn总结的 SPIDR方法，这5个方法比较简单，而且高效。
- Spikes
探针(Spikes)，代表一类用于构建知识的研究工作和活动。
一般来说导致团队无法拆分用户故事的原因有以下几种：
（1）团队不熟悉业务，不知道如何实现它。
（2）涉及的技术不熟练，不知道如何使用。
（3）可能的实现方式有很多，团队背景知识不够，不知道用哪个比较好。
可以在迭代中安排一些研究型的用户故事来解决不确定的因素。探针类用户故事一般用在其他4类拆分方式之前,一旦不确定的领域明确了，就可以使用后续方式对用户故事进行拆分了。 - Paths
路径(Paths)，用户故事如果有多种执行路径，每一个路径都可以拆分为一个新的用户故事。最简单的方式就是按照业务逻辑的执行路径来拆分，例如：电商系统的支付功能，银行卡支付、积分支付可以拆分成两个用户故事。银行卡支付还可以进一步细分，为每条路径拆分出一个故事并不是绝对必要的，有时候拆分的太细，会带来其他问题，比如，无法评估工时。 - Interface
接口(Interface)，当用户故事涉及到横跨多种用户交互接口、数据交互接口时可以使用该方法进行拆分。例如一般交互系统可以分为移动设备和浏览器两大类。而浏览器也可以根据不同类型的浏览器分为：Chrome，Edge，Firefox等。也可以根据开发团队技术的熟悉程度也可以分为可以支持和暂时无法支持两类来拆分用户故事。
数据操作接口，例如支持多种文件类型(excel, xml, csv)的数据导入功能，可以使用文件类型拆分用户故事。 - Data
数据(Data)，当用户故事涉及相关数据的子范围时，可以按照数据类型进行用户故事拆分。比如用户订单统计功能，可以按照订单的状态进行分类。 - Rules
规则(Rules)，按照业务规则和技术标准对用户故事进行拆分。一些业务逻辑会带有很多规则，在开始时可以尝试将用户故事拆分成没有规则和有规则两类，之后可以按照规则继续进行拆分。例如在线售票系统，一些热门场次需要限制单用户购票数量，在一开始的时候可以考虑先实现购票流程，之后再添加限制规则。
关于用户故事拆分，后面可以专门
（三）待办列表中的任务未制定优先级
在计划会议开始时，如果可以快速在待办列表中筛选出高优先级的任务，可继续会议。如果不能快速筛选出高优先级的任务，建议产品负责人（PO）对待办任务完成优先级排序后再组织团队成员开会。
（四）需求不明确，临时讨论需求
应避免在计划会议上展开讨论不明确的需求，该需求不应放到sprint中，应由产品在会后跟需求方完成确认，放在后续的sprint中。
（五）工时评估不准确
影响
工时评估不准确，会导致当前sprint无法完成任务，延期交付；或者当前sprint任务安排不足，产生浪费。
解决方案
对任务熟悉的团队成员，为每个用户故事评估工时并写到便签纸上，等大家都写完后展示出来，参与评估的成员，一一解释评估这个数组的原因，尤其是数字最大和最小的人。团队成员根据解释重新评估工时，直到大家评估的时间比较均匀为止。
和Scrum中的其他会议一样，召开会议并不困难，难的是如何让会议既有效又高效，这需要团队成员共同努力。