BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Michael Floyd 关注 0 他的粉丝 ,译者 姚九强 关注 0 他的粉丝 发布于 2011年11月11日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT