敏捷在软件开发行业已经是一个耳熟能详的概念，从之前个别企业的独领风骚，到现在在软件行业的遍地开花，敏捷以其高效、高质量以及丰厚的投资回报率来不断吸引管理者在其管理模式上的改变。目前，各个软件公司都在或多或少的进行着一些敏捷实践。StandUp作为Scrum敏捷实践中的一个主要活动，它是否在进行着最佳实践，会影响到团队是否会有可观的产出，这是一个量变到质变的过程。下面就来谈谈我对StandUp的理解。
Daily scrum meeting也称为daily stand up meeting, 即每日站会，简称站会。《Scrum权威指南》中给出的范例是：
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
- 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？
我们都知道，Scrum是易于理解但难于精通的，StandUp也是如此，虽然这三个经典问题都很简单，但是是否能从这三个问题中来了解到团队的进度、健康状态、成员之间沟通是否流畅，不同的实践可能会有不同的效果。
我们可能或多或少都有这这样的经历，项目团队组建初期，每个团队都会为达成项目目标约定一些敏捷活动，刚开始每日站会循规蹈矩，团队成员每日更新这经典的三个问题，但慢慢的就会暴露出这样那样的问题：开始有成员迟到；经常会加入技术细节的讨论；某个成员发言时会发生插队甚至直接进行问题的讨论；严重超时；每个人只关心自己做的事情，“汇报”完成后认为自己在站会中的职责就已经完成了，不再关心其他人在说什么。慢慢的，每日站会发展为流于形式，更有甚者，团队成员开始质疑站会的意义，最终不了了之，团队回归到一种“无状态”模式。这种团队状态，从各个角度讲都是十分危险的，我认为其中的根本原因是，团队并未了解清楚站会的真正意义，只是在做一些流于形式的日常，导致目标的偏移，使站会的效果未达到我们的预期。如何进行一个有效的StandUp，我觉得应从以下几个方面去考量：
- 意义首先应让每个团队成员了解到站会的意义是什么：开发团队由每日站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每天开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。会议专注于达成 Sprint 目标的进展，是团队整体的目标进展，而非个人，以主人翁的心态进行项目进程，项目目标，人人有责！
- 纪律既然是团队活动，我想应该有基本的规则约束：每日定时定点，迟到不被允许；TimeBox：每日15分钟；Token制：可以随意拿一个物体作为Token，比如白板笔，持有Token的人才被允许发言，可以有效组织插队和讨论；
- 改进小步迭代、持续改进是敏捷的一大特点，小小的StandUp也是如此，作为Scrum Master和团队成员应经常回顾总结每日站会的效能，识别出哪些是积极有效的实践，哪些是低效无意义的鸡肋，从而总结出一套适合于自己团队的最佳实践，而不只是流于形式，正所谓“不管黑猫白猫，抓住老鼠都是好猫”！
以上就是我对StandUp的一些理解，欢迎大家拍砖指正！
