《敏 捷 教 练：如何打造优秀的敏捷团队》—5.6 难关

5.6  难关

在实践过程中，可能会碰到以下难关。

会上有人迟到

迟来者到达时，别再重复信息。这对其他人很不尊重，还会传达出“可以迟到”这样的信号。

我们曾合作的一些团队，他们会要求错过每日站会开始的迟到者缴纳罚款。这个团队倒是能派上用场，但是得注意，有些人可能反而很乐意交钱(甚至会觉得迟到的感觉很棒，如果所有罚款都会捐给慈善机构或用作团队晚上活动基金的话)。

如果某个团队成员总迟到，那就找他谈谈。试着理解他有哪些问题。也许他的闹钟坏了，或许他对工作失去了兴趣(参见4.4节)。不管什么原因，他都需要改，以便能参与团队会议。

帮助他意识到自己的行为，因为这是触发改变的根源。他是否意识到迟到很让队友们困扰？解释清楚他的迟到行为对其他人造成的影响。

大型可视化图表
Rachel

我曾和某团队的资深开发人员Vicky一起工作，站会她总是迟到。Vicky并未意识到自己经常迟到，在她印象中自己也就是一个月迟到一两次而已。她的行为开始影响到初级开发人员，形成了连锁反应；如果Vicky可以迟到，那么他们也可以这样。

团队在回顾会议上讨论了这个问题，并提出要在他们的团队板上放一张签名图表；每次有人站会迟到，就得把自己的名字加上去。Vicky并未感觉这有什么不妥，因为她仍不相信自己会那么经常地迟到。这张图表为团队提供了一个反馈机制，能帮助他们意识到自己事实上的迟到频繁程度。等到Vicky把她的名字加了好几次之后，她开始加倍努力力图做到准时到达。其他团队成员也如法炮制，到第二周结束时，办公室所有人都已经可以及时地赶上参加站会。

因此，那张用来度量问题的图表的确帮着克服了这个问题。这就是团队决定可视化跟踪信息进而影响行为的一个实例。

会议时间太长

如果每日站会总是超过15分钟，那就得想方法加快速度。这种情况下，我们推荐坚持使用那几个例行问题，每个团队成员轮流回答，把讨论留到会议结束再进行。

提醒团队，没必要罗列他们昨天做过的每件事，只讲那些和队友相关的事情能纵观全局就行。重点在于今天要做的任务以及需要在截止日期前交付的故事。

如果正与你合作的是一个大团队(超过10个人)，你可以要求他们按用户故事而不是按人头逐个更新状态以便加快站会的速度。虽然这样能让站会变得更容易忍受，但它解决不了根本问题，也即是难以创建大型团队的集体主人翁精神。

在这种规模团队的站会上，你可能会发现，有些团队成员并没有听其他人的发言。在制品的数量太多而导致他们无法关注所有细节。有些故事他们觉得跟自己没关系。当大家开始只关心他们自己的任务时，团队精神就会开始瓦解。针对大型团队，更好的方案是把他们拆分成多个子团队，各自独立地规划工作，召开稍小规模的站会。然后，再通过一个称为 “Scrum of Scrum”的新会议来协调他们之间的工作。

站会遭劫持

每日站会也可能被某人接管，因为他注意到这是一个逮住团队进行其他讨论的好时机。这个人未必是故意要扰乱每日站会，这种事经常发生是因为他们不知道敏捷生命周期是如何运转。要处理这种情况，可以会后再和“劫持者”谈谈，而不是在站会上挑战他们。

有时候，这个人来自于团队之外，他参加每日站会是想让团队帮他干点活，比如是一个支持请求或是为销售会议搭建演示环境。跟他们解释一下，欢迎他们来参加每日站会，但重点是当前计划中的故事。建议他们有什么要求的话先和客户谈谈，以便在下次规划会议时把这些要求考虑进去。

劫持者还可能是一名经理或者团队领导。

每日站会被“绑架”
Rachel

Ray在他的团队中导入敏捷。他搭建了一个团队工作室，团队可以在此召开每日站会，还可以把迭代计划贴在墙上。每天早上他都会带头走到团队工作室，拉来一个人沙发坐下等待团队其他成员的加入。等他们成群结队赶来后，也纷纷拉上一个人沙发，颓然倒下等着Ray开始开会。

Ray把每日站会分成上下两个半场，上半场让他有机会汇集团队进度，下半场专门用来解决问题以及分配当天的工作。每日站会通常要花上半个小时，而这其实是Ray和每个团队成员单独进行的一系列沟通。

这样并没有很好地利用他们的时间，肯定也没有鼓励团队主动担当和自组织。在他们看来，Ray可以趁团队成员们都坐在座位上的时候，一个一个地找大家谈话也可以达到同样的效果。以此方式，至少在他和某人讨论时，其他人可以继续专心干活。

我曾和Ray讨论过每日站会的目的，但他似乎并不认为这样开会有什么问题。所以我尝试再换一个角度，要求他一起去观摩另一个团队的每日站会。这开阔了他的视野，他开始鼓励他的团队互相汇报，并让他们决定自己的任务。

别吃惊，还有比这更糟糕的情况。有个项目群经理，她主持着一种坐式每日站会，她会分发一份表格给团队。团队根本不需要发言，填写那份表格即可。

不要批判一个不知道如何召开每日站会的人。你会发现，解决办法就是学习敏捷如何工作。你是否能安排召开每日站会的人参加一些敏捷培训？尝试带他们去观摩组织中其他团队召开每日站会的情形。你也可以提议由你来召开下次每日站会以作示范。在他们尝试运用所学内容的时候，做一个观察者，会后要继续跟进给予他们反馈。

团队没有做计划中的任务

通常情况下，等团队开工干活之后，用户故事的那些任务就会发生变化，因为他们更加清楚真正需要完成的内容了。鼓励团队为新任务增加放在团队板上，从而更清楚地呈现当前计划。同时也提醒他们移除所有打算不再做的任务。现在就更容易匹配每日站会所说内容和团队板上的任务了。

请注意，如果团队成员正在为另一个项目干活，而不是这个项目中的故事，那就有可能导致他们无法交付目前计划中的故事。如果存在此风险，鼓励团队要向客户提出这个问题。

当团队支持一个正在运行的产品时，为此产品开发新特性的同时，计划外工作也经常出现。这种情况常见于项目早期就参与部署软件的敏捷团队。我们建议与客户一起为支持工作安排预算(以开发人员日计算)，并跟踪支持工作实际所花掉的时间。尝试使用不同颜色的卡片表示支持型任务，这样一来，在它们被予以高于新产品开发的优先级时会非常地显眼。

不想开每日站会

每日站会看似很可怕，因为每个人都毫无遮掩。团队若没有完成任务，站会上就能知道了。如果团队中有人拒绝参加每日站会，要检查一下他们的任务有何进展，以防万一他们被卡住还试图隐瞒。然而，如果整个团队都拒绝参加每日站会，那问题可就棘手多了。可能是因为他们目前正忙着学习如何成为一个团队，或是因为这些会议开得太糟糕。我们建议你在回顾会议上和他们聊聊都有些什么担忧。

不是每个人都能站

每日站会时，出于健康方面的原因团队某个成员可能无法站立，比如有人背部不好或是有人怀孕了。寻找方法满足他们的需求，帮助他们获得融入团队的感觉。如果团队其他人都站着，那就确保这个人也是团队圆圈的一部分，而且没有人站在他们前后。你不会想让这个人待在圆圈的中心或外面的。可以考虑把每日站会改成坐会，这样大家就都一样了，但要注意，坐下来的话，会议时间很可能会变得更长。