收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
302 Found

302 Found


nginx/1.11.3
302 Found

302 Found


nginx/1.11.3
302 Found

302 Found


nginx/1.11.3
积木资讯 > 技术前沿 > 正文

工作时间打扑克?--谈谈扑克估算

来源:本站原创 日期:2012-12-05 14:11

不知道是不是因为勾起了大家的牌瘾,最近一阵"扑克"估算很是火了一把,在几个项目尝试后很快蔓延开来,很多项目团队都跃跃欲试。

尝试的过程中难免产生一些困惑,干脆在这里做个澄清,把我实践下来所理解的扑克估算的方方面面跟大家一一道来。

 

在开始之前,首先需要澄清的是,在某种程度上,估算其实是在预测未来!

预测未来是件非常难的事情,我们看看天气预报,就知道人类在这项工作上有多么滴不靠谱了。

 

为什么要做估算?

估算本身很困难,而花在估算活动本身上的时间,又并不能够对产品本身产生直接的价值,那么为什么我们要花时间做估算呢?为什么气象中心还是坚持不懈的发放自己的预报呢?

首先,用户需要一个预期,甚至是承诺,这个功能什么时候能够提供。

其次,管理层需要可预测性,某些决策需要基于估算而做出,即便这个估算还不那么准确,但总是聊胜于无。

最后,团队需要了解如何相互协作,在哪个时间点能够拿到我所需要的接口或素材,据此相应的规划并安排自己的工作。

总之,估算可以帮助我们找到一个合理的计划,给用户、管理层、以及团队自己一个稳定的预期。

 

为什么选择相对估算?

传 统的估算方法,通常是基于人天/小时的绝对估算。而敏捷中所推荐的扑克估算方法,则是基于故事点的相对估算。这种估算一上来容易让人找不着北,大家会习惯 性的问:“那这个故事点到底代表什么?单位是什么?做完了相对估算是不是还要再转化为人天?与人天的对应关系又是什么?”

讲清楚这一系列的问题,我们需要先搞清楚,为什么选择相对估算。相对估算有哪些好处呢?

首 先,相对估算更符合人的本能认知。电脑区别与人脑的一大特点,就是电脑更擅长计算与处理绝对信息,而人脑则对相对印象更有感觉。我们可能永远搞不清楚手上 的核桃和苹果的真实重量,但却能很直观的判断出苹果更重,重量嘛,大概相当于“6个核桃”。瞧,这就是人类的本能认知。

其次,正是因为 相对估算更符合人的本能认知,因此掌握之后,它能让估算过程变得更快更简单。因为我们不再需要纠结于这个任务到底需要5天还是4.5天,我们只需要为手头 的工作定义一个参照物(“一个核桃”)作为基准,然后拿其他的工作与之相比较,工作量是更大了还是更小,复杂度是更高还是更低,然后给出一个大约的倍数值 就done了。

 

相对估算需要转化为人天吗?

在实施scrum的项目团队中,最后得出的故事点的数值,不需要再转化成人天,这是由scrum的特性所决定的。

在 scrum项目中,我们会以sprint为周期来做增量交付,这直接改变了做计划的方式。传统项目中,我们需要根据基于人天的估算来确定各节点及最终发布 的日期到底是几号;而在scrum项目中,周期是事先约定好的,每个sprint的计划不需要确定日期,而只需要估算下一个sprint我们能完成多少工 作。由于sprint固定周期性的特点,在几个sprin t之后,我们就会得出一组相对数据(比如35个story points),来衡量团队的生产效率。根据这个生产率,我们可以很容易的快速进行相对估算,不需要转化为具体人天就能得出结论。

当然,如果你是第一个sprint,没有经验数据的情况下,可以尝试转化为人天找找感觉,或是直接根据团队的直觉来做出判断。

如果你是在传统项目中做扑克估算,那么我的建议是可以直接用人天来进行估算,虽然不如相对估算那么便利,但至少还是获得以下的好处。

 

如何进行扑克估算?

在以下的这篇文章中,配合实例有非常形象的说明,在此就不再赘述了。

Scrum实践系列之一:工作时间打扑克?--谈谈扑克估算 - PM长成记 - PM长成记

http://www.uml.org.cn/SoftWareProcess/201108264.asp


扑克估算有什么好处?

  • 团队一起做估算,估算更全面细致

传统的项目管理中我们也会做估算,WBS分解后完成任务分配,然后每个人估算自己的,如果每个人只对自己的那块比较熟悉的话,估算结果往往会有欠考虑,特别是针对相关性较强的模块,会出现较大误差,从而为项目后期埋下潜在风险。

在 扑克估算时,一开始我们特意不进行任务的分配,对于每一个故事,都会由全员出牌,包括各个模块的开发及测试,每个人从自己角度出发想问题,互相补充。比如 在扑克估算时,测试的成本会被自然地考虑进去,作为一个整体来衡量,对于测试成本高的story,大家会一同来考虑进行哪个层级的测试会更为合适,单元测 试?API测试?还是UI测试。这样涵盖了各方成本的估算结果自然会更全面、更细致。

  • 团队一起做估算,需求探索更深入

实践中我们会发现,真正到了让你给出预估的时候,就会有各种各样的问题冒出来。这个需求到底要不要做这个,是否要满足那个条件,等等,扑克估算让这个需求探索的过程公开化,通过公开的讨论在早期进一步挖掘和明确需求,帮助我们将需求探索进行的更为深入。

  • 团队一起做估算,有助于优化解决方案

大家在一起亮牌,经常会有不一致的情况出现,比如一个人出5,另外一个出40,这个时候往往是团队成员间交流解决方案的好时机。问问你的团队,为什么相差这么远,这样的讨论能够帮助大家找出最优的解决方案,并在团队中迅速共享。

 

估算!=承诺

最 后,区分估算与承诺是非常有必要的。我们经常会将估算的结果等同为一项承诺,然后用这个承诺来要求团队的行为。因为估算与实际不符,就进行惩罚或计入考 核,这种做法忽略了估算在本质上的困难,未免太过于简单粗暴。在某些重要的场景下,如果你需要一个确切的承诺,那么请允许你的团队花更多的成本来进行精确 估算,并且允许他们留一定量的buffer来应对估算误差,是更为合理的做法。

 

以上就是目前我对于估算这个话题的简单认识,希望对各位看客们有所帮助~

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号