而且版本控制系统在需求变动激烈的项目中,更是充当了一种保险机制。无意中用错误版本的代码覆盖工作拷贝的事情可以得到彻底解决。
灵活运用敏捷开发
实际上,我从来没有采用过完整的敏捷开发。因为我认为既然敏捷开发本身强调的就是应对变化,那么敏捷开发过程本身也应该是可剪裁的。像结对编程、持续集成这些,对公司本身和开发人员的要求相对来说都更高。如果要一一达标,确实不太可能。
所以有选择性的实行敏捷开发,是我最常用的方式。
例如对于User Story,除非是客户充分配合,否则是难以实施的。这个时候应该在前期将工作做细致,尽可能明确大部分需求。然后以最快的速度做出原型系统后,和客户进行沟通获取反馈意见。
同时,即便采用User Story,对于较复杂的系统,也应该深入客户企业,了解客户企业员工的工作流程。因为有时候客户方负责项目的人士很可能会按照自己的想法渲染实际的工作流程或者环境,这对项目的中后期是非常不利的。
在国内,一个项目要做得顺利,项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常非常重要的,否则他们一句话可能就会让项目的开发成本增加不少。这些东西的内容远远超过了技术领域,但却是我们不得不面对的问题。
迟来的成功
新系统花了一个月就开发完成了,因为除了权限系统是完全重做的外,其他部分都大量利用了已有系统的结构和代码。虽然在模拟权限系统时花了不少时间,但这样模拟的结果保证整个系统具有充分的可用性。
这个项目是我公司迄今为止用FleaPHP应用程序开发框架(http://www.fleaphp.org)开发的最复杂的应用程序。不算FleaPHP自身在内,应用程序的核心有100多个类,6700多行代码。从与客户意向性洽谈到最后完成,足足花了六个月时间,期间开发实际上只进行了三个月不到,而且还是做了两次。其他时间全花在沟通、协调、开会上了(有时候不得不抱怨一下国有企业僵化的机制)。
如果我一开始能够耐心说服客户接受我的意见,那么整个项目的开发过程可能就会顺利得多。或者说我能在项目初审发现问题后通过其他渠道争取支持,那么也可以避免后来的二次开发。不得不说我在如何“做人”方面还有许多需要学习的东西。
这个故事虽然不够精彩,但是很真实。
此文章共有4页 上一页 1 2 3 4
文章来源:中国项目管理资源网
|