合同的第二部分，他希望根据第一阶段的工作成果制定项目计划，包括费用、人员、进度、范围、交流、风险控制和变化等方面。Chris要求承包方每两个星期提供一个可以工作的软件版本并且可以简单地部署到它的生产环境中。每两到三个月，Chris要得到一个具有完整功能的系统，从而让业务部门尽早使用信息系统，产生更多的商业价值。
拥有了这样一份合同，Chris不再为以前的种种苦恼而忧心了。首先，项目的进展尽在IT和业务部门的掌控。每两个星期开发团队提供一个可工作的软件，这样业务部门就可以对这个软件进行用户测试，从而思考和矫正他们最初对需求的理解。这个过程使得业务部门更好地理解了他们到底需要什么，而不是片面的纸上谈兵，从而大大减少了开发工作中的浪费。
Chris看到的这种方法的价值不仅于此。IT部门在这个过程中起的作用更大了，并且是开发部门和业务部门的融合剂、调和剂。业务部门对IT的看法改变了，他们不再是一个被动的提供技术支持的团队，而是一个主动的帮助业务部门更快、更早、更高效地实现其价值的服务团队。业务部门也不再担心如果在开发工程中产生新需求或者需求变化时，开发部门不能及时应对，因为一切是如此的灵活和敏捷。
Chris了解到，这样的一种合作模式和开发方法是一种叫做敏捷的软件开发方法。其中的两条精髓是“客户合作重于合同谈判；响应变化重于遵循计划”。
这种敏捷的开发方法也改变了工作团队间的交流方式。以前那种依靠详尽的文档和复杂开发过程的交流方式被以尊重个体的交流、以必要的文档为交流媒质的方法所取代。回想起以前伴随软件交付而交付的厚厚文档，Chris就发自内心地感觉这本身就是一种浪费，因为这些文档的大部分不会有人去读。一个没有读者的文档必然就是很大的浪费。敏捷方法的文档形式新颖，大多是以图表、界面原型、故事的方式，很容易被理解。
在鼓励个体交流的同时，Chris看到了一些意想不到且欣喜的变化。各个团队更多关注这个可工作的软件，如何利用先进的Web2.0、SOA、 Ruby On Rails等技术来帮助业务部门实现其需求，而不是文档所谓的准确性。交流的增加使团队间增进了理解，团队的工作氛围也不同了，大家更享受这份工作。
如何保证软件系统的
持续有效运行
软件的维护一直是困扰Chris的一个大问题。这个问题主要体现在两个方面：一是软件的可扩展性差，二是软件的可维护性不好。
扩展性差的原因在于，在传统方法的软件产品设计阶段，需要为这个产品设计出一个“满足各种需求”的架构，这个架构一经确定就不能再变化了。并且这个设计是相对比较详细的，灵活性很差。与这种方法不同，敏捷方法讲究的是每一到两周就可以发布一个可工作的产品，我们把这个时间段称为一个迭代。这种可以连续发布的特性是建立在一个扩展性好的软件基础上的。好的扩展性的实现是通过在开发过程中不断地对架构和代码重构，从而适应不断变化的需求。这样一来使用敏捷方法的软件产品的扩展性就不成问题了。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
