原来Scrum的这几个会我都白做了

306 2023-07-20

迭代团队计划回顾站会

本文1778字，阅读约需2分钟。

对于玩Scrum的小伙伴来说，需求梳理、迭代计划、每日站会、迭代评审和迭代回顾这几个会是再熟悉不过了，然而大家虽然折腾的热闹，很多时候也只是热闹热闹。（注：“需求梳理”在Scrum Guide中并不是一个标准的会议，它只是一个活动，不见得要开成会议，我们只是约定俗成把它叫做会议。）

下面我分别聊聊这五个会中最最重要但又最容易被忽视的一个点，大家看看自己有没有做到位。

// 需求梳理

在需求梳理中，我们要确认梳理的每个需求：

能不能不做？
优先级能不能排得更低？
如果优先级不能更低，那么可否把这个需求的一部分拆出来排到更低的优先级甚至是抛弃？

只有这样，我们才能真正去思考什么才是高价值的事情，我们要有足够的理由把它留着或者留在当前的优先级位置。

而实际上呢，大家的操作刚好相反，觉得有价值就放进来，排序只是走走过场，没有取舍，反正都是做，不是这个迭代做，就是下个迭代做。

// 迭代计划

在迭代计划中，最容易出现的问题是不按团队的能力做计划，明明这个团队过去每个迭代只能完成50个故事点左右，但做计划的时候，偏要排80个甚至100个故事点，不这么安排，产品负责人就觉得不甘心，觉得团队就不会拼尽全力。

结果呢？要么为了完成迭代计划，加班加点儿，大家觉得领导是利用迭代来压榨员工；要么团队觉得迭代计划形同虚设，因为计划多少这么随意，毫无计划可言；要么团队因为迭代完成度不高，导致士气低下，你想啊，每次迭代完成率都是60%，哪赶上80%、100%开心啊？团队不开心，状态能好吗？状态不好，干活效率能高吗？

// 每日站会

最常见的每日站会，是每个人谈自己昨天做了什么、今天计划做什么、有什么阻碍。这三个问题敷衍回答完毕，站会就波澜不惊结束了。

实际上，站会更重要的是，团队作为一个整体，共同看看现在朝迭代目标的进展如何，完成了多少，进展是否顺利，有没有风险和阻碍，为了更顺利完成迭代目标，我们今天需要做哪些调整，所以每日站会，可以看作是每日计划会，而不是每日汇报会。我们可以问问自己，有多少团队有“迭代目标”，更别说朝迭代目标的进展如何了。（关于迭代目标，请参考Scrum Pattern | Sprint目标）

就拿我服务过的一个团队来说，我在站会中给大家加了一个“信心指数”节目。开始大家回答那三个问题的时候听起来一切顺利，等到大家开始评估完成迭代目标的“信心指数”时，就各种困难都提出来了，神奇吧！这个时候才能暴露真正的问题，工作得到切实有效的调整。

// 迭代评审

迭代评审是Scrum针对产品（Product）实现“透明、检视和调整”这三大经验主义支柱的关键环节，迭代评审的目标是给客户、用户、业务方及其他利益相关人展示真正能够运行的产品，收集大家的反馈，希望能够及时做出调整。

现实呢？很多Scrum团队要么嫌麻烦，要么怕收到很多改进意见而增加工作量，要么觉得迭代评审是一种“放在火上烤”的感觉，被人挑毛病浑身难受，面子上过不去。因此，很多团队只是在上线之前两天才给用户看，用户给他们提出100个修改意见，他们会借口只有两天的时间，干不了那么多，还不能拖延上线时间，嘴里还振振有词说：“耽误上线的时间你负得起这个责任吗？”。他们只在两天的时间内修改了10个意见，另外90个修改意见就被搁浅了，什么时候能轮到，那要看缘分了。

如果这么做，何谈及时调整？何谈敏捷性？

// 迭代回顾

迭代回顾是希望每个迭代都能比上个迭代做的更好。

大多数人不愿意开回顾会，一方面是这个会议不能直接产出代码，也不能对软件产生直接的影响；另一方面，大家可以看到，很多团队的回顾会中，来来回回都在讨论相似的问题，而且很多时候还是在讨论团队无法左右的事情，大家在一起只是在抱怨团队外的别人。

要开好回顾会，我们需要真正找到我们能够解决的大家真心希望解决的问题，并落到实处。什么叫落到实处？会议结束之前，要明确我们接下来一个迭代要解决哪个问题，责任人是谁，要做到什么程度，验收标准是什么。之后还要放到下个迭代的迭代计划中进行跟踪。

不要嫌少，哪怕只是扎扎实实解决一个问题。相信大家从此会爱上回顾会。

迭代回顾是Scrum针对流程（Process）实现“透明、检视和调整”这三大经验主义支柱的关键环节。