如何提升团队凝聚力（如何提高团队凝聚力_）

　　编辑导语：有些企业会在早晨进行一场站会，很多人都会觉得这个不仅很傻、还浪费时间。但其实每日站会只要用得恰当，也有着它不一样的意义。作者分享了关于站会的意义以及如何有效地开站会，一起来看下吧。

　　Scrum的迭代冲刺过程中，有个重要的会议—每日站会（daily stand up meeting），可能很多人对为什么开站会持有怀疑态度，觉得一帮人围在一起太“傻”，每天花费时间去搞站会，手头上的工作会被打断有什么意义？个人根据项目中的实践，谈一些理解和感受。

　　一、站会的意义

　　1. 同步迭代进度

　　这是最核心的目的，敏捷研发是一个快速迭代交付的过程，有些项目的迭代时间盒可能是1个月，有些可能是2周甚至更短。快速且高效的进度同步，有助于项目的正常推进、按时交付。

　　2. 团队凝聚力

　　每天定时碰个面可以时刻提醒每位团队成员，我们是一个团队，我们在为共同的目标在努力奋斗，迭代的成功有我一份功劳，迭代中的困难我可以出谋划策。大家在明确项目目标的同时，也有助于提升团队的凝聚力。

　　3. 提升个人沟通能力

　　团队成员在回答经典“三问”前，都会组织自己的发言，或者ScrumMaster引导团队成员有逻辑地表达自己。对于不善言辞的同学，这是个不错的锻炼机会。

　　二、如何有效地开站会

　　1. 时间、地点

　　同一时间、同一地点；地点不谈，主要聊一下时间。有些项目喜欢早上开站会，有些项目喜欢下班前开，个人比较推荐下班前的时间段，原因有三：

　　首先，下班前比较容易回忆起今天做了什么，有什么困难。如果放在第二天可能还要花费一些时间来回忆；

　　其次，有些项目可能会有写日报的习惯，个人理解站会下班前召开，个人可以对自己一天的工作进行总结，一定程度上替代日报；

　　最后，就是这万恶的996、弹性工作制，有些企业是不是经常加班，加班后第二天可能就没那么准时地上班，站会放在下班前比放在早上出勤率要高一些。

　　2. 参会人员

　　团队成员、ScrumMaster；如果领导要参加，建议领导作为旁观者的身份参与，尽量不要发言。不过实际场景中，领导总是要说上两句，再加上领导的参与，会使会议的气氛变得严肃。

　　所以，可能的话，能不让领导来尽量就不要来了。

　　3. 经典“三问”

　　经典“三问”：昨天做了什么、今天准备做了什么、有什么困难。个人理解，站会更看重的是成果，而不是过程的同步。

　　所以，我们希望做一些改变，把“做了什么”改成“完成了什么”，如果没完成还需要多少时间，这样有工作交集的同学知道哪些工作可以对接，哪些工作可以流转，如果无法对接大概还需要花多少时间。同时，这也助于培养成员价值交付的思维，而非流水账似的汇报工作。

　　3. 站会工具和输出

　　站会需要一名主持人，一般是ScrumMaster担任，不过为了提升全员的参与度，个人推荐团队轮值。

　　其次，在站会过程中，我们希望团队是围绕物理看板或者是电子看板中的用户故事或缺陷，进行状态的同步。

　　同时，主持人记录会议过程中待解决的问题或阻碍，便于会后相关人员单独沟通。

　　会议结束后，输出的成果一般是用户故事或缺陷的最新状态，以及最新状态的燃尽图。

　　4. 明确站会的纪律

　　第一，会议的时间控制在15分钟以内，时间过长容易使人产生疲惫感。

　　第二，与会人员尽量不要迟到，大家在实施敏捷前制定一些团队基本协作规范，对于经常迟到的同学，可以给予适当的惩罚，如迟到3次以上可以请团队成员喝蜜雪冰城（旋律走起）。

　　第三，会议过程中不建议团队成员带手机，个人理解有两个好处，其一是手机中的各类推送或聊天会分散个人注意力，不带手机可以避免成员在过程中不时的去翻看资讯；

　　其次也是和个人注意力有关，有些同学可能习惯于同步完个人的工作事项后，不再关心其他人的发言内容，拿起手机玩起来。

　　敏捷过程中，我们希望是全员都要了解每个故事内容，以及团队的困难或阻碍，个人的经历或经验不同，有些困难可能在某些同学眼里，就是三两句话可以解决的事情，全员的参与有助于障碍的快速清除。

　　5. 提升站会的趣味性

　　常规的做法是，大家围成一个圈，按顺时针或是逆时针依次发言，主持人负责维持会议秩序、记录问题。不过，这样久而久之，站会可能会变得枯燥乏味。

　　个人推荐，ScrumMaster可以和团队成员头脑风暴，采用类似点名接力的游戏方式，对于接力失败者给予一点小小的惩罚，每两三个迭代可以更换一种新的玩法，这样参会人员可以集中注意力，同时也可以提升站会的趣味性。

　　不过，需要注意的是，这种方式尽量在团队成熟期举行，在初期或团队磨合期这样玩儿，可能会有适得其反的效果。

　　以上是个人关于敏捷中站会的一些想法，如有不足、欠妥之处，望指正。谢谢！

　　本文由 @贺大叔 原创发布于人人都是产品经理，未经作者许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。