Stand up meeting作为敏捷项目开发中的一个重要实践不可或缺。站立会议每天都要发生，在会议上大家可以了解到每个人的工作进展、项目遇到的concern和issue，从而做出适应的资源调整和措施，保证项目交付的顺利进行。如何让站会变得高效，本人总结了一些tips，希望对大家有用。
站会的形式
一般站会分为两个形式。一种是在站会上每人轮流进行各自的状态更新，另一种是以story wall上的user story为主进行更新。 第一种好处是每人都有更新机会，但是更新的内容稍显混乱，第二种好处是通过卡片追踪能更清晰的了解到当前的状态，不好的地方是如果有人的工作任务没体现在卡片上，可能就没机会得到更新。
我个人比较倾向于第二种更新方式。一个典型的story wall有这些列: BACKLOG->BA->DEV->TEST->UAT->DONE。站会开始的时候，由一个facilitator按照从DONE->UAT->TEST->DEV->BA的顺序依次念出这些故事卡，被点到的故事卡则由工作在这张卡上的人进行相应的更新。之所以采用倒序是出于精益的思想。我 们敏捷的迭代式开发就是要将story card尽量的往done column里挪，采用倒序过卡的方式就是要突出这一点。当将墙上所有的卡都过完后，facilitator可以再问下有没有其他人有update，这样可以防止有些人由于工作不能体现在卡片上而漏掉更新。比如迭代经理可以此时做出自己的更新。最后facilitator再问还有什么问题或风险没，此时可以把自己的一些想法表露给团队,好借团队之力拿出应对方案。
个人的更新
个人的更新注重言简意赅，突出重点。一般更新需要包括下面三点。
昨天做了什么。这个只需2句话带过，切忌陷入细节。
有没有遇到问题，需不需要资源或帮助。如果遇到什么困难，可以大概描述下，并指出需要什么样的帮助。
今天打算做什么。
一些tips
站会一定要站着开。凡是坐着的会议都短不了。
one conversation. 站会上的时候一定要保证同一时刻只有一个人说话，切忌变成了群体讨论。做法可以是将一个小玩具作为token，只有拿着这个token的人才可以说话。
限制每个人更新的时间。有些人在更新自己工作状态的时候喜欢讲的很细节，无形中浪费了很多时间。这时候facilitator就需要适时的打断他，可以告诉他只要给出大概的内容进行，细节部分可以会后再讨论。
团队中成员轮流当facilitator。一般团队中喜欢固定一个人当facilitator，一当就当到了项目结束。其实更好的做法是每天站会时都要更换facilitator，这样保证每个人都能充分参与到团队中。
站会不能迟到，也不要定在刚上班时。刚踩着点进办公室就迎来站会略显紧张，很多人还没调整好状态。 一般可以将站会定为早上上班15分钟后。
凡是可能花时间的讨论都不要发生在站会上。站会只是专注状态更新，暴露问题，而不是解决问题。针对会上暴露的问题可以再组织相关的人商讨解决方案。
切忌将站会流于形式，失去原有的意义。站会注重的是team间横向的沟通，并且每天都会发生，如果不能坚持就说明了团队间配合出现了问题，失去了快速反馈的意义。
