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

7.6  难关

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

客户不知道自己要什么

如果客户参加会议时并未做好准备，可得多花点时间才能把用户故事搞定，从而结束第一部分会议。可以找几个人，在开会前把这些故事先大致梳理一遍，能有些帮助。如果能从团队里找个人来参加最好，这样一来，就能从技术角度检验故事是否可行，单个迭代能否完工交付。

团队被迫过度承诺

有时候，团队会被迫承诺更多工作，比实际能交付的更多。客户产品上市日期不可改变时就容易这样，会带给团队极大的压力。速率显示了团队的完成能力，如果发现团队即将给出的承诺远超过速率，一定要警示他们无法交付所有故事的潜在风险很大。

如果团队一定要这样做，就确保他们把故事拆分得更细，即使他们交不出设想中的高档全功能版，至少也能够每个功能领域多少交付一些东西。[1]

昨日天气
Lasse Koskela，Reaktor Innovations公司

我曾跟一家创业公司合作过，公司不大，舆论对它评价很不错，很多人说它会成为下一个MySpace。客户就是公司创始人自己，他花了好几个月，利用有限的时间构建了他们的第一版在线服务。他的意志极其坚定，满怀激情地看着公司不断发展壮大。

他们又花了几个月的时间组建起一个团队，开始基于全球市场需求重新构建该服务，由于现行的原生态方法已显疲态，于是他们决定采用Scrum方式。

第二个迭代开始时，他们刚刚在第一个迭代交付了总值25点的特性，团队谈论着说要相信“昨日天气”。但客户却很看好团队的潜能，还设法让团队承接了35点。他们承诺了35点，实际交付24点。

迭代规划会议时，客户又发表了一番鼓舞人心的讲话，指出团队才“刚开始”而且团队一直都在学习在进步。团队承诺了35点，实际交付25点。第4个迭代还是老样子。他们还是承诺了35点，因为客户“知道他们能做到”，但同样的，实际交付的少多了。

此刻，客户终于接受了我和另一名教练一直试图解释的，团队生产力是无法靠一厢情愿(wishful thinking[2])和“更努力些”来提高的。更糟糕的是，过量压力还会导致生产力骤降。

计划在迭代进行中发生变化

要留意团队板上的任务，如果每次都是迭代开始没几天任务就变化很厉害，原因很可能就是规划会议开得过于匆忙。我们曾见过一些团队，规划、任务罗列和估算都做完了，却并未真正想明白需要做什么。等真正开始干活的时候，板上的任务很显然无法反映出需要完成的工作。

随着团队对问题的理解不断深入，必然会创建一些新增任务，但要密切注视任务变化很大的情况，因为这可能意味着团队在规划时并未把握住需要完成的内容。鼓励团队下次规划时多花点时间用来仔细检查任务，还要鼓励他们在计划里也安排一些探针进去。

会议中冲突不断，气氛很紧张

执导规划会议很有挑战性。应该如何完成设计，开发人员对这件事的看法往往是不一样的。在改变或拆分故事时，客户可能并未意识到这一点。

在会议第一部分讨论故事时，紧张感可能和如何切分故事或哪个故事最重要有关。鼓励团队向客户讲出心中的想法和担忧。明确告诉客户他们需要认真听。最终选入计划的故事应该是一个共同的决定。

会议第二部分也可能变得很紧张，因为团队需要商定如何构建软件交付故事。适量冲突兴许还有助于测试和改进想法，冲突太多就很令人讨厌，也很缺乏效率了。如果可选提案有好几个，看起来又都挺好的(或都挺差的)，就要提醒团队从实施难易程度角度去判别这些方案。团队也许想多试几个方案，这能帮他们加深对问题的理解。很快就能够知道是哪个方案更好，还是说混合两种想法的方案最好。尽管编码实现两种方案挺浪费资源的，但这往往也是学习的最快方法，可能从中得到更好的方案。

团队速率下降

新团队往往要花好几个迭代才能够稳定他们的速率，这很正常，不过即使速率稳定下来，团队也应该继续跟踪记录。随着项目不断向前进，软件支持更多用户故事，团队速率通常会有所下降。同时，由于对敏捷的信心越来越强，团队也会变得更为乐观。帮助团队留意任何放缓的迹象，并尝试找出问题根源，虽然这可能要花上好几个迭代才能查明原因。与此同时，应根据新度量的速率制定计划，而不是继续沿用原来的速率并期待着奇迹发生。

规划毫无意义

有时候你会发现，坚持召开规划会议已无意义，例如，有些团队成员不在办公室，休假了，或是参加培训，又或是有很多缺陷需要修复。缺陷修复很难估算，因为大部分工作都是追踪问题发生原因的探查型工作。

此时，不必再浪费时间召开规划会议，在团队板上给工作任务建立优先级排序列表即可。团队可以自选工作方式，召开每日站会时排定当日工作优先级。就这样先干点小活儿，等团队回来之后或缺陷清理完毕了再说。

如果这种情况时常出现，可以考虑转而选择看板开发方式，它并不依靠迭代时间盒来限制在制品[3]。