《敏 捷 教 练：如何打造优秀的敏捷团队》—5.2 始于团队，服务于团队

5.2  始于团队，服务于团队

务必让团队了解，每日站会是他们用来同步他们的工作内容的。它不是项目经理或团队领导用来收集团队进展情况，或对他们的工作给出反馈的。鼓励团队成员面对其他团队成员进行交谈。

让谈话聚焦于计划中的工作，即使有人刚刚度假归来，现在也不适合讨论他们的旅行。团队并不需要提到为其他项目而完成的工作，除非它极大地束缚了他们完成工作的能力。礼貌一点，但是如果真的出现了这种情况，提醒团队每日站会的目的，让会议继续进行。

如果团队上不太习惯每日站会，可以推一把促成交谈。要是有人略显迟疑，就任选三个问题之一提示他们。团队结对工作时，其中任何一个人总结他们做了什么即可。等团队习惯每日站会之后，你将发现他们会自然而然地打破三个问题的固定格式，并增加更多问题。团队可以为这些新问题增加提醒，放在团队板上。

契柯夫站立
Rachel

我在一个极限编程(XP)团队待过，我们在团队板上贴了一个检查表，用在站立会议时提醒我们要讨论哪些内容。我们把这个列表称为“契柯夫站立”，还把《星际迷航》中帕夫·契柯夫的照片贴在我们的团队板上，用以提醒我们检查那些契柯夫问题。

你会发现，我们已经越过了三个问题的标准格式。有了一些我们想涵盖的其他问题，多数跟客户支持相关。例如，我们以轮岗方式，确保每天都有开发人员担任“暴露者”，应对销售和客户支持相关问题的打扰。当时，我们还在试验跟踪记录每个故事所花费的时间，可以帮我们改进估算。但我们借助站立会议解答的最关键问题是谁将和谁一起结对编程。

后来我们团队增加了一些其他的“契柯夫”，提醒他们注意其他事项，例如把一个故事项做完。

契柯夫站立[1]

我们昨天做了什么

有无新增卡片？

销售会议？

今天曝光谁？

标记已花费时间

挑选卡片和同伴

建立团队焦点

密切关注——如果你总是在每日站会上问问题，你会发现团队成员转而向你答话，好像会议是单为你开的，而非他们自己。想方设法扭转形势，避免与他们目光对视，要环顾整个团队。

如果发现团队成员持续把站立会议看作是向你汇报，要直截了当地说：“可否请你面向整个团队答话？每日站会是你们所有人一起确定今天要做什么，不是为我。”也可以尝试根本不参加每日站会，让团队自己开。

避免给出表扬，比如，有人跟团队讲过他们完成的内容，可别接着说“太棒了！”甚至“谢谢你！”这会加深他们的印象，认为每日站会是为了博你高兴，而非同步团队的活动情况。当你用单个词汇进行表扬时，听众会感到困惑。你的意思是他们工作做得好？是哪方面做得好呢？你还会让团队疑惑，为什么一些人得到表扬，而其他人没有。

团队掌控流动

鼓励团队自己掌控每日站会。为了明确这一点，可以引入发言令牌机制，从一个人传递给下一个人。令牌可以是任何物件(比如一个球或记号笔)，如果人们有话要说时得拿着它才能发言。发言时团队成员要拿着令牌，还要决定接下来传给谁。没有某个单独的控制点，有助于保持会议流畅，拿着令牌的人更清楚团队其他人在等待。

如果有人无法出席每日站会，只能通过电话参加会议，那么手机话筒就是个很好的发言令牌。电话那一端的人可以听见，又能让大家专注于跟团队说话，而不是对着手机。当他们习惯了每日站会流动方式之后，团队也可能决定不再使用发言令牌。

下面是一轮典型谈话的样例，你很可能在某次每日站会上听到过。

星期二上午

Damian开始每日站会。“好的，那就从我开始吧。昨天，我在处理新的数据源。已经签入，但是我发现它似乎会停在中途，并没有导入所有的书籍说明。所以，今天我会先努力弄清楚发生了什么问题，然后再领取其他任务。没有其他障碍。接住！”他说完就把团队用作发言令牌的网球投给Larry。

Larry今天看上去昏昏欲睡，他被吓得跳起来了，勉强接住了球。“嗯，我一直在建测试数据。通过对数据源进行采样，我已经创建了一些XML文件，昨天晚上已经签入SVN。今天，我想开始测试图书轮转，不知道它做好了没？”他说完把球传给了Rebecca。

Rebecca接到令牌。“嗯。”她犹豫了一下，“没有完全结束，不过如果你能瞟一眼我已经做完的部分，那也不错。”“好的。”Larry补充到，“那我们今天上午就做这个了。等你快准备好的时候，我就开始写推荐引擎的测试脚本。”

Rebecca继续讲：“所以昨天……我在做轮转。进展相当顺利，但我还没做任何的浏览器测试，我想Larry肯定会发现一些问题。我很可能大部分时间都得做这个活。没有遇到什么障碍。接下来，Joe？”Rebecca边问边递出令牌。

Joe拿过令牌：“今天来得早，上午就已经完成了ISBN搜索，也可以测试。我先不拿新任务，因为Amanda要我去参加今天上午与新加坡团队的电话会议。”

“好吧，那就没啥问题需要我跟进啦？”Raj问到。“让你失望真是太抱歉了，Raj！”Joe咧嘴一笑。团队结束会议，马上开工。

注意，在这个故事中团队讨论的是任务的进度，而不是他们昨天都做了哪些琐碎的事务。此外，他们也没有试图解决遇到的所有问题。如果Joe有更好的方法可以解决Damian遇到的问题，他们可以会后再讨论。

只由真正在做团队板上贴着任务的人来回答这些问题。Raj是项目经理；他在那里是为了跟进遇到的任何问题，而不是为了按计划执行任务。Amanda是产品经理，扮演着团队客户这一角色；她无法参加每日站会，所以她得晚些时候再找参加站会的人了解目前的进度。

哪些人参加?

整个团队都要参加每日站会：开发人员、测试人员、设计师、客户和敏捷教练等。我们已经见过一些敏捷团队告诫客户(以及其他干系人)必须保持沉默，因为他们是“鸡”。要阻止这种行为，这样做很失礼，还会引起不必要的烦恼。团队需要在他们和干系人之间建立起沟通的桥梁，而不是毁它们。

每日站会关注的是当前计划中的工作；这事客户同样有份，就像团队里其他人一样，她也能用相同方式让团队了解她正在做的事情。向团队传递未来工作的信息，每日站会也是一个非常理想的时间选择；这类信息更新可以在会议结束后再做。

每日站会时，要密切关注那些并非整个团队都在参与的讨论。在每日站会期间，如果由于讨论并非和所有人相关而叫停某个讨论，要提醒他们在每日站会后再小范围继续讨论。

每日站会两部曲
Rachel

我曾经工作过的一个团队，他们决定把站会分成两部分。第一部分是开发团队进度汇总：谁在做什么，有没有碰到问题。由于讨论的都是各种技术术语，对客户团队来说，听起来相当枯燥。这可不是排斥客户团队；他们看得到会议什么时候开始，我们都站着呢，并且很欢迎他们的加入。第二部分时，开发团队会邀请客户团队加入，让他们知道谁会继续做用户故事，并安排一些后续会议继续讨论故事测试的细节。

团队的这个解决方案很有效。现在团队已经可以拥有开始他们一天工作所需的所有讨论，又不浪费客户的时间。