对于估算，团队经常会有这样的疑惑:估算要花很多时间，但最后发现估算和具体还是有很大的误差。有必要做估算吗？怎么做？
俗话说的好，一百里走一半九十，也就是说一百里距离前面的九十实际上只走了一半，剩下的十里还得走非常长的时间。那么，在我们的日常生活和工作中，是不是经常会遇到这样的情况呢？回想一下是否会有这样的经历:打扫卫生，把房子收拾干净整洁只需要20%的勤奋，但是把房子收拾干净整洁一尘不染需要80%的勤奋。那么大家需要思考的是，从干净整洁到一尘不染的整个过程中是否需要有木材，房子从凌乱到干净整洁是否足够。我想没有mysophobia的普通人和我一样，会觉得后面的全程高性价比真的太低了，完全没有必要。
转过身来，看看我们在新项目中的估算还能不能比。从没有估算到估算，实际上花费的精力是比较有限的，但是从估算到追求完美的“精确”估算是一个漫长的过程，而且有数据信息显示信息。每个人都不容易得到需要一些时间的估算数据信息和需要很多时间才能得到的结果。在《敏捷估算和规划》一书中提到，在可能的准确性和投入的劳动力数量之间存在以下相关性:
所以在进行估算的时候，不需要期待准确性，也没有办法让每个人都保证准确性。估算只是估算，只要尽可能有效，尽可能接近真实值。
估算企业的挑选有些团队在估算之初通常会担心如何选择估算公司，因为有效的选择是风险估算成功的首要条件。那么如何选择呢？
理想人日理想人日是指成员在不受影响的情况下，花费全部时间开发一个需求的天数。
理想工日的缺点取决于:工作组成员对技术和新项目的熟悉程度，以及本人工作经验和工作能力的差异，都会导致基于理想工日的估算值存在一定差异。比如你问一个擅长C语言的成员，用java开发一个理想的人的一天，他可能会告诉你是5天。但是如果你问一个擅长java的成员同样的问题，他的回答可能是一天。这样的差异会导致人们对日常任务规模的理解出现误差，难以考虑新项目的具体“规模”。而它的优势在于:对于团队之外的人来说，理想的人日要容易理解得多，不需要表达出来。对于团队来说，这样更容易估计。
理想人时理想时间的存在与理想时间相匹配，但其粒度分布较小。等你熟悉了需求，用理想人时间会更准确。想象一下，给你一个估计，在接下来的一个小时里你能完成多少工作目标，第二天你能完成多少日常任务。哪个会更贴近具体情况？我觉得应该是前一种。由于一天可以完成的工作量，每个人都必须去掉很多“琐事”(比如喝水、尿尿、和朋友聊天、戳网页等。)来估算纯工作的时间，这通常很难，会有一些误差。但是估计你在接下来的一个小时里能做什么应该是非常容易的。理想工时估算的优势在于:在充分理解需求的情况下，可以帮助团队保证估算更接近真实值。但缺点是对于一些大的需求，这样的粗粒度是无法保证的。
小故事点小故事点来自于灵巧的定义，日常任务管理尺度的可能性，是一个相对的定义。比如要求X有四个小故事点，要求Y有八个小故事点，这意味着Y的业务规模是X的两倍，但并不意味着开发Y的时间是它的两倍，因为还是由技术娴熟的技术英雄开发的。小故事点的优势在于:一方面，基于小故事点的估算更纯粹，不容易因为开发人员和时间的变化而改变。也就是说，在一个新项目进行到一半的时候，有成员辞职，有新成员加入。这时候你不用再让每一个日常任务都成为可能，只需要再评估一遍，是否有一个小故事的关卡必须调整插入到今天的迭代更新中。另一方面，因为人们通常更擅长相对估计，小故事点会使估计更快。试想一下，估算一杯水是另一杯水的几倍，会比估算每两杯水每毫升多少钱容易得多吗？劣势取决于:一方面，由于计算机语言或层次业务流程不同，大家很难找到一个熟悉的需求作为标准，所以很难用小故事点作为估算企业的方法。另一方面，小故事点的相对性相对于其他估算公司难以理解，也导致估算无从下手。
估算的几类常见方法自底向上的估算每个开发人员估算自己的任务时间，然后汇总所有的日常任务，在考虑到日常任务的相互依赖性后，拟定一个计划。这种方法适用于具有以下特征的团队:成员业务流程意识强，对彼此业务流程的熟悉程度不太高且熟悉成本很高，难以进行相互估计；每个成员的工作经验都比较丰富多彩，对自己的日常任务都能做出很好的评价。
在这样的团队中应用这种评估方法有以下优点:
估算高效率较高，分别每日任务的估算能够并行处理。精确度也会较高，由于对分别的每日任务较为熟悉。权威专家分辨一个或几个权威专家可以根据相对的开发情况得出日常任务的预估值，但前提条件是你能找到这样一个熟悉所有业务流程和所有新项目组成员的权威专家或专家组。在边肖的团队中，开发负责人通常以这样的角色出现。
它的好处不言而喻:
一般不用过多的時间，一个人估算就不会有过多的沟通交流成本费。精确度也是有一定的确保。乃至有直接证据说这类估算方式比别的的剖析性方法更精确。扑克牌估算就是以扑克游戏的形式进行团队估算。在评估开始之前，每个评估者都会得到一叠扑克游戏，每个游戏都有一个分数，比如0，1，2，3，5，8...然后，负责人将解释必须评估的需求或日常任务。在解释之后，任何人都可以向负责人询问关于该需求或日常任务的问题，直到他们有足够的知识来做出估计。所有成员分别选择一个扑克游戏，代表自己对这个物品的估计。比如A得到8，而B只给出2，那么A和B必须得到原因来表明自己估计的原因。那一轮大家对内容的掌握程度都有所提高，然后进行第二轮估算。如果距离仍然很大，将再次进行下一轮。大多数情况下，最多两轮，大家的估计已经很接近了，可以取平均值作为内容的最终估计。
扑克牌的估计收益取决于:
结合了全部团队成员的建议，比一个人的估算少了许多主观性成份；次之，在估算全过程中，加强和深层次了大伙儿对要求和每日任务的了解，将其考虑到地更为细腻，减少了可变性给方案产生的冲击性；最终，这类方式使相对性严肃认真的方案和估算会越来越更为趣味。可是迫不得已认可，这必须比前二种方法大量的经济成本。具体运用中的估算团队1构成：4人团队（三人开发，1人检测）。现况：团队平稳协作近2年，试着灵巧一年多，开发語言统一，成员间对互相的业务流程也都较为熟悉。估算的企业和方法:因为非常容易找到一个熟悉的用户故事作为标准，所以在这个阶段，团队正在使用基于小故事点的扑克牌估算。团队经过几次迭代，大部分都知道团队的开发速度(每次迭代可以进行的小故事的水平)。在接下来的迭代更新中，团队根据扑克牌估算确定每个客户故事的故事点，然后根据用户故事的优先级逐一插入迭代更新开发计划中，直到无法再进行服务承诺。
团队2构成：9人团队（7人开发，两人检测）现况：团队建立不上3个月，开发語言不统一，成员较为年青，系统对的熟悉水平都不高。估算的企业和方法:一方面，由于成员对业务流程不熟悉，开发语言不统一，团队不能随便找一个合适的标准用户故事，所以团队的估算是基于理想的人。另一方面，由于开发人员众多，部分成员缺乏工作经验，团队无法很好地进行团队估算。因此，在这一阶段，团队选择权威专家进行区分(发展领导者以获得估计)作为执行方案的主导方法。
团队3构成：13人团队（9人开发，4人检测，两人运维管理）现况：团队建立约一年多，商品控制模块较多，不一样控制模块有不一样的责任人，成员对自身控制模块的领域模型非常清楚，可是对别的控制模块的业务流程掌握很少。估算的企业和方法:由于成员之间对业务流程的熟悉程度不高，开发语言不统一，团队找不到合适的标准故事点，所以团队选择理想的工日作为估算企业。另一方面，因为控制模块很多，开发负责人不可能熟悉各种领域模型，所以团队选择了自底向上的估算方法。成员们分别估算自己的日常任务，然后得出发展计划。
团队4构成：4人团队（三人开发，1人检测）现况：团队建立2年多，商品早已处在成熟，现阶段绝大多数工作中处在查缺补漏的环节。各成员一种对自身负责的行为的一部分较为熟练。新项目选用1周的短迭代更新方式。企业和估算时间:由于迭代更新时间短，团队成员对自己的行业熟练，所以可以保证按照理想工时自下而上的估算，估算误差一般较小。
根据以上诸多例子，边肖想说明的是，各种估算企业与估算时间本身之间没有优劣之分，只有适合与不适合。每个团队必须根据新项目的现状选择其成员。如果剧本总是达不到成功，那就是因小失大。
有关估算，大家务必搞清楚我们要了解，估算只是是一个预测分析，当对外开放服务承诺新项目进行時间的情况下，最好是出示一个日期范畴，让闻者了解你的估算仅仅估算；无论是用哪种估算方式，更一小块的工作中一直更非常容易被可能；团队必须训练估算而且搜集意见反馈，沒有意见反馈的估算最后将被证实是毫无用处的。每一次估算相匹配的开发完毕后，大伙儿必须转过头看一下大家当时做的估算是不是有效；估算或许必须不断开展，当新项目开展到一半时，发觉估算过度开朗了，那麼就必须对剩余的工作中开展再次的估算。创作者:何燕华，网易游戏杰出项目经理，PMP，CSM。反过来，在网易游戏私有云存储、网易游戏个人中心、网易游戏GACHA、网易游戏LOFTER等新项目从事项目风险管理时，积累了丰富多彩的项目风险管理社会经验，并自始至终关注新项目的成功交付和团队身心的健康发展趋势。网易一千零一夜的主创之一。
文章内容创作者为@网易游戏航研项目风险管理(微信公众平台:NetEasePM)，未经批准严禁拦截。
注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）