【IT168 技术文章】

    缺乏真正的风险管理与控制是导致软件项目失败的最重要原因。实施有效的风险管理，做到真正风险驱动的迭代式开发，尽早排除架构(性能上)的风险也是最重要的。因此，风险管理是软件项目管理的第一管理要点。

    软件项目失败的种种问题

    当笔者三年前读到《漫谈企业应用项目的软件开发过程:一个PRM系统实施的经验与教训》时，就发现它是一篇非常难得的好文章。

    国内类似这样的软件工程案例分析太少了，很多人没有时间写或舍不得与旁人分享其中的美妙，何况这篇文章还是专门针对XP、RUP并涉及到敏捷统一过程实践的。

    除了这篇PRM(伙伴关系管理)案例外，Johnson其实早在2002年7 月还发表过一篇《从一个项目谈XP在国内的应用》，该文在网络上流传甚广。

    这两篇文章好像是国内互联网上最早公开的XP(极限编程)实践案例，还是尝试XP、RUP整合的案例。姑且不论它们是否真正做到了敏捷，整合是否成功，但这两个应用案例的结果恰好一个成功，一个失败，其价值就在于真实性和典型性，具有很好的说服力和教育意义。

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

    PRM系统虽然通过2个月紧张的敏捷、迭代开发并准时交付使用，但却后来出现性能问题，大半年之后仍然没有通过客户验收，不但有几十万尾款没有收到，而且还影响了开发商其它项目的投标。

    为什么一个曾一度成功按时交付的系统，在新旧系统数据集成、上线运行的几个月后会出现严重的性能问题，并暴露出系统架构设计上的缺陷，导致迟迟无法获得客户的信任，让项目各方都陷于被动和尴尬呢?是XP、RUP不行?还是敏捷过程、方法不行?有没有可能事先避免这种典型的风险呢?以上所有这些有趣的问题，都值得我们深入探究。

    迭代真正的目的是为了通过加速客户反馈，显著地消除开发风险，这就要求每次迭代结束必须有一个可运行、可演示的系统。这时的系统可能功能上还不完整，仅仅是一个骨架，但它总是系统开发中最难、最重要同时是风险最大的部分。

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

    风险驱动的迭代是RUP的核心特征之一，XP对此强调的不够，在早期的XP项目中主要是客户驱动的。所以，真正的迭代式开发在项目早期就允许客户对可运行的系统进行验证，从而使项目的风险减到最小。
   
    开发工作也应该根据风险的大小来安排，通过迭代及时调整优先级，风险越大的任务越应该及早设计、实现、测试和反馈。