每日站会，英文Stand-up，跟Scrum框架中说的Daily Scrum是一个事儿。
我听过一个有趣的现象：在敏捷开发方法兴起的时候，很多传统开发模式的团队跃跃欲试，他们选择从Stand-up切入，站会成为了敏捷第一会也由此而来。然后他们每天早上上班后，大家聚在一起开个会（站着、坐着都有），然后该怎么做还是怎么做。他们会对别人说：“我们在搞敏捷开发...”
Stand-up就是团队站在一块儿快速的开个会，相比于其他正式的会议，站着开会可能显得不那么难“正式”，即便这样，也不能掩盖期价值，它是一个性价比很高的活动 -- 投入10分钟，却能让团队发生积极的变化。当然还有其他一些好处，比如：
- 吹响工作的号角，让团队进入一天的工作状态。
- 同步工作进度，让大家清楚项目整体上下文。
- 暴露问题和风险，寻求其他人的技术支持或者Team Lead的资源支持。
- 共享知识，避免其他人重复造轮子，提供可供复用的解决方案。
一个高质量的站会在带来上述这些好处，一定会让团队发生一些积极的调整：
- 吹响工作的号角。（调整精神状态，进入专注的工作状态）
- 同步工作进度。（调增自己的步伐，更好跟其他人保持统一步伐）
- 暴露问题和风险。（跟他人协作来解决问题，而不是一个人死磕）
- 共享知识。（采用现有轮子，高效解决问题）
要举行一个高质量的站会，还有很多工作要做。
如何开始？
对于一个新团队，即便是站会这种相对“非正式”的会议，也通常会面临一些如何开始的基本问题：
- 每天说什么？
- 什么时候开始？
- 都需要谁参加？
站会说什么？
越是简短“非正式”的会议，条条框框相对就越少，一些团队在开始执行站会的时候，每个人习惯性沿用自己惯有的表达方式，整个会议下来信息凌乱。
即便是短短10分钟的会议，说什么也得有讲究，不可不着边际的讲。有一个入门三段式来辅助一个新的团队开始，这个模板可以让站会先流转起来。其实就是回答三个问题：
- 我昨天做了啥？（昨天完成了什么？进展如何？）
- 我今天计划做啥？（今天将完成什么？预计多久完成？）
- 我遇到了什么阻碍？（有什么风险？需要什么帮助？）
三个简单的问题，不用说太多，主要是跟团队同步一下状态。最好快速讲完，每人讲个45'' ~ 60''就差不多了，你可以以这个时间作为Timebox，避免大家陷入细节。其实要想快速，还有一个办法，就是让大家开得不要那么舒服，最好是站着开。研究表明，当人们坐着开会的时候，会议的时间会被无形中拉长。
站着开会这个主意还真不错，如果能将站会议控制在 5 ~ 10分钟就开完，就是一个不错的站会。因为站会的频率很高，控制好时间，让会议高效进行是让它能够持久保持活力的关键。
什么时候开始？
对一个在一个时区的团队，在同一个办公空间内最好。每日站会通常建议在一天开始上班的时间进行，这样更能够有效地建立起一天工作开始的节奏。时间安排的话，也不用太苛刻，在工作时间后半个小时是个不错的时间，比如你公司规定9:00上班，9:30就可以开始了。有了这个缓冲时间，大家就不用手持煎饼果子边吃边开会了，还能安置一下新买的大衣外套，设置好电脑的角度，沏壶龙井，并列出一天的todo list。
也有一些少数的团队会安排在其他时间，比如下午的时间，如果不是因为分布式团队存在时差的原因，不建议安排到下午，因为可能经过了一个晚上非工作的时间，注意力经过了多次切换，会造成不必要的损耗。
需要谁参加？
没有什么特殊原因的情况下，团队全员都得参加，注意这里的团队是一个跨职能的全功能团队，而不是开发部门的研发团队。跨职能全功能团队，通常是包含一个端到端的交付团队，角色包含架构师（通常是Tech Lead）、开发人员、测试人员、设计人员、业务分析师 （代表客户的产品负责人），有些项目会有项目经理和Scrum Master，这两个角色有时候也会参与进来。
这些角色共同构成了一个全功能团队，因为完成交付离不开这些角色的共同协作，敏捷团队就讲传统的职能团队打散组成一个这样的团队，并让他们在一起工作，避免了由职能部门墙造成的各种沟通障碍，提升沟通协作的效率。
如果一些人因为特殊原因经常不能按时到，可以考虑调整一下时间，但也不宜太晚。按理说，在大部分强制打卡的公司中，团队成员不能按时到问题应该不大，ThoughtWorks因为不打卡，这种场景需要适当兼容一下。当然还有一些不能到场的时候，可以适当选择远程接入，再不济就群里文字更新。
走样的站会
站会本身规则很简单，上述几个问题有了答案后，团队可能很快就掌握了开始的技巧（注意我用的是技巧），至少有形了，迈出了从0到1的第一步，很多人怀揣忐忑和新鲜感，在站会上“言不由衷”、“唯唯诺诺”地交流着，总感觉不是那么一回事，因为：
- 每天都像是在跟领导汇报工作，报喜不报忧
- 每个人每天工作都很顺利，但没什么进展
汇报会
团队敏捷第一会也开了有一段时间了，可总感觉哪里有点不对劲，尤其是项目经理在场的时候。大家总是目光朝着经理讲话。“昨天我做了，这个功能花了我6小时，终于搞定了，我只用了3个小时做测试并交给QA了……” 注意到没有，这个更新带上了工作时长，生怕项目经理不知道自己昨天在超时长卖力地工作。开完会，项目经理得知每个人昨天都在全力工作，面带微笑还鼓励大家继续加油。这样的汇报会开了几天了，一天项目经理没到会，感觉有些人就有点儿丢了主心骨似的。
其实这种汇报会有一个好处，就是很少有人犯错，一片和谐，因为大家都没有提供有价值的信息，也没人暴露问题，每次站会完后几乎没有发生什么改变。
注意到团队站会的这种现象，可以给予适当的提醒，引导大家使用三段式模板更新，有必要的话可以询问一下当前的阻碍和风险，提醒大家关注自己手头的任务的进展，是否在预期之中，是否面临风险。
同时跟项目经理也进行沟通，作为Leader，**关注接力棒，而不是运动员”。站会中关注接力棒（用户故事）是否在保持前进，是否顺畅的传递，胜过 关注某个人是否有偷懒，工作是否饱和**，相信团队都是在全力投入为迭代目标努力干活。
一成不变
团队成员在站会中分享工作进度，暴露问题和风险，有帮助就寻求帮助，有好刀就慷慨借出去。如果一次站会下来，大家做出了积极的调整，那站会就算是就发挥了功效了。迭代中每天都发生PDCA环，每日站会是CA的关键活动，得让它为团队带来些变化。
稍微留意一下某些人的更新方式，你会发现有一些有意思的地方。“我昨天在做这个卡，我今天还会继续做这个卡...” 几天都是这句类似的话，很可能这个人卡壳了。他的更新里面连基本的进度信息都丢失了，很可能是卡在某个地方，又不敢说出来，或者感觉自己再努力一把就可以跨过去。遇到这种现象，你就要当心熊出没了。站会完之后主动沟通，看是不是遇到什么阻碍了，要不要寻求帮助，然后给予关注和帮助，让接力棒传递下去。
鼓励成员将问题暴露出来，可能别人也遇到过类似的问题，开完会再交换一下思路可能就搞定了，这样在站会结束后团队就会发生一些积极的改变，问题容易得到解决，任务往前推进，团队的信心也得到了增强。
教练工具箱
作为团队的教练，你不能代替团队去直接解决问题。你要做的是给予团队可用的工具，让团队自己将站会良好的运转起来。站会是一项理论简单但实操有难度的活动。你也不必时刻盯着团队苦口婆心去教导，你要做的更多是在站会中保持观察，提醒团队，帮助团队在站会中免受干扰，过程中重点关注每个人的状态：
- 每个人是否关注迭代的目标，完成高优先级的任务。
- 每个人是否有保持激情、积极投入。
- 每个人是否能够专注不受干扰地干活。
为了让团队能够更有效地自组织，可以做一些事情来帮助更顺畅地前进。
建立规则
仪式感
首先要形成固定的站会节奏，到点开始站会，创造工作仪式感，比如更个人更新完后，一起击掌庆祝站会结束，开始进入战斗状态。关于站会的时间，可以让团队自行来决定，当然你有义务给出必要的建议以及原由。
Token
站会中如果经常发生打断别人、抢话，可以引入一个Token（标志物）充当接力棒，只有拿到这个Token的人发言。那些容易手拿且比较明显的物体都可以作为Token，也可以引入一些能够呱呱叫的玩具鸭子，会带来一些乐趣。我们之前团队甚至用了瑜伽球，说话的人要扛起或者抱起来，所以我们团队的站会充满了欢声笑语。
停车场
在站会更新的时候，引入了Token是为了良好的发言秩序，但不能阻止别人提问，因为有一些问题在现场的确认和回答也很有价值。但要注意不要陷入细节讨论，因为往往这个问题不是团队所有人都需要密切关心的，如果问题能够一两句话得到回答就当场确认，如果需要更多讨论，可以创建一个待讨论主题，放入ParkingLot（停车场）中，让站会继续更新，站会后召集相关成员进行讨论。
战场分割
如果站会中有客户的团队成员参与，将站会分成两小段，在前一段团队成员分享工作进展，会讨论一些技术问题，这些问题对于客户来说可能不是那么友好，客户团队可以根据自己的意愿选择参与进来。后部分跟客户团队更新用户故事的进度，并跟客户协商验收测试的一些工作安排。
由于站会本身时间就很短，不太会耽误大家工作时间，客户团队全程参与也有一些其他的好处，比如知晓开发过程中遇到的困难，看到团队在积极解决问题，加深客户的信任。除非客户提出明确的反馈，分割战场一般不会派上用场。
利用可视化
看板更新
敏捷提倡高效沟通，团队需要借助一些可视化工具让大家高效地信息传递。每日站会的核心内容是更新当前迭代的目标达成情况，迭代的目标会分解到用户故事中，这些用户故事会借助一些卡片来记录，并将他们放在一个看板上：
在团队的共享工作空间中，很多团队会建一个物理看板，将这些卡片的进度状态可视化在上面，站会中每个人都会边讲边动手挪动卡片，凭借这样的一个物理看板，团队可以快速对每个人表达的信息达成一致理解。所以，站会的时候，团队需要一块这样的物理看板，大家看着版更新，时不时动动手，或者帮别人挪挪卡，产生更多协作和更高效的沟通。
数据为王
1960年初，Scrum创始人Jeff是西点军校的一位新兵。他在那里受到美军严格的训练。在西点的最后一年，他被晋升为Training Officer（培训专员），被指派到L2军排。L2又名为Loose Duece，是西点内较差的一排。年复一年，在西点内的各项比赛中，都是末尾或落后，多年未获得任何奖状或嘉奖。Jeff被指派到这一排的，就意味着必须义务培养一排“猪队友“，多年以来，无人能成。为什么呢？因为Training Officer没有直接的权力，也不属于军内的直接汇报线。
他左思右想，觉得他首要做的事情，就是将所有人的表现透明化。让每个人都知道自己的短板，并且诚实的沟通面对，进行改善。起初，所列出来的都是必要的细致动作优化，比如，一位成员的挥手过于松弛，另一位的开步过于绷紧等。当大家都看到自身的不足时，并真诚的接受反馈时，神奇的开始自我修复开始了。一段日子后，连排长都跟着大家一起优化一起调整。就一狠招，全排的表现突飞猛进，L2战队成为西点军校内#1的军排！当美国二战英雄MacArthur将军逝世时，L2战队被任命为MacArthur将军的殡仪小队。
要打造高效的团队，首先大家都必须想改进，然后即可将：
- 状况透明化
- 反复检视实况
- 进行调整与修复
所以，你在站会的看板上，把一些关于迭代目标完成情况的数据直观的呈现透明出来，有时候往往不用多说什么，每个人看到当前的真实状况，看到了被Block的工作和风险项，看到当前迭代还剩余的点数，看到某个人在Doing一列上待了很久没有移动，看到In QA那一列卡片有点多，看到某个人的头像出现在5张卡片上，等等。当这些数据被真实的可视化出来时，团队就不会假装视而不见，很多想法由此激（刺）发（激）出来，而你身为教练，也好像不用难开口怕得罪谁，把最好的方案交给团队自己，你要做的是充分利用可视化透明信息。
寻求突破
鼓励认可
有时候敏捷就是撕掉每个人身上的一块遮羞布，让自己的短处暴露在团队面前，对于一个刚接触敏捷的团队来说，很多人不太适应，难免会有遮遮掩掩，不敢暴露的时候。作为教练，尽量避免操之过急的说教，而是要创造一种安全的环境，当成员尝试暴露问题和风险时，给予更多的鼓励和赞扬，给予实际的关注和帮助，帮助其解决困难，从而帮助人们认识到暴露问题是安全的，也是被鼓励的。
打破常规
当一个团队使用站会一定时间后，并进入到了良好的秩序，大可不必严格按照三段式来更新。此时，团队自身也会发明一些不一样的方式，比如站会上直奔迭代showcase，讨论如何分工协作，有谁来主持showcase，有哪些功能准备演示，谁来准备演示环境和数据。再比如一起为即将到来的版本发布发愁，开发人员询问测试人员是否需要帮忙做回归测试等等。
