对于敏捷的估算一直心存问题，所以阅读了很多关于估算的文章，了解了不少估算什么及如何估算的真知灼见，但心里的疑团不仅未减弱，但又加剧了许多。原因在于我觉得估算更复杂了，更难把握了，比之之前的拍脑袋估人天更让人没有安全感。另一方面却又明显觉得自己陷入了一个误区，没有很好把握估算的本质。在阅读了 Mike Cohn 老先生的 Agile Estimating and Planning 之后，顿觉清晰明了，为了梳理思路总结认知，写下如下文字，以作记录。
书中开篇明义。
“The estimating and planning processes must themselves be agile. Without agile estimating and planning, we cannot have agile projects. ”
在进一步梳理之前，让我们先来学习几个词：Planning，Estimating and Scheduling。
Planning 旨在回答“我们应该在什么时间完成什么”这个问题。而要回答这个问题，我们又必须先回答“这个要完成的东西有多大”（Estimating）及“什么时候能完成?”和“到什么时间我收获多少?”（Scheduling）。通过这层关联表述，我们清楚了要想知道什么时间能够完成什么，必须先了解工作对象的大小及具体工期估算。记得有篇文章专门讲到，敏捷估算请忘掉人天，我深以为然，因为敏捷中的 Estimating 本身估的项目的客观大小，与具体工作的人无关。所以用人天估算没有办法做到。但是如果不估算人天，我又如何得到排期呢（Scheduling）。需求估算可以通过故事点衡量，与人无关，但排期是与人有关的，那么关联大哪里呢？
好吧，貌似我们现在有两个问题，一个是如何实现敏捷的估算，另一个是故事点和工期估算各自应该如何做。现在我们换一种方法来继续我们的讨论，我们先来理解一下敏捷中的估算（故事点和工期）是怎么进行的。首先敏捷估算从来不会以“完成这个项目，我们需要多少人天”这种方式来估算。通常团队会说完成这个项目，我们大概需要多少个迭代，如果说每个迭代固定为两周的话，那么为了估算出多少个迭代可以完成项目，又需要得出团队的产能 -- 即每个迭代可以完成多少需求，为了计算产能，则由于人天的局限性，所以引入故事点这个概念。
至此已经非常清楚了。
1. Estimating -- 先估算故事点以了解需求体量，同时为捕捉团队产能提供衡量单位。
2. Scheduling -- 其次估算工期，但这个工期的估算与以往的工期估算相比，反其道而行，即我不去估算做这么多需求我可以用多少人天完成，因为这个是拍脑袋估出来的，存在太多不确定性，并不准确 -- 敏捷团队会根据团队现有的状况（实际工作人天数，知识能力，依赖等情况）来承诺迭代内可以完成多少需求（以故事点度量），打个比方说就是船有这么大，我们来试试能装多少货。
3. Planning -- 通过将总需求拆分成若干小份，并评估固定时间周期内（迭代）团队能够消化的需求数量，确定迭代目标，在捕捉到团队稳定产能后，再估算出实现最终产品交付的工期。
这样做的理由有三：一需求越小越容易评估，估算也会相对准确；二船小好调头，迭代开发，增量交付有利于适应随时可能发生的需求变化；三快速并相对准确地估算，快速并相对合理地排期。
估算第一篇中已经讲了故事点估算都要考虑哪些基本因素，即故事点估值等于工作量，复杂度因素，风险因素和不确定因素的综合估值，为了方便我们简称之为 ACRU（A = amount of work, C= complexity, R = risks， U=uncertainty）。那么要完成这些因素的评估，我们必须要对每一个用户故事进行分析梳理吧。
Scrum 官方对梳理会的定义如下：
名称：Product Backlog Refinement
定义：A continuous effort than a formal sprint activity -- work together to prepare for the upcoming Sprints
目标：
1. Everyone is clear about the requirement - backlog meets DoR
2. Product Backlog Items targeted to the next sprint are Small Enough
3. The entire Product Backlog is Re-Estimated
所以我们发现 Backlog 梳理是非正式的 Sprint 活动，完全可以线下完成，不一定要有正式的会议，另外请注意，梳理是主要目的，估算其实并没有真正占用多少时间。因为分析梳理是进入新迭代前必须要完成的工作，否则就是取消了开发人员对需求的知情权和建议权，是主要的，所以反而估算是捎带手的事儿。姑且设定每天 20 分钟左右，从当前迭代的第二周开始算起，共五天 120 分钟，平均每 5 - 10 分种完成一个用户故事的梳理和估算，那么我们可以覆盖大概 12 - 24 个用户故事。当然我认为如果当前迭代第一周团队已经初步进行技术分析和开发规划，这个效率可以更高。
这样来看估算的确可以敏捷起来。
但是还不够，由于我们实现了敏捷的估算，我们同样可以让 Planning 变得敏捷。且看下文：
梳理完成后，基本实现了上面提及的三个目标，可以进入迭代计划会了。怎么做呢？
我们已经对故事做了充分拆分，每个用户故事都足够清晰，并且进行估算，那么团队在计划会上只需根据团队现状进行承诺就可以了，即团队现在交付能力有多大，我们可以装载多少用户需求进入本次迭代的大船。让我们尝试用下面的模型来模拟这个任务装载过程：
迭代计划.jpg
为了确保成功交付，团队会基于现状（人员，时间，干扰等）做出承诺确定迭代目标，那么如果现状是明确不变的，这个任务装载过程应该是十分高效的。
传统的工期估算方式，通常会以这种方式来计划：
• 完成这个需求，我们需要 300 个人天。但依据是什么呢，这个结果准确吗，用户会信服吗？
由于有了前面的故事点估算为基础，敏捷工期估算时完全反其道而行之：
• 团队 4 人，假设迭代期间没有休假，在没有其它时间占用和干扰的情况下，我们每个迭代（假设两周）可以交付 25 个故事点左右。
• 理想估计全部需求，总计有 300 个故事点，大致需要 12 个迭代周期可以完成，但期间根据团队现状（如人员变化，外部干扰）和需求变化，我们会随时更新迭代计划和最终交付计划。
Scrum 计划的敏捷性体现在计划的过程 -- 即开发过程中可以根据团队现状和需求随时调整计划，不断的更新计划以适应变化。传统的计划你随便变更一下试试，因为所有方案都是预先设定好的，所有需求都是预先定义好的，且中间不会频繁检查和调整，而更多侧重于如何不偏离即定计划。所以任何的变更都可能意味着要重新设计，要重新定义，甚至往往推倒重来。而敏捷的计划则是一个随迭代不断更新的持续行为。这种不断检查，调整和适应的过程本身是敏捷的。
- 方案随迭代变化，即使用户不提，团队本身也会考虑优化，谁都不想做出一堆垃圾出来；
- 需求有变更，反正迭代范围有限，船小好掉头，可以接受，而且因为交付是建立在承诺基出之上，承诺不是保证，合理的变更客户也是不会反对的；
所以 Agile planning 指的是，只要我们一致认同迭代开发，增量交付；只要我们一致认同开发团队基于现状承诺迭代目标；只要我们一致认同每一个迭结束，离最终交付目标就更近了一步。我们拥抱变化，欢迎变化，甚至主动发起变化。因为团队具有持续的计划能力和敏捷的规划能力。
网友评论