Scott W. Ambler 是一名知名作者兼咨询顾问。自 2007 年以来,他每年做一次分析 IT 项目成功率的调查。近日,他公布了 2011 年度的所有调查回卷及他的分析方法,别人也可根据这些内容做自己的分析。
他在一篇题为“ IT 项目太成功了,是真的吗?”的 Dr Dobbs 文章中总结了 2011 年度的调查结果。
他分析了“开发模式”对项目产出的影响,希望找出最佳方法。他如下描述了以下 5 种方法:
在一个临时(ad hoc)软件开发项目中,团队不遵循任何流程。
在迭代软件开发项目中,团队遵循的流程被分成几个连续阶段,这些阶段被称为一次迭代或时间框。在项目中的任一天,团队成员都可能在收集需求、做设计、编码或测试。这种迭代流程的一个实例是 RUP。
在敏捷开发项目中,团队遵循迭代流程,但该流程是轻量级、高度协作、自组织、以质量为重的。该模式的一个示例是 OpenUP、Scrum 或 XP。
在传统软件开发项目中,团队遵循阶段式流程。在该流程中,首先是明确需求,接下来定义架构和设计,然后是编码,再然后是测试和部署。传统流程通常指的是“瀑布”或“顺序”流程。
精益是一种给以客户价值为中心的 mindset 或哲学方法打上的标签。精益流程不停地尽力为最终用户带来最大价值,同时尽可能地降低时间、质量和成本的浪费。最后,精益过程转变成精益组织的发展过程。精益方法 / 流程的示例有 Kanban 和 Scrumban。
在分析调查结果时,他对成功项目、问题项目和失败项目做出如下定义:
在此调查中,项目的成功程度定义如下:交付的解决方案符合组织验收标准的项目是成功项目;若只交付了解决方案,但是未能符合客户验收标准(例如,质量尚可,也按时完成,但是 ROI 太低)的项目称为问题项目。如果项目团队连解决方案都未能交付,则称为失败项目。在将来的调查中,我会重新定义失败项目,将那些由所有干系人达成一致的情况下取消的项目排除出去。
根据以上定义,他发现如下结果:
- 迭代和敏捷方法得到的统计结果几乎一样。迭代式项目中,69% 是成功项目,25% 是问题项目;而敏捷项目有 67% 的成功项目和 27% 的问题项目。
- 传统和 ad hoc 团队得到统计结果也很相似,但是低于敏捷和迭代团队的成功率。传统团队有 50% 的成功项目和 36% 的问题项目,而 ad hoc 团队的相应数值则是 49% 和 38%。
- 62% 的精益项目是成功的,而 30% 的有问题的,成功率位于上述两组数据之间。
本文进一步分析了促使项目成功的各种因素以及使用方法之间的关系。他将成功看成一个多维度的结构体:
- 时间 / 进度计划:20% 的人倾向于按进度计划来交付,而 26% 的人则倾向于在系统可交付时交付,而 51% 的人认为二者的重要性相当。
- 投资回报(ROI):15% 的人倾向于在预算范围内交付,60% 的人侧重于产生较好的投资回报,而 25% 的人认为二者同等重要。
- 干系人价值:4% 的人倾向于根据需求说明书建设系统,而 80% 的倾向于满足干系人的实际需求,而 16% 的人认为二者同等重要。
- 质量:4% 的人倾向于按时按预算交付,57% 的人倾向于交付高质量且易于维护的系统,而 49% 的人认为二者一样重要。
他比较了每种尺度对开发方法带来的产出,最后得出如下结论:
调查再次显示敏捷和迭代软件开发方法优于传统方法和 ad hoc 方法。这与此前的调查结果保持一致,也一定程度上地解释了 IT 社区向敏捷方法 / 战略发展的现象。
Ambler 绝不是唯一做此类调查的咨询顾问。人们最常引用的是 Standish Group Chaos Survey ,它将项目成功与按质量、按预算和按范围见的关系定义的更为严格。Standish 的最新的报告发布于 2011 年 3 月,其主席 Johnson 说:
“这一调查结果显示,今年(2011)的项目成功率是 CHAOS 调查研究历史上最高的。明显,我们对项目成功或失败的原因的理解迈上了一个新台阶。”
Ambler 对成功的定义有效吗,他的调查结果是否反映了你们组织的事实?
该调查的参与者都是自愿的,这是否在一定程度上对结果有影响呢?
查看英文原文: Real IT Project Success in 2011
评论