2011年IT项目取得切实成功

作者 Shane Hastie 译者 马国耀 发布于 2012年1月9日

领域

过程 & 实践

主题

瀑布模型 ,

企业级敏捷 ,

精益 ,

调查 ,

敏捷

分享到

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%的有问题的，成功率位于上述两组数据之间。

本文进一步分析了促使项目成功的各种因素以及使用方法之间的关系。他将成功看成一个多维度的结构体：

1. 时间/进度计划：20%的人倾向于按进度计划来交付，而26%的人则倾向于在系统可交付时交付，而51%的人认为二者的重要性相当。
2. 投资回报（ROI）：15%的人倾向于在预算范围内交付，60%的人侧重于产生较好的投资回报，而25%的人认为二者同等重要。
3. 干系人价值：4%的人倾向于根据需求说明书建设系统，而80%的倾向于满足干系人的实际需求，而16%的人认为二者同等重要。
4. 质量：4%的人倾向于按时按预算交付，57%的人倾向于交付高质量且易于维护的系统，而49%的人认为二者一样重要。

他比较了每种尺度对开发方法带来的产出，最后得出如下结论：

调查再次显示敏捷和迭代软件开发方法优于传统方法和ad hoc方法。这与此前的调查结果保持一致，也一定程度上地解释了IT社区向敏捷方法/战略发展的现象。

Ambler绝不是唯一做此类调查的咨询顾问。人们最常引用的是Standish Group Chaos Survey，它将项目成功与按质量、按预算和按范围见的关系定义的更为严格。Standish的最新的报告发布于2011年3月，其主席Johnson说：

“这一调查结果显示，今年（2011）的项目成功率是CHAOS调查研究历史上最高的。明显，我们对项目成功或失败的原因的理解迈上了一个新台阶。”

Ambler对成功的定义有效吗，他的调查结果是否反映了你们组织的事实？

该调查的参与者都是自愿的，这是否在一定程度上对结果有影响呢？

译者 马国耀 关注企业级应用开发与架构，有多年SOA项目实施和咨询经验，专注于SOA及云计算的融合。