引入敏捷开发
其实我公司不是第一次尝试敏捷开发，只是这个项目由于前期做了“细致”的文档，所以没有按照惯用的快速迭代模式进行开发。但新系统在排除了“人”的障碍后，采用敏捷开发的条件已经很充分了。
User Story
我首先和客户方派来的代表一起模拟了权限系统的运作方式，最终得到了一个和最初设计功能近似，但具备充分实用性的权限系统设计方案。
模拟过程类似角色扮演游戏。我先在许多张卡片上写好各个部门及员工的名字、职位信息。然后我和客户代表一起，手持不同的卡片扮演不同的角色。然后将不同角色之间的交互过程记录下来。这个过程就是敏捷开发中倡导的“User Story”，虽然简单，但是非常有效。不但能够真正理清各个角色之间的关系，还能找出实际运用时的不足之处。
在我和客户代表的模拟过程中，开发人员则迅速创建一个符合我们演示过程的权限系统来验证权限系统的可行性。当然，如此高要求的快速开发还需要借助公司从以往项目中积累的大量可复用代码以及高水平的开发人员。
快速决策和充分沟通
由于在客户企业，一个很简单的决策可能也要层层批复。所以经过我公司的艰苦努力，客户企业最终决定由一位领导来专门负责该项目的决策。所以大部分决策可以在较短的时间内获得反馈意见。
而客户代表在整个新系统开发期间，几乎一半时间都在我公司上班。这也保证了我公司和客户之间的充分沟通，并且当面沟通也比通过电话更容易说服客户接受我的意见。
实际上，不管采用何种开发模式，充分的沟通都是保障项目成功的关键因素之一。沟通越充分、双方协作程度越高，项目就会进行得越顺利，成功的几率也更大。而在敏捷开发中，由于是通过小步前进的快速迭代来逐步逼近项目最终目标，所以沟通就更为重要。否则一次迭代完成后，却得不到及时和正确的反馈，那么项目也无法进行下去。
有限的单元测试
持续集成虽然非常有用，但是对于这个项目却不太适合。不过为了保证子系统的修改不至于影响到全局系统，我仍然编写了一些重要的单元测试。
准确来说，这几十个单元测试都不太符合“单元测试”的标准。因为每个测试实际上都要用到子系统的许多接口。但在项目时间压力下，这些测试既能很大程度上保证子系统的修改不至于对全局系统产生太大的破坏作用，又不用花太多时间去维护。所以是一个折衷的选择。
不过这里我认为这里做得很好的地方就是单元测试是由我来编写的，并不是开发人员自己编写的，所以更能够反映我和客户的意图。同时测试重点也更偏重业务领域，而不是程序行为。
版本控制系统
虽然敏捷开发没有对版本控制系统做要求，但使用版本控制系统可以很明显的提高开发效率。例如我和客户代表验证一个想法后，发现这个设想并不好，那么通过版本控制系统，开发人员几分钟就可以退回到先前的代码或者切换到其他阶段的代码。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
