请用 Safari 11+、Firefox 60+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* Wikipedia* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/25 登录/0

一次有益的敏捷 XP 失败

阅读数:9297
基本历史
前言


本案所反映的问题和现象在我国的软件开发项目中是非常典型的。 程序员高手和笃信编程技巧大于一切的观察家们会指着 PRM 项目说: 这明显是开发人员的水平不够,页面处理太笨,数据库设计太次 …… 要是我早就搞定了! 可是,问题的根源果真是技术原因吗?

前言


当我三年前第一次在 developerWorks 上读到这篇文章(漫谈企业应用项目的软件开发过程:一个 PRM 系统实施的经验与教训)时, 就发现它是一篇非常难得的好文章 —— 国内类似这样的软件工程案例分析太少了, 很多人没有时间写或舍不得与旁人分享屋中瑰宝,何况这篇文章还是专门针对 XP、RUP 涉及到敏捷统一过程实践的。

除了这篇 PRM (Partner Relationship Management)案例外, Johnson 其实早在 2002 年 7 月还发表过一篇《从一个项目谈 XP 在国内的应用》,该文在网络上也流传甚广。在我的印象中, 这两篇文章好像是国内(互联网上)最早公开的 XP 实践案例,而且还是尝试 XP、RUP 整合的案例。 姑且不论它们是否真正做到了敏捷,整合是否成功,这两个应用案例的结局恰好一个成功,一个失败, 其价值就在于真实性和典型性,具有很好的说服力和教育意义。 通过案例介绍用事实和数据说话,我为 Johnson 的勇气和科学态度叫好! 不管结果如何,PRM 原文的篇幅不长,却有很多值得我们借鉴、学习的地方。 除了作者总结的经验和教训之外,我还看出了一些其他问题,有一些新的联想和补充,于是写下来与大家交流探讨。

我个人认为 PRM 这个项目无论从商务角度,还是从工程技术的角度来看,都是比较失败的。 印象最深刻的一处是 PRM 系统虽然通过 2 个月紧张的敏捷、迭代开发准时交付使用, 却由于后来出现性能问题,过了大半年仍然没有通过客户验收, 不但有近一半的尾款没有收到,而且还影响了开发商其它项目的投标。 为什么一个曾一度成功按时交付的系统,在新旧系统数据集成、上线运行的几个月后会出现严重的性能问题, 并暴露出系统架构设计上的缺陷,导致迟迟无法获得客户的信任,让项目各方都陷于被动和尴尬? 这些麻烦究竟是什么原因造成的,是 XP 不行,RUP 不行,还是敏捷过程、方法不行? 有没有可能事先避免这种严重的风险呢? 以上所有这些有趣的问题都值得我们深入探究。

<帮助> <全部评论> 共 0 个主题 0 条评论 (agiletrial)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2018 张恂 版权所有. 沪ICP备05023401号