过去，我们可能要花几个月的时间来规划某个技术项目，然后再花上几个月、甚至好几年的时间来实施项目。如今则大不相同：经营战略极具动态性，特别是面对目前颇具挑战性的经济形势。

　　在笔者所在的运输公司Con-way，几乎所有好的想法都需要通过技术实施。过去，等到好想法通过IT指导委员会、项目规划和设计审查的层层环节，早就过时了。直到我们采用了敏捷开发方法。

　　若使用敏捷方法，软件开发不再经过漫长的项目周期完成。相反，对预期的整个概念首先进行大致定义，然后以短迭代的形式进行开发。一个迭代的持续时间通常不再超过一个月。每个迭代完成后，软件立即发布供人使用。大家使用软件后，确定下一步应该开发哪些功能特性，提供一条反馈回路(feedback loop)，确保优先级最高的功能特性得到开发。

　　采用敏捷开发方法需要IT团队成员和业务用户的工作方法都进行重大变化，而这给CIO们出了一道变革领导力方面的难题。

　　IT人员的一大变化在于：如果采用敏捷开发，总是有一个即将到来的交付日期。与此同时，过去拥有私密空间的开发人员可能觉得空间由于两大因素受到侵犯：一是结对编程(pair programming)，即两名开发人员同时构建同一部分代码;二是集中办公(colocation)，即团队成员尽可能地待在一起工作。至于业务用户，敏捷开发方法则要求他们在整个过程中扮演极其积极主动的角色。他们必须与IT人员密切合作，共同确定每个迭代的优先事项。他们还必须每天为IT人员明确方向需要开发什么样的功能。

　　布道：敏捷开发优点

　　让IT团队改用敏捷开发方法面临的挑战主要在于：克服他们的阻力。IT团队已经习惯于使用旧的开发技术和方法，而且一直用得很成功。此外，他们听说过敏捷开发项目的许多失败案例，于是对此抱有怀疑态度。向业务主管宣传敏捷开发方法的优点同样面临挑战，因为无论是从外面请顾问教我们一套新的方法，还是购买实施这套方法所需的新工具，费用都相当高昂。另外，业务主管们必须接受这个事实：由于IT人员要学习新的开发技术和方法，新项目短时期内需要花费更长的时间。

　　于是，我列举了IT部门需要改变的理由：如果我们可以更快地交付优先级最高的功能，我们会得到怎样的好处。我不断重复IT人员能从中得到的好处比如敏捷开发方法可以让软件开发人员不喜欢做的许多单调乏味的任务实现自动化。对代码进行改动后，敏捷开发方法可以自动将代码与其他代码集成起来，并执行事先定义的回归测试。大多数IT专业人员不喜欢手动执行这些任务。

　　我也列举出业务部门需要改变的理由：丰厚的投资回报，对提高开发过程效率、更迅速地交付所需功能，以及减少在建项目(work in progress)总数带来的好处进行量化;敏捷开发方法有望把开发人员的效率提高35%;业务驱动因素可以跟踪分析获得的投资回报等。

　　尽管我们有几十个项目团队和几百个开发人员，但我还是竭尽全力，抽时间(曾有几段时间约占我三分之一的工作时间)与开发团队交流，听听他们关注的问题。从中了解到他们对要求严格遵守敏捷顾问规定的做法有抵触情绪。开发人员尤其不喜欢被迫坐在别人旁边结队工作;他们认为自己能够自行决定要不要采用那些开发方法。

　　我担心的是，如果我们不遵守这些开发方法，就会错失敏捷开发方法带来的显著效益。于是规矩：每个人一开始都要严格遵守敏捷开发方法，等到他们对这些方法深入了解后，可以稍加改动;等到真正了解这些方法，可以自行决定采用哪些方法。到目前为止，采用过这些方法的人大多决定长期采用下去。

　　平息：敏捷开发风暴

　　尽管我做了很多努力，但并非各方面都进展顺利。新的团队通常经历四个阶段：组建期(forming)、激荡期(storming)、规范期(norming)及执行期(performing)。我当时并不知道，当你改变了现有团队的基本工作方法，他们会在组建期阶段故伎重演。

　　多年来一直协作很好的团队突然开始出现激荡行为，包括态度出现波动、为无关紧要的问题而争论、过度紧张、担心工作过于繁重。如今我在确保这些团队在经历转型过程中，能够意识到这一点：他们需要重新设定规范;需要为此留出时间。

　　改变工作最终取得了成效：九个月后，敏捷开发方法兑现了承诺。软件开发的迭代方法提供的反馈回路，让我们可以开发真正所需的功能。原有的瀑布开发方法固有的浪费问题不复存在。由于每天不断地相互联系，以及敏捷开发方法帮助IT人员更清楚地了解业务，敏捷开发方法让IT部门与业务部门的关系更加紧密。

　　正如确实会收到成效的任何技术一样，敏捷开发方法大大改变了IT和用户。对于想要把本企业带上敏捷开发这条道路的CIO们来说，有必要重温一下变革领导力方面的最佳实践。最重要的是，要创造一种环境，让你的团队自然地表达他们担心的问题，那样你就会知道什么切实可行、什么需要相应改动。