文章

使用估算扑克做工作量的估算

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

Scrum中文网微信号:Scrum_CN

scrumcnweixin

使用估算扑克来做工作量估算是最有效,也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成,这些数字包括: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估算。

Scrum中的工作量估算

当我们提起工作量估算的时候,我们会碰到同样的问题,我们如何来做估算?有什么方法可以遵循呢?如何估算才更准确?我对某个功能做了估算,但它超出了预计的开发时间,为什么?

Scrum团队已经做了很严肃的承诺去完成开发工作(可以交付的产品),必须要深思熟虑才可能成功。成功的工作里昂估算的几个步骤:

估算每个团队成员有多少时间可以在Sprint中被使用:

估算每一个团队成员在当前的Sprint中有多少时间可以被使用时Sprint计划会议的一个非常非常重要的部分。需要注意的是如果一个开发人员估算一个任务8小时可以完成,这个并不等于他一天可以做完。事实上,没有人会做在座位上一动不动,工作8个小时,参加会议的时间,午饭时间,意外的打断,看email, 接听电话等等都要考虑进去。

刚刚开始实践Scrum的人经常会问“是否需要预留一些时间来做bug修改?”。我当然不会准备两个Sprint,一个用来做产品backlog的开发,一个做bug修改。bug修改的时间应该是每天例行的时间,也就是说这是我们每天例行工作的一部分,扣除这些例行的时间,剩下的才是你可以承诺给Sprint的时间。1. 估算每个成员有多少时间花在和Sprint相关的工作上。

Sprint可用的工作时间= 平均日工作时间 – 其他活动.
平均日工作时间 = e.g. 8 hours
其他活动: = e.g. 4 hours
Emails and Phone : 1 Hrs
午饭: 1 Hrs
读Blogs/bbs : 0.5 Hrs
Bug fixes : 1.5 hrs
Sprint可用的工作时间= 4 hours

为产品Backlog中的每个项目估算工作量: 

有完成过类似工作经验的人来做相关的估算会更好一些,有历史数据可供参考。最好是让相关的有类似工作经验的人参与进来做适当的估算。经过几个Sprint之后,团队成员就会找准自己的位置,知道自己可完成多少工作。这也会使估算更为准确一些。

2. 所有的团队成员都要参与工作量估算的游戏。

3. 从Product Backlog中挑出排列好优先级的项目,要能够完全理解它,知道应该做什么,有哪些依赖、复杂度,风险等。如果需要的话让Product Owner做相关的澄清。
4. 细化理解后的项目为2-16 h/m工作量的小任务。

5. 为每个小的任务估算时间.

关于工作量估算的一些注意点:
1.一旦已经承诺要递交的Sprint的工作任务,团队成员不应该在受到外界的干扰,比如指派新的工作任务,或改变工作任务等。

2. 余下的工作将被移动到下个Sprint中。
3. 为了达到目标,团队必须是自我组织,并且团队成员之间是透明的。

故事点是工作量,而非复杂度

是工作量,而不是复杂度
有个客户问我,“我的团队什么时候才能完成这个项目?”我已经被问过千百次类似的敏捷项目管理问题了。
但却从来没人问过我,“开发这个项目我的团队要费多少工作量去进行思考?”
客户,老板,顾客以及干系人只会关心一个产品要耗时多久,却不会去理会要交付该产品我们得多么殚精竭虑地思考,除非这些必要性的思考会带来时间或成本风险。 Read more

敏捷的心跳

一直以来,如何在Scrum中预测团队可以在一个Sprint交付的工作量都是一项挑战。很多人把一定的工作量定义为一个故事点来尝试建立一个基 准,而没有留意团队的实际工作方式。例如,有些团队把对一个有8个字段的数据表的CRUD操作定义为一个故事点数。这种方法实际上是行不通的,因为团队里 面的每个人都有不同的经验、专长和特质。每个团队都拥有自己的特质,每个团队完成同一项任务所需要的时间也不一样,所遇到的困难也不尽相同。总而言之,对 于一个由人类组成的团体而言,也许会有生产效率的统计标准,但是永远不会有可预测的而且精确的工业标准。这个时候,我们所面临的问题是:是制定一个计划, 然后为了合同或者公司利益按照计划勇往直前,还是先制定一个目标,然后一直跟踪团队的效率成长来不断调整项目计划,为团队创造良好而且高效的工作环境,最 终令客户满意更好? Read more