风险管理:软件项目管理的精髓

　　不管结果如何,PRM原文的篇幅不长,却有很多值得我们借鉴和学习的地方。笔者认为这个项目无论从商务角度,还是从工程技术的角度来看,都是比较失败的。

PRM系统虽然通过2个月紧张的敏捷、迭代开发并准时交付使用,但却后来出现性能问题,大半年之后仍然没有通过客户验收,不但有几十万尾款没有收到,而且还影响了开发商其它项目的投标。
 
　　为什么一个曾一度成功按时交付的系统,在新旧系统数据集成、上线运行的几个月后会出现严重的性能问题,并暴露出系统架构设计上的缺陷,导致迟迟无法获得客户的信任,让项目各方都陷于被动和尴尬呢? 

是XP、RUP不行?还是敏捷过程、方法不行?有没有可能事先避免这种典型的风险呢?以上所有这些有趣的问题,都值得我们深入探究。

敏捷开发的基础是首先做到迭代式(Iterative)开发。迭代不仅仅是把整个系统开发任务逐一分解、按阶段分步骤来实现的。 

如果迭代的含义仅仅停留在这个层面上,那么提出用迭代演进式过程取代瀑布型开发模型也就毫无意义,因为我们做任何工作本来就是要一天一天、一块一块地来完成,不管瀑布型还是演进式皆如此。
 
　　迭代真正的目的是为了通过加速客户反馈,显著地消除开发风险,这就要求每次迭代结束必须有一个可运行、可演示的系统。这时的系统可能功能上还不完整,仅仅是一个骨架,但它总是系统开发中最难、最重要同时是风险最大的部分。 

RUP核心之一:风险驱动的迭代 

风险驱动的迭代是RUP的核心特征之一,XP对此强调的不够,在早期的XP项目中主要是客户驱动的。所以,真正的迭代式开发在项目早期就允许客户对可运行的系统进行验证,从而使项目的风险减到最小。

开发工作也应该根据风险的大小来安排,通过迭代及时调整优先级,风险越大的任务越应该及早设计、实现、测试和反馈。 

我们知道,RUP从风险驱动出发把一个软件项目分为四个阶段:起始阶段、细化阶段、构造阶段和移交阶段,这四个阶段分别对应着项目的四个里程碑。起始阶段主要消除项目的业务风险,细化阶段应该尽力消除项目的主要技术风险:架构风险(同时包括功能和非功能两方面)。 

很遗憾,PRM项目是在到了项目最后一个阶段:移交阶段。在系统运行了几个月、数据迁移完成之后才发现架构设计上存在着严重的性能缺陷需要修补。重要的是:在项目之初的合同上其实就已经对数据迁移、上线运行的要求作出了规定。 

这导致了最大架构级风险:系统性能满足用户的真实需要吗?直到临近项目结束也未能被消除。实际上PRM项目的“细化阶段”并未真正完成,建立稳定、可靠的系统架构的里程碑目标也从未达到。 

在项目几近成功、圆满结束的时候,突然爆炸一颗硕大的“地雷”(严重的系统缺陷或问题),导致项目进度拖延甚至失控,人员失和,资金拖欠,这就是软件开发中最糟糕的一种情况。 
　　
　　不幸的是,这种在各种经典教材中都能大量看到的案例,再一次地在已经(部分)采用了敏捷XP、RUP实践的PRM项目上重演了。那么,我们有没有可能事先防范PRM项目这颗延迟爆炸的“地雷”呢? 

当年PRM项目已经花了10个月的时间,却仍未能通过客户验收。前期用了2个月完成功能开发,2个月部署和试运行,从第5个月完成实际数据导入、开始正式运行起,就出现了严重的性能问题。 
随后的6个月基本上都用在了系统的性能优化和改进上。总体上项目开发给人一种手忙脚乱、进度失控的感觉。现在看来,PRM项目的进度至少延误了一倍时间。 

软件工程不相信眼泪 

如果PRM团队和客户从一开始就意识到系统潜在的性能问题,明确了对系统容量的要求;如果PRM系统的架构师拥有足够的设计经验,系统表示层、控制层和数据资源层在上线之前就已经得到优化,提供了足够的性能;如果架构设计评审产生了真正的效用;如果 PRM 团队做到了完备的系统测试;如果时间能够倒流……。 

所有这些“如果”当中,只要有一条灵验,那么那颗可恶的“地雷”可能就不复存在了。
 
　　PRM项目可不可以做得更成功呢?答案是肯定的,我们不妨逆向思维:如果PRM团队能够把这个项目重头再做一遍,把吸取到的教训和学到的软件工程“新”知识都用上,在5个月内提供满足客户实际要求的系统应该足够了,至少PRM团队下次再遇到类似的项目他们成功的几率肯定会大许多。
 
　　规避风险,成熟的软件工程可以设置几道防线,采取许多措施。如果PRM项目按照RUP 风险驱动的迭代方式来做,那么从项目一开始我们就应该对需求、架构进行更为细致、全面的分析,既包括功能,也包括非功能,还可以通过多次迭代反馈来确认分析的结果。 

假设如果不知道有哪些风险,我们又如何来防范?所以,关键是要建立一张随着迭代演进不断被动态更新维护的风险清单(RUP工件叫Risk List),制定出防范其中所有主要风险的预案。 
　　
　　就PRM项目而言,一方面,功能开发不是一个重大风险,因为有旧的PHP系统、源代码和现成的算法可以参考。另一方面,J2EE的应用架构设计得不好可能会存在性能问题。 
　　
　　因此,我们应该把注意力更多放到系统的非功能风险上(性能、可靠性、可维护性等)。具体表现为:客户应用访问的最大并发用户数到底是多少?我们交付到客户手里的系统最大容量又是多少?怎样才能保证系统的性能?如果上线后性能达不到,不能满足客户要求怎么办?等等。 

明确了项目所面临的重大风险,比如系统的性能问题,我们就可以根据需求和设计方案制定出完善的、有针对性的测试计划。包括在客户可接受的响应时间要求下,系统最大能够支持多少个用户的并发访问(具体可细分为增、删、改、查等多个操作类型)。 
　　
　　明确了项目的风险、需求还不行,作为风险预案的落实,我们还应该进行系统性能、可靠性等方面的设计,真正(通过编码)做出一个符合要求的架构(框架)基础,通过迭代开发、测试和评审对此进行验证。 
　　
　　在开发阶段,系统还未部署,如果我们无法获得真实的用户和使用环境怎么办?用模拟测试!对,如果严格按照 RUP 风险驱动的迭代演进式开发进行管理,在半年多的时间里应该还是有机会尽早发现这个问题的。 
　　
　　但是,这种方式可以消除局部的缺陷,但却很难发现全局性的架构问题。对于软件架构,“头痛医头,脚痛医脚”的做法往往是行不通的。 
　　
　　PR项目虽然模仿X迭代周期,甚至每天都开例会(这有点像Scrum),很容易获得真实的项目情况,就像"掀开地毯下面的东西",保证了初始版本的准时交付(在保证PRM前期进度方面,迭代还是有功劳的),却仍然没有能够防止较大风险的发生(交付系统几个月后才逐渐暴露出性能和架构上的质量问题)。

可以说,这并没有达到XP或RUP迭代开发的最终目的。在项目初期,没有把合同中已经提到的数据迁移视为一个关键风险,是前期分析工作或者说整个项目的一大失误。

文章来源：项目管理者联盟