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