一个遗留产品或者代码的维护往往是Chris和整个IT部门的噩梦。随着人员的更迭，文档没有人维护，开发团队想在这个遗留产品上进行二次开发甚至是修改一些缺陷都变得几乎不可能。究其原因是没有人知道代码的哪部分实现了什么样的功能，无从考证。与之相比，使用敏捷方法交付的软件就相对容易维护。Chris带着无限的好奇和团队中的几个开发人员进行交流后得知，敏捷方法将测试完全融入编码的各个环节，在写功能性代码之前单元测试、TDD（测试驱动开发）、产品的验收测试、性能测试等等这些可读性极高的测试就是最好的“文档”。当开发人员读懂一段测试就知道与之对应的这段代码所实现的功能。在此基础上，开发人员可以放心大胆地通过TDD的方法修改缺陷，只要写一个针对这个缺陷的测试，然后写功能性代码来通过这个测试就可以了。与此同时，还需要确定修改或者新增的代码没有破坏原有的测试。
敏捷方法将系统本身和测试作为最好的“文档”。几个月前对这种遗留系统需要1～2个月的时间才可以研究明白如何在此基础上进行二次开发，使用敏捷方法交付软件将这个时间缩短到了一个星期以内。测试覆盖率的提高和测试质量的提升保证了产品的质量。产品出现问题的几率小了，业务部门的投诉和抱怨少了，Chris可以从容地把一些技术支持团队成员的时间分配去帮助业务部门开发新功能，从而实现更多的商业价值。
与此同时，业务部门对IT部门的看法有了更大的改变，多的是了解和理解，少了抱怨和指责。 Chris和他的IT部门的工作也变得有趣了许多。
如何更好地与CEO、CFO
等其他决策人员有效的合作
值得高兴的是，不只业务部门、IT部门还有CFO，由于Chris使用了适应敏捷的合同模式，CFO不需要在合同签订初期就支付50%的定金，而是随着每个迭代得到的经过用户验证的可工作产品而进行支付。每次支付的压力减小了，对这个公司的现金流也产生了很积极的影响。由于产品质量的提高， IT部门人员的职能和作用都产生了变化，一个二、三十人的IT部门创造出比以前大得多的价值，花在编写详尽文档、维护和重写文档的时间少了，浪费少了，效益就显现了出来。无论是CEO和CFO都看到了Chris的这个“革新”给公司带来的价值。他们也更多地邀请Chris参加公司发展和决策的会议，使得IT对公司做出更大的贡献。
Chris和其IT团队所取得的成绩斐然，这始于IT咨询公司将其领进了敏捷这扇门。由于敏捷开发在国内起步比较晚，拥有敏捷实践经验的公司寥寥无几。ThoughtWorks作为优秀的敏捷咨询业务和复杂产品交付的提供商，十几年来为世界财务500强提供了优质的服务。敏捷方法改变了Chris，一个非IT公司的CIO的命运，以及IT部门的命运，他希望可以将这个方法推广到更多的同行当中，更好地回报社会。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
