CIO如何从敏捷软件开发中受益

1、 cio如何从敏捷软件开发中受益 “客户合作重于合同谈判;响应变化重于遵循计划”是敏捷软件开发的精髓所在，正是这种新兴的敏捷方法改变了一名cio，使之收益颇丰。作为公司的cio，chris早晨9点来到办公室，看了一下今天的安排。09：30 查看技术支持中紧急和重要问题的处理情况10：30 与ceo和cfo讨论新的软件项目计划和预算13：00 听取当前软件项目的进展15：00 审批下一季度的采购清单.这并不是chris一周中最繁忙的一天。想起昨天已经使用了2年半的交易系统又出了大问题，导致半个多小时无法使用，这些不禁让他回想起这个项目: 历时9个月开发耗资上百万，经历一期和二期的开发已经基本满足

2、当时的业务需求，但是短短的半年之后，由于新业务的引入和当时对需求的不完全理解，这个系统目前只能支持60%的业务需要。随着用户的增加，导致系统的性能和稳定性都下降了。技术支持团队不断收到这样或者那样的问题和投诉，这令他们应接不暇。随着世界经济和信息科技的发展，很多公司纷纷开始组建自己的it部门。作为it工作的负责人，cio承担着巨大的责任和挑战。it也从计算机网络、信息系统的维护等基本工作逐渐发展到应用新科技来帮助公司拓展业务、节约成本、为市场和销售部门提供信息技术方面的服务。让cio头疼的事情不只前面提到的这些。公司业务发展得好，就对it系统要求更高;当遇到问题，需要裁减人员时，it部门也是首

3、当其冲。因为大多数人的理解是it是个只花钱不创造价值的部门，属于支持服务部门。由于业务需要，新的信息系统需要交付，谈起和软件承包方的合作就又增添了无限的烦恼。早期就固定下来的范围没法适应不断变化的业务需要，从承包方拿走合同和需求文档的那一天开始，chris就提心吊胆，不知道6个月后拿到的是什么东西，会不会有良好的性能和稳定性。更糟的是在项目开始阶段，没有拿到任何可工作的产品的时候就需要付50%的定金，项目验收后再付剩余部分，这种方式对公司的现金流有不小的冲击，和cfo的协作也因此不是那么融洽。chris受够了这种合同模式和运作方法。难道就没有一种更好的方法来解决这些问题么?如何高效运用信息技术

4、解决业务部门遇到的问题chris想要的合同是有灵活性，能够激励软件开发团队和业务部门的交互的。与其在立项过程中花两到三个月制定一个纷繁复杂的合同，不如在获取一些重要需求的基础上就让开发团队尽早进入开发阶段。首先他要求承包方与it部门及业务部门合作在23周的时间内获取基本的业务需求，至于需求的细节，在这个阶段他并不关注。之后这些需求用msl(m aster story list)的形式和界面选型来表述。这样业务部门、it部门和开发方就共同拥有了一个可以理解和交流的媒质。这些要求可以作为合同的第一部分。几周之后chris可以对开发团队的工作有一个基本的验证，一切不再是一锤子买卖的赌博了。合同的第二

5、部分，他希望根据第一阶段的工作成果制定项目计划，包括费用、人员、进度、范围、交流、风险控制和变化等方面。chris要求承包方每两个星期提供一个可以工作的软件版本并且可以简单地部署到它的生产环境中。每两到三个月，chris要得到一个具有完整功能的系统，从而让业务部门尽早使用信息系统，产生更多的商业价值。拥有了这样一份合同，chris不再为以前的种种苦恼而忧心了。首先，项目的进展尽在it和业务部门的掌控。每两个星期开发团队提供一个可工作的软件，这样业务部门就可以对这个软件进行用户测试，从而思考和矫正他们最初对需求的理解。这个过程使得业务部门更好地理解了他们到底需要什么，而不是片面的纸上谈兵，从而大

6、大减少了开发工作中的浪费。chris看到的这种方法的价值不仅于此。it部门在这个过程中起的作用更大了，并且是开发部门和业务部门的融合剂、调和剂。业务部门对it的看法改变了，他们不再是一个被动的提供技术支持的团队，而是一个主动的帮助业务部门更快、更早、更高效地实现其价值的服务团队。业务部门也不再担心如果在开发工程中产生新需求或者需求变化时，开发部门不能及时应对，因为一切是如此的灵活和敏捷。chris了解到，这样的一种合作模式和开发方法是一种叫做敏捷的软件开发方法。其中的两条精髓是“客户合作重于合同谈判;响应变化重于遵循计划”。这种敏捷的开发方法也改变了工作团队间的交流方式。以前那种依靠详尽的文档

7、和复杂开发过程的交流方式被以尊重个体的交流、以必要的文档为交流媒质的方法所取代。回想起以前伴随软件交付而交付的厚厚文档，chris就发自内心地感觉这本身就是一种浪费，因为这些文档的大部分不会有人去读。一个没有读者的文档必然就是很大的浪费。敏捷方法的文档形式新颖，大多是以图表、界面原型、故事的方式，很容易被理解。在鼓励个体交流的同时，chris看到了一些意想不到且欣喜的变化。各个团队更多关注这个可工作的软件，如何利用先进的web2.0、soa、 ruby on rails等技术来帮助业务部门实现其需求，而不是文档所谓的准确性。交流的增加使团队间增进了理解，团队的工作氛围也不同了，大家更享受这份工

8、作。如何保证软件系统的持续有效运行软件的维护一直是困扰chris的一个大问题。这个问题主要体现在两个方面：一是软件的可扩展性差，二是软件的可维护性不好。扩展性差的原因在于，在传统方法的软件产品设计阶段，需要为这个产品设计出一个“满足各种需求”的架构，这个架构一经确定就不能再变化了。并且这个设计是相对比较详细的，灵活性很差。与这种方法不同，敏捷方法讲究的是每一到两周就可以发布一个可工作的产品，我们把这个时间段称为一个迭代。这种可以连续发布的特性是建立在一个扩展性好的软件基础上的。好的扩展性的实现是通过在开发过程中不断地对架构和代码重构，从而适应不断变化的需求。这样一来使用敏捷方法的软件产品的扩展

9、性就不成问题了。一个遗留产品或者代码的维护往往是chris和整个it部门的噩梦。随着人员的更迭，文档没有人维护，开发团队想在这个遗留产品上进行二次开发甚至是修改一些缺陷都变得几乎不可能。究其原因是没有人知道代码的哪部分实现了什么样的功能，无从考证。与之相比，使用敏捷方法交付的软件就相对容易维护。chris带着无限的好奇和团队中的几个开发人员进行交流后得知，敏捷方法将测试完全融入编码的各个环节，在写功能性代码之前单元测试、tdd(测试驱动开发)、产品的验收测试、性能测试等等这些可读性极高的测试就是最好的“文档”。当开发人员读懂一段测试就知道与之对应的这段代码所实现的功能。在此基础上，开发人员可以

10、放心大胆地通过tdd的方法修改缺陷，只要写一个针对这个缺陷的测试，然后写功能性代码来通过这个测试就可以了。与此同时，还需要确定修改或者新增的代码没有破坏原有的测试。敏捷方法将系统本身和测试作为最好的“文档”。几个月前对这种遗留系统需要12个月的时间才可以研究明白如何在此基础上进行二次开发，使用敏捷方法交付软件将这个时间缩短到了一个星期以内。测试覆盖率的提高和测试质量的提升保证了产品的质量。产品出现问题的几率小了，业务部门的投诉和抱怨少了，chris可以从容地把一些技术支持团队成员的时间分配去帮助业务部门开发新功能，从而实现更多的商业价值。与此同时，业务部门对it部门的看法有了更大的改变，多的是

11、了解和理解，少了抱怨和指责。 chris和他的it部门的工作也变得有趣了许多。如何更好地与ceo、cfo等其他决策人员有效的合作值得高兴的是，不只业务部门、it部门还有cfo，由于chris使用了适应敏捷的合同模式，cfo不需要在合同签订初期就支付50%的定金，而是随着每个迭代得到的经过用户验证的可工作产品而进行支付。每次支付的压力减小了，对这个公司的现金流也产生了很积极的影响。由于产品质量的提高， it部门人员的职能和作用都产生了变化，一个二、三十人的it部门创造出比以前大得多的价值，花在编写详尽文档、维护和重写文档的时间少了，浪费少了，效益就显现了出来。无论是ceo和cfo都看到了chri

12、s的这个“革新”给公司带来的价值。他们也更多地邀请chris参加公司发展和决策的会议，使得it对公司做出更大的贡献。chris和其it团队所取得的成绩斐然，这始于it咨询公司将其领进了敏捷这扇门。由于敏捷开发在国内起步比较晚，拥有敏捷实践经验的公司寥寥无几。thoughtworks作为优秀的敏捷咨询业务和复杂产品交付的提供商，十几年来为世界财务500强提供了优质的服务。敏捷方法改变了chris，一个非it公司的cio的命运，以及it部门的命运，他希望可以将这个方法推广到更多的同行当中，更好地回报社会。交付团队、客户与最终用户通过迭代周期开展协作王晓明：英国约克大学信息系统硕士，thoughtworks公司咨询师、项目经理、敏捷教练和商务分析师。拥有在金融、零售、机械加工、石油天然气、hse、crm