郭晓：敏捷文化里更需要的是领导力

郭晓：敏捷文化里更需要的是领导力 (1)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

【赛迪网报道】敏捷方法已经在全球范围内成为公认的主流软件开发方式，其对软件开发方法论的贡献至少可以从两个方面体现出来：人比过程更重要；对变化的态度。敏捷对预测未来的方式是全新的，强调通过提高团队的能力、设计的弹性和流程的灵活性来适应变化。以上内容是ThoughtWorks中国区总经理郭晓先生于9月14日在北京举办新闻发布会上提到的，与此同时就瀑布式开发、敏捷文化、如何学习和掌握敏捷开发、敏捷在中国现在的发展状况以及敏捷开发与云计算等问题，郭晓先生接受了赛迪网记者的专访。

 

 

 

 

郭晓在ThoughtWorks已经超过十年了，最开始做开发，从九几年开始使用敏捷开发方法。敏捷十年更多接入2001年敏捷宣言提法提出来的，作为一个里程碑式的说法，叫敏捷十年。实际上敏捷在这个行业里已经存在了非常长的时间，1999年的时候，第一次使用敏捷开发方法，十年过去了，作为敏捷开发的实践者，有什么样的反思和总结呢？今天最主要的是与大家一起分享郭晓本人在这方面的思考。

 

非常有震撼力的报告

在01、02年的时候，ThoughtWorks做了比较大的敏捷开发项目，这个公司叫Forrester，是一个分析师，他的研究报告比较有特点的一点是完全是用数字说话，他对ThoughtWorks做的很多类似项目，和其他公司项目的使用不同开发方法做了一个比较，得出了一个报告，这里比较重要的图表就是他提出敏捷在使用敏捷方法之后，他叫做对总体的拥有成本造成的影响是缺陷率降低了63%，核心的缺陷率降低了79%，整体投入的付出的努力减少了62%，整个项目开发的时间缩短了69%。这些发现做成了一个报告，非常有震撼力。

郭晓：敏捷文化里更需要的是领导力 (2)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

最痛恨的报告之一

实际上这是最痛恨的报告之一，为什么呢？因为作为一个敏捷开发的实践者，如果有人跟你说敏捷的目的是为了提高生产效率，是为了减少缺陷率，从某种角度讲是正确的，但某种程度是讲的敏捷副产品而不是敏捷的核心，它没有思索软件开发的本质、敏捷开发的本质。

 

 

瀑布式开发

实际上来源于工业生产的偏见，制造业追求的所有东西都是生产效率，怎么能提高生产效率，更快的生产出产品，更快的使工人的生产的产品速度提高。实际上这种追求跟软件的开发是完全不一样的，在工业化生产里，可以看到它实际上是一个大量的生产的过程，完全可以把流程分解成很多微小的步骤，这是福特对人类做出的巨大贡献之一，把生产流水线以可分割的方式，从设计结束到把每个生产步骤，做成重复生产的模块，工人不需要什么培训，很快的就可以学会怎么操作，迅速生产出相当不错的汽车。这种方式把人固定在非常小的环境里，重新某一个操作，变得非常有效率，这个思维对软件产生了很大的影响。软件刚刚出现的时候，四、五十年代那时候程序员是非常像牛仔，基本自己写一点跑一下卡片机，有什么文化修一下，没有任何流程控制可言，造成的结果是任何软件开发的项目没有任何人预测什么时候做完、质量怎么样、需要多少钱，导致商务部门非常恼火，为什么不能给我一个计划。在60年代末，北约开了一个会，第一次提出了软件工程这个概念，把工程学里的做计划、分步骤、做设计、做分析、编码、测试，把这套体系提出来，叫瀑布式开发。

 

郭晓：敏捷文化里更需要的是领导力 (3)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

瀑布式开发方式对软件开发的一种扭曲

这种瀑布式开发方式完全对软件开发的一种扭曲，软件开发作为知识型的产业，完全跟工业化大生产的制造业和工程学的建筑工人从事的工作方式完全不一样，是一种创造性的、高附加值的、学习人的主观能动性的一种工作方式，完全不是制造业的，只需要一个人把某个步骤的效率提高。另外软件开发本身也是跟制造业完全不同的一种行为，软件价值并不在于多长时间内生产多少代码或者做出多少份软件，价值在于给业务提供了什么价值，把什么行业企业的行为转换成给他的企业客户提供价值的手段。软件作为催化剂，价值并不是以软件本身衡量的，而是在生产过程中使的最终客户得到什么价值。敏捷开发实际上是从90年代到现在，不断的进行的一个行为，是软件行业本身对软件开发的本质在做出的思考。传统上的追求效率、追求生产率、追求产出，实际上是一种很错误的思维。而我们在思考什么是软件，什么是软件，有什么特性。

软件开发并不是把人当作机器

这里提到的是开源软件这个概念，开源软件除了说它本身版权上的贡献以外还有一个很有意思的特点，这些开源软件基本上所有程序员利用自己的业余时间做出的东西，这里值得思考的事情是为什么这些人会有这样的兴趣做出一些对自己没有商业回报的一些事情。还有一点是以Linux作为例子，它稳定性、质量非常出名，同样跟这个操作系统比起来优点非常明显，绝大部分商用的大型的企业级应用部署在Linux开源代码平台上的，而开源软件怎么组织的，为什么使程序员有这么大热情参与做出这种软件，这对敏捷开发本身思考敏捷开发背后的理念很有借鉴意义的。因为软件开发并不是一个以追求人作为机器一样尽快发挥出效益出来。而软件开发者，如果想做出更好的软件，更有价值的软件，要思考的不是画一个框框，以什么方式运作。而是让他怎么更有热情、动力，主动的想怎么写好软件。

敏捷并不仅仅是技术上开发方法的变革

所以说敏捷实际上核心是完全不同的管理文化，在谈到敏捷的时候，很多人看到它的不同的方法论、流派，在很多细节上有所贡献。在70年代末出现了很多方法，汇总之后很多人觉得这些具体的方法有很多相似的地方，在01年的时候，所有方法的最有影响力的人聚在一起提出敏捷宣言四条，实际上敏捷在经过这么多年发展最终体现的并不仅仅是技术上的开发方法的变革，而是实际上是对一个软件开发行业的不同的管理方式。

 

郭晓：敏捷文化里更需要的是领导力 (4)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

敏捷文化里更需要的是领导力

经常看到敏捷里强调一点，每个程序员都是一个软件设计者，也是软件的测试者。这个例子是跟工程学、制造业的方法套用过来的模式是完全不一样的。敏捷开发里，每个程序员应该承担不同的角色，在编成以外对软件设计、测试做出自己的贡献。这种方法跟敏捷宣言里最核心的四条里的其中一条非常有关系，这一条就是People Over Process，它认为软件开发过程中，人的因素要比流程因素重要的多。作为管理者，作为一个项目管理者和IT部门管理者，他所应该重视的或者应该思考的，并不仅仅是怎么制定出一个流程，而是说怎么让这些人更好的发挥能动性，为他们提供什么环境，让他们怎么在这个环境里充分发挥自己的热情、主动性和能力提供更多的价值。这一点上，中国人的词汇用的比老外好的多，老外管IT管理者叫管理，管理就是管理这些人，理顺流程。中国人喜欢管这个人叫领导，领导这个词很好，带领、引导，并不是规定这些人应该怎么做某些事情。敏捷文化里，更需要的是领导力而不是管理能力。

 

 

敏捷十年

敏捷十年，简单回顾一下在过去十年，敏捷这个行业里最大的变化，刚才谈到八、九十年代有不同的流派、不同的方法产生，如果看最近十年，没有什么特别具有颠覆性的理论出现，敏捷方法在这十年最主要的进步表现在什么地方呢？其实它在横向扩展方面有非常大的变化。如果在2000年以前，即使是看极性编程的鼻祖，他认为极性编程只适用于6、7个人以下的小团队的。当时ThoughtWorks在最初采用这个方法的时候也是有一个挑战，当时有一百多个人的项目，采用了极性编程这个方法，它99年就开始了。ThoughtWorks主营业务是写软件，定制软件开发的公司，之所以谈敏捷，ThoughtWorks作为一个核心的理念，认为优秀的卓越的软件是ThoughtWorks所追求的东西。在这个过程中ThoughtWorks希望把理念分享给社区，敏捷开发只是使用的方法，而且积累了很多的经验，所以谈这样的事情。

 

郭晓：敏捷文化里更需要的是领导力 (5)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

企业范围内实施敏捷信心与日俱增

九几年的时候，加入公司的第一个项目，这个项目非常有意思，是一个租赁的非常复杂的体系，当时开发的时候先是写了很多文档，做了很多设计，一两年之后还没有交互任何东西，客户也很着急，还有六个月就要上线了，这种情况下，几个敏捷当时的一些先驱做了一个咨询，引上了这条道路，他们当时也很犹豫，这么大项目极性编程基本方法能不能使用呢？包括现在经常使用的IPM，摸索了很长时间，犯了很多错误，结果非常受鼓励。他们建议把所有文档都扔出去，这一百人的团队认为是极限了，所有人认为已经是对敏捷实践做出了某些挑战，不可能再进行扩展了。实际上05、06年，BT，英国电讯做了一个事情，他的CIO在行业里很有名，他非常强势，他是一个忠实的敏捷信徒，他认为敏捷是能够作为一个企业，给他带来巨大的竞争力。他要求所有的项目在几个月之内完全进行转型，BT有多少人呢？BT研发部门将近15000人，印度就超过了10000人。行业里很多人都很怀疑，15000人的团队不可能做敏捷开发的。ThoughtWorks当时也参与了，帮他们做咨询，怎么做敏捷实践，尤其是英国那边，怎么进行推广。实际上他最后收到很多成效，BT很多项目都是做两年、三年甚至更长，前面调研可能就要半年，设计半年，真正写代码的时候都已经一年多过去了。最后在BT团队里实现什么结果呢？所有项目不管多大，90天内必须上线。这种变化当时让行业非常震惊，在这么大的团队里，居然能拓展敏捷方法。所以有一些不同的意见，他没有完全的敏捷化，表面做了很多敏捷的工作，但这个实验对这个行业有很大的促进作用，很多IT企业在企业范围内实施敏捷信心增加很多。

推行敏捷过程最后变成了文化和组织的改变

ThoughtWorks前四年已经举办了四届敏捷大会了，国内包括参与的和看到的、听到的和跟ThoughtWorks经验分享的敏捷经验的，发现当敏捷尤其是涉及到比较大的组织和体系里，它所带来的影响可能不仅仅停留在技术这个层面，最终敏捷在大型企业里最后是对它的文化和组织结构产生了非常重大的影响。曾经一个合作的企业，将近有四万人的研发团队，实施敏捷大概两年多以后，某个角度讲他有一定的信心，很多行业大型企业都已经全面的进行敏捷实践，所以他们有这个信心做这件事情。最后负责敏捷推广的负责人跟郭晓说了一个很有意思的话，他说做到最后发现谈了这么多具体的实践，这么多改革的方法、管理模式，发现需要的是CCO，说需要一个对文化的改变，如果不改变文化的话，是改变不了这些实践的。举个例子来说，这个公司对生产效率，他作为一个企业有非常高的要求，他每个人都有一个KPI，很重要的是代码行数，这个代码行数实际上我们所有写软件的人都知道，这东西没有任何意义，可以写很多代码，但可能没有任何价值，可以重复拷贝。最后代码越来越多，敏捷有很重要的一条叫做重构，使得你的设计更加清晰，扩展性更强。这在公司推广的时候很难，一重构绩效就没有了。所以说推行敏捷的时候，推行过程最后变成了文化的改变和组织的改变，而不仅仅是技术。

 

郭晓：敏捷文化里更需要的是领导力 (6)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

谁能从敏捷开发中获利

经常遇到一个问题，谁能从敏捷开发中获利，如果说作为一个CIO、CTO，只是想怎么提高生产效率、减少缺陷率、尽快提高上线时间，他的目光是不够的。作为一个IT管理者，作为软件从业者，应该更多的思考软件开发的本质是什么，人在里面扮演什么角色，怎么使自己的组织发挥更大的价值，不是去管理，而是领导这个团队。这里最核心的是IT经理人有足够的勇气做这件事情。所有从事敏捷开发过程中，真正成功的，总结了两个层次，有勇气的管理者才能真正实施好敏捷。

作为一家软件开发的企业，除了在敏捷以外，其实最主要的业务是进行软件开发，作为自己的一个理想，能把卓越的软件世界上更广的推广开来。对技术方面有很多自己的看法，如果大家看一个新技术怎么被社区接受的，最初很少的人研究这个东西，到后来突然变得急热，然后进入冷却的过程，最后进入成熟期，它所面对的听众是满足于跟在后面使用行业里比较成熟的技术或者平台。如果你是一个有勇气的IT经理人，你现在应该看到什么东西，接受什么东西，你应该全力推广的是什么东西。这些人才能真正的在敏捷、技术层面更早的获得利益，更好的在竞争当中、同行当中脱颖而出。

 

如何学习和掌握敏捷开发

在管理理念上讲敏捷，实际上各个不同的角度，很多人认为敏捷是最佳实践的总结，怎么写一个软件，从对需求的理解，怎么组织团队，在项目中期采用什么措施，这一系列最佳实践统称为敏捷开发方法，在细微之处略有不同。敏捷作为一个整体的方法论，敏捷宣言提出核心一点是不会对某些具体的细节作为敏捷方法的总称做出评判，它是把不同类似方法进行提炼，作为一个敏捷思想提出来了。刚才提到人比流程更重要，是它比较核心的四个思想之一。再下一个层次，做软件设计的时候，不是先想好、设计好这个软件怎么做的，按照个人设计再写代码。反过来，他认为在我设计软件的时候我首先想的是怎么测试这个软件，用什么测试的条件、方法，有哪些流程，把这些想清楚了，针对测试的规范写软件，写的过程中包括最佳实践的使用，这个过程是先写测试，再写代码，是一个设计的过程，这个设计是通过不断演变演变出来的。测试驱动开发就是其中一个招数，作为一个团队、企业想接受敏捷，除了理念上要坚定决心，首先要想清楚具体的实践必然是一步步要做的，要花很长的时间学习这些基本的编程技巧和方法，才能在这个过程中不断的使用、理解，你才会对自己对敏捷有很深层的理解。

 

软件工程某种程度上是对软件开发的扭曲

提到软件工程概念对软件开发是个扭曲是随便说的还是有考虑的，首先这个说法是比较极端的说法，但行业里很多人，包括不管是做敏捷还是不做敏捷的，都有一个比较清晰的认识，软件开发作为知识产业跟制造业是不同的性质，还有二十世纪人类最掌握的核心技能是量产，而二十一世纪需要掌握的是大量的定制，软件是大量定制的过程，虽然某些软件作为产品能不断复制、使用，但每次软件开发过程都是重新创造的过程。谈到软件工程学对软件开发是一个扭曲，实际上是自己对软件不断的认识，在五、六十年代是没有什么选择的，刚开始是很无序的状态，项目无法把控，软件工程学这套理论所有人都很喜欢。还有瀑布式开发这篇论文里，那篇论文实际上是在否定瀑布式开发，他在说为什么不适应软件开发，有什么问题。现在好像使用瀑布式开发软件的方法远远比敏捷的方式多，但这并不意味着瀑布是合适的办法。从不同行业、谈对工作沟通，绝大部分一旦尝试和使用了敏捷式开发方法，就不再愿意回去再用瀑布式方法。但为什么瀑布式还这么普遍，应该更好的宣传、普及，使大家更好的了解敏捷开发。

 

郭晓：敏捷文化里更需要的是领导力 (7)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

缺陷率、生产效率和交付时间都是衡量一个软件开发团队或者组织的标准

缺陷率、生产效率和交付时间都是衡量一个软件开发团队或者组织的标准，这些东西都是结果，但能达到这个结果需要的是软件管理方式、软件开发方法、软件本质做出更深入的思考，用正确的方式做这件事情才会有这样的结果。很类似于一个比喻，一个企业，从管理学角度来说，利润是追逐的结果，实际上，所有管理学都认为，如果仅仅为了追逐利润、衡量利润的话，实际上会走很多弯路，做很多错误的事情。作为一个企业，应该想为客户带来什么价值，怎么更好的让企业持续的发展下去，利润是副产品，它是结果，但不应该是企业追逐的目标。CIO、CTO应该认为敏捷使他做出更有价值的软件，而不仅仅是成本降低、效率提高。

 

敏捷开发如何帮助开发团队解决问题

国内有一个小公司，他是一个互联网公司，叫做交易平台，虚拟物品交易平台，现在虚拟物品买卖，尤其是游戏、空间里交易很常用，他有一个商业想法，但他的团队开发角度讲实力比较差。他这个平台自己有想法，软件应该怎么设计，怎么为最终客户提供价值，他有了这个想法之后实施过程中发现如果说是按传统方法，可能六个月、八个月之后上线，有一套自己的客户反映，再继续往下演变。这个项目使敏捷的方法，跟他的员工合作，两三个月之后就上线了，后来发现一个很有意思的现象。他做虚拟物品交易平台有一个功能，什么功能呢？在进行交易之前先把它存在一个地方，再放到平台上交易，交易之后再进行物品的易手。存储功能很有意思，因为游戏里很有价值。他怎么发现的呢？是开发上线两个月之后研究用户使用习惯，马上开发了这个功能，到最终上线就用了两个星期的时间，把商业模式增加了一个全新的模式，这个CEO说传统方法很难进行这种改变的。但通过测试体系，整个过程中都能快速的适应变化进行调整，两周之内就对这样的业务模式做了调整，他的平台能起到支撑作用。这是敏捷怎么让开发做正确的事情的一个例子。代码行数这个例子是我经常举的一个例子，是对文化的一个影响。

 

ThoughtWorks怎么帮助企业达到“本”的

首先90%左右我们合作过的企业最终没有达到这个本，因为达到这个本是很缓慢的，一个文化的改变，作为一个企业，上到CEO下到所有员工都要对软件开发本质、流程做出一个认识。所以达到这个本是一个理想，不是一个轻易能实现的状态。在这个过程中，会看到有些公司对本的理解有了更深的理解，发生了很多可喜的变化。举个例子，有一个客户，他流程当中没有任何业余时间的，就是每天规定十个小时工作，排的非常满，在引入敏捷的理念过程中，他发现原来一味追求让这些人加长工作时间是有害处的，比如这个员工白天八个小时时间里，可能生产效率很高，但最后这两个小时生产效率也不错，产生很多代码，但实际上他发现最后这两个小时做的工作到第二天修改的东西很多。他采取的措施是什么呢？节律编程这个理念，两个人做一份工作他认为是一个非常不可以理解的措施，实际上他发现，这个过程中，他收获的最大的价值并不是代码行数变多了，同样的道理，他发现开发人员沟通过程中，讨论的更多的是对客户需求的理解，对软件价值的体现，怎么更好的提高软件的设计，最后交付出的软件更符合客户的需求，更让客户满意的一个软件，少走了很多弯路，这个过程中他发现对他的影响并不仅仅体现在代码行数和软件质量上，而是更加相信写出好的软件是他企业能够更好的生存下去的最根本的因素。

 

郭晓：敏捷文化里更需要的是领导力 (8)

发布时间：2010.09.17 17:10      来源：赛迪网     作者：徐培炎

 

敏捷在中国现在的发展状况

从五年以前，更多的是很多人知道敏捷这个概念，属于草根性行为，有人看过书，在做一些简单的实践。到08年属于一个普及的阶段，开始行业里除了ThoughtWorks，有很多不同媒体、平台开始宣讲敏捷这个概念，有很多不同的组织和活动探讨敏捷的目的、操作方式和所能带来的价值。最近09、10年这两年，感觉敏捷在不同的企业和社区里开始有更多的探索性的实验，可能并不是全部的开发团队，但比如中国移动研究院oPhone就是用敏捷开发的。这些使用敏捷方法的企业比较有前瞻性，比较需要具有技术竞争力的企业，既可能是大企业，也可能是在某些方面有需要的企业，从比例来讲，可能非常小，数目来讲绝大部分还是在用瀑布式的开发。而国外呢，可能有60、70%的企业全面的使用敏捷的开发方法，所以差距主要是体现在国家的广度以及深度，深度就是很多中小企业三、七开，而且还有很多伪敏捷，并没有更好的使用。敏捷方法的实施是跟行业的能力、基础成正比的，当能力有很多需要提高的地方，使用敏捷也有很多的困难，能力是开发人员和IT企业的成熟度。

 

敏捷开发与云计算

云计算有一个特点，利用云这个平台，利用弹性从部署的角度讲，利用云的弹性解决很多在开发时候产品的性能问题，比如最大的亮点是有很多的案例，包括微软有很多案例，一个小型企业设计了一个平台，在互联网上应用，过段时间变得非常热，用户量从几百个增加到几万个，传统的部署环境里无法实现，但云的平台上可以实现，可以突然容纳这个容量，过了一段时间又掉下来了。如果实现这一点，需要程序员编程的方式和方向，对部署的理解，对怎么能够使我的软件设计具有弹性是有很高要求的。这里还有一个要求是敏捷的最新的前沿，对这个要求有一个匹配。就是说敏捷现在比较新的，持续交付和开发运行维护的结合，这个概念的背后理念是说，敏捷开发很多时候解决的问题是开发过程中，上线之前怎么有效的把握客户的价值，更好的做出正确的软件，让团队发挥更大的价值，没有涉及到软件上线以后，或者上线过程中怎么操作的，很多最佳实践，包括TDD、重构，全是上线之前的最佳实践。持续交付是不断的编译、测试，放到部署环境里部署，有大规模的自动化实现，把产品从开发环境里部署到生产环境里。云计算的弹性应用是要求你自动化的部署，平台已经搭好了，我写一个应用，怎么突然适应一万个人的用户量，实际上在计时的做了一个部署，突然把应用部署到了更大的虚拟的环境里，这个过程是云计算平台不能提供给你的，作为开发人员、作为应用，你要能做这件事情，自动化的做才能用好云计算。所以从敏捷的概念，对部署的自动化的理念，实际上是会是将来从一个云计算的使用者的角度讲，作为开发的群体需要很好掌握的一项技能，只有有了这样的技能才能很好的有效的使我的应用很好的利用云计算提供给我的能力。否则的话就像给我一台强悍的计算机但我不知道怎么使用。对云计算平台提供商，没有什么太大的影响。