966,690 二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
用户故事估算技巧
用户故事估算技巧
日. 估计阅读时间:
不到一分钟
相关厂商内容
相关赞助商
QCon北京-18日，北京&国家会议中心，
使用数字4，可以让你得到一个粗略的估算，而不必在精确程度上花费太多时间。有的故事感觉比2点大一点，但是又比4点小一点。这样的故事不能估算为3点。也没有理由使用3点进行估算。类似的故事隐含的风险或是未知因素让人觉得它不是2点，因此，它很有可能是一个4点的故事。如果使用平均数、或是不在估算取值范围中的数字，有可能给团队成员或是项目干系人造成暂时的（也是不必要的）困惑。同时，从项目整体的角度来看，偶尔不太确定的估算也不会影响大局。要保持简单，坚持使用取值范围中的数字。
受他人影响是人的本性。如果一个技术leader说一个故事大小是两点，很可能其他团队成员都会随声附和。因此，在我负责的估算过程中，我会让每个团队成员独立做出自己的选择。要想达到这样的目的，可以为每个成员发一张纸，让他们在上面写上自己的估算，等到每个人都写好之后，大家可以一起展示各自的估算。另外一种方式，也是我喜欢的方式，是用&石头-剪子-布&（译注：英文名rock-paper-scissors，简称RPS）进行估算。在估算会议上，我们会一直讨论某个故事，直到大家都准备好估算为止，然后我们会一起&抛出&自己的估算，就像是同时伸手出石头、剪子、布一样。我所说的&抛出估算&就是：伸出一个手指头表示1点，两个手指头表示2点，四个手指头就是4点。要是表示8点，那就得双手并用了。
选取最大的估算值
即使反复提醒过了，开发人员们还是很难估算，因为他们仍会受到团队的影响。如果某个开发人员认为可以在一天内做完某个故事，他会伸出一个手指头。然而，这个故事也许不由该开发人员负责，另外的团队成员会接手，可是他可能会认为这个故事应该是2点甚至是4点。我总是选择团队成员给出的最大估算数值。也许有人认为这是小题大做，可实际上每个团队成员对于风险的认知不同，也许给出最大估算的成员想到的风险要比其他人更完备。选择最大的估算值还有其他好处。如果必须要同意一个较低的估算，那么做出最大估算的团队成员就得说明原因。对于团队中不那么资深的成员来说，这样的讨论可能让他觉得窘迫。对开发语言和工具相关经验的匮乏，他们可能不知道怎么样快速完成某项工作。他们的担心是由自己的技能水平决定的。如果因为不想讨论为什么估算值那么高而不愿意给出自己真正的估算，这对团队可无甚裨益。
对于取值高低的讨论，有可能使得整个团队提升估算值，或是让开发人员不甚情愿地降低自己的估值。不管怎样，你都要花更多时间来讨论，而这些讨论可能一无所获。到最后，最重要的还是保持一致。通过跟踪团队开发速度（注），团队在一个迭代中可以完成多少故事，这总是可以知道的。因此，即使估算有所&膨胀&，速度也会随之变化，对于规划来说没有影响。
最后，选取最大的估算值可以节省估算会议的时间。如果团队中有人认为一个故事应该是8点，在讨论这个故事时，他可以大声说出来，宣称自己将抛出8点这个估算值。除非有人认为在团队成员的估算之间有很大差距，既然这个故事必将成为8点，那就没有必要再针对它讨论下去了
讨论大估算差
对于估算，经常会有误解，以为整个团队都同意某个故事的大小。如前所述，我会选择更大的指来解决估算不一致的问题。然而，有时很大的估算差距意味着存在某些误解。因此，如果有两个估算的值差距大于2，总是会引发讨论（比如，如果一个成员抛出1点，而另一个认为是4点，大家就得澄清一下了）。讨论这些大的差距，还可以减少给出最大估算的人被轻视的机会。
提防信息不足
有时会发生估算会议结束时还有故事未被估算的状况。与其匆忙给出一个让人不舒服的估算，不如去征询更多信息。估算为8点，暗示着这是一个很大的故事，但也意味着你觉得它会占用两倍于4点故事所用的时间。因此，不要随便将不清楚的故事估算成8点。估算会议的目标不是要得到所有故事的估算值，而是要为提供了足够信息的故事给出估算。
必要的投入
没人喜欢参加估算会议（好吧，就我所知的都不喜欢）。在我经历过的项目中，语速快的人负责将故事大声念出来，开发人员会问领域专家各种问题，然后他们会进行估算。当没人向领域专家发问时，他们会在自己的笔记本上做其他的事情。一开始，我觉得这是利用时间的好方法，但是他们却会因此而错过一些东西。后来我参加了这样一个项目，经理要求每个人轮流念一个故事。这样领域专家就参与进来了，因为他们害怕轮到自己念时看起来很愚蠢。由于每个人的全情投入，整个会议也变得更有价值了。
在供应火腿和鸡蛋的餐馆里面，猪是全身心投入，而鸡只是参与而已。
我经常听到这样的话：业务人员不应该干扰开发人员的估算，因为开发人员属于&猪&的角色，而业务人员都是&鸡&。我真觉得这个类比很不好。一个坏的产品出来，更有可能被解雇的是业务团队，而不是技术团队。然而，让业务人员干扰估算是会引发利益冲突的。
这个问题也很容易解决。业务人员想知道他们在下个迭代后能得到哪些功能，他们需要估算。由于业务人员不写代码，他们的估算都不大准确。在实际的估算过程中，业务人员参与得越多，由此而对开发人员产生影响，也就有可能使业务人员得到的估算越不准确。在会议上，最好的领域专家只回答问题，而不会去干扰故事开发过程的一丝一毫。
估算小组人数
团队的大小各有不同。在小于等于6个人的小型团队中，我建议整个团队都参与估算会议。不同的观点有助于夯实项目远景，并对估算产生正面效果。不过，我相信是存在收益递减效应的。如果是大团队，就不一定全都参与针对每个故事的估算了。再说，这就是一个估算，6个人跟15个人的准确性不会有太大差别。如果你的团队多于6个人，我建议分成不同的估算小组。一般来说，我希望最少能有3个人参与故事估算，但是不要超过6个人。
新故事的出现有两种形式：新功能需求和既有故事的切分。一般我会根据新故事的优先级考虑何时进行估算。如果一个故事要在下个迭代中完成，那就得对它马上估算。不过，要是新故事在接下来几个迭代中都不会出现，再等等也无妨，直到有了足够的故事来证明召开估算会议的必要性。我发现估算会议上得到的估算值更为可靠，因为在那个环境中，大家都将精力放在估算之上。通过切分得到的故事有其复杂性：它们可能已经估算过了。我强烈建议在估算新故事时，不要考虑之前的估算值。如果一个故事因为其风险或不确定性需要切分，很有可能之前的故事是不靠谱的&&忽略原先的估算吧。
不要用笔记本电脑
至少不要给开发人员提供笔记本电脑。把故事列表打印出来分发给大家，或者用投影仪投放在屏幕上，但是不要让开发者从自己的笔记本上读故事列表。笔记本总是从某些方面吸引开发人员的注意力，因此使得他们偏离会议的目标：得到有价值的估算。
必要的参与
这个建议非常重要。理论上说，除团队之外的开发人员都不能参与估算会议。也就是说参与会议的每个程序员都有可能要去开发被估算的故事。如果一个开发人员不喜欢估算某个故事，那我就不希望他们开发这个故事。当然，凡事有例外。对于新成员来说，我会给他们一周的时间来适应，之后再参与估算会议。不过，一般来说，拒绝参加估算会议的开发人员应该说明：有什么样更严重的问题等着他解决。
过时的估算
团队会改变，项目会变化，天有不测风云。不管是什么原因，估算都有可能过时。过时的估算毫无用处。要跟上过时估算，开发团队会有压力，而业务人员根据之前了解的进度，希望故事可以及时完成。估算过时与否并不重要，重要之处在于估算不再可行了，由之产生的计划也不再可靠。我参加过的项目中，所有的估算在 12-24周内都会过时。承认估算过时，而不要用不准确的信息安排计划。因此，我建议重新过一遍已经过了12周的故事估算。虽然这些估算可能没有问题，但是开发人员有机会提供新的信息，这对于整个业务来说肯定有所裨益。
这个建议最容易做到了。为估算会议购买各种好吃的零食。科学证明：甜食会让人产生幸福感，而幸福感会带来协作。想让估算会议按照既有方向进行，这是最简单、最便宜的方式。不过要注意：好吃是关键。如果拿出来的零食在团队房间中已经存在，那就索然无味了。在最近参与的项目中，一想起来要开会了，我就会去面包店买刚出炉的什锦饼干。
我想特别感谢：Brent Cryder, Dennis Byrne, Fred George, Joe Zenevitch, Mike Ward, Sean Dora。他们帮我把这些想法固定下来而且不断改进，跟别人一样，我也肯定遗漏了一些做出贡献的人，请原谅我的疏漏。
Jay Fields在ThoughtWorks工作，负责软件开发和相关的顾问工作。他热衷于发现和改进创新的解决方案。最近，他的主要精力放在领域特定语言（DSL）之上，而且已经交付了很多应用，使得领域专家可以顺利地编写业务逻辑。对于开发人员通过软件测试提升软件设计的成熟度，他也很感兴趣。
阅读英文原文：
*速度：当项目的生命周期通过迭代组织时，用来计算一个迭代能够完成的工作的点数。比如：如果你在5个迭代中完成了20点，你的速度就是4。只要故事的估算之和是4点，你就可以在一个迭代之内完成这些故事（比如，一个估算为4点的故事，2个估算为2点的故事，4个估算为1点的故事等等）。
在InfoQ英文站文章后的评论里，读者dale moody补充了一个技巧&&限制会议长度。他说：
超过30分钟后，我的估算质量就开始下降了。要是过了一个小时，我可能连自己的名字都不记得了，更不要说该我估算的故事标题了。&估算疲劳&会让人们状态下降。为了隐藏这个事实，开发人员们给出的估算会比较中庸，这样大家就不会再被迫去讨论故事了。
如果你发现有人出现了萎顿的状况，干脆叫停会议算了，感到疲倦的应该不只一个人。我发现，短暂的休息只能带来短暂的状态恢复，最好是等明天大家都充满活力 的时候再继续开会。再说，如果估算进行得太久，也许估算的就太多了，而领域专家、业务分析师、项目经理可能都还没有准备好。
读者Arnon Rotem-Gal-Oz对&独立投票&这个技巧进行了补充：
我们用手机。每个人把自己的估算在手机上按出来，然后我们会对比各自的估算。 ：）
读者keith gardner分享了他的故事估算技巧：
我最近换了工作，之前的工作是与团队坐在一起的，现在的职位要与分布式团队一起合作。同时我在帮现在的小组从瀑布式过渡到Scrum开发（效果看来还不错，因为我们每隔2到3周就要改变优先级。而且我现在的组织好像经常会改变优先级）。
我曾在故事估算会议上用过扑克式规划，也取得了一些成功。不过在之前的公司里，我们面对着下面这些挑战：
让每个人同时展示他们的估算卡片（展示估算卡片，还得同时，这比想象的要难得多）。
查看所有的卡片，判断高低。
确保每个人都把注意力放在当前的故事之上。
当有人不在现场时（似乎总是会有这样的状况），尽量让他们也参与进来（当大家都已经写好估算之后，让这些不在现场的人先说出他们的估算，然后再让房间里每个人展示自己的估算。确保不在现场的人能够知道所有的故事细节，而且可以听到房间里的对话，并且能跟上大家的节奏）。
我最近发现了一个免费的扑克式规划工具，我很喜欢它，网址是：（由Mountain Goat Software提供）。我们也用Rally管理用户故事（/）。
我们的估算会遵循下面的步骤：
准备阶段。在规划会议前一至两天，产品负责人和scrum master会先把用户故事整理整理一遍（添加验收条件、确保有足够的细节、排定优先级）。
准备阶段。在规划会议前几个小时，scrum master会将用户故事从rally导出到扑克规划工具中。我会安排优先级，因为我们将会议时间限制在一个小时，并且处理尽量多的故事。如果需要的话， 我们会有后续的会议来过更多的故事。如果完成了高优先级故事的估算（以及其他团队挑出来的任何故事），接下来会进入规划阶段，并排定下个sprint前要 开发的故事。
我们会用电话会议服务进行辅助。也用过WebEx让大家看到同样的信息，不过最好让大家都可以展示他们希望给别人看到的信息，这样更有效率。
工具可以促进并强迫每个人展示各自的估算。这样很好，去掉了很多问题（作为管理员的Scrum master可以输入最后的估算）。
工具只显示目前处理的故事。
在逐个估算这些故事时，对它们的问题和澄清会被录入到rally中。进行讨论时，有效的scrum master可以保证每个人都能有机会对故事发言，并且每个人都不会分散注意力。
在达成一致意见之前，我们会进行几轮估算，而且会与不在现场的人讨论。
工具可以跟踪整个会议中所有的估算。
会后，我们会把估算数字录入回Rally中。
我非常喜欢我们的这个过程，而且我个人觉得这比个人用扑克进行估算的效果更好。
读者Andrea Maietta对于如何管理估算选择的数值提出了自己的看法：
就像Mike Cohn在他的书里面指出的那样，我们选择斐波那契数列进行估算，而且觉得效果非常好。我们有从0到20的卡片，但是很少选择超过13的数字，因为这会留下至少5点的估算差值。
至于工具，我们用涂有颜色的纸，并切成有规格的纸片，其中涂上我们的数字。这样就得到了规划扑克。
我觉得选取故事估算的最大值是节省时间的一种方式，但对于小型团队来说，我觉得对被选中的值（和隐藏风险）进行简短的讨论，这有助于提升对于项目的整体理解。
读者Dave Rooney提出：
在大型团队中使用规划扑克时，我发现总是有一组人的估算比较低，一组人比较高，还有一帮人的估算介于中间。一般我会让提供高值和低值的人解释他们的想法，防止有人对故事了解得不完整。通常情况下，需安装的估算不一定是最高的，经常是中间的值。
对于他的说法，作者Jay Fields这样回应：
保持一致是最重要的。如果总是选择中间的值，依我看，这问题不大。进一步讨论应该会有效，但是要考虑两 点。第一，你可以得到更多信息，但是在这个时候这么多信息是不是真的有价值呢？我发现更多的讨论总是会使大家选择中间的值，但是也会带出更多信息，而这些 信息不是整个团队所需要的。不是每个人都需要知道每个细节。第二，你不会希望鼓励大的估算。有时人们会感觉一个值有点大，这个感觉通常是对的。如果你强迫 他们去解释，他们也许会给出更低的估算，而忽略自己的感受。当然，如果总是有人过高估算，这也没什么，还得要保持一致性。我觉得你的选择也不错，但是我个 人还是觉得选择最大的估算是最有效的方式，而且也能让参与者感觉良好。
对此，Dave Rooney也同意保持一致非常重要，他回应道：
&&如果给出高估算值的人确实发现了别人没有想到的东西，当然我们会选择更高的估算。
不过我有时会得到这样的回答：&我没怎么用过这个技术&或是&我不太理解需求&。对于前者，降低故事是有意义的。如果给出高估算的人来开发这个故事，可以让他们跟精通技术的人一起结对。对于后者，明显是由于这个人没有提出足够的问题，没有深入了解进行估算需要知道的东西。
所以，对于上述两种情况，我推荐用中间值。不过我同意，在大部分情况下，还是&最高的估算为王&！
读者Vladimir POPOV指出：
我们曾用过2的幂进行估算，后来发现在项目级别来看，它有点过于&扁平&了，所以我们就用e的幂。有趣的是，斐波那契数列与e的幂非常接近。比如1、3、8、21、55&&实际上，我们用到的复杂度也就这5级，最后一级用来识别需要重新估算的故事。
读者Martien van Steenbergen对于故事的排序提出了自己看法：
&&对于按照业务价值对故事进行排序，我使用&大家下注吧（faites vos jeux）&的方式，也是由玩扑克得到启示而产生的实践。
每个业务干系人（他们做决策，控制预算，也可能是用户）拿到10到20个筹码。所有筹码的价值相等。接下来，如果他们认为某个故事应该在接下来的两个sprint中开发，就会把筹码放在其上，并提出下列问题：
（在我内心深处）这样做感觉好么？
这样做有意义么（是否理智）？
这样做可行么（是否可以实现）？
这样以来，下两个sprint中开发的故事就是基于他们的价值进行排序了。
接下来就让开发人员选择故事吧。
作者Jay Fields在评论中对于估算值的选择给出了新的解释：
Fred George，是我遇到的最好的同事之一，他喜欢用T恤的尺寸进行估算。这样做的优势在于：你无法对尺寸取平均值。但是我觉得有个问题：你没有办法用手表 示M，而是要用两个手指表示2点。我喜欢大家用1、2、4、8个手指进行估算。要是表示估算得用两个手的话，做估算的人就得考虑下为什么要用8点了。这通 常会得到一些关于故事的新想法&&可能是技术也可能是业务的角度。我不反对使用斐波那契数列，但是这会让我不能给出10点以上的估算值。你可以使用1-5 级（就像Vladimir POPOV在之前的评论中提到的），但是我想即使用1-5级的方式思考，但是写在纸上的数字却可能会有所不同。这没啥问题，但我还是喜欢在思考、给出估算 值和记录估算值时，使用同样范围的估算数值。这样更自然，而且我也有很好的例子来证明。
读者Maurice Hager对于文中没有提到Delphi估算技巧表示惊讶，并认为这是一个不错的工具。
［译注：通过Delphi方式进行估算，项目经理会把团队召集在一个房间中，并就项目有关事宜向他们进行阐述。大家会提 出各种问题，每个人都会写下来自己的任务列表和时间估算，同时注明自己对项目的预设条件。接下来，团队会收集任务列表并进行复查，看看哪些任务可以同时进 行。项目经理会把估算时间加在一起，得到项目的整体估算。可参考文章《》］
志愿参与InfoQ中文站内容建设，请邮件至。也欢迎大家到参与我们的线上讨论。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Re: Fibonacci number 也是好選擇
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。软件项目估算是一件很难的事情 - 文章 - 伯乐在线
& 软件项目估算是一件很难的事情
最近Uncle Bob发表了新的博客《》。
Bob大叔首先抛出一个问题，如何将著名的葛底斯堡演说的237个单词以固定字体和固定行宽写在一张书签上。如果人工执行这个任务，假设每秒钟处理一个单词来寻找合适的断句点，估计5分钟内就可以完成，而且实际花费时间也和估计的差不多。然而，如果要编写程序来做，要花多久？而且是在知晓算法、没有意外情况、没有绊脚石、无需备份和恢复功能的情况下，编写程序要花多久时间？
Bob大叔提醒说：程序只不过是遵循某个过程的具体指令，而这个过程是已知的。在动手写程序之前给出3个估算，最佳情况、最差情况和正常情况。根据Bob大叔的统计，大部分人需要花上30-45分钟，也有人用了15分钟，还有人用90分钟。这样，很多人之前的估算与实际花费相差悬殊。其中一个原因，他们基于手工任务看似简单来进行估算的。
Bob大叔回忆某个下午和Kent Beck采用测试驱动开发来结对编程写这个算法。他们估计这需要10-15分钟，结果花了30分钟却毫无进展。在被迫接受这个体验后思考，为什么这算法这么难？为什么把如此简单和直观的过程写下来这么难？
其实，人类是目标导向的，在分解文字时，人类不会遵循一个过程，而是不断评估输出，然后调整做法直到正确为止，因此会预估5分钟之内完成。而过程是盲目的，它不管输出是否正确。如果过程错了，那输出结果也会错。人类不了解过程，不了解过程的难度如何。人类不是电脑，做事的时候不会遵循过程，所以无法比较过程任务和手工任务的复杂性。这就是估算为什么难，而且经常犯错的一个原因：任务看上去简单，人们基于这个表面现象来估算，之后却发现写出过程实际上是多么复杂。人们估算不准是因为估算了错误的东西。
回到分解长字符串的例子。每次分解一行，记录下分解位置和选择这个位置的原因。将其概括为三个不同的场景：
1.如果单词长于10个字符，在第10字符处断词。
2.如果第11个字符是空格，在第11字符处断词。
3.从第10个字符向回查找，如果找到一个空格，就在该处断词。
这些场景仍然需要被组成一个过程，但是至少知道这个过程有几个部分组成，从而使估算更容易。
这个故事的寓意是任务看似容易被人类解决，却经常被描述为复杂的过程。所以估算时，确保不要被简单的表面现象所迷惑。深入进去，尝试列举出过程所包含的场景数量。
博文显示估算失真有多容易。人脑不善于回答抽象问题，往往替换实际问题为一个直觉问题。而直觉在寻找答案时，如同博文所说，以期望结果的产生来考虑问题，不关注未知或可能出错的东西，而是关注那些能够理解的东西。
博文引发。有人认为分解过程为小的片段并无价值，有价值的是知道哪类问题是困难的和为什么困难。也有人认为多练习有助于提高估算准确度，或者让有经验的人而不是新手估算。然而经验最可以依靠，却仍然可能出错，除非项目与之前完全一样。
除了博文所讨论的原因，还有人认为，团队水平、办公室政治、企业缺乏变更控制，也都成为导致估算不准确的原因。
更多的人：在实际中，估算往往发生在没有明确需求可以参考的时候，更不用说之后不断变化的需求、未知因素、代码基础中隐藏的陷阱。因此固执地遵循最初的时间表也使得估算看起来是不准确的。而且开发人员面对来自于客户和经理的压力时，往往倾向于低估时间表。
各位读者，你们对于估算有什么样的经验？什么时候估算得准确，什么时候又不够准确呢？
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
&#8211; 好的话题、有启发的回复、值得信赖的圈子
&#8211; 分享和发现有价值的内容与观点
&#8211; 为IT单身男女服务的征婚传播平台
&#8211; 优秀的工具资源导航
&#8211; 翻译传播优秀的外文文章
&#8211; 国内外的精选文章
&#8211; UI,网页，交互和用户体验
&#8211; 专注iOS技术分享
&#8211; 专注Android技术分享
&#8211; JavaScript, HTML5, CSS
&#8211; 专注Java技术分享
&#8211; 专注Python技术分享
& 2017 伯乐在线developerWorks 社区
本文将详细介绍优秀的估算实践的重要性。文中将展示和分类一组估算技术，还将对敏捷和传统技术进行总体比较，最后会推荐一些一般的估算技巧。估算可能是一种具有更高的认知度和协作水平的高效实践。
, 首席 IT 专家,
Dina Sayed 在 IBM 拥有 10 年的软件开发经验。她在埃及工作。自 2004 年到 2010 年，Dina
一直在担任软件开发人员。她设计并实现了各种解决方案来利用 IBM
产品中的阿拉伯语支持，还为不同开源项目的开发做出过贡献。她在不同的编程语言、API、工具和 IDE 上拥有实践经验。2011 年，Dina
担任技术项目经理的职位。她是一位经过
的 “首席 IT 专家”，该计划是一项对 IT
专家的专业技能、知识和实践经验给予认可的全球认证计划。她拥有通信和电子工程专业的学士学位。2014 年 10
月，她获得了诺丁汉大学自然语言处理专业的理科硕士学位。
任何项目领导都需要具备的主要技能之一，就是对工作量估算具有良好的认知。精通估算非常重要，因为这会对项目交付期限带来很大影响。不准确的估算会显著影响任何项目的成本和盈利能力，还会影响所有团队成员和客户对项目领导的看法和信任。知道如何估算对所有团队成员都不可或缺，因为他们都会在估算过程中发挥一定的作用。毋庸置疑，整个团队建立这种能力至关重要。但是，我们需要认识到我们在软件行业中的估算过程中面临的挑战：几乎无法复制同一个项目，并假设所有估算结果都将保持不变。每个项目始终具有一组新的需求、风险、技术、团队成员等。估算挑战可总结为： 可能太乐观或太悲观的极端估算。个人对估算是一种承诺的错误认知。拒绝适应新出现的因素可能影响估算结果。缺乏可为估算结果提供初步基础的专业技能或历史信息。项目范围或业务需求的不确定性。糟糕的风险阻碍计划。无法度量的临时活动，比如会议、假期、演示、原型设计。无法使用更新的工具和流程来跟踪估算。
为了获得此技能，每个人需要知道他们可使用哪些选项。可使用哪些不同的技术和应何时使用它们？本文将介绍各种有助于控制项目和改善决策的估算技术。本文首先会概述一些流行的传统方法，然后展示一些敏捷技术。文章最后将对敏捷开发与传统方法进行总结比较。您还将了解成为更优秀的估算人员所需的一组要素。 传统估算方法 许多项目估算结果是以过去的项目历史或主题专家 (SME) 的专业技能作为指导来建立的。在下一节中，您将学习一些专注于项目之间的相似性的方法。历史信息PROBE（基于代理的估算）此技术是卡耐基梅隆大学的软件工程研究所的 Watts Humphrey 作为
PSP（个体软件过程）的一部分而创建的。它基于的理念是，如果工程师在构建某个类似他以前构建的组件的组件，那么它将花费与过去相同的工作量。在
技术中，一个存储库包含之前构建的每个组件的所有详细信息。然后在需要估算一个新项目时，它会分解为与历史信息匹配的组件。然后使用一个公式来计算每个任务的估算时间。COCOMO II1980 年开发了构造性成本模型 (Constructive Cost Model, COCOMO)。它基于对 63
个软件开发项目的统计调查结果的分析。10 年后，引入了一个名为
的更新版本，该版本涵盖现代开发生命周期并使用了更庞大的数据集。新模型接受一组输入变量，基于以前研究的项目而计算目标估算结果。分组估算 是 1940
年开发的一个流程。它依赖于分组估算，项目经理选择一个调解人和一个估算团队。调解人秉持公正原则来管理会议。调解人还确保每个人都参与。项目经理必须是估算团队的成员，以便团队知道需求的优先级。该流程首先是一个启动大会，团队在其中熟悉项目的目标。会议的输出是一个高级任务列表和一组假设，它们由调解人编写并分发给团队。估算团队的每个成员单独创建一组准备结果，如图
所示，以便为下一次估算会议做准备。始终可以添加更多任务或假设来进一步讨论。在估算会议中，调解人向每个估算人员分配一个空表格。每个估算人员基于他或她的准备结果来填写估算表格。图 1. 准备结果在图 2 中可以看到，每个估算人员将一组任务放入每行中，包含估算表格的相应估算值和假设。然后调解人收集此信息并将它写在第一轮的白板上。图 2. 估算表格图 2. 估算表格估算人员之间的讨论涉及到每个评估人员使用偏差列来调整估算结果。调解人在白板上写下每轮的新估算时间。请注意，在每轮中，估算结果的一致性变得更加接近，如图
3 所示。这符合预期，因为团队成员的观点已被逐渐阐明。图 3. 写在白板上的估算结果估算会议之后，项目经理将所有输出收集到一个表中并列出所有估算结果、最佳场景和最糟场景。标记出较大的估算差异供进一步讨论。项目经理召开最后的评审会议，以便与估算人员分享总结的结果，并允许展开更多讨论或达成一致意见。参数估算参数估算方法使用历史数据和其他参数之间的关系，通过数学公式获得估算结果。一个简单的示例是：如果编写一个方法的估算时间为 2 小时，那么编写 50
个方法将需要 100 小时。本节将介绍不同种类的参数估算。用例点 (UCP)此技术是 1993 年开发的。它基于统一建模语言 (UML) 中使用的用例来估算软件的大小。UCP
估算许多元素，比如用例参与者、技术复杂性和环境复杂性。它然后将它们集中到一个公式中来计算总大小。UCP = (UUCW + UAW) × TCF × ECF公式各部分：UUCW：未调整的用例权重UAW：未调整的参与者权重TCF：技术复杂性因素ECF：环境复杂性因素有关的更多信息，请参阅 。功能点分析 (FPA)作为一个概念，它非常类似于用例点。
个类别中的一个：输出、查询、输入、内部文件和外部接口。然后基于功能的复杂性为其分配一些功能点。使用下面这个数学公式来计算估算结果。FP = UAF × VAF公式各部分：FP：功能点UAF：未调整的功能点VAF：值调整因素有关更多信息，请参阅 。3 点估算此方法使用项目评估和评审技术 (Program Evaluation and Review Technique, PERT)。PERT 技术基于 3
种估算结果来计算估算结果，将输出放在一个数学公式中来进行分析。E = (O + 4M + P) /6公式各部分：E：估算结果O：一种乐观的最佳案例场景P：一种悲观的最糟案例场景M：最可能的场景有关更多信息，请参阅 。敏捷估算方法传统估算方法与敏捷估算方法之间的一个核心区别在相对估算概念的使用上。在敏捷估算中，没有绝对的估算天数或小时数。相反，使用故事点。此做法背后的理由是，许多研究证明人们在估算中使用对比时结果更准确。例如，您可携带两个包，估计一个包比另一个包更重，但您不能确定每个包的实际重量。在以下各节中，您将学习敏捷估算中一些最流行的估算方法。计划扑克 (Planning
poker)计划扑克是最流行的敏捷估算技术之一。它通过玩游戏来保证所有成员都积极参与。该游戏首先给团队的每个成员发一组扑克牌。每组扑克牌包含一个不同的数字，这些数字在很大程度上遵守斐波纳契数列：0、1、1、2、3、5、8、13、21、34
等。在图 4 中可以看到，这些数字表示故事的相对估算值。0 表示故事太繁琐，难以跟踪；20
表示故事需要分解为更小的故事。使用斐波纳契数列的目的是创造一种不确定性，鼓励讨论，尤其是对于大数字。现在返回到游戏中。团队的每个成员开始估算某个故事，然后每个人揭示包含来自他或她的立场的故事估算值的扑克牌。估算出最高和最低值的成员解释他们的参数。这些解释进而使整个团队反思推理过程，然后分享经验和假设。整个团队反复重新评估故事，直到他们达成一致意见。有关更多信息，请参阅
。图 4. 计划扑克牌的示例T 恤码号 (T-shirt sizing)在此方法中，分发一组码号卡片。每个码号卡包含一个特定的码号，它们是：超小号 (XS)；小号 (S)；中号 (M)；大号 (L) 和超大号
(XL)。这些卡片水平分布在桌子上。整个团队合作来将每个故事添加到合适的码号类别下。所有用户故事分类完后，对于每个码号，团队放置一个等效的故事点，如表
1 所示。例如：XS 是 1 个故事点，S 是 2 个故事点，M 是 4 个故事点，依此类推。此方法可确保所有故事都对应于故事点。表 1. T 恤码号与故事点的映射关系T 恤码号 故事点 XS 1 S 2 M 4 L 6 XL 10 类似地，其他方法鼓励使用更有创意且有趣的大小方法。例如，使用狗的重量，其中吉娃娃是最轻的，大丹狗是最重的。另一种方法使用动物体形，其中老鼠是最小的，大象是最大的。估算大量故事如果您需要快速估算大量故事，该怎么办？在这种情况下，使用。该方法生成一种快速方式来分类和估算大量积压的故事。要使用此方法，您需要每个故事都有一张卡。对于桌面上的一组故事卡，调解人挑选一张卡片并问团队，“这个故事被视为大、中还是小？”依赖于团队的答案，将该卡片放在桌面上的特定位置。如果它很大，则放在桌面上的左侧。如果它很小，则放在桌面上的右侧。如果它是中型的，则放在桌面上的中央。转到下一张卡片，问同样的问题并相对于之前的故事卡来放置新故事卡。这个过程持续到所有故事都排列在桌面上。另一种旨在快速估算大量积压故事的类似方法称为 。此方法使用一面很大的空墙来排列故事。顶部的故事表示最高优先级，而底部的故事表示较低优先级。也可以在墙上水平排列来确定故事大小。左侧的故事最小，而右侧的故事最大。敏捷方法与传统方法中的估算结果的比较大家首先想到的一些问题是，“我应该使用哪种方法？” 和
“哪种方法最好？”这是一个值得商榷的问题，实际上没有正确的答案。本领域有许多研究证明，正确答案依赖于许多因素，比如项目的类型。这些因素如表 2
所示。表 2. 敏捷方法与传统方法之间的对比矩阵敏捷方法传统方法项目大小中小型项目 大型项目 软件生命周期敏捷生命周期。例如，极限编程 (XP) 和 scrum 传统生命周期。例如，瀑布和螺旋式 估算团队大小通常在 5 到 9 之间。 可以小于 5。在主题专家情况中，它可能是一个成员。 团队协作 所有团队成员（比如产品所有者、开发团队、测试团队）积极参与。 不是所有方法都鼓励所有团队成员参与。 历史信息估算方法没有强制要求存在历史信息。 大部分方法都依赖于历史信息。 估算时间可能花更长时间，因为它是以对估算结果达成共识为基础的。 可能比敏捷方法所花时间更短。 点值系统 点值的复杂性。例如，故事点大小。 参数点。例如，功能点分析和用例点。 估算原则相对估算。 绝对估算。 更有效的估算的要素建立良好的估算结果，对促进项目成功不可或缺。估算是计划的最重要元素之一。估算结果越好，对交付结果的控制就越好，浪费的成本就越少。那么您如何度量估算结果好不好？比较估算值与之际值之间的差异。根据定义，良好的估算值
75% 的时间在实际结果的 25% 以内（Conte、Dunsmore 和
Shen，1986）。无论您选择采用哪种估算技术，都有一些要素肯定能让结果更好。对估算技术的认知。您需要熟悉所有估算方法，才能知道哪种方法最适合您的项目。使用小任务单元。您将任务分解为越小的部分，您越能了解完成任务需要多长时间。通常，任务的估算完成时间应在实际完成时间的
2 天内。团队合作。让整个团队参与估算，可消除对任务的任何模糊理解。它有助于交换信息和专业技能，进而获得更好的估算结果。它还会改善估算结果和任务的所有权。询问正确的问题。每个任务都包含模糊性。您需要询问正确的问题，然后尝试找到答案，以消除模糊性。抛开假设，以便对任务边界和风险达成共识。记录您的实际工作。从以前的估算结果中学习无疑会带来增值。您需要记录实际的估算结果以作为历史参考数据。结束语要成为更优秀的估算人员，需要理解和探索不同的估算技术。一定要知道可用的选项，以及哪个选项满足您项目的需求。本文提供了敏捷和传统方法中的丰富的估算技术。文中提供了充分的信息来帮助您理解基础知识和熟悉每种技术。比较敏捷与传统方法的矩阵有助于您决定使用哪种方法。借助一般建议和技术概述，您将会成为更优秀的估算人员。致谢感谢 Amr Yassin、Michael Schenk 和 Sally Fikry 审阅本文并提供反馈。很高兴与他们共事。
参考资料 使用 COCOMO II 估算软件成本，Barry Boehm
等（Prentice Hall PTR，2000 年）传统和敏捷方法中的工作量估算模型分析，Manjula, R. 和
R. Thirumalai Selvi“软件开发项目中的传统和敏捷成本估算成功因素分析”，Mansor、Zulkefli、Saadiah Yahya 和 Noor Habibah Hj
Arshad。(International Journal of New Computer Architectures and
their Applications (IJNCAA) 1.4 (2)“敏捷和传统软件开发方法之间的比较，Awad 和 M.
A.，（西澳大学，2005 年）敏捷估算和规划，Cohn 和 Mike。（Pearson
Education，2005 年）
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
免费下载、试用软件产品，构建应用并提升技能。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=DevOps, RationalArticleID=1012621ArticleTitle=您项目的最佳估算方法是敏捷方法还是传统方法？publish-date=