关于每日站会和Plan会议的一些思考

入职新公司以来差不多已经深度接触了6个敏捷组，最近在参加站会的时候发现一个现象，大部分的敏捷组的站会都是团队成员轮流对照看板说自己昨天做了什么，少部分人会谈及自己今天准备做什么，几乎很少的人会表达自己遇到的阻碍和问题，基本自己的部分或者和自己相关的部分说完后就退出会议或者开始玩手机。

今天大佬提出了一个关于团队忙于开会的问题，我很快就想到我们的站会，Plan会议，我们每天组织这些会议的目标到底是为了什么？花的时间真的达到效果了么？在我看来，大部分的会议时间是花的不划算的。

每天开站会的目的是什么？

最近在敏捷社区看到一篇文章–五种常见的CSRUM反模式，就有提到一种，把每日站会开成了对Scrum Master的汇报会议。每日站会的目标应该是：团队成员之间同步信息以及共同管理迭代工作的会议。会议的主角应该是Sprint Backlog，而非个人的工作。我们每天每个人轮流说自己的任务，其实是对每日站会的误解，我思考了一下，Scrum一开始会有描述三个问题这样的倡导，或许是因为他的背景是一个Story往往是由一名成员负责到底的，他个人在讲的时候，聚焦的其实是他所负责的那个Story的情况（无资料参考，自己YY的），而我们一个Story往往至少由1～2名开发+1名测试共同完成，这种情况如果还是按照Scrum的3个问题的模式进行每日站会，往往就变成了个人的汇报会议，而没有聚焦具体的Story上。

每日站会的还有一个目标是共同管理迭代，这是很容易被忽略的一个点，Scrum提倡团队在每日站会的时候去计划一天的工作，这一点在实际实践中，就会变成说明自己今天计划完成什么。我们计划的到底是我今天要完成什么，还是我们团队今天需要完成什么？我认为应该是我们团队今天要完成什么，然后根据团队的目标，将任务分解到个人身上，然后第二天站会再一起过团队前一天的目标完成情况、Sprint Backlog的进展，和当天的计划，这时候就可以借用一些工具（比如燃尽图、累积流图等）来协助我们判断Sprint的目标进展及风险等情况。

既然我们每天做Sprint当天的计划，似乎和Plan会议又存在一些重复内容，那我们Plan会议又该做什么？

Plan会议的目的是什么？

在我这几年的敏捷实践中，一直致力于在Plan会议上把Sprint计划做的完美，明确每个人要做什么，每个Story要花多少时间，甚至什么时候可以开发完成、什么时候联调、什么时候提测、什么时候上线。一次会议做完一个Sprint的计划。其实现在回想一下，这并不敏捷，一旦中途有需求的变更，就需要进行一次繁琐的计划调整，什么拥抱变化，根本拥抱不动。

那我们的Plan到底应该怎么做？在Scrum框架中，Plan会议会有几个部分：

• 接下来的 Sprint 交付的增量中要包含什么内容？
  – PO讲解 Sprint Goal以及达成该目标所需完成的Backlog
  – 团队选择这个Sprint的Backlog数量，即Sprint Backlog
• 要如何完成交付增量所需的工作？
  – 团队规划出在 Sprint 最初几天内所要做的Story，并制定优先级
  – 团队对这些Story进行估算和任务分配
  – 每日站会再根据Story的优先级做当天的计划

但这也会带来新的问题，因为Plan只做了前几天的详细计划，而后面的计划都是需要在每日站会中明确，那我们该如何保障我们挑选出来的Sprint Backlog能够被尽量完成呢？

这里要讲一讲团队速率，团队速率是我们经过几次Sprint后得出的一个经验值，这是一个很好的参考，当团队较稳定，且人员变动也不大的情况下，团队速率就会趋于稳定，此时，这个团队速率就可以作为我们Plan时该挑选多少Backlog数量的一个参考。

我们还有一个原则，我们在进行Sprint时，需要优先完成那些高优先级的事项，这些高优先级的事项正是影响我们Sprint目标完成的关键点，在我们这个快速发展的环境下，市场的可能每周都会有变化，在变化的过程中，那些低优先级的需求可能就会变得没有价值，甚至可能都会被叫停，所以我们并非一定要100%完成原定的Sprint Backlog，在每日站会的时候我们调整计划正是拥抱变化的一种体现。不要忘了我们最终的目标是达成Sprint Goal。