Phil Abernathy谈敏捷项目治理和Suncop的敏捷转型

　　InfoQ的Shane Hastie有机会采访Philip Abernathy，请他谈谈在澳大利亚Suncorp公司内实施组织级敏捷转型的经验。Phil是该公司敏捷转型核心团队的关键成员，领导了这家员工超过20000人，其中IT员工超过4000人的金融机构实施敏捷转型。敏捷方法已成为“我们做事的方式”，并给公司带来数百万美元的收益、同时大大降低了新产品投放市场的时间。在如此之大的组织内实施变革需要自上而下投入大量成本和投入。Phil自2007年起成为领导团队的一员。他同时也帮助成立敏捷学院（Agile Academy），用以和澳大利亚与新西兰的其它组织分享在Suncorp实施敏捷过程中取得的经验。

　　首先非常感谢你能够在百忙中抽出时间接受我们的采访并精心准备。在采访开始之前，你能否向我们简单介绍一下“Phil Abernathy是谁”—— 就是简单谈谈你的背景和加入Suncorp的经历

　　你看我已经头发花白了，我在IT业内干了29年。我是在壳牌石油开始了程序员生涯，并在那里不断成长，和许多人的发展经历类似，我先后做开发、系统分析、设计、架构、咨询并最终做到壳牌石油阿曼分公司的CIO。在为壳牌石油工作了15年之后，我离开了壳牌石油，在这15年的工作经历中，我在很多地方都工作过，比如文莱、马来西亚、英国和其它一些地方。离开壳牌石油之后我在荷兰创建了自己的IT公司，专注于敏捷软件开发。这是95到96年的事情了。我的公司逐渐成长到120人的规模，为美国和荷兰的客户提供服务，并在印度有一家软件工厂，我们做过各类敏捷项目，公司运营了12年。

　　由于个人原因，我要搬到澳大利亚去。在卖掉了荷兰的公司后我举家搬迁。在澳大利亚，我加入了ThoughtWorks，成为他们敏捷大学（Agile University）的主管。我创办了敏捷大学并把它变成全球业务，但他们最终决定投入到其它的业务中，在那时我决定离开并成立自己的咨询公司。然后，Suncorp雇佣了我，要我帮助他们开启他们的敏捷之旅。

　　关于Suncorp的经历，最近有很多新闻报道Suncorp在澳大利亚开展的业务。你能解释一下Suncorp的敏捷之旅是怎样的吗？

　　Jeff Smith在2007年初加入Suncorp担任CIO，在了解了Suncorp的情况后他发现显然Suncorp需要事半功倍的做事方式。在2007年Suncorp面临一个巨大的集成项目，因为那时Suncorp刚刚与Premina合并。他们从一家10000人的公司一下子变成20000人，几乎翻了一倍；IT部门也翻了一倍，很多集成项目和风险需要管理。快速增长的业务，更快的市场反应和风险，这些促使Jeff思考如何事半功倍的做事。

　　Jeff根据他以往的经验知道敏捷方法是满足这些需求的唯一方法。因此他在那时开始主导敏捷方法。首要的问题是“什么是敏捷？”，因为如果你问5个敏捷大师的话你能得到6种意见。因此我在这个时候加入，与我一起加入的还有Katrina Rowett，他负责整个转型计划。Jeff把采用敏捷方法作为转型计划中的重要部分，而非那种“让我们开始敏捷吧”的尝试。敏捷方法成为新的工作方式，而不仅仅是一种软件开发方法，在给公司内部做的首次展示中，公司给了敏捷方法一切所需。因此我们的做法时自上而下推广敏捷方法，凡是和IT相关的业务都涉及，包括项目治理、基础设施、维护和支持、产品支持、电话系统和整个软件交付流程。

　　在组织内自上而下推广敏捷方法？

　　没错。

　　那结果如何呢？

　　有大量的工作要做，开始估计需要3到5年完成转型。我们回顾了过去24个月的成果，觉得我们的敏捷之旅走完了一半。当然还有很长的路要走，不过我们的确取得了巨大的收获。

　　Suncorp通过实施敏捷节省了数百万美元，同时整个集成项目在预算内按期交付。这些都是损益账户上确凿的数据。他们不是那种没有说服力的收益，而是可测算的。这些从实施敏捷方法、在很多情况下仅仅是从实施持续改进所获得的收益被量化后，可以从明年的预算中减掉。

　　如果说是敏捷方法的成功的话，那么的确是巨大的成功，整个Suncorp的IT管理团队、CEO、管理主管和董事会都非常确信实施敏捷方法是正确的选择。我们用实实在在的数据赢得了他们最大的信任和认可。企业通过成本削减、更快速的市场交付和仅仅用敏捷的方式思考获得了数以百万计美元的成本节省。

　　因此这是个伟大的敏捷之旅，话虽这么说，不愿改变的情况也相当多见，因此转变拒绝改变的心态仍需要做很多艰苦的工作。实施敏捷是企业文化的转变，改变一个企业的文化需要慢慢来，这样人们才愿意加入敏捷之旅。有些人已经接受了敏捷方法，有些人正在进行转变，另有些人仍对敏捷方法持怀疑态度，需要更多信心，这也就是为什么敏捷转型管理计划全程支持敏捷转型之旅的原因——支持企业的转变。

　　你提到了可测量的收益——你能和我们分享一下具体情况吗？这是机密吗？

　　嗯，我没法在不透露机密信息的情况下说明具体的情况，不过我可以解释一下一些简单的指标。

　　在每个大型公司，你都可以看到很多项目可行性研究阶段就持续数年以上。采用敏捷方法后，很多项目在经历了两周的敏捷开发后就被终止，或者需要做出很大调整，这就帮助公司节省开支和避免成本浪费达几百万美元。

　　实施敏捷方法之后的另外一个例子是：大型解决方案，比如网上银行，我们能够在6到8周完成，相比其它公司他们需要花费上百万美元开发同样的的解决方案，甚至有些以失败告终。

　　项目动辄超过5千万美元，比如最近另一家金融服务机构近期宣布要实施的，在我们公司已经不存在了。我们谈的是小于1百万美元的项目，这些项目能够非常迅速的在几个月内通过评估、审批、计划并实施。低成本高效益的项目能尽早交付业务价值，缩短了推出市场的时间，这些都确保了我们的竞争优势。

　　我们还把敏捷方法应用于维护和产品支持领域，缩短了交付周期同时提升了系统的可靠性。自动化测试节约了我们一大笔钱，因为自动化测试能够对遗留系统进和web前端行全面测试。这是之前我们从未做过的。

　　简单来说，从第一天起在很多方面敏捷方法都为我们节约了大笔开支。

　　在Suncorp的敏捷转型项目中，哪些是最好的东西？

　　我认为最好的自然是敏捷学院（Agile Academy），Suncorp出资创建了它。当开始敏捷之旅时，我们认识到培训和指导是成功的关键因素。我们在市场上寻找但发现很少有适合的，因此就开发自己的培训。Suncorp投资开发课程，现在我们创建了一个有25门课程的系列培训，覆盖敏捷转型的方方面面。通过敏捷学院向业界提供培训，敏捷学院是一个采用合伙制的非盈利组织。

　　我想这确实是一个亮点，因为在2008年2月的时候人们才开始觉得敏捷学院走上正轨，并认识到我们提供的不仅仅是口头上的好处，而是实实在在的承诺和在背后投入。

　　第二个好处是，让高级IT管理团队认识到敏捷方法确实能够提供巨大的收益。他们通常都是抱着”试试看“的心理开始，但当他们看到敏捷方法不是那种华而不实的宣传或仅仅是让Java程序员做出一些“酷”东西的时候，他们就100%买敏捷方法的账了。

　　第三点，我认为业务人员反过来对IT部门说：“天哪，我们跟不上你们交付的速度”，这是让人瞠目结舌的事情。因此我认为得到业务人员的全力支持是件有些让人吃惊的事情，因为很多人都说业务人员拒绝变化。但是实际上我们的情况正好相反。业务部门是最早接受敏捷转变的部门之一，因为他们看到了直接的收益。

　　最大的挑战是什么？

　　挑战一波接一波的到来。第一个挑战是对敏捷的无知。这种对敏捷的无知造成某种程度上对未知的恐惧。因此当我们通过“敏捷启蒙”计划来克服这个恐惧后，人们开始认识到敏捷真正的意思。

　　下一个恐惧是：“老天！我们该怎么做？”这是一种能力上的恐惧。公司里几乎所有人，从初级员工到资深经理都能感受到这种恐惧。我们通过指导、培训和职业支持来克服这种恐惧。

　　第三个层次的恐惧是担心自己的职位不再需要。这个恐惧是担心丢掉工作。这时正逢市场急转直下。因为市场崩溃，Suncorp和大多数企业在过去两年中做的一样，通过大量裁员来重建组织。这样人们就担心在通过敏捷方法提高生产力后，可能有些职位就不再需要了。可能中层管理人员就不再需要，可能只需更少的业务分析师，没准项目经理要被裁掉。这些都是猜测。实际上我们需要得更多。这些角色之间有明显的区别，他们共同工作、相互影响，只是换了个方式。但他们的角色还是需要的。当这个担心消除后，阻力就大大减小。

　　这就是我们面对的三类主要挑战和我们如何通过耐心、支持、分享知识和传播信息来克服这些挑战的实践。

　　Suncorp是一家金融机构，一个常听说的观点、或者说是猜测，敏捷项目在严格机制的环境中不容易实施，是这样吗？Suncorp如何克服这个问题？

　　我认为你说的对——这只是一种猜测而非事实。

　　当我们开始实施敏捷的时候，给你举个小例子，我们有这么一个敏捷项目，人们找到我，说“这个项目的业务需要严格遵循规则。我们要和财政部合作，敏捷方法在这个项目中不合适。审计人员不会喜欢敏捷方法的，他们甚至不会审核通过这个项目。”因此我们问审计人员是谁。“哦，X&Y公司提供审计。”接下来我问：“那你们问过他们了吗？”“不、不、不，还没有，不过为觉得他们不会同意的。”我说“好吧，那我们就和他们谈谈。”我们给审计师们讲解了敏捷方法，开始之前很多人，包括审计团队都满脑子疑问，他们觉得敏捷方法就是失去控制、混乱的、适合牛仔蛮干的方法，并不严谨。然而，敏捷方法是非常严谨、严格受控的，也是有纪律的。因此当我们给他们看了我们的产物：包括控制点、审计事项、用于敏捷方法的风险缓解技术之后，他们非常满意，在多数情况下比已有的方法更满意，因为敏捷方法最终能给出更快的反馈和风险控制。

　　另一方面项目需要遵守APPRA规范。我们给他们展示了敏捷过程，敏捷过程符合所有的APPRA需求——我们交付了高安全性的系统，系统符合所有的APPRA条款，在这个项目上，敏捷方法和在其它项目上一样，取得了很大的成功。

　　项目治理结构如何对敏捷方法构成挑战？

　　嗯，这是个有意思的问题，因为有两个层次的项目治理会影响敏捷项目。

　　第一个层次的项目治理我称之为“做正确的事”。这是包含了整个筹备中项目管理、项目组合管理、潜在客户管理中的业务需求，然后觉得哪些需求需要着手解决。应用敏捷原则和精益原则来管理潜在客户是一个“必须包括”的关键项目治理。生成在一个项目上合作的跨职能团队对于增加软件项目交付总量和生产效率来说是最为关键的。对潜在需求进行节流控制、排列优先级和管理处于上升期的项目是敏捷项目环境中的关键项目治理活动。

　　第二个方面是“正确的做事”。这些项目治理关注正在进展中的项目或项目集管理。这些项目级的治理需要符合敏捷项目的节奏，可驾驭并能够对敏捷项目快速的交付周期做出响应。

　　如果你的项目迭代周期是两周然后你给进行项目治理的一个委员会做交付展示（showcase），然而他们需要3周才能批准交付物，这样是无法工作的。所以批准和控制周期需要和项目的周期一样。否则你就是在浪费资源，人们无所事事或者就是在没有批准交付物的情况下工作。有时项目团队因为只能等待批准交付物而被解散，日后让他们重回项目团队非常困难。

　　总之，两个需要和敏捷环境相适应的项目治理领域是项目组合管理方法和项目管理节奏。对于其它方面适用同样的原则。你需要管理项目范围。你需要管理项目时间。你需要管理项目成本。你需要管理项目收益和风险。因此你需要考虑这些问题，在这些领域没什么不同。

　　你认为其它公司可以从Suncorp的经验中学到什么呢？对一个组织进行敏捷转型需要采用哪些呢？

　　我可以把这个问题分成两部分：如何实施敏捷转型，然后是经验总结。

　　首先一个基本的事情是信念。相信敏捷方法可以在组织中发挥价值能起到促进作用。目前这个信念还不能被证明。你无法说先给我证明看看然后我才做，因为人从不相信别人告诉他们的事情。就像某人曾说过的：“人可以不相信他们看到的。人可能相信朋友们说的，但人们绝对相信他们自己的想法。”因此来自领导团队的信念是非常重要的。

　　Steve Jobs在给斯坦福大学的讲演上说过，“在刚开始的时候点之间是不会链接起来的”。你可以通过观察、直觉、经验和尝试来构建你的信念。在你没有真正相信之前不要开始大的转变。如果你还没开始做出转变你可以小规模的尝试和验证它是否能工作，看其它成功实施的案例，思考另外的观点和任何有助于做出承诺决定的事情。一旦真正确信，那就开始做。

　　一旦决定做出向敏捷工作方式转变的决定，那就把它视为一个严肃的变革计划，因为需要对企业文化做出大量改变。你思考的方式、工作的方式、合作的方式、交互的方式都会因为采用敏捷方法而改变。

　　所以需要承诺。这是第一件事。

　　第二件事情是你不必一次做所有的事。饭要一口一口吃。进行敏捷转型需要时间的。你可以由一个小的方面开始，然后你让它增长，然后你再慢慢的扩展。在全程提供培训、指导、沟通和变化管理等形式的支持是非常关键的。

　　如果你不提供支持只是说“让我们开始敏捷吧”，你不会得到任何敏捷方法提到的收益。看看Suncorp就知道：

　　Suncorp在Jeff Smith加入的5年以前就开始尝试敏捷方法。大约是在2002年。第一个敏捷项目启动但只是在小打小闹，因为他们没有得到高层管理团队的承诺，无论团队证明他们做的多好，其它团队只是看着，并且出于对变化的恐惧，他们说“那（敏捷方法）并不适用于我。我们项目和他们的项目显然不同。我知道他们能做成，但我们的项目办不到，因为⋯⋯”

　　很多大型组织在2000年早期都小范围尝试过敏捷方法。这些尝试大多数都非常成功。然而多年后他们能展示得出的成果只是几个实验项目。因为他们没能提供支持和得到在组织内推广的承诺。

　　因此信念和高级管理团队的支持对于敏捷转型来说至为关键，和其它变革转型计划一样。

　　现在我再谈谈经验和如果再让我们做一次，哪些地方我们可以做得更好。哪些地方我们可以改变，等等：

　　第一件事是我们开始就面临很多困难，因为在整个过程中我们没有系统的培训。因此我们花了六个月来开发培训。我们投入了大量努力，现在这些都可以为其它组织所用。不过我们因此付出了成本并延误了一些。

　　第二是我们应该更强调指导，而不是在要求下才去指导。我们最初的方式是“项目需要花钱得到指导，如果你需要指导的话就找他们”。猜猜发生了什么？我们项目的预算总是很紧张，从来没钱用于指导。因为没有用来指导的经费，他们也不做“Eliga”项目，或者我们称之为的“Tragile”项目，这是和敏捷方法背道而驰的。在这些项目是“啊，我们来开个站会（standup）吧，我们试试回顾会议（retrospective），我们来试试这个。”然后他们失败了，也没人帮助他们，因此项目面临很多困难，这种困难很不好，因为负面的经验传播出去，也让其他人对敏捷方法感到气馁。

　　因此回顾过去，我会建议其它组织必须要得到专家的帮助和指导。不仅是培训，而是培训和指导——我们现在称之为“训导（Troaching）”。

　　第三是得到各层管理者，从上到下而非仅仅是高级管理人员的承诺非常重要，而这些承诺也不能只是口头承诺。必须是绝对的认同和取得领导团队的信任。这需要花很长时间，并且这也就是转型之旅的一部分。

　　你刚才提到了敏捷学院（Agile Academy），说你们通过敏捷学院把经验传授给其它组织。你能跟我们多聊聊敏捷学院吗？

　　现在敏捷学院提供了一组课程，这组课程包括大约20到25课，围绕一个成熟度模型展开，课程面向IT组织中的所有角色，包括分析师、测试人员、开发人员、项目经理、IT基础架构组长、业务领域专家、团队领导和高级经理。这些课程能让他们从“我一点儿不了解敏捷方法”，到“我是敏捷方法专家”。然而他们同时也需要在工作中得到指导。

　　一到两天的培训课程帮助学员了解培训课程的主干，包括针对不同角色的培训路线图。目前我们商量和一些合作方，如Software Education和ThoughtWorks，一起向业界推广。我们邀请其它合作方加入，以便不断成长，使澳大利亚和新西兰的IT业界从中受益。我们已经接到其它地区访问我们学院的培训材料的请求，比如阿曼、印度和中国，因为其它地方都不能提供向我们一样的整合完整的培训材料。因此从某种意义上说，敏捷学院的核心就是敏捷方法学习的知识中心。www.agileacademy.com.au提供更多信息。

　　这是一个冒险的挑战和创举。总结一下，你要走到多远？你的个人计划是什么？Phil Abernathy的雄心有多大？

　　好吧，我总认为自己是个炼金术士和变化的催化剂。是那个形成变化、推动变化和实现变化的人。我对IT业充满激情，有关我们做的一切，我总是试图改进我们做事的方法。不仅仅是提高工作效率，也是为了尝试完全不同的做事方式，并乐在其中。敏捷学院就像是我的孩子，但是它已不再是个孩子了。他完全长大了并开始快速成长。Phil Abernathy期待下个做出变革的机会，做些不同的事情。

　　Phil，谢谢你接受采访。

　　非常感谢，Shane。

　　查看英文原文： Phil Abernathy on Agile Governance and Suncorp's Agile Transition