《敏 捷 教 练：如何打造优秀的敏捷团队》—7.3 明确工作规模

7.3  明确工作规模

在对工作进行估算之前，团队还需要讨论软件设计的牵连范围。确保团队会花时间探究故事的技术细节。

这部分会议恐怕不值得客户花时间参与。让她知道她可以离开会议，等团队估算完所有用户故事之后，再打电话给她。这样做对团队也有帮助，某人站在一旁等待交谈结束，这会给团队带来压力，会迫使他们草草了事，提早结束讨论。

不只是数字
Rachel

我曾与项目经理Amir共事。有一次在规划会议中，他颇为沮丧地对团队说道：“别扯了！我只是想拿到这些故事的数字而已。”

Amir给团队造成一种错觉，以为规划会议就是完成项目管理的工件。他没有抓住要点，召开规划会议的目的是弄明白要做什么，而这必须得先搞清楚它需要多长时间。团队不可能在讨论清楚需要做的事情前就“给故事弄个数字”，而这种讨论往往会涉及软件设计方面的交流。

会后，我跟Amir分享了我观察到的情况，他很高兴我指出了问题。随后那次会议，设计议程的时候，他就预留出时间来进行技术讨论。尽管如此，团队也需要时间建立自信，才能做到真的把讨论设计思路作为规划会议的一部分。

鼓励团队使用白板，这有助于大家以视觉方式呈现设计思路。不必急着在规划会议上明确设计的所有细枝末节。有些设计决策并不影响估算(或其他故事)，可以留待日后负责此故事的开发人员去决定。

团队厌恶规划
Rachel

我曾遇到过一个团队，他们厌恶规划会议。会议拖拖拉拉地耗掉整个下午，中途也没有休息。团队主管Amy控制了规划会议，她试图在迭代开始前把所有故事的设计都定下来。经验更丰富的开发人员觉得，这种给所有故事创建任务的行为就是微观管理(micro-management)，会使他们在着手构建软件之时设计方面没有可调整的空间。更糟糕的是，她还总是哄团队接受某估值，而这个估值远低于团队最初的提案。

团队在回顾会议上提出了他们对冗长规划会议的担忧。第二天有人带来一个厨房计时器，任何人都可在会议中使用，用来限制谈话不超过10分钟的时间盒(timebox)。如果过了一会儿有人伸手去拿计时器并重新计时，就意味着应该结束交谈，继续前进。

将故事分解为任务

有些故事比较大，要花好几天才能做出来，建议团队把这些故事分解为任务，也即有助于交付用户故事的小块头工作(大概几小时的工作量，不超过一天)。这种做法有时候能挖掘出更多的故事测试以及进一步拆分故事的方法。不过，如果团队对工作已有透彻的理解，再将其分解为任务就没有必要了。

团队把工作拆分成任务还有一个好处。小任务更有利于团队为了同一个故事而共同努力，也便于协调多人同时参与。团队可以把任务贴在团队板上，以便每天都能看见团队的进展。写任务的时候对模板倒也没有什么特别的要求，但字迹要清楚，放在团队板上，站远点也能看得见才行。

指引团队讨论需要完成什么工作时，如果我们并不了解团队的代码库(code base)，就很难将故事内容读给团队听，所以要问他们需要为此做哪些工作。要让团队自己想办法。

如果他们陷入了僵局，试着问一些问题推动他们摆脱困境：

l  我们需要改数据库吗？

l  这个东西我们怎么测？

l  有没有什么编辑文案(editorial copy)或GUI设计资产之类的东西可以向其他团队要？

l  我们还需要做些什么才能满足“完成”的定义？

估算，而非猜测

弄明白需要做什么之后，团队还需要估计这些故事需要多长时间才能完成。他们以协作方式进行，此时尚不决定哪个人做哪个任务。告诉团队只考虑需要完成的工作，估算时不要因为事情可能出错而留有余量。即使某些日子里接二连三地出现意外，也不可能估算出这些干扰。

在会上说清楚，估算可不是凭空瞎猜！如果团队真不知道要完成什么(因为他们不熟悉代码基，或是使用了一些新技术)，建议他们不要急着进入估算环节，而是花点时间探索一下需要完成什么。也有团队在召开规划会议时，上午只是讲解用户故事，下午才进行估算。这可以使开发人员有时间先看看代码，然后再一起讨论需要完成什么。

如果需要进行较长时间的调查，建议团队为此安排一次探针(spike)。探针即一次时间盒形式的调查，目的在于得出用户故事的估算，而不是要产出任何代码。等团队更深入地理解相关工作之后，就可以考虑把故事放入下一个迭代。

得出估值

最简单的方式是，一个一个地讨论用户故事，再就估值达成一致。此办法一般适用于不超过5个人的小团队。大型团队做规划时，你会发现一些团队成员会保持沉默，不参加讨论。这或许是因为他们缺乏自信，也或许他们可以接受任何提案，但不管是哪种情况，团队其他人都无从了解他们的想法。使用计划扑克，可以让所有人都参与讨论(参见后文补充内容“计划扑克”)。

完成用户故事估算后，在故事卡上标出估值并平摊在桌上。矩阵式排列故事卡，估值相同的故事卡各成一列，并按照估值从低到高的顺序横向摆开，让团队可以一目了然地看见所有故事卡。正如图7.1所示。[1]这有助于团队维持估值的一致性。迈克·科恩(Mike Cohn)称之为“三角测量法”：“以此方法进行估算，无须把故事拿去跟某个基线标准或通用参考值一一进行比对。相应地，是拿用户故事跟某类已估值的故事进行比对。”要了解估算及制定敏捷计划的相关信息，可参见他的《敏捷估计与规划》[2][Coh06]，这是很棒的参考资料。