注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

世界的瞭望哨

认识自己 认识世界

 
 
 

日志

 
 

Zz 开发速度正在杀死敏捷吗?  

2011-11-27 16:14:26|  分类: 敏捷 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
原文传送门:http://www.infoq.com/cn/news/2011/11/velocity-highsmith

作者 Michael Floyd 译者 姚九强 发布于 2011年11月10日

领域
过程 & 实践
主题
企业级敏捷 ,
敏捷技术 ,
敏捷实施 ,
敏捷
标签
生产力 ,
Velocity ,
敏捷估算 ,
持续改进 ,
持续交付

敏捷宣言的签署者之一,Jim Highsmith在他最近的博客“开发速度正在杀死敏捷”中描绘了对开发速度“饥渴”的经理会用开发速度作为生产率的衡量指标。他写道:“……他们通常狂热的衡量开发速度——团队开发速度、不同团队间开发速度的比较、组织级的开发速度、甚至是每个开发人员的开发速度(呸!)”

Highsmith指出开发速度正被越来越多的用来衡量生产率。原因显而易见。任何衡量生产率的方法,可以帮助你了解什么方法有效、什么方法无效, 以便调整。而且,开发速度数据容易获得、便于计算并被视为是大量输出的计量结果。但Highsmith警告说,这种度量太过关注交付故事点的数量。“这个 数量降低了交付的客户体验的质量”,并在他所谓的“交付引擎”上投入过多。

让问题更加复杂的是,敏捷运动专注于高度客户参与——总的来说这是好事——但我们走得太远了。很多“敏捷主义者”公开抱怨他们不 能让组织专注于技术实践——但为什么我们鼓励产品经理对优先级做出决定,然后当他们用速度来衡量工作情况时,而大吃一惊呢?在传统方法中,我们太过缺少客 户参与——从而赋予产品经理安排优先级的控制权。

Highsmith不是第一个质疑敏捷实践中开发速度的用法的人。Mark Levison在他去年的博客文章“敏捷项目中开发速度的误用”中,他定义了开发速度是团队完成的工作量除以完成时间。他写道“工作量通常以故事点数(一个相对大小的数量)计算。”

Levison谈论了用开发速度比较两个团队的生产力。但Levison指出:

敏捷/Scrum团队使用相对大小的估算(比如,这个用户故事/功能是大于还是小于我们的“基准”用户故事?),而不是像传统方 法中的绝对大小估算。互相比较、标杆对照、或者任何比较开发速度的尝试时,都会遇到这个问题:我的故事点数 ≠ 你的故事点数,因为不同的项目采用了不同的基准用户故事。不同的项目的问题域不一样,项目成员也不一样。

Scott Ambler也在几年前写过有关“在不同团队间比较开发速度的危险”这一主题的文章,他建议不要计算每个团队的加速度。Ambler认为,这种做法的优势在于:容易计算、易于自动化并难于博弈。缺点是,这种度量是间接的,很大程度上依赖于Ambler称之为的“捏造因数”。

可能是Highsmith标题党了,他和Levison都不是说开发速度是完全邪恶的。Highsmith写道,“开发速度的正确用法是一个校准工 具,是一种有助于做基于能力的计划的方法”,Levison说,“开发速度和发布计划的真正价值在于让产品经理清楚在下个发布时能得到什么。”

查看英文原文:Is Velocity Killing Agile?

  评论这张
 
阅读(200)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018