讨论聊聊你司的站会，是否有必要每天都开？

自我感觉我司的站会从开始的了解，督促进度的意义，而后流于形式。某天琐碎的工作可能难以在站会讲清楚。

这个搞到后面就跟写日报一样，都流于形式和应付了。建议每周一次站会总结一下上周的工作内容和遇到问题，说一下本周的工作计划可以会不那么形式。

立会也许初期需要，同步成本很高，但有密集沟通的必要时，一开始作用如校时一样，彼此调整好时脉，避免不必要的功耗或是等待。

Daily stand-ups 在 remote first/friendly 团队，有许多非同步的替代工具能用，也大量降低同步成本。如调动所有人的肉身/感官/注意力到场或在线，只是为了获取状态？是不必要的浪费，像等候时间与打断他人工作节奏，若团队成员跨时区协作，为了同步而同步的成本会更高。

视觉是工具，用来辅助知觉的控制与确认，团队成员将状态定期更新到一处(trello/slack/git repo等等)，状态汇整能被看到，已尽 daily scrum 责任。

至于是否需要 Daily stand-ups，也许看团队的发展状态是 efficiency-driven 或是 Innovation-driven 阶段？若是前者，慎防 dark scrum/agile 照搬瞎操作为获资源，而对 stand-ups 的滥用。前面朋友提到，只要成员不自愿参加、甚至牴触，这是很强的 bad smell，特别是 dev leadership 出了大问题。

任何事都有两面性，我的理解： 站会是为了适应敏捷和管理需要，及时了解和跟进团队所有成员状态，避免问题到最后暴露时无法补救或者补救代价太大。站会是否必要要看具体的团队协作或者流程管理情况。
1。 团队如果没有很好的协作工具或者大家都没有形成及时更新状态的习惯，那么站会有很有必要，站会的目的是让团队成员形成协作习惯，及时更新自己的状态、汇报可能的困难或者风险，及时寻求团队的帮助，也让团队成员能够更好的预计当天或者未来的工作任务和节奏，保证项目按照预期的方向走下去。
2. 团队如果已经形成的很高效的协作模式，成员都习惯及时更新和分享自己的状态、进度、风险等信息并及时呈现在团队层面，那么可以不需要站会，因为站会需要的目的已经通过其它手段实现，不需要重复。

大家感觉到站会的问题主要有：感觉别人说的和自己关系不大， 感觉自己说的和别人关系不大。 团队中偶尔发生这种感觉是没问题的，因为团队分工中，每天的任务不一定都是和别人密切相关的，但是在一些关键节点都需要团队相关，所以这种情况站会是一个仪式，为了培养习惯，还是利大于弊的。
如果发现很长一段时间内都是这种感觉，说明项目团队的组建或者划分是有问题的，表明可能是行政上凑了一个团队，但是项目任务上各做各事，这种情况下需要考虑重新划分团队或者审视工作任务的安排。

我司最牛逼的在于站会+任务ticket，绩效挂钩
任务ticket里会有对应的 预期时间 和 开始-结束时间
每天早上站会需要对着自己完成的bug\feature汇报工作

很多bug分不清前后端，但是一般会先将任务分配给后端
为了完成工作量，不管前后端哪边改bug更简单, 后端都已经debug找原因了，不可能打回给前端，强行后端改
而且有时候莫名其妙改着改着前端发布代码后该bug没了，后端也会将改的代码提交，工作量证明
每天疲于应付，烦了就会满足工作量证明，学不到东西就自己带薪摸鱼学习

所以，根本不会再有多余的心思思考怎么写代码或者设计流程更合理，因为这些不算工作量，而且，有更多不合理的地方，才会带来更多的工作量

人都有惰性，每天整一整有必要，但说的要有总结性，别吹水。有助于把控风险，目标达成。

至少对于我公司的站会，我是烦透了，站会半个小时，罚站25分钟听每个成员汇报跟我们没关系的内容，还都是在下班时间。有这时间我bug都修完了

一般敏捷开发里面比较流行每日站会。但是就和敏捷开发这个名词一样。敏捷开发不是只有敏捷，也不是只有站会。国内的很多公司特别喜欢拿一半就开跑。

无论是站会也好，敏捷也好，用户故事也好，这些方法论最终都要落实到人上面执行。人优秀了，什么流程和方法都能够发挥它最好的效果。人不行，再好的流程和方法都会负担而非提升。

上一家公司的每日站会就是学了敏捷开发之后弄的，站会的重点是根据任务时间安排，及时暴露出存在或可能存在的问题，SM可以及时协助组员解决问题。但很多时间都只是汇报一下工作情况，也就很可能流于形式了。

个人觉得对于远程来说，每天的站立会议其实没有必要。
颗粒度太小了，如果是一个比较大的任务的话，可能三四天都再处理这个任务。
但是周会还是有必要的，大家沟通沟通这一周彼此在干什么。
同步一下每个人的工作，以及是否有一些问题。

项目不停的快速迭代的同时，间隔性的开会是必要的。

• 昨天完成了什么
• 今天要完成什么
• 遇到了什么阻碍
  昨天完成了什么，今天要完成什么，这个完全可以用项目进度看板，没有多大作用。
  遇到了什么阻碍，不是几分钟内就能提出解决方案解决。
  总结：过于形式主义

对于公司的管理层来说，开例会确实有助于了解属下的工作进展，对属下员工来说汇报进度也有督促的作用，但是开会的频率如果没有控制好那可能就适得其反，天天开会我是觉得不必要，有事说事才比较高效。

开站会每天汇报完成任务、规划、阻碍本身从这些内容来讲，大部分时间没啥用，坚持日报的人都知道，大部分时间都是平淡到能用 “正常” 二字来总结。

但是站会并不是一无是处，在稍微大点的公司，你开站会与不开站会给人的感觉就不一样，这是从团队影响力的角度去考虑问题，每天这么坚持就能让别人感觉你这个团队很有战斗力。

其次，对于能力差成员占比更多的团队而言，站会是必须的，因为对于这些同事，你得把控着他们做事。等团队能力起来了，就会出现我之前所说的平淡到正常的情况，这时候，站会就得改周会了。如果是我的话，我更愿意将团队划分成一个个小组，把站会这件事下放到更小的单元，重心应该是培养骨干了，对于组长就不站会了，甚至都不周会了，直接看周总结就行了。

站会是有必要的，但是要控制规模的细粒度，最好以一个单元业务，最好定职责人员，因为有些人你不问他不太会暴露问题最好是小团队技术负责人大家过一下，几分钟的事情你说浪费我觉得也没啥浪费的，大家抽支烟都不止几分钟吧

原来最早在华为接触敏捷开发，敏捷倡导面对面的沟通，站会让每个人都有了这样的机会。了解他人工作的机会。
在更早的开发模式下，每周有一个周会，平时都是事件触发式的会议，团队间每天的交流可能会少。

我们团队有很多刚入职场不久的人，需要老员工或主管带，每天站会都可以及时发现新人可以进一步提升的点。
站会也可以让大家不断提升自己总结归纳的能力，短时间说清楚自己的3件事。

敏捷，一个迭代2-3周，一般团队采用2周，甚至更短，这个要求团队更加成熟，每个人的能力更强。
如果一个足够成熟的团队，大家的敏捷流程在线上异步沟通做得很充分，其实没有站会也是没问题的。
会议的目的高效面对面解决一些复杂的问题。站会也不例外。一定不能流于形式。

对站会的组织者也提出了要求，能把站会组织成积极、每个人都参与度高的会议，挺需要一个好的主持者。

我们公司开发人员只有三个，但还是会有站会，只不过是每周一次。
因为三个人都是远程的原因，经常聊着聊着就会讲到各自生活中的点点滴滴。这样的周会讲讲工作，再讲讲生活，一般会持续一到两个小时。

有事说事，无事退朝的感觉，看主管的人和控制与会人数

团队引入了飞书来协同
提前更新晨会内容，讨论议题，列明to do
效果不错，目标更聚焦了，效率有所提升

我是项目经理，更加了解站会的意义和无趣。

单独为了站会的形式去开会，其实是无趣的，并且消磨大家的热情。最后他就是个大家碰嘴会，嘴皮子一碰就结束了，没有任何的收尾。

开会开到后面，我作为主持人，反而为了怎么引发底下人的热情而苦恼。

后面改成一遍嗑瓜子，一遍沟通，就好了很多。大家在放松的状态下能够说出一些平时不说的内容，比如楼上仁兄说的菜价啥的，以及对某些事务的评价。后面的会议，就变成了奶茶，瓜子。。零食会，3个月后，团队内部集体都胖了一圈。然后就各种爬山减肥打球会。。。

会议分两种，比如一种为了宣贯重大事情的会议，另外一种就是这种为了解决问题的或者同步问题的小会议。在这种形式下，也是成功的把甲方带歪了。。。甲方跟我们一起嗑瓜子发版上线；

聊跑题了。站会这种东西，不必要每天开，但是开的话，一定要持会议质量的。比如每个人发言的程度，沟通，一定得主持把控好。其次，会议的气氛很重要。大家在水底开会，和大家都山顶上开会，心情都是不一样的