分享到
关于Scrum中sprint的规模估算的对话
 

作者:zhangmike,发布于2011-12-2

 

Chen:

您好,我看了您些的关于Scrum sprint plan中规模估算的一篇文章(http://blog.csdn.net/zhangmike/article/details/6980334),觉得梳理和总结的比较好。

在我所服务的公司中,也在大力倡导Scrum模式下的敏捷开发;基于我个人的感受,在sprint plan时,对于得到一个满意的estimation,觉得有些纠结。

我们现在采用的是基于历史数据作估算,对于前面几个iteration的相应规模如果有较大的起伏,我们采取了一种取历史上多个iteration规模取移动平均值的做法。

我注意到你在文中提到,资源利用率通常是在75%,对应的velocity似乎是6,我想这是个比较理想的利用率。在我所在的scrum team中,team size是4, 但是资源利用率看起来似乎是56%左右,velocity相当于是 4.5个 ideal person-hour每工作日。

在如何看待这些metrics指标的事情上,我个人觉得脱离应用场景单看指标的做法没有太好的指导意义,就如同挣值算法中的cpi/spi。而实际我们尝试提高velocity的时候,可能会导致最终在task估算时候,task规模估算结果难免掺水;最终velocity上去了,但是生产率实际没有提高。同时团队成员也不大情愿做这样的事情,毕竟他们在这样的模式下已经工作了很久(不否认他们的productivity,team size小,近距离的观察表明了没有明显损失效率的工作习惯)

在遇到此类两难问题时,我首先的立场是尽管velocity是4.5这个较低的水准,但是由于团队对task的估算结果使用了”干货策略“,而且即便如此也存在偶尔加班的情况,所以实际的生产率不会是4.5所体现出来的这么低;但是另一方面,4.5这个velocity在向PMO做汇报的时候,往往容易引起误解。

不为提高velocity而提高velocity,毕竟目标是提高productivity。不过就上述情形而言,我们的项目组织和流程上,是不是也存在一些问题? 我们现在用的是hours-burndown, 最近在看story point方面的内容,在这方面是否能够找到改进机会呢?

最后,稍微表达一下歉意,在邮件中串了不少英文单词,可能是因为习惯,很多时候觉得英文单词的意思会更准确些。期待你的答复,祝工作顺利!

Zhang:请问你们用什么来表示sprint的规模? 是用理想人天吧,还是用户故事点数?

由于Scrum/Agile中的不少词没有确切的中文,只能夹杂E文。

Chen:我们采用了理想人天的方式,例如velocity是4.5,

表示一个工作日相当于是 0.56 个理想人天 ( 4.5/8), 以一个sprint两周来计算的话,sprint规模的计算公式是: velocity * 项目人员数量 * 10个工作日 , 这里的数量单位是: 人-小时数

由于现在的项目进度每日进度跟踪现在非常依赖于 JIRA,而JIRA目前只提供了hour-burndown, 所以故事点数暂时没有推行。

Zhang:敏捷是基于信任的,秉承的是Y假设。

敏捷本身不鼓励外面给团队设定velocity要求。

采用理想人天后,在技术手段上就更加没有特别好的手段来从外面给团队设定velocity要求。

什么算一个理想人天,由于处理的事情多种多样,是很难归纳的,我猜想你们也许没有一个恰当的定义。

我想推荐给你们的是 积累典型样例(不知道你们是否已经这么做了?)。 什么样的典型事务 算1个理想人天,什么样的算5IMD。

有了这些积累后,理想人天就相对客观。

当然这些积累不是不变的,随着时间推移要变的,否则可能会出现资源利用率大于 100%的事情来,这个解释起来更麻烦。

团队有了相当比较客观的基础后,就可以在样例和数字上做文章了。

以上也许只是数字的提高,真实的提高是要靠真正提升团队的能力、热情和氛围,敏捷团队建设不是个快速过程,不能照着某些敏捷文章描绘的美妙场景马上推进,小心敏捷的乌托邦。

如果采用Story point 或者 UCP,那么在技术手段上 会比IMD要多一些方法。你们可以看下。

但是不会改变敏捷的本质,如果你们开发团队认为IMD用得不错,只是PMO有点意见,那就没有必要改。

对付PMO,相信你有很多办法:)

Chen:谢谢您的答复,我得到了很多启发 :) 相信我已经得到一个比较合适的思路和方向

Zhang:能告诉我 你的思路和方向吗?

另, 可以把 你的问题和我的回答 放在我的blog上公开吗?

Chen:完全没有问题,我觉得把这个thread放到blog上,

能够获得更大范围的知识讨论和共享,对于各方来说都是件非常有益的事情。

关于思路和方向,在那个时间我当时的想法是针对于PMO的问题,我大致上可以有一些合理分析:首先是以什么样的标准,来界定日常工作中的某个时间是划分到ideal时间内,例如各个team是否统一这样的一个共识,这样横向比较的结果才更加客观。(例如A team,对于research的讨论,不认为是ideal hour, 而B team则划归为ideal hour,这样比较A和B的velocity,自然是不够客观。)基本上我认为这是个PMO需要澄清的问题。

现在我在想法上,更好的思路可能应该是,PMO提供支持和帮助,而对于上面提到的ideal标准问题,尽量避免尝试推行一个“放之四海而皆准”一个客观标准,因为这毕竟有X假设的倾向,而且不利于Scrum团队的自组织,但是可以推行一个参考而非强制的标准。

没有观察就没有发言权,如果你(PMO)有质疑,那么欢迎你抽出一些时间,作为chicken角色和观察者,抽出一些时间来参与并帮助我们分析和改进实际的生产力;如果只是要velocity的report好看,这个通过投巧的办法,实在是太容易做到了。

Zhang:PMO的X假设倾向 在有些组织里得到更高层领导的支持。

而且在以PMBOK为代表的项目管理理论上,并不排除X假设,并不全盘采用Y假设。感觉在PMBOK中,秉承的是中庸之道,XY各占一半。

PMO的X假设倾向做法虽然跟敏捷方法有抵触,但从公司级管理看,不会没有道理。敏捷的项目团队需要适应这种环境。如果一味的强调"团队决策自组织",而与公司级管理措施抵触,我以为是没有必要的。


 
相关文章

由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
 
相关文档

统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
 
相关课程

IT安全原理、框架与实践
ITIL认证
ITIL Foundation认证培训(ITIL V3 Foundation )
IT规划体系与实践
 
分享到
 
 
     

相关文章
由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   

相关培训课程
统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

成功案例
某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号