敏捷教练第七章

第七章计划

没有人喜欢长时间的会议，但是深入的讨论对于做一个真实的计划是很需要的。所以，如何帮助团队在计划会议上保持好这个平衡呢？

鼓励团队去做不同颗粒的计划。他们很可能既需要很粗的计划（看起来是未来的几个月），又需要下个迭代更细致的计划

做计划就像是在做你最喜欢的蔬菜拼盘

准备：和团队一起、特别是客户，得到准备开会的用户故事。把故事尽可能切成片，使得你不要丢掉受益点

一次油炸一个：一次只讨论一个。如果团队讨论如何开发一个故事，然后他们走偏了开始讨论这个故事和其他故事比较多重要，他们就会饶圈圈。

继续进行：让会议继续进行，让他们重新回到会议上，组织他们陷入困境

控制温度：团队可能在压力下承诺去做更多的本Sprint需要完成的工作。帮助他们得出设计细节，这样他们就会使用过去交付的数据来进行真实的估计

这个秘方来源于准备

7.1 Preparing for Planning（为计划做准备）

鼓励团队和顾客一起工作，得到为了计划而完成的用户故事。我们不建议整个团队进行预计划会议，这个有一些团队成员参加就可以了。

现在指导团队按照下面的基本步骤去做计划：

Understand priorities:（理解优先级）

顾客希望在下一个迭代要发表的故事是用户故事的会议的开始

Size the work:（为工作定大小）

当故事被理解了，帮助团队计算出交付这些故事需要做些什么

Agree on the plan（同意计划）

将要真实地交付哪些内容，对这个达成共识，会议就圆满结束

团队对于需要做什么有一个很好的理解，这样就能将会议的这些步骤减少至少一个小时，然而一个新的团队开发一个复杂的问题很可能会需要更多的时间。当你看到团队有很多工作要做，建议每个步骤分成一个单独的会议。

提前和团队一起为计划会议建立一个日程。如果团队中的每一个人了解要发生什么、什么时候发生，他们就已经准备好了。一个日程在会议中是很好用的，当会议离题了，你可以通过使用日程表来提醒团队重新回到会议上。

7.2 Understanding Priorities（理解优先级）

推荐客户召开会议，说明下个迭代或者发布的目标。她要展示用户故事，并且说明如何支持实现目标。让他在桌子上按照优先级的顺序把卡片排序。让顾客了解你已经知道所有的用户故事都是重要的，但是也要了解在下个迭代很有可能不能全部完成

鼓励团队其他成员去问问题，寻找吧用户故事分解的机会。当故事很小又有明确的故事测试时，很容易估计和更有可能被交付。然而，如果分解得太小，故事从生意的角度来看可能就可能缺少了功能性。

现在鼓励团队去review下一个迭代可能交付的故事的测试。一个简单的做这个事情的方法是让每一个团队成员拿起一个故事，大声地读测试。你想要整个团队了解这些测试，使得他们在估计故作的时候可以考虑清楚。

Rachel Says. . .

No Projector

在进行用户故事讨论时，如果你可以不需要使用的话，不要使用放映机。没有比这件事情更令人沮丧了，每个人都坐在会议室中，盯着屏幕等着一个人打字。看起来你节省了时间，因为在会后不再需要打字，但是这是一个错误的节约，因为浪费了团队的时间。

相反，和顾客一起工作时，要保证他们已经准备好了，已经带着故事索引卡去了会议室。

你可以在会议结束后，再更新电子记录

我没有说从来不能用投影仪，如果你在会议上需要看已经存在的用户接口和设计，这个时候就必须要使用了。

7.3 Sizing the Work（估计工作）

在可以估计工作之前，团队需要讨论软件设计实现。确保团队花费了一些时间去讨论每个故事的技术细节。

Suggest the customer steps out.

会议的这个部分肯能没有好好利用顾客的时间。让她了解离开会议更合适，当团队估计完所有用户故事时，你们会再叫她回来。这个也能帮助团队，因为一个人一直等着会议结束可能会给他们压力让他们过早地完成讨论、

Not Just Numbersby Rachel

我和一个PO Amir,一起工作，他在计划会议上和团队说“来吧，我就想要故事对应的数字！”

Amir给了团队错误的感觉，计划就是给PO创造数字。他遗漏了关键点，计划是找出要做什么，这个必须在得出需要花费多长时间之前就要得出来。团队不能仅仅“在故事上加一些数字”，而不开会讨论他们需要做什么，经常的这个团队包含了软件的设计。

在会后我和Amir交流了我看到的问题，他很高兴，我指出这些问题。下次，他确保会议议程中有一些技术讨论。然而，在团队信任计划会议的一部分是可以真的讨论设计思想的问题上，也花费了一些时间。

鼓励团队使用白板去帮助他们可视化设计思想，没有必要在计划中想好每一个细节。不影响估计的设计决定（或者不影响其他故事的工作）可以留到开发人员进行那个故事的时候再考虑。

Team Hates Planning

by Rachel

我和一个不喜欢计划会议的团队一起工作。团队持续了整个下午，一直没有修改。计划被开发负责人所控制，他尽力在迭代开始之前确定所有故事的设计。建立每一个故事的任务，好像对更有经验的开发人员进行管理，因为这让他们感觉到留给他们构建软件的选择是非常少了。甚至更坏的是，她经常劝诱团队去同意比他们初始建议更低的估计。

团队在回顾会议上提出长时间的计划会议不好。第二天，一些人带来了厨房定时器，可以使用这个时间盒，让任何讨论延长10分钟，。过了一会儿，如果有人超过了时间，设置定时器运行，这个就作为一个完成讨论、继续进行的信号

Rachel Says. . .

Keep Design Discussion Alive

我遇到一个团队，他们形成了这样一种印象，如果是敏捷团队，仅仅敏捷会议（计划、站会、演示、回顾）他们应该召开。这个是不对的。鼓励团队在需要的时候，开会去讨论软件设计，而不是在计划会议上去硬塞这些讨论。

Decomposing into Tasks（分解任务）

对于大的故事，可能会花费两天以上去构建。建议团队把工作分解成任务，小片的工作更容易交付用户故事（几个小时就做完或者超过一天）。有时会找到更多的测试和方法去把故事拆分得更小。然而，如果团队已经对工作有了很清晰的理解，拆分成任务就不必要了。

把故事拆分成任务对于团队还有其他的好处。小的任务更容易共享工作和协调工作，因此几个人可以一起完成这个工作。团队可以在白板上贴上这些认为，这样他们每天就能看他们有多少进展了。他们不需要特别的写任务的模板，但是他们应该保证在远处能能看的见。

当我们不知道团队的编码时，看起来引导团队去讨论他们需要完成什么的时候，是很复杂的。把故事读给团队，然后问他们会发生什么。等待团队自己想出新的想法。

如果他们遇到困难，通过问下面的问题来推动他们思考：

l  数据库需要变化吗？

l  怎样进行测试？

l  需要其他团队帮忙吗？例如编辑拷贝或者CUI设计？

l  满足最后的“done”，需要做其他事情吗？

Liz Says. . .

Don’t Play the Secretary

不要在会议室显示所有写的东西。我们很可能被诱惑去做这些，因为这个是你能做的支持团队的工作。但是这个有可能让其他人不再关注会议，然后让你感觉这个会是为了你的利益，而不是团队的利益。鼓励团队中的每一个人来参与吧。

Estimating, Not Guessing（估计，不是猜）

一旦团队得出了需要做什么，他们需要估计要花费多长时间完成这个故事。他们合作得出这个结果，而不是做决定谁完成这个工作和任务。让团队去考虑工作的完成，而不是在估计中增加允许出错的时间。即使有些天看起来他们不断地被打扰，也是不可能估计出被打扰的时间的。

要清楚在会议上，估计不是做疯狂的猜测。如果团队真的对于需要完成什么没有概念（因为他们不知道代码或者使用的新技术），建议他们不要直接进去估计，而是花时间去找到需要完成什么。有些团队这样进行计划，用户故事在上午准备、估计在下午完成。这个使得开发人员在一起讨论需要完成哪些之前，有一些时间去看代码

Spike to get a better

estimate.

如果需要长时间的调查，建议他们定义一个截止时间。一个截止时间是一个时间盒的调查，有1个得出用户故事估计而不是产生代码的目标。一旦团队对所完成的工作有更好的理解，他们可以考虑在下个迭代重新估计故事。

Arriving at an Estimate（到达估计）

最简单的方法是去讨论每个故事，然后得到估计。这个经常在不到五个人的团队起作用。当大的团队进行计划时，你会注意到一些团队成员保持安静，不加入讨论。这个可能是因为他们缺少自信，或者他们可能他们喜欢附和别人提议的。不管是哪种情况，团队其他人不能听到他们的观点。你可以通过使用估计纸牌，把每一个人都引入到讨论中。

当每一个故事都估计了，估计值被写在卡片上，被放在桌子上。通过把类似估计的放同一列来创建一个故事卡矩阵，并且从低到高进行排列，使得团队可以看到这些。在图7.1中的下一页可以看到。这个帮助团队保持他们估计的一致性。Mike Cohn 称之为triangulation：当估计时，你不能用所有的故事和基线或者一般的进行比较，相反，你要使用每一个新的故事和原来那些已经估计的同一类的进行比较，来进行估计。Agile Estimating and Planning是一个很好的关于估计和做敏捷计划的书

7.4 Review and Commit（回顾和承诺）

计划会议的下一步就是把故事分成组，然后按照迭代的进度进行交付。这个经常是最难的部分，因为经常要进行一些平衡

Checking Team Capacity（检查团队的能力）

一旦所有的估计完成了，团队需要了解他们的能力，这样他们就能计划一个可以交付的用户故事的数量、在进行了一些迭代以后，团队有一个平均速度，这些可以表明他们每个迭代可能交付多少个故事。

如果团队刚启程，还没有速率的数据，一个粗略的计算经常被使用。举个例子。假设团队有三个开发人员，一个测试人员，一个PO(他投入到文档的任务中)。他们机会以两周作为一个迭代。他们计算出，他们每个迭代要花费2天来开会，另外几天做项目支持，所以他们粗略地估计，他们每个迭代有大约30天。然后他们还记得，一个开发人员有两天假期，所以他们调整这个数字为28天。

提醒团队，小心不要任务过重。如果仅有1个人可以做Ajax工作，他们不应该填满计划。如果团队一直有知识瓶颈问题，估计他们在计划中安排学习的任务，去扩展团队的技能。

Planning Poker（计划扑克）

James Grenning发明了计划扑克。打牌时，团队中的每一个人需要使用一手牌进行估计、每手牌包含了一些有点数的数字用来估计，例如0，1，2，3，5，8，13，21这些数字用来估计。21代表故事太大了，或者使用更大的数字99来代替大故事的值。

当故事被大声朗读出来时：

l  每个团队成员，从手中选出一张牌，背面朝下放在桌子上，这样来做估计。背面朝下做估计不会影响其他人

l  当每个人都选好牌后，把牌翻过来，然后比较

l  如果数字都是相同的，那么这个估计值就被写在用户故事上

l  如果成员有不同的点，团队讨论为什么他们认为这个工作是困难的或者容易的，然后他们再次投票

l  如果有人没有想法，他们可以用？打牌

打扑克牌抱着让会议中的每一个人都参与进来，帮助团队不要固定在第一个人提出的估计点上。尽管扑克牌可以帮助加速会议，但是这个不是关键。当团队同意一个数字前，估计有分歧是，要希望他们多讨论一会儿。讨论时很有用的，因为他引起了假设和思考这个故事是什么和如果构建。

要记住，估计扑克只是一种估计故事的方法。我们经常遇到团队会用估计值太小、很好理解的故事作为下个迭代的故事。你会发现这个故事对于为后几个月的发布做计划更有用，因为顾客需要在所有用户故事全部开发完之前，通过知道初始故事的大小得到最早的反馈。

Laying Out Iterations（得出迭代）

按照开发计划的顺序把故事卡片放在桌面上。除非有风险、依赖或者和其他卡片有一起的交付时间，把最高优先级的放在前面，这些问题需要解释给顾客。你可以看下面的图，是如何组织故事的

如果顾客在估计阶段就离开了，那现在是时间要求他回来了。告诉她故事变化的一起情况，例如把故事拆分成更小的故事或者有了新的测试。现在故事看到所有的估计值都写在卡片上了，她需要重新再排一下优先级。期望很小的移动故事，哪些需要及时完成、哪些又不在计划里面

Liz Says. . .

Be Realistic

不管团队和顾客希望交付多少故事，做一个过渡不现实的计划很有可能是以失望而结束。这是很重要的，团队要有1个持续的步伐、组织中要有1个真实的期望。鼓励团队去做完和上次能够完成的数量相同的机会-除非他们已经知道环境有所不同。

如果团队感觉到很乐观，那么建立一个“支持板”，如果他们完成得早，那么就做这些故事

Looking Further Ahead（提前看的长远些）

理想情况下，团队应该在每次迭代结束都能提交给用户一次发布，但是他们可能有更好的原因不去发布或者不是总是向所有使用者交付。

当计划中充满了迭代，横跨几周或者几个月的时候，提醒团队新的故事有可能会出现。鼓励他们预留一些空间，而不是把计划塞得更紧。更容易的方法去做这个是有1个迭代没有故事。这是给新的用户故事预留一些空间，这是也是如果开发故事花的时间太多了，可以有1个缓冲。

一般情况下，这样通常是没有什么感觉的，做一个超过三个月的计划。超过三个月后，要基于故事使用一个路标题。

如果团队只需要进行一些小的变化来支持发布的应用，而不是需要开发一个产品，让团队一起来做一个长期的机会，可能是没有意义的。相反，你可以更好地使用看板（下一页有说明），这个可以让团队能够更好地提高工作连贯性。

Kanban by Karl Scotland, EMC Consulting

软件开发的看板系统帮助我们的工作可视化，当工作通过各个流程时，把工作限制在每一个点上。这个帮助团队发现系统中瓶颈和限制，例如他们可以持续地努力去提高系统、提高生产率和效率。

关注流动的任务，估计是不需要的，记录拆分的任务的分析和设计活动。优先级、计划、发布仍然是经常发生，在每个活动上形成了一个很自然的节奏。团队不用再估计他们在一个时间盒内需要交付什么，而是广播在已知的循环周期内他们需要交付多少。

7.5 Keeping Track（保持跟踪）

会议后，团队可能很渴望去开始新的故事。在他们解散前，有人需要在白板上布置故事和任务。建议团队提名一个人去跟踪，一些团队在团队中轮换这个角色。

Tracking should focus on team deliverables.

我们注意到，使用跟踪工具会减少管理成本。不需要在计划电子池中记录所有的任务，可以在白板上进行跟踪。提醒团队出资者会会完成的所有用户故事感兴趣，而不是任务，因为任务是不可交付的

在软件中中的发布计划也是很重要的，因为需要和出资人共同讨论。团队可以简单地在电子数据表中列出用户故事和估计、什么时间交付故事。团队需要确保所有不同类型的计划需要保持同步。

鼓励团队记录下计划完成的故事的估计点。在迭代技术，可以比较故历史数据（速率）和实际完成故事的速率。这个团队经常计算的，帮助团队看到他们的估计的完成率。举个例子，如果全部的故事点数计划时50，在迭代结束，总共是 40点，那么这个团队的完成率就是80%

7.6 Hurdles（障碍）

下面是你可能遇到的一些障碍

Customer Doesn’t Know What They Want（顾客不知道他们在做什么）

如果顾客还没有准备好开会，那么会议的第一部分可能会花很多时间来得出用户故事。和一小部分人一起召开一个与计划会议，是很有用的，可以在会议前得出一个大概的故事。如果会议包含至少一个团队成员，这个成员可以从技术角度给一些输入，去验证故事是可行的，在一个迭代中交付也不会太大，这个会议会开得更好。

The Team Is Asked to Overcommit（团队被要求承诺太多）

有时，团队可能被要求承诺要完成比真正可以交付更多的工作。当顾客有很紧急的交付时，这个就经常要发生，那样团队就会有很多的压力。如果你看到团队正要承诺完成远远超过他可以完成的速率的工作，警告他们这是有风险的，可能不能做到所有的故事都被交付。

如果团队坚持这样做，确保他们把故事拆分得非常好，这样每一部分的功能他们都能交付，即使交付的不是是一个完整的版本。

Yesterday’s Weather

by Lasse Koskela, Reaktor Innovations

我曾经和一个需要很少时间就要发布的团队一起工作。为了成为下一个MySpace如此等等，他们进行了很多讨论。顾客是公司的创始人，他们在几个月内构建了在线服务的第一个版本。他非常热切和坚信公司可以变得更大。

和团队一起过了几个月的没有规律的开发，他们开始建造世界市场服务，他们决定使用Scrum，他们现在使用的方法已经表明是有缺点的。需要更多的纪律和可视性。

在第一个迭代他们交付了25个点，他们开始了第二个迭代，团队在讨论真实的“昨日天气”，然而顾客对于团队的潜能非常乐观，想让团队去完成35个点。他们承诺了35，但是交付了24

再一次，顾客在迭代的计划会议上开始了鼓舞人心的话，他指出我们正在开始，团队一直在学习和提高。团队承诺35个点，然后交付25个点。

第四次迭代，同样的事情发生了。他们承诺35个点，因为顾客知道他们可以做这些，然后交付的更少了。

这个时候，顾客最后接受了我和另外一个教练的解释-团队的生产率不会因为许愿性的想法“更加努力”而提高。更坏的是，在过多的压力下，可能还会下降。

Plan Changes During the Iteration（迭代过程中计划改变）

在每一个迭代的前几天，如果白板上的团队任务变化得过于激进，那么一定要小心。这可能是一个线索-计划会议可能太匆忙了。我看到一些团队在进行计划会议，列任务，但是不仔细思考将要发生什么就估计。这样，当他们实际开始故事的时候，这就很明显，白板上的任务没有实际反映他们需要做的。

当团队需要理解的问题增加是，要让团队给故事增加一些新的任务，但是要注意：如果团队改变得太多-这是一个信号，团队没有抓住他们在计划会议中讨论的需要完成的事情。鼓励团队在下次计划会议上留更多的时间去完成任务，也鼓励团队在数量急剧上升时去做。

Meeting Has a Lot of Conflict or Tension（会议上充满了冲突和紧张）

进行计划会议可能很有挑战性。开发人员经常在设计如何做有很多的反对意见。顾客可能在变化中或者拆分故事时，遇到这些问题。

在会议的第一部分，是很紧张的，在故事被讨论时，可能关于如何拆分故事或者什么是最重要的故事。鼓励团队把他们的想法和关注的问题告诉给顾客。要清晰地知道顾客需要去听。最后，故事要以一个大家得成的共识的计划来结束。

会议的第二部分也很紧张，因为团队要达成共识，他们如何构建软件来交付故事。一些冲突可能帮助测试和想出一些想法，但是太多的冲突是不高兴和无效的。

如果几个可以选择的方法可以被选择，所有的都看起来相当好（或者相当不好），那么提醒团队去根据开发是否简单来判定每一个解决方法。这个可以帮助他们对这个问题学习得更多。如果一个解决方法比其他的好或者如果两个方法结合起来更好，那很快结果就会很显然了。尽快看起来把两种解决方法都编码是很浪费的，但是这可能是学习的最快的方法，这样也可以提供更好的解决方法。

Team Velocity Drops（团队速率下降）

对于一个新的团队进行了几个迭代后，速率确定下来，这个是相当正常的。但是一旦确定下来，团队应该保持跟踪他。当工程正在增长，软件支持更多的用户故事时，团队的速率经常会下降一些。同时，当他们对敏捷更自信的时候，团队可能会更乐观。帮助团队注意到哪些下降了，然后找出根因，尽管这些需要花费更多的时间来确定。同时，计划应该基于新的可测量的数据而不是继续根据老的速率去计划，希望奇迹出现。

Planning Doesn’t Make Sense（计划没有意义）

你会发现，很多次当你进行计划时，没有意义的。例如当一些成员在办公室外、度假、或者在火车上，或者当团队有很多bug修复时。Bug修复不容易估计，因为大部分的工作是在找造成问题的根因。

在这种情况下，不是浪费时间在计划迭代上，而是在白板上建立工作的优先级顺序。现在这个团队能够按照他们的工作方法来做，在晨会上为一天的工作排定优先级。一直继续进行小的工作，直到团队回到正轨或者bug被清除了 。

如果这个经常发生，那么考虑移一个看板来进行开发，这个不依赖于时间盒来限制过程中的工作。

7.7 Checklist

l  和团队一起建立一个计划会议的议程，可能会把计划会议分成几个会议。向团队展示，如果他们偏离了会议，如何在会议上使用议程使他们重新回到会议上，

l  提醒团队在计划会议前，和顾客一起工作准备用户故事

l  确保每个人在计划会议上都有机会问关于用户故事的问题

l  在估计工作之前，鼓励关于设计的讨论。如果顾客不在会议上，这个经常会讨论得很好。

l  建议团队为大的故事做任务分解。在迭代中，任务可以和故事贴在团队的白板上，帮助团队调整工作。然而，提醒团队跟踪完成的故事比任务更重要。

l  通过建立用户故事矩阵来把同一类估计值的故事分群来帮助团队保持估计的一致性。

l  要注意，团队要以一个持续的步伐来工作，不要承诺看起来他们不能跟上的速率。建议团队在确定计划要完成哪些故事前，检查他们的能力。

l  在会议结束前，确定每个人都抖拿了卡片，把他们放到了白板上。团队需要注意计划了哪些故事（带有初始值），这样当他们计算速率时就有了基线。