敏捷教练第五章

第五章站会

你已经参加了很多次站会，现在你会惊奇地发现有一个完整的关于站会章节。看起来是很容易执行。所有你需要做的就是在每天的同一时间把团队召集到一起站成一个团，让他们回答三个简单的问题：

l  我昨天做了什么

l  今天我要做什么

l  我遇到了哪些困难

这三个问题是一个好的开始，但是这不是团队仅仅需要的。作为一个教练，你要带着团队超越这个形式，帮助他们定制满足他们需求的会议。你希望团队接纳站会作为自己的会议；他们自己决定谁将做什么事情，这个鼓励他们自管理。一旦团队学会了如何召开站会，敏捷教练可以去休息一下了。

你会发现站会揭示了团队成员如何在一起更好工作。小心站会成为一个肤浅的给管理者的状态报告，团队中的人没有真正的听其他人说的。注意，如果会议拖延，是否真的是因为讨论过多细节，而浪费了团队的时间，或者他持续了半个小时或以上。当很快、很高效、自我管理时，团队正在正确的轨道上。另外一个好的信号是，甚至当你不在周围时，团队也能召开站会

在站会上，有1种好的方法能让信息分享平衡。让我们看一下，你能做什么，帮助团队更好的开始站会。

Rachel Says. . .

Follow Your Own Advice

通过遵循自己的建议，建立你的角色模型。在站会上，确保你按时准备好会议。当会议开始后，站直而不是靠在凳子或者墙。如果你不严肃地参加会议，为什么其他人要这样呢？

为你期望团队去做的行为做行为的榜样是很重要的引导技术。使用你希望从团队身上看到的行为，这个会让他们受到感染。

5.1 Standing Up

首先，团队可能对于站着开会而不是坐在会议室里面开会，感觉到不舒服，特别是他们在一个更传统的组织里面工作。人们可以感觉到自己站到了被别人看到的地方，这个看起来很古怪，甚至是异常的。确保团队了解站会的好的原因：人们站立时，会议会花费更少的时间。这个很有可能会赢得他们的称赞，更多的人希望花费更少的时间在会议上。

当团队在团队自己的空间围着白板一起开会时，站会的效果比较好。团队需要足够的空间站成一个圈，这样他们就能看见自己和白板。鼓励他们移动家具来使得站会有更好的空间。如果在他们的工作场地没有足够的空间，就在附近找空间。当会议室很缺乏的时候，要去创造会议室。我曾经和一个这样的团队一起工作过，他们在宽敞的楼梯走廊开站会。

如果团队不得不在远离工作空间的地方召开晨会，这个是有坏作用的，因为不得不浪费时间往返于哪里。这也可能是个问题，因为他们需要在白板前讨论认为。有些团队通过占据一个会议室来在墙上放他们的白板和图来解决这个问题，这个会议室就是scrum会议室

我不是特别支持这种方法，因为他们不能在一天中的其他时间看到这些任务，他们的白板不再成为一个信息指示。他们最好再建立一个手提式的白板，这样可以在站会时使用，然后可以带回到团队工位。在第八章将会讨论如果帮助他们这么做。

5.2 For the Team by the Team

让团队都了解站会是帮助他们共同来做他们的工作，这个是非常重要的。不是为开发负责人或者团队领导搜集团队的进展或者获取工作反馈来召开这个会议。鼓励团队直接把答案给其他团队成员

要保证会议时以工作计划为中心的。如果一个成员刚度假回来，现在不是时间来讨论他的旅行。团队不需要提到其他工程中的工作，除非经常妨碍他完成他们的工作。如果发生了这种情况，一定要礼貌，提醒团队站会的目的，并且很快地回到会议中来。

Nudge conversation along.

当站会对于团队来说很新鲜时，你可以轻轻推动会��的进行。如果一个人犹豫了，迅速地推动他们回答三个问题中的一个。当人们结对的时候，只让结对中的一个去总结他们所做的，是很好的。一旦这个团队习惯了站会，你会发现他们很自然的按着三个问题的模式向前，而且还包含一些其他问题。团队在白板前，会增加一些新的问题。

Standup Chekov

by Rachel

我和一个XP团队一起工作，他们在白板上贴了一个检查单，来提醒我们站会中包含的内容。我们给这个检查单叫做Standup Chekov。在白板上我们贴一个信号带着这个Chekov，这个提醒我们要检查这些问题。

你会注意到，我们已经不是三个问题的格式。我们有其他的需要覆盖的条目，大部分是和顾客支持相关的。举个例子，我们都要轮流去确保一些开发人员已经被指派揭露的，这个意味着需要中断顾客的课题。同时，我们要跟踪每个故事的时间分配，这样就能提升我们的估计。但是最关键的问题是，使用这个会议作为愿意一起结对编程的一种形式。

我们的团队后来增加了一些检查项来提醒他们关于一些其他事情，例如故事完成。

Establishing a Team Focus（建立团队焦点）

小心：如果你总是在晨会上问问题。你可能发现，团队成员直接回答你的问题，好像这个团队是为了你的利益所召开的，而不是为了他们。尽量避免这些事情，通过不要看他们的眼睛，向团队中的圆圈看。

如果你发现团队成员继续把会议看成是向你报告，出来和他们说：“你能向整个团队来报告吗？站会是让你们所有人去找出你们今天需要做什么，不是让我去做”。你可以试着根本不去参加站会，让团队自己去开会。

避免在一个人让团队知道他已经完成后，就给赞扬，例如说：太好了！或者甚至是谢谢。这个会加重这个概念：站会是来取悦你的，而不是让他们同步团队行动的。当你就给了一句赞扬使，可能导致接受者很疑惑。你的意思是他们做了一个好工作吗？他工作的哪个方面太好了呢？你会让团队疑惑为什么有些人得到赞扬而其他人没有得到。

Team Controls the Flow（团队控制速度）

鼓励团队去控制站会。为了让这个更明确，使用一个讲话的标志，从一个人传递到另外一个人。这个标志可以是任何物体（例如球或者钢笔），当有人要说话的时候，就让这个人拿着。每个团队成员在讲话的时候拿着这个物体，并且决定下一个给谁。没有单独的控制点。这个帮助会议一直在进行，拿着标记的人会更加意识到团队成员在等待。

如果有些人不能参加这个会议，而是电话参加会议，那电话听筒可以当做标志。它使得另一端的人可以听到，要让会议中的人记住是和团队说话而不是和电话。团队可以在他们习惯站会流程后，决定停止使用谈话标志

下面是一个典型的轮换站会的例子

Tuesday Morning

Damian开始了站会。“好，我现在拿着球了。昨天，我忙于处理新的数据。我拿了这个任务，但是我注意到只能进行一半，没有把书里所有的简介都拿进来。所以今天，我在取其他任务之前，我会再找出问题在哪里。我这里没有其他阻碍，接球！”他边说着边把球给Larry，球是他们讲话的标志。

Larry，今天看起来有点困倦，惊奇地跳起来，正好抓住了球，“我昨天在组织测试数据。我通过抽取数据，建立了XML文件，我昨天检查了SVN数据。现在，我想开始测试书的旋转，现在准备好了吗？”他把球给了Rebecca

Rebecca接住了球，好的，Rebecca有点犹豫“还没有完全完成，但是如果你愿意帮我看一下，那很快就会好了” Larry说：“好的，今天上午就看，你准备好了，我就开始测试脚本。”

Rebecca继续她的更新“昨天，我做了旋转木马。现在，进行得很好，但是我还没有做浏览器的测试。我期望Larry能找到一些问题。我可能会今天大部分时间会做这个。我也没有遇到困难，joe呢？”Rebecca把标志伸了出去。

Joe拿到了标志，“我今天早上来得很早，完成了ISBN搜索，现在准备进行测试。我今天不会开始新的任务，因为Amanda今天上午要我去和Singapore的团队进行电话会议”

Raj说：那今天没有问题需要我去跟踪了吗？

Joe说：”不好意思让你失望了”,团队解散了，开始干活了。

你会注意到，故事中的团队谈论了任务的进度而不是给出了他们昨天做了什么的详尽的说明。当然，他们也没有尽力去解决已经发生的每一个问题。如果Joe已经有了Damian提出问题的解决办法，他们可以在会后再一起讨论

仅仅是实际参与白板上的任务的，才可以回答问题、RAJ是开发负责人，他来这里是跟踪已经提出来的问题，而不是开发计划中的任务。Amanda是PO，被看做是团队的顾客。她不能参加站会，所以她不得不晚一点通过问在这里的人情况来跟踪进展。

Who Takes Part（谁参加）

整个团队来参加晨会，开发人员、测试人员、设计人员、顾客、敏捷教练等等。我们看到敏捷团队告诉顾客（或者其他投资者）他们必须要安静，因为他们是：鸡。别沮丧，这个可能会导致失礼和造成人心混乱。团队需要和投资者之间建立关系，而不是毁掉关系。

站会的重点是现在计划中的工作，顾客在这里也起了作用，因为她让团队了解他正在像团队中其他人一样从事这个工作。站会可能是最理想的时间告诉团队即将来临的工作，例如在会议结束会更新会覆盖。

小心站会不能让整个团队跟上进度，如果你在站会中打断了一个讨论，因为不是和每一个人都相关，要记住在站会后和小团队一起再讨论这个问题。

Two-Part Daily Standup

by Rachel

我工作的一个团队，决定开两部分的站会。第一部分是开发团队的进度，他们做了什么、遇到什么问题。这个对于顾客团队听起来是相当没有意思的，因为会议充满了技术术语。我们不排斥顾客团队，他们可以看到会议开始了因为我们站起来了，也欢迎他们加入。第二部分，开发团队会叫顾客团队过来，让他们知道谁将开发用户故事、并且安排后面的会议来讨论故事测试的细节

 

这个解决方法很奏效。现在团队可以开他们认为有必要的会议，而不会浪费顾客的时间。

5.3 Handling Issues（处理问题）

当团队中的一个人提到他遇到了一个阻碍问题，最好的解决办法是在站会后讨论如何解决这个问题。知道每个人都讲完了，团队才进行全部的构思，而且并不是每一个问题都需要解决。试着分开会议和展会，在讨论如何解决问题的时候，让团队成员先来说明进展。快速的澄清问题是ok的，但是一旦他们理解了问题，就要鼓励他们立刻继续站会。

如果问题没有被跟踪，询问是什么阻碍了问题的进展是没有意义的。避免说在每次的会议议程中或者有人提问题的时候，说“我们会后讨论吧”，因为这个是不明确的。不要在笔记本上胡乱写，而是需要把后续跟踪的每一项写在白板上，为每一个人的问题建立一个停车场。在会议结束，重新回到停车场，按照优先级排序问题，得出后面的问题需要谁去继续跟踪。任何在站会上发现的问题，如果已经解决，就可以被擦掉。没有必要一直留在那里，即使是外部的干扰，团队可能决定去跟踪浪费的时间。

Liz Says. . . Forget the Formula

Scrum是有严格的要求，在站会上，谁来讲话、应该说什么。重点要及时开始。

进行站会的规则帮助团队如何开始。规则是没有魔力的。这些规则可能不能总是对团队有用，固执地坚持规则可能会让站会感到：“是按照数字来做的”，使得自组织感觉到窒息。

我的建议是，不要让团队失去了目的。我非常高兴听到有生气的讨论和看见每一个人都参与，而不是看到敏捷规则被死气沉沉的执行。

 

站会不是其他会议的代替。如果提出了一个问题，需要和整个团队长期间讨论，建议团队安排一个会议去处理这个问题，而不是在站会会添加这个会议。

除此之外，对于团队提出的问题，你可以检查是否有问题是依赖团队外的人实现。一些典型的例子是软件接口、编辑拷贝、设计共享、数据库变化等等。

5.4 Setting the Time（设置时间）

大多数的团队喜欢在工作的开始开站会，在开始工作之前，去讨论谁来完成工作。然而，在很多公司，人们没有在同一时间到公司，所以他们需要找到一个满足所有人的会议时间。

Make it a team decision.

作为一个教练，你不应该去挑选会议时间。相反，让团队去选择什么时候他们想召开站会。这个不会使得这个决定更容易，但是可以让团队对时间许诺，促进团队养成解决自己问他的习惯

有时，让整个团队每天都来开站会是一个挑战。举个例子，有些人可能在家里工作、或者在其他会议、或者没有在项目中是全职的。当团队是分布式的情况下，站会在不同的办公室和市区，甚至是更大的挑战。记住不管你尽力在试着做到什么-好的交流和每一个人都要了解他们需要做什么。鼓励团队使用不同的方法去尝试直到他们找到一个好的折中的办法。

远程会议或者改变站会时间可能会有作用，有些人可能不能参加会议然后使用其他方法更新进度。可能有的团队成员通过会议终端和远程的团队成员进行面对面的站会。对于不同的时区，会议甚至可能会在一天的结束。

Night People vs. Morning People by Rachel

我一起工作过的一个公司，工作时间非常灵活，雇员都非常活跃。一些团队成员直到午饭才来公司上班，然后工作到深夜。其他一些人来的很早，在下午就完成工作。团队选择下午时间召开站会，这个帮助他们同步站会。

负面影响是，上午来的人在不知道其他人工作到哪里的情况下，不得不开始就先开始工作，一直到午饭后的站会后才能了解其他人工作进展。在不同时区的团队有同样的问题，经常要在早上和下午都开站会。我建议团队这样做。现在早上的人可以在晚上工作的人到来之前，同步彼此的工作。

5.5 When to Coach (什么时候开始引导)

如果你没有指导会议，保持会议按时召开，那么你在哪里增加作为敏捷教练的价值呢？我们的观点时敏捷教练是团队的良心。举个例子，如果团队迷失了，你可以温柔地提醒团队他们应该计划做什么。这有个真正的艺术，你不需要过来唠唠叨叨的，所以尽量不要先发制人，你不应该总是这样一个人，总是说：不要忘记这个，或者不要忘记那个。等待他们真的变化了，然后看他们实际做的和他们计划的有什么不同。问题他们是否真的是个问题，如果是，他们将如何打算处理这个问题

团队成员花费时间实现用户故事，他们经常没有注意到时间是怎么快速过去的。你可以提醒团队在下一次demo或者发布之前，还有多少天，让他们检查反应他们正在工作的白板。

不仅仅是需要你去提醒他们过去的时间。他们还在不断地循环。他们在每个周期内，需要花费时间，需要和其他顾客在下一次计划前，去准备用户故事。他们需要跟踪回顾会议中的问题，然后在下一个阶段中解决这些问题。

有时团队没有提出问题，因为他们已经习惯自己这样去做、或者这种思考方法、作为一个教练，要保持爱打听的心思，要寻找提升的机会。站会经常会展示某些需要引导支持的部分。通过仔细听团队在说什么和没有说什么、注意他们古怪的身体语言，来读懂团队。

l  每个人都在参与吗？都很积极嘛？都很兴奋吗？

l  他们记录了过程，从事了高优先级的任务吗？

l  他们一起工作了吗？互相帮助了吗？

l  他们能够很专心地、没有干扰地工作吗？

除非你非常关心团队没有遵循现在的计划，那么就在会后跟踪这些问题，或者推迟到下个回顾会议去讨论

5.6 Hurdles（阻碍）

下面是你可能遇到的阻碍

People Arriving Late for the Meeting（有人迟到）

如果有人来晚了，不要重复信息。这个对其他人是失礼的，这也是默许了来晚了是OK的。

我和这样一个团队一起工作过，如果错过了站会的开始，他们让来晚的人交罚金。这个可能对团队是有效的，但是要意识到有些人是愿意付钱的（如果把钱给慈善机构或者团队晚餐，甚至感觉到迟到是很好的）

如果团队成员持续迟到，因为这个可以导致变化。他意识到来晚了影响其他团队成员了吗？把他来晚的这个影响解释给其他人

Big Visible Chart

by Rachel

我工作的一个团队，有一个高级开发人员Vicky，站会他经常迟到，Vicky没有意识到她迟到到底有多么频繁，在她的意识中，她一个月就迟到了一到两次。她的行为对初级的开发人员有了影响，如果对于Vicky迟到是ok的，那么他们也可以迟到。

团队在回顾会议上讨论这个问题，提议在白板上跟踪一个明显的图。每次有人站会迟到，就在名单上加名字。Vicky对这个没有感到不舒服，因为她仍然认为她不是迟到很频繁。这个图对团队提供了反馈机制，帮助他们意识到他们实际迟到有多频繁。在Vicky的名字上榜很多次以后，她开始为及时到岗做努力了。团队成员也在这样，下两周，每个人都准时到达参加站会了。

所以，这个图上描述的问题实际是帮助他们解决了问题。这个一个团队如何让跟踪信息更可视化影响行为的例子

Meeting Takes Too Long（会议花的时间太长）

如果会议经常花费超过15分钟，找个方法把时间降下来、在这种情况下，我们推荐坚持问规则中要求的问题，让每一个成员轮流回答，直到结束后，才进行讨论

提醒团队，没有必要吧昨天做的每一件事情都列出来。仅仅说和团队成员有关的事情。要关注和今天要做的任务相关的，后面的日子要交付故事、将要发生什么事情。

如果你和一个大的团队一起工作（超过10人），你可以通过问每一个用户故事更新程度、而不是每一个人来减少站会的时间。尽管这个会让站会更难以忍受，它没有解决潜在的问题：很难在大团队中建立共享权限的共识。

在这种情况在的站会，你可能会注意到一些团队成员没有听其他人员说话。过程中大量的工作让团队成员不能跟踪所有的细节。一些故事看起来是和他们不相关的。当人们开始仅仅关系他们自己的任务时，团队开始瓦解了。

一个更好的解决方法是，大的团队拆分成小的团队，分别计划他们的工作，有更小的站会。然后团队通过scrum of scrums.会来协调他们的工作。

Daily Standup Is Hijacked（站会被劫持）

站会可能会被其他人占领，当他发现这个一个好的时间让团队进行其他讨论。这个人并不是有目的的干扰站会。这个经常会发生，因为他们不了解敏捷生命循环式如何运作的。在会后和黑客讨论，来处理这个问题，而不是在会上直接挑战他们。

有时，这个人是团队外部的，他们来团队是因为他想团队帮助他进行一些工作，例如需求支持或者为销售会议建立demo。向他解释，非常欢迎他们来站会，但是站会重点在计划中的用户故事。建议他们和顾客讨论他们的需求，他们可以在下次计划会议中来考虑。

另外的黑客可能是管理者或者是团队领导。

Daily Standup Takeover

Ray的团队开始使用敏捷。他建立了一个团队的工作房间，在这里团队可以召开站会、在墙上跟踪每个Sprint的进展。每个早上，他走进房间，拿起一个坐垫，然后等其他人加入。当其他人进入时，也是拿起一个坐垫，坐下来等待Ray开始过程。

Ray把站会分出两个部分。第一个部分是他自己来搜集团队的进度，第二部分是解决问题和分配今天的工作。站会一般会花一个小时，但是这个真的是Ray和他团队间的一些会谈。

这不是好的时间的利用，这个最终没有鼓励团队拥有自主权和自管理。从他们的观点来看，Ray本可以通过到他们的座位上去问每个人的进展来获得同样的效果。至少是那种方法，在他和别人交流是，他们自己可以继续一些工作。

我和Ray交流站会的目的，但是他没有意识到他召开站会的方法有问题。所以我用了另外一个角度：我让他去观察其他团队召开站会。这个使他的眼界宽阔了，增加了他鼓励他的团队向每一个人报告并且决定任务的的可能性。

 

你可能很惊奇，但是有可能比前面的故事更糟糕。另一个坐着开的站会，是由一个编程的管理者制定一个电子表格给他的团队。团队填写表格，不是和其他人交流

不要批评那些不会开站会的人。你会发现纠正方法依赖于教他们如何运作敏捷会议。你能安排一个在开站会的人来给他们做培训吗？试着带他们去看组织中其他团队如何来开敏捷会议的。你可以建议他们下次按着这个例子去开下次的会议。当他们试着运用他们学习到的去做时，你要作为一个观察者，在展会后，然后通过给他们反馈来跟踪问题。

 

The Team Isn’t Working on the Planned Tasks（团队没有按照计划工作）

经常当团队开始工作时，对于一个用户故事的任务改变了，因为他们已经了解到实际需要做更多的事情。鼓励团队去在墙上增加卡片来代表新的任务，这样就更清晰现在的计划时申明。也提醒他们移除哪些他们不打算再去做的任务。现在很容易来匹配站会上所说的和团队白板上的任务。

要不住，如果团队成员进行非工程故事中的其他工程，这个可能导致他们不能交付现在计划中的认为。如果有风险，鼓励他们去引起顾客的注意

当支持一个在线产品时或者开发产品的新特征时，经常会出现计划外的工作。对于进行早期产品开发的敏捷团队，这个情况非常普通。我们建议顾客建立一个支持预算，跟踪花费了多少时间。试着在墙上，对支持任务使用了不同颜色的卡片，以便于如果他们的优先级高于产品开发，这样就显示的更明显。

Daily Standup Isn’t Wanted（不需要站会）

站会看起来很可怕因为每个人都被暴露出来了。当团队成员没有完成任务，在站会上看起来就很明显了。如果团队中的一个人反对参加站会，仅仅当他们遇到阻塞问题、试探隐藏的时候，检查任务中的进展是多少。

然而，如果整个团队反对站会，你现在要处理一个严肃的问题。很有可能是他们作为一个团队很努力的在工作，而这个会议运行得很糟糕。我们建议你在回顾会议上讨论他们关心的事情。

Not Everyone Can Stand（不是每一个人都一定要站着）

你可以让身体不好的团队成员在站会中不要站着，例如这个人后被不舒服或者怀孕了。找一个满足他们需求的方法，帮助他们感觉到和团队是一个整体。如果团队其他的人站着，然后确保这个人是团队中的一部分，不要让他站着团队前面或者后面。你不需要让这个人站在圈的结尾或者圈的外面。考虑把站会当成是一个坐下的会议，这样所有的人都在同一水平，但是要意识到，如果你们都坐下，很有可能会议会开得很长。

 

5.7 Checklist

l  找到一个可以让团队在白板前开站会的地方。如果你们的工作空间没有地方，那么使用一个手提团队白板。

l  确定团队开站会的时间。如果每一个人不在同一时间工作，你可以一天开超过一次的站会，

l  鼓励团队保持他们的回答很短、很愉悦。三个问题的模式帮助团队开始站会，但是不能让这个成为站会一直的情况

l  保持团队一直在进行：要使用一个讲话标记来控制团队

l  让顾客跟踪站会，给出进展和更新

l  收集问题，放在白板上每个人都能看见的地方。和团队一起确定优先级，后面再继续跟踪。

l  在回顾会议上回顾站会的效果，试验开站会的新的模式