最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
站会？这时很可能一个冷眼丢过来：你们这些搞敏捷的啊，就是会多。可是啊。2025年，Agile Alliance都被PMI收了啊。
如果你经历过团队站会开得贼溜，但是项目的迭代各种出问题的：
比如移测又推迟啦
迭代干不完啦
又来了新需求了
需求又修改了
……
你可能也经历过确实每天开站会就那几个问题，大家都知道答案，……甚至想改变，可是错付了……你终究会需要直面这个问题，站会必须得开吗？这个站会是开给谁的？怎么开站会才算是还可以？他们说的是不是故意骗我？报喜不报忧？
1
说到站会，可能还是会有一些误解，比如：
有了站会就解决了团队进展管理问题
听说你们有手册，按手册执行就能解决问题
这个会议会不会很长？之前我们开过一上午
站会这么有用，我们搞个大规模推广吧，每个团队都搞起来
站会的主持人是固定的，会议没开好，就是Scrum Master或者敏捷教练的责任
面对开了一段时间站会的团队，迟到早退或者请假虽然时时发生，但是我们可以罚钱，然后大家团建Happy来让大家更愿意参加
就天天那点事，说的都差不多，是不是没会硬开？好象多此一举啊
原来你们的管理就是开会收数据啊
我们天天都要忙死了，你们还要求这要求那的
别的会跟这个冲突了，你们等我
开站会说的事大家都知道，能有啥实际作用，对面工作没啥帮助，形式主义
每天站会都一样的流程，开发个系统随时能看不就得了
看看，他又来观摩站会，刷存在感
注意！PMO今天来，大家说点好听的
昨天的情况不是告诉你了吗？这一天天又是日报又是站会的
……
每一种自信都有期待，每一种吐槽皆有其原因。
2
我们为什么要开站会？我们在站会中究竟需要解决什么问题？前面说了那么多站会的误解也好、吐槽也罢，对于项目的过程来说，有几样式还是我们关注的：
我们在哪儿。也就是当前的进展。知道进展就能分析与目标的差距。就可以推演以目前的状态是否可以如期达成目标。前面还有哪些心里没数的。这个就有点意思了。我们知道不同的角色都有自己的术语和关注的内容。比如开发人员说写了多少代码和测试说执行了多少案例，看着是说了进展，但实际上又从逻辑上没有什么帮助。
我们还需要知道遇没遇到坑，可能的问题在哪里。哪些事情我们没有预见，或者哪些预见了但是我们并没有准备好对策。对未来有什么影响，什么解决。
谁是我们的同路人。我们要和哪些人/团队一起达成目标？我们需要谁的帮助？谁需要我们的帮助？我们都知道所谓一个人走远快，一群人走得远。可是管理上的解耦让明明是一群有着相同目标的人，没有那么多沟通了。就像是明明是一场团体越野跑，大家要一起到在终点，可是跑着跑着就因为能力不同、奖励不同（考核）演变成了竞速赛，队伍跑成七零八落，甚至掉队、无法完赛。
我们还需要一些策略。如果要爆雷，是每次我们都能控制，还是最后来个核爆，然后焦土一片？目前的状态需不需要调整我们的措施？比如重新安排资源或者调整方式、优先级？
这就是有需要。那就非得开会吗？当然得开。因为我们是一伙儿的。最有效率的沟通就是面对面。
3 我们为什么开不好站会
有些人可能会说了，站会有什么难的？就几个人问题一说不就清楚了吗？而且人家早就有最佳实践，写好了指南，作业都写好了，你不会抄作业啊？自己去翻Scrum Guide去：
“每日Scrum 站会是以 15分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的 24 小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日站会之前所能完成的工作。每日站会在同一时间同一地点进行来降低复杂度。会议上，每个开发团队成员都需要说明：
昨天我为开发团队达成 Sprint 目标做了什么
今天我准备如何帮助团队达成 Sprint 目标
有什么事情阻碍了我帮助团队达成 Sprint 目标
开发团队用每日站会来评估完成 Sprint 目标的进度，并评估完成 Sprint 待办列表的进度趋势。每日站会优化开发团队达成 Sprint 目标的可能性。
每天，开发团队应该知道 如何以自组织的形式协同工作以达成 Sprint 的目标，并在 Sprint 结束时开发出预期中的增量。整个开发团队或者部分团队成员经常在每日站会后聚集到一起进行更详细的讨论，或者为 Sprint 中剩余的工作做调整或重新计划。
Scrum Master确保开发团队每日站会如期举行，开发团队自己则负责召开会议。 Scrum Master指导团队把会议控制在 15 分钟内。
Scrum Master强制执行每日站会的规则——只有开发团队的成员才能参加。每日站会可以增强交流沟通、省略其他会议、确定开发过程中需要移除的障碍、强调和提倡快速决策、提高每个成员参考项目的认知程度。这是进行检视和调整的关键会议。”
是的。就这么简单。很多团队就是这么做的。可就是仍然出问题。这也是被吐槽得最厉害的地方。这一个会议快背锅到承担了一切。你们敏捷就是会多。而站会是敏捷独有的吗？我们来将这份Guide拆成几个检查点，你没开好，大致是这些点没有做好：
团队的Sprint目标不够清晰。完成了能达成什么业务目标？这个目标可以拆分成小步可以快跑吗？我们多长时间可以看到Sprint目标的进展？
我是如何知道昨天我为Sprint目标做了什么的？是真的有进展感，还是完全凭感觉？我们关于进展的数据是如何呈现的？
我准备如何帮助团队达成Sprint目标？是完成我的任务，还是一次集体“冲刺”？
有什么事阻碍了我？是阻碍了？还是可能阻碍？是有对策？还是听天由命？是已经预知的？还是突发事件？解决方法是临时的，还是对大家来说都有意义？
我们说的是不是同一件事？不是开发在说代码写了多少？测试通过了多少案例？产品写了多少个需求？
管理者知道真实的情况吗？
在站会上要解决的事情是什么？有哪些在开会前应该准备好了？
有什么事情发生的时候就需要做出响应？
站会开完团队成员是否准备好了能开始向目标前进？
我们的站会解决了干系人关注的问题吗？咱们自己说的事儿，其他团队知道吗？特别是必须合作的团队？
4 站会怎么开？
站会要怎么开？Scrum Guide说的已经很清楚了。然而，所有故事都有上下文。如果上面写的那些问题没有解答好，大概率是开不好站会的。所以关于开好站会，我们有三条建议：
从现在出发，循序渐进种一棵树，最好是在10年前，其次是现在。在理想的条件下开始，效果可能会很好。持续改进，团队能更好地理解我们为什么这么做，以及怎么做到的。还能在持续的改进过程中，形成团队精神。比如：
目标需要怎么对齐？
需求拆分到什么大小合适？（一个21天的需求跟踪起来，显然比一个1天的更复杂）
每个小目标的负责人是谁？
我们的目标达成之后，会有哪些特征，有什么检查条件？
当我们离理想的会议状态有差距的时候，我们需要做的改进有哪些？
统一语言，讲一件事每一个角色都有自己的专业领域。沟通的时候，需要尽量讲人话。在我们的工作中，一定有很多协同。解耦确实能让有些事情得到分隔。但是成功的关键一定是在协作之中。这意味着，我们需要对齐在会上讲什么，输出的是什么：
每个角色讲的进展是什么？
会议的输出是否可以真实反映现状？
会议是否可以解决不同角色关注的问题？
4
还记得我们前面提到的问题吗？这些问题都有答案：
站会肯定是要开的，而且要每天都开。不开，蛐蛐你的人大把，与其私下里对来对去，不如好好解决。
现在开站会的方法，有好多是有问题。一个最简单的问题是，早上发过的誓，下班的时候不是拍着良心说干完，而演给大家看？
5
每天的站会，就像一个健身过程。你可能不一定立刻感受到它的好。但是健过身的朋友都知道。你每天都跑5km，当你跑个10km就可能不是事。但是如果你没经过这个锻炼，除非你天赋异禀，否则大概率就是要了老命了。
我们要去哪儿。也就是我们的目标。这个目标，很多时候我们以为我们是清楚的，始终不变的。大家都清楚的。可实际上呢？大家清楚的可能只是自己的任务（），这个目标可能也会随着项目的进展，与业务的需求澄清不断扩大，可是人还是这点人（）。
构建自动运行的系统，让账实相符在管理的过程，团队的状态经常被质疑。他们说的是他们真的那个状态吗？于是有各种所谓的检视措施。最常见的就是问团队要各种数据，要求日报、周报、双周报、月报、季报……即便是这些数据有了，还会各种担心，因为好象团队给的和我们感觉的，以及最终结果表现的，不怎么一样。这里我们建议构建一个自动运行的系统。让过程可以数据化。当然你们可以自己开发，但是简单点做个共享的数据表都是可以的。你要谨慎选择统计的走向，是功劳还是苦劳？因为你的倾向会影响团队的走向（）。我们也建议这个系统中的数据是有实践守护的。比如发誓-雷劈系统。每天的目标是可以通过实践进行跟进和确认的（）。最简单的就是晨夕会，早上站会说可以完成几个，夕会就以秀出来作为最简单的检查点。群仙都在，没达成用雷小劈一下也没什么问题。一个迭代也可以这样，计划会是一次发誓，评审会就是一次群仙会，团队完全可以通过自己是不是每次都是外焦里嫩来改进自己。
至于他们说的是不是故意骗我？是在报喜不报忧？现在我们看到很多站会召开指南都没有讲这个话题。我们当然有着让你能够看到。还贴心的架构了晨夕会的着数，配合，就可以账实相符。这个在之前的RSG分享后有写出来分享过：。
