[Day27] Scrum失败经验谈 – 危机四伏的Sprint planning会议

Sprint planning meeting的目的是在於定义这次开发周期间共同所要追求的价值目标，为每一个使用者故事(User story)给予故事点数(Story point)，选择合适的故事排入开发周期中，并将使用者故事在拆分成子任务，给予估时。这样的流程，平凡又简单，除了[Day21] Scrum失败经验谈 – 没有价值的User story 提到的没有价值导向的使用者故事外，我们过去在各个环节犯了不少错误：

使用者故事在Sprint planning会议初登场

危机一：使用者故事没有足够时间可以迭代优化

在过去，使用者故事在sprint planning会议才和工程师相见不欢，这样的行为代表，使用者故事的开立具备百分之两百的信心，确信故事没问题，故事完全符合INVEST原则，也考量过工程师的技术能力与可能性，对！完全是不可能的事情！完全没有工程师意见input的使用者故事，是不可能顺利进入sprint里面的，虽然，我们後来有意识到这件事，将使用者故事提前到sprint review and retrospective会议，但还是远远不够，当发现故事有问题的时候，是没有足够的时间修正使用者故事，最好的时间点，还是要在使用者故事诞生的时候，就要徵询工程师意见，不论是固定的会议或是和工程师另约时间都好，当使用者故事大量不清楚的时候，就不要让故事进入sprint之中。

估时後，紧接执行与排序

危机二：忽略「无法掌握事项」的风险

我们会利用费氏数列(1, 2, 3, 5, 8, 13, 21, …)来为使用者故事评估难易度，最早我们在估时的时候，给予故事点之後，就会紧接着开始分配任务，让每一个工程师所取得的故事点加总相同，然後让各自去拆解故事变成子任务，完美地弃风险而不顾。故事点是帮助我们了解难易度的一个量化管道，当故事点值很大的时候，就代表着需要被关注，依据我们要开发的项目与难度，我们团队後来的共识是只要故事点大於13就需要被讨论，故事点值很大代表的可能性有两种：一种是故事描述不清楚或规模过大，这时候，就需要请PO处理，将故事厘清或再次确认规模是否可以再调整；另一种则是所需要采用的技术或做法已经超出当前工程团队所能掌握的范围，不管实际作法为何，但就要给予工程团队Survey的时间，将不确定性下降，才有办法将风险降到最低，如果时间很赶，就需要想个替代方案了。

未认真看待估时

危机三：未能将估时视为一把尺，找出方法提高准确度

「估时都是不准的」，「请问估时重要吗？」讲师那时下了一个宣称(Statement)之後，问起了我们。答案当然是重要的，如同那时候讲师接着往下说的，「否则为何我们要花时间讨论估时这件事」。要让估时不断准确，有很多种的工具可以辅助我们观察，但我在这里要说的是看待估时的心态，不要将估时视为期限(deadline)，而是一把标尺，当估时视为是期限的时候，我们都会想尽办法追求数字上面的符合，而忘记其实是要利用「经验法则」更加掌握自己和掌握任务的核心意义，而这样的心态，不单单是工程师要有，身为推动者或主管也要有，这样团队才能发挥估时真正的价值与意义，让我们更能了解每一次开发的风险位於何处，而非只是看表面数字的完美。