Success/Failure Criteria for Software Projects

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/CMMI6SigmaRUP甚至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

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

 

更多内容请看原文

 

posted @ 2006-07-07 16:52 风满袖 阅读(...) 评论(...) 编辑 收藏