在最近过去的几年中，我在许多不同的每日站会中担任过参与者和协助者的角色。众所周知，每日站会的真正价值在于团队有能力不断地为当前的sprint周期的“承诺”而努力。每日站会并不是状态汇报，现在团队成员经常很容易陷入提供状态相关信息的这样一种模式。近期虽然我正在使用一种最老的每日站会的方法，但我认为一个成熟的团队可以从不同的程度来花费15分钟做这些事情，与此同时他也继续在进化使用敏捷/Scrum。
我很幸运的是和一个由10位成员组成的团队一起工作过，团队在一起工作至今已经近10年了。在加入我们之前，一些团队承认已经在其他组织中有过敏捷/Scrum的经验，有些成员对于它则是完全不熟悉的。经验告诉我们，至少百分之99.99的情况下，我们在15分钟的框架内完成我们的每日站会比较好。我们团队有百分之九十是可控制的，而且我们不断地相互鼓励将敏捷/Scrum提升到更高的程度上来。在过去的几个月中，我们在我们的每日站会中使用了不同的方法，目的在于在个人和团队成长的同时，为我们的日常行动建立一个积极向上的氛围。虽然我们沿途而笑，但是我们关注什么才是真正重要的：彼此。不管你的团队是集中的还是分散的，有时随意地尝试这些方法，质疑你的团队去创造自己的抉择。你可能对结果感到意外。
加快Scrum的速度
运用传统的方法（例如，三个问题，“我昨天做了什么？”，“今天做什么？”，“我是否有任何阻碍？”），这样的scrum是用来质疑每个团队成员是否尽快的完成他或她的任务。通过这个方法，我们可以在8分钟内完成每日站会。所表达的内容极其精简，团队成员必须仔细倾听来跟上会议。
你是否觉得有这样的情形，每个人不能在限定的时间内完成要说的内容？在这样的情况下，尝试一下“击鼓传花”的方式。在每日站会中带入一样物件；第一位表述者拿着它。一旦那位表述者已经说了他或她的内容后，他或她将物件传给另一位团队成员。这样直观地使讨论从一个人传递到另一个人那。注意：团队成员不能直接将东西传给站在直接旁边的人。物品是使团队移动，不仅是语言上的，同样也是肢体上的。
时间限制的Scrum
这和我们上面讨论到的加快Scrum的速度有些类似，但是有一些细小的转变：每个团队成员都有指定的时间来完成这3个传统的问题。带几个秒表到每日站会，并且将他们发给团队成员。这是一个很好的相互鼓励的方法，同时也是注重着每日站会的价值。
挑战Scrum
在这个环节中，团队允许问每位表述者一个具有挑战意义的问题。这些问题在本质上必须是有建设性的，而且它们必须是基于团队成员所做的任务或者用户故事的。质疑scrum是狡猾的做法，但它帮助人们活跃地参与到每日站会中去，并且我发现在sprint周期中尤其成功，它非常依赖于其他团队或者说拥有极高的复杂度。
例如，这项工作在特定的sprint中需要和其他团队来合作（例如数据整合，数据流转，或者数据库模型变化），我们可以使用质疑Scrum来帮助验证这个方法。表述者用同样的传统的伞个问题，但必须强调出他或她的回答。下面是个例子：
表述者 #1 “通过这个方法，昨天我为我们的第一个用户故事完成了数据整合的搭建【对这个方法给予一个快速的概述】。今天，我会完成这个用户故事中的第二，第三项任务。”
疑义 “做的好。我想知道你是否有考虑到这和你原先的方法有一些细小的偏差？【对改变做一个快速的概述】。这个细小的改变是否可以带来帮助？”
通过这样的方式来制造“挑战”，团队成员为了达到一个积极的结果而随意地相互提问。经常有很多次一个团队成员可以学到新东西来改变其方法本身。
重做是不是一个最终的结果？这当然是一个很有潜力的结果。可是事情往往不是这样，团队成员至少可以使用原先的部分方法。
至今我还没看到每个人的更改都被质疑。事实上，在运用这个方法是重要的一点是只有一个人可以在每日站会上提出质疑。如果还有其他的想法，那么我们会将这些团队成员在每日站会完成后直接诶聚集在一起来提出。
只有阻碍的Scrum
以我的经验来看，这部分总是常常被忽略。可能发现在板上的用户故事和任务没有阻碍。不幸的是，真正的“根本”阻碍通常只有在sprint回顾会议上才被提出，这在周期内已经为时过晚。一个只有阻碍的每日站会真地可以帮助识别那些主要的任务和用户故事，哪些可以由其它团队可以通过团队成员和扫除阻碍的方法来协助完成。
奖励Scrum
这对于每个人都是一个极大的鼓舞，奖励scrum是为了确认谁在每日站会中最清楚的表达了他或她的信息而设定的。一旦每日站会结束，每个团队成员投票表决谁给出了最佳信息。奖励可以基于这些准则，例如信息的速度，数量，准确度和及时性为准则。每个参加每日站会的人都可以投票。团队成员不可以投自己的票，并且只可以为一个人投票。你事先决定所用的准则及奖品。我发现甚至是最内向的人在这样的讨论会中也觉得是场友谊赛。而且你会发现，一旦被授予奖励，胜利者将会和整组人分享奖品。有趣而且鼓舞人心！
商业价值向导的Scrum
依赖于你的组织，任务和用户故事可能会使技术长进的很快。出于善意地来关注商业价值，团队成员总是埋头钻研于技术层面来使系统或应用程序工作。帮助你的团队成员将他们钻研于技术的清晰想法带到另一个层面，仅是关注这个用户故事和任务所提供的商业价值。例如，“昨天我完成了这个用户故事/任务，他让用户去做ABC，今天我会完成这个用户故事/任务，他可以让用户去做XYZ。”通过这个方法，我们可以看到开发团队成员将他们的每日站会又带到一个新的高层面上。
没有看板的Scrum
像许多其他组织一样，我们有实物的sprint看板，也有电子版的。我总是发现团队成员只是和没有生命力的对象交谈，而不是和周围的人来交谈。如果这是你团队中的一个问题，那么从每日站会中拿掉sprint看板。不用担心；人们记得他们昨天做了什么，并且他们今天要做什么。你会发现，取而代之的是他们站得更直了些，并且相互交谈，而不只是看着白板或者显示器了。简单方便，并且能周而复始地产生极好的作用。
白板Scrum
这跟上面提到的没有看板的Scrum有些相似，但有一些不同：给你团队成员一支白板笔，（通过图片，文字和组合的形式）来画出他们昨天完成了什么，他们今天会完成什么，以及障碍在哪里。鼓励每个人，因为一些人会犹豫，因为他们并不是”艺术家“。这不是什么问题。许多人是视觉学习者，并且许多每日站会没有视觉上的指示，只有写在sprint看板上的任务。善用图片，看着你的团队走向成功。
与Scrum携手并进
每个人都真的擅长于提供他或她在做什么的信息。我们都紧紧地融入于我们的任务活动之中，因为我们都努力完成承诺。如果你发现自己需要改变些什么，尝试与scrum携手并进。基于一窝蜂的原则，每个团队在每日站会中向另一位团队成员提供信息。这是确保跨团队合作的一种很好的方法。我通常喜欢保证团队成员提供信息在他或她的正常范围外也有用。（例如，一位用户界面开发为质量保证人员提供更新，反之亦然）。
为此，2位团队成员在每日站会前必须商讨以至被表达的信息尽可能的准确。这使团队成员在每日站会开始前团队成员就要相互沟通。例如，我想表述你现在正在做的任务/用户故事的信息，而你将表述我的信息。这个理想的目的是因为基于任何一个角色或专门技能的水平，让人们走出他们的舒适地带（例如开发或者质量保证）。
是否可以克服以及适应它，在于我们团队的核心。众所周知，每日站会是我们敏捷/Scrum流程的重要组成部分。sprint周期一般来说是9天，
我们的团队成员在不断地发现新的方式来互相质疑以及质疑自己。我们仍然使用行之有效的每日站会的方式，但我们发现利用上面所提及的一些方法会增添极大的成功。我们完成工作……但我们同样发现，在一天开始时的一些笑声可以创建一个优秀的工作氛围。
作者:Eric King
原文地址http://www.scrumalliance.org/articles/417-maximizing-the-value-of-your-standup-
