Success/Failure Criteria for Software Projects

Introduction

什么是软件项目成功或失败的标准？对此，可能每个人都有自己的观点。一个软件项目如何才能成功？需要具备哪些要素？比如出色的开发者，正规的开发流程、细致的需求、UML、有效的风险管理、周全的计划、明确的商业目标、频繁的评估和回顾。记得以前看《软件工艺》的时候，为书中新颖独特的观点所深深吸引，虑及自己所经历的项目，发现很多地方印证了书中的观点。软件工艺强调人的作用，不过，它似乎并没有改变大多数人心中软件工程的地位。很多PM还是在对制定“计划”乐此不疲，费尽心机想导入某种正规的“Process”，想尽办法去进行“风险管理”，强调“明确需求”；很多设计人员整日抱着UML，画着各种“Diagram”……可是现实世界发生的事情可能令我们感到困惑甚至吃惊。

A Study

有位澳大利亚的教授研究了400个美国、澳大利亚和智利的软件项目后，得出一些惊人的结论，大致如下（斜体部分是我的看法）：

1、  大多数没有进度表的项目最后成功了。

这的确令人感到惊讶，没有进行计划安排的项目居然能成功，要么是组员比较优秀，要么项目比较小，容易达成目标。

2、  需求对于项目的成功是需要的，但是在项目早期并非必须的。

通常我们期望需求得到得越早越好……

3、  没有明确的需求，项目常常也能成功地继续开展下去。

就我的经历而言，没有明确的需求是很正常的事情，特别是做产品的时候，往往还不知道最后的产品应该具有哪些特性。如果是做具体的项目，我则期望需求越明确越好。但是需求总是会变化，team需要对客户的反馈有能力作出及时的调整。

4、  需求方法论的选择并不重要，UML没有什么帮助。

我是UML的热爱者，喜欢使用UML来表达我的想法，表达设计，和组员进行交流。不过事实表明，UML只是一部分人（喜欢可视化的图表的人）的工具。对于表达需求来说，UML的确没有什么用，Use-Case Diagram就是几个用例（椭圆、连线和角色），看了之后你能对需求了解多少呢？还是看文字描述的Use-Case比较直接和准确。但我相信使用UML表达设计是很好的做法。

5、  使用某开发方法论是成功的要素，特别是它适合我们的应用的时候。

的确如此，适合我们的过程就是最好的过程。国内有很多企业都使用CMM/CMMI、6Sigma、RUP甚至XP，不过大多数的软件企业还是没有progress。即使有些企业获得了CMM/CMMI的认证，执行中也常常是留于表面。

6、  很少有项目使用风险管理，而且这些项目也很少管理其风险。

事实如此，但并不说明风险管理不值一提，它还是很重要的。公司要规避风险，项目当然要规避风险。

7、  很少有能坚持进行频繁地评估和回顾的，几乎总是在成功的项目中才做到了。

我认为进行评估是规避风险的一个具体做法。比如对架构设计进行评估，就是为了从技术上尽量降低项目失败的可能性。但这个评估和回顾应当是在良好的气氛中进行，适时变化。

8、  ……

该研究还提出了一些预见（似乎是众所周知的）：

• Success comes from a culture that investigates and deals with problems

最赞同的一点。

• The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
• Project managers should be involved in the estimation activity
• Project managers should be good at customer and developer communication; they need not be good at the technology

这点可能会有争议，项目经理到底有无必要精通技术？

更多内容请看原文。