标签存档: 估算

由于我对估算和计划是在太感兴趣了，因此每当我看见有人在博客或者消息组里面宣称“估算是在浪费时间！别再做了！”我都会十分留意。有趣的是，这些针对估算和计划的争论从来都不会来自那些我们为他们开发产品或者系统的那些人，因为他们都明白估算和计划的意义（以及错误的估算和计划带来的痛苦）。

让我们来仔细想想那个观点。在你的人生当中，有多少件事情是你完全没用做计划的？我估计你会为婚礼做计划，为搬到另外一个城市做计划，为假期出行做计划，或者为任何你事先没有打算做计划的这类事情做计划。

假设你打算第一次去意大利旅行。你可能会计划去哪些城市，每个城市要呆多久，预算是多少等等。现在假设你打算第一百次要回去你长大的故乡，你也会进行计划——尽管你计划的内容是决定你不需要做任何计划。

计划，是一种考虑将来的行为。有时候，将来是存在着风险以及不确定因素的。在这些情况下，我们需要比对可预知的将来（如第一百次回故乡）做更多的计划。当未来是可预测的时候，我们要做的计划可能只是花费几个毫秒来决定我们并不需要做更深入的计划。

当然，一个软件项目远没有那么简单。

那么估算呢？我们真的需要估算吗？答案是肯定的。因为估算是计划的前提条件，你不可能在没用做任何估算之前就做计划，就算这些估算是非正式的或者是隐式的。当我在写这篇文章的时候，我还在飞往加州的飞机上。在登机之前，我决定去ATM机取一些现金，因为我估计在稍后我需要一些现金。然后我又估算了一下数额，大概200美金就足够了。在这个例子中，估算所花费的时间还不到一秒钟，我甚至都还没有意识到，它就已经发生了。

当一位Product Owner 说：“我希望加入这个特性，而不是那个”的时候，他其实已经在为每一项特性所需要的时间做估算了，虽然这是一种隐式的估算（或者叫做猜测好了）。当一位程序员决定在下班之前修复一个BUG，而不是开始做一个新的用户故事的时候，其实他也进行了一次隐式的估算，而他估算的是在到下班之前的这段时间里，他刚好有足够的时间完成这个BUG的修复工作。

有的团队说：“我们不会进行估算的，我们只会把所有用户故事定义成同样的大小”，但是他们却没有意识到其实他们已经是在进行估算了。在这里，他们所估算的是一个用户故事要和其他用户故事的大小相同。其实，我认为要令所有用户故事大小相同，比要估算在大小一定范围内的大小不一的用户故事更困难。
其实，尽管你没有意识到，但是在不知不觉中你已经进行估算了。那些在博客和消息组里面说估算是浪费时间的人，正是忽略了这种估算的存在。
但是，这种随意的，下意识的估算足够吗？如果团队进行正式的估算会不会更好呢？

也许吧，但是并不是所有情况都适用。团队只有在深入调查后需要采取不同的行动的情况下才有必要进一步深入估计，否则就应该适可而止了。当然，如果进一步的计划能够让团队作出更好的决定（对交付日期更有信心，或者更好地为功能排列优先级等等），那么就应该进一步估算及计划。

举个例子，我们最近在给一个网站添加对我们的敏捷估算和计划的eLearning功能的支持。我没有询问负责这个功能的程序员完成该功能所需要的时间，但是我仍然能够有一个大致的概念知道需要多久能够完成。因为我和他已经在一起工作很久了，我对他的工作效率非常清楚。进一步地追问并不会为这个项目带来任何改变。

从上述可见，估算和计划是必须的。因为它们可以（而且应该）是轻量级的。如果进一步的估算不能让你做出更好的决定，那么你目前的计划就是足够了的。

项目经理被问到最多的问题就是，“这个项目什么时候才能完成？”
被问的时候，可能项目才定下来，仅仅知道大概的功能模块，非功能性需求还模糊不清，甚至团队成员都没到位。但是上级、销售、客户急切地要知道，这个项目什么时候才能完成？
被问的时候，也可能项目已临近结束，或者说临近当初计划的交付日期。然而待完成的功能还有一堆，测试出来的bug有一大堆，客户又提出了新的需求，团队正有人要离职 …。但是上级、销售、客户非常急切地要知道，这个项目到底什么时候才能完成？
这还不算糟糕。更头疼的问题是：“再有三周，项目应该完成了吧？”
因为后者根本不是问题，而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目；或者说明在三周内，能够完成什么。
我们都用过MS Project， 但是那上面的漂亮表格对这样的困境毫无帮助。相反，正是Project 中的甘特图和日程表，埋下了陷阱。因为，在Project 中无法预估需要多少工作日才能完成模糊不清的需求，也无法体现实际情况发生变化后对进度的影响。
当我们讨论进度的时候，其实包含了两个未知的变量。第一是完成需求所要的工作量，包括需求定义、开发内容边界；第二是团队的工作能力，包括成员的行业知识专业技能，成员之间、成员和外部的沟通能力，等等。
关键就在于，这两项都是变量。如果任务是搬一千块砖头，每分钟每人能搬10块，那么结果是显而易见的。
在敏捷开发中，采用相对估算和迭代求精的方法来处理项目进度的问题。
首先是工作量。用估算代码行数或者界面元素的方式，就像论斤卖书一样，只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮，而是可靠易用的功能。
在敏捷方式中，先由用户和设计人员粗略估计各个功能模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是10分，那么查询模块可能是15分，而修改为20分。
下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要10人天，从而得出单位分值对应的人天为1；那么，整个项目就需要45人天。
这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有偏差？没关系。接下来通过迭代来求精。先来实现显示模块，如果事实上花费了12人天，那么根据比例关系，剩余内容的估算大约就是42人天。
当然，比例关系也不是一成不变的。随着模块的逐个完成，项目经理对项目的认识也在加深，他可以再调整剩余模块的相对分值。
在实际操作中，项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分，再选择分值最小的模块开始开发。统计总工作量时，按比 例累加其他模块的工作量，并加一定的调整系数，因为模块的复杂度不是线性增长的。每次迭代开发完成后，逐步降低调整系数。通常4~5次迭代后，可以将调整 系数归零。
在上面的例子中，第一次估算的初步结果是45人天，因为完全是凭经验，因此要给较大的调整系数，比如说0.4，因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见，项目经理上报的工作量为70人天。
第二次估算，剩余内容的初步估算为42，调整系数下降为0.3，因此给出估算区间为30到50人天之间。依此类推，通过不断迭代，对剩余工作量的估算将越来越精确。
这样估算的好处在哪里？
首先，工作量变量的很大一部分因素，存在于非功能需求，例如界面的美观程度。而同 一项目的不同模块之间，非功能需求往往是一致的，相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然，随着项目的进展，成员的开发能力应 该有一定的上升，但随着加班出差等因素，投入程度也可能下降，因而会相互抵消。总之在周期6个月以内的项目中，很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。
其次，迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的，但只要团队稳定，没有大的需求变动，估算范围将迅速收缩。这比一次性报数更准确。
它的额外好处是，敏捷开发是遵循优先级的，即使对剩余时间（即低优先级模块的开发时间）的估算不十分准确，影响也不是非常大。
对比一下甘特图方式，在开发初期就要把各个模块的开发时间估算出来以统计总量，这就是瀑布开发的模式。
进度问题的另一方面，是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后，项目经理如何做到心中有数，估算任务实际完成时间。
敏捷开发过程中，由开发人员自己来估算完成该任务所需要的时间。当然，每个人的能力不同；每个人的心态也不同，有的人保守，有的人乐观。没关系，还是靠迭代来逐步求精。
在每天的例会上，开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间，敏捷方式只关心这项任务还需要多少时间去完成，直到归零，然后再来统计实际的工作时间。
为什么？因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同，也许昨天用了8个小时没有一点进展，今天一旦想通了就事半功倍。我们真正关心的，就是到底还需要多少时间来完成任务，而不是已经花费掉不可恢复的时间成本。
在每天例会中，项目经理需要注意时间曲线保持水平的成员，他是不是遇到瓶颈了，是 否需求帮助？也要留意时间曲线下降幅度过大的成员，他发现了什么好的办法，有没有低估需求？这样，项目经理会更面向结果，只要按计划保证质量完成任务就 行，成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容，第一是因繁琐而失真。其次，一旦上级发现某人工作时间不够（即便他完成了任 务），忍不住会派新任务，从而造成越干活越多，反过来打击程序员的积极性。
敏捷估算的关键之处，是把成员能力这个变量的估算，交给最合适的人去做，即程序员本人。然后通过比较历次迭代时的预估和实际时间，给出校正系 数，以避免程序员过于保守或过于乐观。这肯定不是绝对准确的，但效果往往比项目经理自己拍脑袋估算，然后强行指定deadline 要好得多。
在敏捷开发中，做计划比计划本身更重要。项目经理需要时刻向前考虑，考虑各种动态因素，而不是死报着计划本身。在进度估算的时候，项目经理应该在不同阶段，根据实际情况，给出合乎情理的回答。

来源：软件开发网

微信扫一扫，立刻免费使用微信版估算扑克

Scrum中文网微信号：Scrum_CN

使用估算扑克来做工作量估算是最有效，也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字，可供4个人使用。

估算扑克的使用方法：

1.每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
2. 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。
3. 团队讨论这个条目。
4. 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。
5. 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数”1,2,3″,大家同时展示估算结果。
6.团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？团队共同讨论估算的差异，最终达成一致。
7. 回到第二步，开始估算下一个条目。

 为什么要使用估算扑克来做估算

有人可能会问，在传统的做法中，我们一般是让一个专家或者项目经理来做估算，给出结果，然后团队照做就可以了，多个人都参与估算不是浪费时间吗？
使用估算扑克来做估算基于两个结论，
第一：团队的智慧要高于某一个人的智慧。
第二：真正参与工作的人做出的估计要高于其他人做出的估计。
估算扑克有效还有如下几个方面的原因：
1. 传统估算通常是一个人在思考，而使用估算扑克估算时，鼓励跨职能团队的多个团队成员参与估算，团队成员可以从不同的视角来思考和分析问题，估算的过程中考虑的更加全面、估算也更加准确。
2. 在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观。这样也避免了很多时候过于武断，或是拍脑袋做出的决定。
3. 估算的过程也是一个知识分享和学习的过程，对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识。

如何获取估算扑克？

估算扑克由于需求量很小，所以目前市场上是买不到的。 您有以下几种方式可以获取：
1. 选择专业的扑克定制厂商定制，一般是5000到10000副起印。
2. 联系Scrum中文网购买，每幅扑克30元，联系方式： info@scrumcn.com.邮件标题注明购买估算扑克，邮件中请提供您的所在单位、邮寄地址、购买数量、联系人姓名及手机，以方便我们与您联系。
3. 获取电子可打印版本，自己裁剪，URL: https://www.scrumcn.com//down/html/index.php?29.html  。
4.扫描Scrum中文网微信（文章开头），立刻免费微信版估算扑克，T-shirt Size估算。