另一种开站例会的方法
内容列表
兵无常势水无常形 ，这句话对站例会也同样适用。
虽然没有任何资料明确要求，站例会上我们应该每个成员轮流发言直到结束。但在实际操作中，我们发现这种作法的团队不在少数。
当然，我无意于说这种作法不对，但是的确有几个问题会在这种作法中暴露出来。
可能的问题
我们来看一个场景：
当前有A、B、C、D四项任务和甲、乙、丙三个团队成员。
假设甲处理A和B的部份内容，乙处理了B和C的部份内容，丙处理了B和D的内容。
当我们根据甲、乙、丙的顺序，分别让他们回答了站例会的三个问题后，SM 或者其他人是否能对A、B、C、D四项任务状态有一个明确的认知？
我相信不是不能，但是会有点混乱。SM 和其他人要听取了别人的同步信息后，自己整理到每个任务中，最后得到了一个状态。而其中最可怕的是，由于这个是每个人的理解不一样，最后头脑中汇总出来的最终状态，极有可能是不一样的，这就造成了可能的潜在的风险。
那么有没有其他方法来开站例会呢？
一种新的方法
既然轮流发言容易导致我们对用户故事状态的混乱，那我们根据用户故事来同步信息如何？
- 由一个成员（可以是SM）拿出一张用户故事卡片，依次询问“昨天我们对这张卡片有什么进度？” “今天我们要完成这张卡片的哪些工作？”“工作过程中有什么障碍？”
- 然后再进行到下一张，直到所有的未完成的用户故事都进行了同步
- 没有第三步了
新的方法的好处
- 由于是根据用户故事来更新进度，每个人最终对用户故事状态的理解是一致的；
- 由于不在是根据人来同步，而是根据用户故事来同步，这就让整个团队的着眼点回归到用户故事这个具有价值的单位上面；
- 可以人为设定“故事所有人”（Story Owner），所有与故事状态、问题解决有关，可以第一时间找他负责处理，避免了因为团队主观能动性不足导致的无人负责情况；
- 由于根据用户故事来更新，可以更方便看清楚故事的负责人，进而帮助团队成员进度透明化进一步提升；
- 由于根据用户故事来更新，可以将故事的障碍（impediment）和阻碍（blocker）更明显的暴露出来。
说在最后
- 原来我们团队轮流发言的方式是有用的，否则不会这么多团队在用；
- 根据用户故事为单位来更新，这不是银弹，需要根据团队、环境等进行选择；
- 根团队成员轮流发言OR 根据用户故事来更新，并不是非此即彼的状态，可以在不同时间灵活使用；
- 最后的最后，只要团队成员满意，且进度正常，不要轻易去改变方式。
这就是我今天与大家分享的内容。如果你有什么观点，希望你可以与我分享。
