| 大多数的软件项目都是失败的。实际上，Standish group
报告表明，80% 以上的项目都是不成功的，或者是因为超过预算或延期未完或缺失功能，或者几种因素都有。此外，30% 的软件项目执行得十分糟糕以至于在完成之前就被取消了。根据我们的经验，即便使用了诸如
Java、J2EE、XML 及 Web 服务的现代技术，软件项目都无一例外的应验了这条规律。本文概述了有助于提高软件开发项目成功率的最重要的十点因素。Standish
Group 等业界领头羊也为软件项目提供了重要的成功因素文档。
项目成功的因素
1. 招募技术熟练、经验丰富的人员 — 现在的环境要比以往的任何时候都要复杂。
像WebSphere? Studio 这样的工具是很有用的，但在经验不足的员工手里结果往往最多不过得到普普通通的成效，大多数时候还是失败，这是因为他们不懂什么是好的项目管理以及应用新技术的最佳实践。优秀的项目经理和项目架构师或技术指导将结成项目的领导力量。他们决定了这个项目将如何开展，并且对项目最终是否成功有着巨大的影响。如果您拥有这样的人员，对待他们要好，而且要非常好。项目经理和技术指导有必要面试其他小组成员并决定谁可以加入这个小组。小组的其余成员同样需要具有平均水平以上的技能和经验。表现不好的人需要不断去关注，但他们通常总是“达不到要求”。最终，他们总是会拖小组的后腿，使得项目进展缓慢。然而，这并不意味着小组中不能有任何初级水平的人员。通常，这种成员如果获得机会就会受到更大激励，会尽力把事情做到最好。例如，在一个
20 人的小组里，可能有 2 个领导，6 个高级人员，9 个中级人员和 3 个初级人员。这样 20 人的小组可以再细分为 4 或
5 个小组，每个组有一个组长。IBM Software Services 和 IBM Global Services（IGS）有经验丰富的项目经理、项目架构师、技术指导和顾问，他们可以为您的项目提供帮助。
2. 应用前沿的、但非极端前沿的技术
《财富》杂志 500 强中的许多公司已经在软件项目中成功地应用了成熟技术（如 J2EE 和 WebSphere 产品系列），这些项目对公司的商业经营模式产生了巨大的影响。在某些情况下，应用前沿技术是有必要的，这有助于帮助您在竞争中获得显著的优势。但是，这样一种策略是需要承担风险的，在这种情况下更重要的是拥有优秀的项目人员。由于几乎没有人具有这类前沿技术方面的经验，所以获取外部专家的帮助同样重要。项目若采用极端前沿的技术或还未测试通过的技术就必须自行考虑研究计划。这也许对新兴技术中的概念进行早期验证会有所帮助。然而，与使用更成熟技术的项目相比，要用相同的方法或以相同的成本来交付基于这样一种技术的项目是不现实的。
3. 运用正确的开发流程 — 现代软件项目的特性要求使用一种螺旋式的开发流程（如 Rational 统一流程（Rational
Unified Process，RUP）、某种反复式 IGS 方法甚或是灵活方法（如极端编程（eXtreme Programming）。
螺旋式的开发流程具有多个开发阶段，可以逐步地降低项目风险。在每个阶段结束时都需要决定继续还是停止。在初期阶段，原型可以用来供小组研究新技术，也可以用来研究用户界面。举例来说，RUP
方法定义了每个阶段的角色、任务和构件，这些在项目小组在考虑项目相关事宜时起到提示作用。对任何项目而言，最重要的一点并不是用哪一个流程，而是流程应用得有多好。项目经理和技术指导需要重视并懂得如何根据碰到的问题调整流程，以及如何应用最佳实践来执行流程。流程为需要做什么提供了指导和提示。另一方面，偏离流程原则太远也会导致灾难性的结果。相关文章软件开发项目的最佳实践中有详细的内容。
4. 提供适当的工具 — 任何的软件项目都需要有适合的工具来帮助小组提高生产力。
这些工具包括适当的硬件设备以及设计、编程、和测试工具。工具成本的合理性解释起来相对比较简单。例如，假设像 WebSphere
Studio Application Developer 这样一个 IDE 环境可以节约一个程序员一个星期 5 个小时的时间，平均下来，这个程序员对公司而言成本为
50美元／小时。很容易看出，这样的投资回报（return on investment，ROI）是值得的。同样的道理，要保证小组使用最新的和最快的
PC 用于开发，还要为质量保证、用户确认和部署测试提供适当的测试环境。进行应用新工具或新技术的培训对于完全发挥这些工具或技术的优势是必需的。IBM
拥有一个巨大的培训资源库，包括在线及课堂课程。IBM Software Services 和 IGS 的顾问还可以提供专题讨论、咨询和现场培训。
5. 应用源文档控制管理
在项目一开始就要应用源文档控制管理（SCM）系统。不仅是源代码，所有的文档都要实施 SCM 系统的版本控制。这使得小组可以回顾项目的历史记录，并获取项目早期版本的所有相关文档，如用例、体系结构和设计文档、以及测试脚本和测试计划。我推荐您使用企业级的
SCM 产品，如 Rational ClearCase/ClearQuest。
6. 应用有效的评估方法
多数项目在执行时都会超出预期的时间的 25% 到 100%，但也有一些项目比较准时，与进度相差的时间不到 10%。如果不能准确地估算进度，就没有办法有效地进行计划。但是，在项目的初期阶段所估算出的用时和工作量是非常模糊的。这些估算包含了许多偶然性并且可能使估算的值要翻上一倍。软件开发是一个逐步求精的过程，估算也是如此。随着项目的向前进展，估算也会更加精确。在项目结束时即可获知项目实际的用时和工作量。多数软件工程师往往会估计不足，项目的成本自然就很可能有所增加。当估算进度时，注意不要过多地压缩进度。小组如果不能按照紧凑的进度执行，最终很可能与预期进度相差很远。
7. 将工作细化为小的目标
小目标就是大目标细化后的结果。主要的目标是一个阶段或一段增量的末尾。要达到那一点，项目需要在整个进程中都设立细化的目标。小目标一到两天的工夫就可以达到，以小时为单位。它有这样的好处：可以改善状态报告；因为可以知道一个小目标是否没有完成所以能够实现细粒度控制；因为大约每天都可以完成一个小目标所以会更好地激励员工；还有可以降低执行进度超时的风险。为了避免项目中的各种问题，建议小目标的设定从项目一开始时就着手实施。最好的办法是用电子表格记录和跟踪小目标的执行进度。由工具（如
MicroSoft? Project）生成的项目计划最好只用于更上层的任务。当然，只当前的阶段才划分多个小目标任务。后面的阶段在需要时再进行划分。尽管开发人员认为设定小目标是个麻烦，但是这个问题补偿了小组领导和单个开发人员定义他们自己的目标并分散项目管理和跟踪项目的工作量的能力。通常一个由技术指导定义的任务，一旦由开发人员将其细化为多个小的目标，则任务就会变得更大。有时技术指导会提供备选的、更快、更易维护的方案，在其他一些场合他也同意任务的分解并分配给任务更多的时间。尽早地实施小目标计划的工作可以避免潜在的灾难性结果的发生。
8. 以小时为单位跟踪所有的项目时间
不仅要跟踪以小时付薪的顾问和立约人所花的时间，每个项目成员所花费的时间同样很重要。这样做的好处是可以对照个人所用的时间与项目计划的时间。如果个人已经转向其他任务就要采取一些步骤。同样，实际的时间也可以对照估算的时间，估算的时间可以依次地为项目的下一个阶段或下一个项目的时间估算方法提供反馈。对小目标的全部时间的估算可以限制时限的超出，因而这些时限是可以修正的。应用小目标技术要求来自各方面的包括技术指导、小组领导和每个开发人员的时间和努力。至少每个星期，每个开发人员要以电子表格的方式提交他的工作状况，让项目主管可以在每个更上层的任务中更新完成进度的百分比。这样将使项目管理的工作量分散到其他的小组成员身上。跟踪项目时间会耗费更多的时间，但这能实现非常有效的项目管理。
9. 应对不断出现的变化
对于大多数项目，每个月项目的需求变化不会大于 5%。这些变化的产生有多方面的原因，例如没能在正确的时间提出恰当的问题、正在处理的问题发生了变化、用户改变了他们的主意或观念、商业环境发生了变化或者是市场发生了变化。功能特性蠕变都会轻易使得成本和执行进度超出预先的估计。在项目的初期阶段，项目需求中有许多缠杂不清的地方。当执行到某个阶段（通常在第二阶段的末尾）时，项目需求就必需确定下来并锁定其核心内容。一个变化的管理过程由一个所谓的“变化委员会（change
board）”来执行，变化委员会由项目所涉及的每个领域的代表组成，例如业务、市场、开发、质量保证、用户文档、客户支持和项目管理等。变化委员会负责将所要做的改变交由适当的人去完成、对改变作出说明并测定来自各方的估算值的大小。在获得足够的信息后，变化委员会就可以决定接受还是拒绝这项变化。一旦接受一个变化，它将被加入到计划当中并且执行进度也要做出改变。伴随有变化的项目要比原先没有变化的项目提交得晚，但是它仍然是成功的，因为它仍然满足修正后的执行进度和股东的期望。一个项目如果在启用变化委员会之后有超过
5% 的改变，则表明项目制定得非常糟糕或者已失去了控制，最终很可能会失败。
10. 项目领导
公司的管理者委任一个执行者承担软件项目成果的责任是至关重要的。这个关键的执行者不仅要总览全局，还要获得和控制项目所需的资源来帮助和支持这个小组。同样重要的是，执行者不需要去干涉、管理小组中的一些琐碎的事。执行者要相信小组是可以委以重任的。
结束语
本文列出了帮助提高软件开发项目成功率的十点因素。遵从这些指导原则，您可以在预算和预定时间范围内更好地完成项目、保持一个高效率的小组并尽量不改变功能特性。您可以参考
Mike 的另一篇关于最佳实践的文章软件开发项目的最佳实践。
|