《敏 捷 教 练：如何打造优秀的敏捷团队》—7.4 审查并承诺

7.4  审查并承诺

接下来是规划会议的第二部分，选择团队切实可交付的故事，并相应地安排迭代时间表。这部分往往是最难的，因为此时通常得做出一些取舍。

检查团队产能

完成所有估算后，团队还需要知道自己的产能，然后根据可完成的用户故事数量，相应地制定计划。运行几个迭代之后，团队就会有一些平均速率的数据，可以看到他们平均一个迭代所能交付的量。

如果团队刚刚起步，并无任何速率数据，那就掐指一算(back-of-the-envelope calculation)吧，往往也是足够精确的。例如，假设某团队有3名开发人员、1名测试人员和1名项目经理(负责文档相关任务)。他们的迭代周期为两周。他们发现，在每个迭代，他们要花两天开会，还有几天做支持，如此算来，每个迭代他们大概有30天可以用来干活。接着，他们想起有一个开发人员说过要休几天假，因此又把数字调成28天。

提醒团队注意，要避免队内专家负担过重的情况。Ajax的活儿排得满满当当，能干活的却只有一个，这样是毫无意义的。如果学习瓶颈是团队一直都存在的问题，就鼓励他们在计划中安排一些学习型任务，以丰富团队的技能。

计划扑克

计划扑克[Gre]实践最初是James Grenning提出的。玩计划扑克时，团队里每人一手牌，用来给出故事。每手牌包含如下一系列的数字用于估算，例如0、1、2、3、5、8、13和21，再附加一张牌表示故事太大，牌面可以用感叹号(！)或者99这种大数字。

大声读出故事之后，依情况采取以下行动。

l  所有团队成员从手中选择一张牌代表自己的估值，面朝下放在桌上。这样做是为了避免估值受到其他人的影响。

l  所有人都出牌后，再摊开牌面比较。

l  如果数字全都一样，就在用户故事上标出该估值。

l  但如果大家给出不同的点数，团队就得讨论他们对工作难易程度看法不同的原因，然后再重新投票。

l  如果有人拿不定主意，就可以出问号( ？)牌。

使用计划扑克方式可以保证所有参会者的参与，也能够避免有人喊出首个估值后，团队其他人全往上靠。虽然计划扑克有助于加快会议进程，但要点并不在此。如果估值的分歧较大，那么可以预见，团队必然要先讨论一番之后才能商定某个数字。这种讨论通常都很有帮助，人们对故事和故事构建工作的各种假设和想法都会在讨论中显现出来。

请注意，计划扑克也仅仅只是估算故事的其中一种方式而已。团队不恰当使用此方法的情况我们见过很多，他们会在规划下一迭代的时候，用这个方法估算那些小个头、已有充分理解的故事。你会发现，这个方法最适用于如下情况：要为几个月后的发布制定前瞻性计划，而客户则需要在彻底理清用户故事前先大概了解故事规模。

按迭代摆放

按照开发团队计划着手干活的顺序摆放这些故事卡。摆在最前面的是优先级最高的，除非有一些卡片牵扯到了风险、依赖性或最终期限，遇到这些情况还要跟客户解释清楚。可以从下图看出，根据团队后续几个月的目标发布对卡片进行组织的概览图[1]。

如果客户在估算环节时已经离开，那么现在就该把她再邀请回来。跟她讲解故事的所有相关变化，例如把它们拆分成了更小的故事或是新的故事测试。现在客户可以看得到故事卡上的估值，她兴许要重排优先级。要有心理准备还得再挪动一番，然后才能最终确定计划包含哪些故事，不包含哪些故事。

向前看

在理想情况下，每个迭代结束时团队都会提供一个最新发布给用户。但是，有时候他们也有充分理由不那么频繁地发布，或者不总是向所有用户发布。

在团队试图填满一个长达数周或数月计划中的迭代时，要提醒他们注意，未来可能还会冒出新的故事。鼓励他们给自己留一些余地，不必安排得太紧凑。要做到这一点，最简单的办法是干脆空一个迭代出来。可以把它预留给新的用户故事，也可以用作应对已计划故事开发延迟时的缓冲。

通常来说，基于用户故事做计划不要超过3个月。超过的话，可以基于故事主题(theme)来制定路线图。

如果团队只不过是做一些小改动来支持已上线系统而非开发一款产品，把团队聚起来创建较长期的计划恐怕意义不大。不过，可以考虑采用看板(参见下页补充内容)，它能使团队专注于改善工作流。

看板——Karl Scotlan，EMC咨询

软件开发中的看板系统专注于实现工作的可视化，呈现价值流中的不同转化阶段，并限制每一点的在制品数量。团队因而可以发现系统中存在的瓶颈和约束，并借此持续改善系统，提高生产力，改善绩效。

专注于流动后，任务估算已不再必需，任务拆分也变成一种分析和设计的活动。排优先级、规划和发布还是会定期发生，在每种活动之间形成一种自然节奏。团队不再对时间盒内的交付进行估算，而是根据已知的周期时间(cycle-time)和产出能力(throughput)对交付做出预测。

团队做出了一次处理最多不超过3个特性的限制，这样就能全神贯注地加速流动去完成那些特性，至于新的特性，则可以等到他们有多余产能时再投时间进去。如此便可以做到“即时”触发新工作的优先级排序、分析和规划，而不是在迭代规划会议时安排。优先级是基于团队过去的特***付能力以及未来的业务目标和目的，经过权衡之后得出的。

看板在日语中是“可视化卡片”的意思，它是丰田生产方式中使用到的一种工具。软件开发的看板系统往往会使用索引卡作为限制在制品的标志物(token)，一个标志物代表一个价值单元，例如一个用户故事。看板系统也因而可以管理客户价值单片流，从想法(idea)直到发布(release)，贯穿整个开发系统。

华为云会议 Meeting 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。