小编自己做了一个电子书下载网站，网址：

    谢明志 著

    企业转型、升级与再造之道

    敏捷思维：移动互联网和大数据时代IT目录

    序言一

    序言二

    序言三

    序言四

    序言五

    前言

    第1章 敏捷思潮

    1.1 变革悄然而至

    1.2 最简单的敏捷交付

    1.3 百家争鸣

    1.3.1 极限编程

    1.3.2 水晶方法

    1.3.3 动态系统开发方法

    1.3.4 精益生产1.4 Scrum

    1.4.1 发源与发展

    1.4.2 自我管理

    1.4.3 七经八络

    1.5 敏捷旅行

    1.6 敏捷实施报告

    1.7 案例分析：IBM的敏捷转型之路

    1.7.1 转型历程

    1.7.2 品牌的力量

    1.7.3 核心竞争力

    1.7.4 敏捷品牌

    1.7.5 成功转型

    第2章 敏捷落地艰难

    2.1 敏捷实践误区

    2.2 理论的局限性2.3 传统团队践行

    2.3.1 挑战传统管理

    2.3.2 PMBOK理论

    2.4 敏捷实施法则13条

    第3章 大企业的敏捷转型

    3.1 重新诠释敏捷宣言

    3.2 新敏捷扩展模型

    3.2.1 规范性敏捷交付方法

    3.2.2 新敏捷思维的延展

    3.2.3 案例分析：“唯衣定制”——ASM框架下

    的制衣品牌

    3.3 持续改进转型模型

    3.4 案例分析：IBM Rational中国的敏捷转型

    3.4.1 统一的研发流程

    3.4.2 流程开发的利器3.4.3 研发转型的困境

    3.4.4 定制企业开发过程

    3.4.5 规范性敏捷管理

    3.4.6 满足客户

    3.4.7 培养客户关系

    3.5 故事分享：Rational中国敏捷开发者的一天

    第4章 初创企业的敏捷转型

    4.1 初创企业的敏捷思维

    4.1.1 使用瀑布式的初创企业必亡

    4.1.2 开发新商业模式

    4.1.3 以客户为中心的价值主张

    4.1.4 抛弃以产品为中心

    4.1.5 过硬的产品

    4.2 以客户为中心

    4.2.1 敏捷交付4.2.2 建设敏捷团队

    4.3 如何解决人事危机

    4.3.1 快乐才是我的目标

    4.3.2 人才流失

    4.3.3 构建人文环境

    4.4 人格与职业

    4.4.1 荣格人格类型理论

    4.4.2 16种人格类型及其特点

    4.4.3 团队“人格”

    4.4.4 择“优”录取

    4.4.5 SJ型与SP型人格的任用

    第5章 敏捷型人才的培养

    5.1 如何培养自我管理的秉性

    5.2 如何培养自知之明的秉性

    5.3 如何培养自律的秉性5.4 提供上升空间

    5.5 团队的沟通

    5.5.1 “听”的哲学

    5.5.2 “说”的魔法

    第6章 非凡的测试

    6.1 故事分享：从测试工程师成长为敏捷测试

    工程师

    6.2 决策影响力

    6.3 合理投入

    6.4 “等待”和“浪费”

    6.4.1 仅仅足够好

    6.4.2 理性规划

    6.5 自动化敏捷测试

    6.5.1 自动化的落足点

    6.5.2 ROI指标判断6.5.3 自动化测试的ROI

    6.5.4 合理的投入

    6.5.5 自动化回归测试

    6.5.6 敏捷测试的自动化

    6.5.7 与传统自动化的对比

    6.5.8 自动化的ROI

    6.5.9 小结

    6.6 故事分享：Rational中国敏捷测试工程师的

    一天

    6.7 选择自动化工具

    6.7.1 度量尺度

    6.7.2 量化指标

    6.8 案例分析：改进自动化工具

    附录A 有关敏捷思维、敏捷转型的常见问题和回

    答附录B 第二代敏捷猜想

    附录C 敏捷大赛评分规则

    结束语

    参考文献序言一

    我作为最早加入摩托罗拉中国公司研发中心

    的人员之一，在IT通信行业工作了超过20年。和

    明志的经历相似，我早期主要从事测试方面的工

    作，而后又参与了开发、系统集成等工作，亲身

    经历了开发中心从最初的十几个人发展到上千名

    工程师的辉煌。我在10年前离开摩托罗拉加入

    NEC后，又开始侧重于市场、销售方面的工作，直至负责公司的全面运营管理。我看到一般大型

    企业尤其是外企的产品研发和市场运营都采用按

    部就班的模式，虽然有其严谨的一面，但有时不

    免效率不高，很可能由于一个环节的拖延造成整

    个项目的延迟。明志书中的敏捷研发和敏捷管理恰恰另辟蹊

    径，开拓了另一片天空。在摩托罗拉等外企衰落

    的同时，华为等一批国内企业快速成长，成为市

    场上的领军企业。众所周知，华为聘请IBM为咨

    询顾问，任正非总裁曾经说IBM是最好的老师，明志也参与了其中的项目。华为把IBM的敏捷研

    发和敏捷管理灵活应用于软件研发、项目管理甚

    至客户服务流程中，取得了巨大的成功。

    在书中，作者不仅对敏捷方法进行了系统和

    详尽的描述，还论述了如何在大型企业和创业型

    企业中应用敏捷，如何避免容易出现的问题和误

    区，结合大量的案例和切身经历深入浅出地讲

    解，以便读者理解和掌握。此外，书中也融入了

    许多关于管理和人才的讨论，例如人才培养和潜

    力发掘的相关内容，使方法、工具与人得以有机结合。

    随着微信的普及和碎片化时间的利用，很多

    人放弃了系统的读书习惯。2012年，几位资深创

    业人秋游西山，有感于当前知识信息碎片化、社

    会功利浮躁、精神交流匮乏以及人际信任缺失，组织了学习互助型群体，现已形成以创业家为主

    体，同时包含金融投资家、企业高管、资深媒体

    人、专家学者在内超过一千人的西山读书会。明

    志和我皆是西山读书会的成员之一，每天读书也

    已成为习惯。本书的出版面世，从管理学的角度

    带来了新的思考，希望书中的内容能够给广大读

    者以启迪。

    丁伟

    NEC通信(中国)有限公司常务副总裁序言二

    武林至尊，宝刀屠龙，号令天下，莫敢不

    从，倚天不出，谁与争锋!21世纪初的科技界，一如武侠场，英才辈出，新式武功不断显现江

    湖，而在一场场移动互联网新技术的激烈逐鹿

    中，也诞生了一些名满江湖的高手，他们的传奇

    经历，一如倚天屠龙传记，不禁让人拍案叫绝。

    2009年的一天，偶然在网络上搜索“敏捷测

    试”，排名第一的《敏捷测试的最佳实践》赫然

    映入眼帘，作者正是IBM资深敏捷专家谢明志。

    虽然素昧平生，但明志热情地接受了我们的咨

    询，并无私地利用个人时间多次接待了我们的登

    门造访和求教。明志身上IBM国际化的专业经验打动了我，我在中兴通讯所肩负的民族企业使命

    感和创新学习精神也打动了明志，这就是缘分。

    由于我个人在工作上向来讨厌官僚、追求高效，明志甚至帮我们在IBM与中兴通讯两个大公司复

    杂漫长的流程中找到捷径，灵活而“敏捷”地为我

    们打造了一次量身定制的敏捷测试咨询服务，让

    我们得以快速揭开敏捷的神秘面纱，见到倚天

    剑、屠龙刀的真容，这让我感动至今。

    与明志认识的那一年，也正是中兴通讯手机

    测试团队试水敏捷的元年，经过与IBM的合作，我们收获了很多有价值的思想和方法，不仅有效

    促进了当时我们与北美顶级客户Verizon的一个项

    目进程，而且经过多年的学习、思考、交流与沉

    淀，中兴形成了一套独特的敏捷思路和方法，这

    对于后来整个中兴手机测试中心的组织转型和专业化发展都有非常大的帮助。但其实我更希望强

    调的是，一种思维、一种方法，无论以何种方式

    被应用，其结果如何都并不重要，重要的是领悟

    和知己。高手过招，有时求的也许不是胜负，金

    庸用“华山论剑”而不是“华山决战”、“华山比

    武”来形容南宋那一场武林“峰会”，高手自能领会

    其中真意。

    得客户者得天下。敏捷是软件行业从传统模

    式走出来的一次伟大变革，除了传统软件业之

    外，敏捷天然地与互联网行业结合，造就了这个

    伟大的时代。敏捷模式的快速迭代和拥抱变化让

    产品、交付及其演进过程焕然一新，最好地契合

    了各类客户需求，在这个模式下工程师们的观念

    和思维开始不断进化，成为软件业具备互联网思

    维的先行者。我认为这是敏捷超越行业的一个重要贡献和意义，它让人们思考如何更好地融入这

    个时代，迎接变化，顺势而为。

    开放思维、乐于分享、重视朋友，通过近年

    来明志领队的多次IBM workshop和交流，我的团

    队不仅收获了先进、专业、地道的敏捷咨询服

    务，造就了中兴通讯终端测试技术在业界的领先

    地位，更从明志身上看到了从为人到做事的诸多

    闪光点，并以为同业挚友相交多年。明志是有真

    才实学又乐于分享的人，其思想最能够不断成

    熟、完善，其实践最能够带来启发，也更接地

    气，相信此书能够为读者提供一份精美的敏捷大

    餐!

    谢伟

    中兴通讯终端事业部副总裁中兴通讯终端事业部产品测试中心主任序言三

    本书作者谢明志以敏捷开发正规军的角度与

    我们分享他在敏捷开发管理中的实战经验。虽然

    讲述敏捷开发理论与案例的书籍绝对不缺，但是

    本书从更多维度来剖析敏捷开发的真谛。

    我多年前刚回国的时候，就听说敏捷开发在

    国内已经流行了不短的时间，大部分IT企业也都

    说自己的研发流程是敏捷的。可惜当我有机会深

    入了解后却发现，大家除了能说出“快速迭

    代”、“响应变化”、“小步快跑”等关键词，绝大部

    分的研发团队其实并没有真正理解敏捷开发的核

    心思想，结果敏捷开发成为开发不写文档、需求

    无序进入开发环节、架构不断被推倒重来等恶果的最有力借口，用户也就不可能真正享受到敏捷

    开发所应该带来的用户体验不断递增的快感。其

    实，我们还能从实践误区中更好地理解为什么很

    多敏捷开发团队的产出并没有达到预期的高度。

    从Rational产品的发展历程中，我们也能体会到敏

    捷开发并非初创团队才能使用的专利，像IBM这

    样的大型企业也能完成从瀑布式到敏捷式的华丽

    转身，让敏捷开发成为基石，以应对万变的市场

    需求。

    本书还用大量篇幅讲述了敏捷型人才的培养

    方法，详细地把优秀人员的素质罗列在我们的眼

    前，在我看来，这才是敏捷开发成败之间最大的

    分水岭。敏捷开发的确需要大量的前置培训来统

    一关键人员的思想，而这些培训并非单单提供理

    论上、流程上与技术上的知识，更重要的是提高大家的自我管理、自律与协作能力。更理想的状

    态是，团队不仅仅理解规划需求，而且对目标用

    户和市场有业务上的理解，使得呈现出来的产品

    能真正触动用户的内需，从而让用户真心实意地

    成为铁杆粉丝。

    以前市场存在着各种经济红利，IT企业并不

    需要精益求精就能活下来，而且还能活得不错。

    可是温水煮青蛙还是终有煮熟的一天，本书不仅

    仅对国内的开发环境提出了有力的批判，同时也

    提供了可借鉴的转型之路。但愿我们能与作者共

    勉，为更多企业踏上康庄的敏捷开发之路做出贡

    献。

    余康柱

    资深IT互联网企业管理人前易宝支付运营副总裁序言四

    当明志请我为他的新书写序时，我毫不犹豫

    地答应了。因为这本书将为中国的IT行业带来非

    常正面的影响。

    2006年，IBM软件部面临了很多市场和经济

    方面的挑战，那个时候的IBM软件部已经是独当

    一面的部门，每年的收益是200多亿美元，而每

    年并购进来的大小公司有几十家，在全球89个地

    区有27000多名开发人员，但也是由于这个原

    因，软件部内部产生了协作和创新的问题。要解

    决这些问题，并且实现收益的持续高速增长，IBM软件部肯定要转型。

    IBM软件部确定将当时行业中非常流行且得到认可的敏捷方案作为转型的模式。当然，IBM

    Rational亦是这个领域的专家，它在软件和系统工

    程市场上累积了超过30年的经验，转型将建立在

    Rational Unified Process(RUP)的坚实基础上，与之相辅相成。

    2006~2013年期间，IBM软件部在敏捷开发模

    式下创造了有目共睹的成果。我们的Release

    Cycle从2006年的一年一次大大缩短至一季度一

    次，功能上的提交一点都没有减少，而且质量继

    续维持在一贯高的水平。

    过去几年，IBM Rational致力于推动敏捷开

    发的方法论和管理，希望把我们的经验分享给客

    户和社区。很多大中型的企业对敏捷开发都非常

    感兴趣，特别是怎样将敏捷开发从理论上落地到大企业和大团队的开发实践中。过去几年，IT行

    业的不断变化和新技术的不断涌现，如云计算、移动互联网、大数据，都迫使我们的很多传统客

    户变得更敏捷。

    但每次我们探讨敏捷话题的时候，结论都

    是：今天企业需要的不单是开发的敏捷，更是企

    业的敏捷。这就带出了另外一个课题——

    DevOps。

    就如敏捷开发一样，DevOps过去几年也是IT

    行业里备受关注的方法论。DevOps本身当然是针

    对Development和Operations之间的协作矛盾。但

    是，如果引入敏捷开发，矛盾将会进一步加深，因为敏捷的一个重点是持续交付，即多版本多交

    付，这势必会减少大版本带来的风险和不灵活性。

    Development和Operations中间是一个关卡，要达到企业敏捷，我们要过的关卡还有很多。所

    谓企业，是端到端的，由企业愿景开始，变成业

    务计划和需求，变成IT项目和需求，经过分析、设计、编码和不同环境的测试，如单元测试、性

    能测试、SIT、UAT，再交给Operations团队进行

    最后的生产环境上线测试，等等。每一个关卡都

    会影响整个流程的进度，当然，最终会影响我们

    满足业务的需求。所以，IBM Rational认为

    DevOps的定义应该是涵盖整个端到端的企业流

    程，只有端到端的DevOps才能做到企业敏捷。

    本书通过深入浅出的讲解，把敏捷开发从传

    统的小规模敏捷伸展到跨地域、跨时空的DAD方法，是读者了解敏捷的必备参考书。

    谢毓明

    IBM大中华区Rational CTO序言五

    自从1946年第一台计算机诞生以来，人类一

    直在寻找开发软件的最佳方法，以提高软件质

    量，减少项目成本，并更好地控制项目进度。最

    早的软件开发模型是1970年W.Royce提出的瀑布

    模型(Waterfall Model)，这种方法在20世纪80

    年代成为软件开发的主流。瀑布模型的概念是按

    照需求、设计、开发、测试的顺序，线性地开发

    出软件产品。在前一个阶段完成之前，不能进入

    下一个阶段。这种方法对需求明确、设计方法成

    熟且开发人员对编程工具非常熟悉的软件项目十

    分适用，但是对已经完成的工作进行修改却很麻

    烦。为克服瀑布模型“死板”的缺点，在20世纪90

    年代出现了迭代和增量开发模型(Iterative and

    Incremental Development Model)，其核心思想是

    每一次“需求–设计–开发–测试”的迭代只开发整

    个软件的一部分，这样做的目的是尽早发现并解

    决项目中存在的重大问题。在迭代和增量开发模

    型的基础上，也出现了一些更加“短小精悍”和更

    加“以人为本”的开发模型，比如RUP(1994)、Scrum(1995)、Extreme编程(1996)等。这些

    方法更加注重持续回顾和增量开发，并通过逐步

    完善的方法来开发和交付软件产品。

    2001年2月17日，17位“草根”程序员在美国

    犹他州发布了敏捷宣言(Agile Manifesto)，其

    中最重要的4项原则是：“个人和交流重于过程和

    工具，能运行的软件重于详尽的文档，与客户合作重于合同谈判，响应变化重于执行计划”。敏

    捷宣言的发布，在软件开发方法领域开启了一场

    轰轰烈烈的敏捷运动。所谓敏捷方法，其实只是

    一个概念，它是所有带有敏捷特征的软件开发方

    法的统称。上面提到的Scrum和Extreme编程都属

    于敏捷方法。

    在过去的十几年里，随着网络的普及，以及

    近年来越来越多移动应用的出现，信息的传播速

    度越来越快，软件开发的周期也越来越短。很多

    项目启动时需求并不是很明确，传统的瀑布模型

    不再适用，敏捷方法的优点得以发挥。因此，敏

    捷方法越来越流行，特别是针对小型项目。在敏

    捷方法里，使用最多的是Scrum方法。据敏捷联

    盟(Agile Alliance)统计，在全球使用敏捷方法

    的企业里，66%使用过Scrum方法或Scrum方法的变种。

    提到软件开发，我们不能不提到CMMI模

    型。有人认为CMMI和敏捷方法是相冲突的，二

    者不能共存，其实这是一种误解。CMMI规定了

    必须做什么，但是没有规定怎么做。在选择项目

    的生命周期模型时，CMMI项目可以选择瀑布模

    型，也可以选择敏捷模型。敏捷方法的出现，实

    际上是丰富了软件开发模型的可选项，是对

    CMMI的补充。敏捷方法合理地借鉴了CMMI的

    400多条最佳实践，可以最大限度地保证敏捷项

    目的成功。所以CMMI和敏捷方法是相辅相成的

    关系，不是对立的关系。写这篇序的时候，我正

    在美国华盛顿参加CMMI研究所举办的北美SEPG

    年会，今年年会的一个特点就是出现了大量

    CMMI与敏捷结合的论文和报告。可以预见，在未来的几年，CMMI与敏捷方法的结合将会是一

    个重要的趋势。

    在敏捷方法不断发展的过程中，IBM扮演了

    一个非常关键的角色。从最早的RUP方法到

    DAD，再到最新的DevOps方法，IBM都走在时代

    的最前沿。本书作者非常幸运地亲身参与到这场

    轰轰烈烈的敏捷运动中，更为可贵的是，作者把

    自己在IBM十年的亲身体验写下来，与广大读者

    分享，为大家更好地理解敏捷方法，避免已经走

    过的弯路，提供了第一手的资料，非常有意义。

    最后祝愿敏捷方法如作者所期望的那样，能

    在中国的企业里开花结果!也祝愿中国的软件产

    业能早一天走向世界!

    高山CMMI评估师，CSM前言

    这是一部讲述管理思维变革的书，一部用失

    败教训、成功体验和行业前沿的系统管理思维打

    造的创新之书。它将管理学与心理学融为一体，告诉你如何将敏捷思维用于商业、工作和生活，破译初创团队成长为千人企业的平稳转型密码。

    什么是敏捷方法？作为IBM敏捷官方发言

    人，无数人问过我这个问题。敏捷方法是一种让

    企业最大程度降低成本、增加利润的方法，一种

    通过增量互动对客户的需求和反馈保持开放的产

    品或服务。它不是出于恐惧项目超期、成本超

    支、团队离散而制定出的一些监测和控制项目的

    方法，而是赋予团队信任和自治、全力支持团队以满足客户需要、最大化交付价值的方法。迄今

    为止，我已经以敏捷方法为主题做了近8年的讲

    座，工作成绩得以飞速提升的学员不计其数。他

    们不仅跨越了知识和经验的门槛，运用“新式武

    器”打击顽固的症结，而且窥破了敏捷方法的奥

    秘，在工作中变得“放下”和轻松许多，仿佛不知

    不觉中，封存起来的内在力量冲破禁锢释放出

    来。他们能够全神贯注于自己感兴趣的工作，将

    精力和时间用在对人生和企业有价值的事情上。

    他们明白在职场中要做到不复制、不模仿，在团

    队中要证明自己的差异价值，通过真实的自己来

    影响和带动团队，成为团队中独具一格的领袖。

    这就是敏捷思维的有趣之处。敏捷思维是一种非

    颠覆性的创新，以“实现最小代价换取最大回

    报”为价值度量，在“简化工作流程+合理运用工具+智慧管理人心”的平台上实现降低产品交付成

    本且全心成就客户。

    从2006年开始接触敏捷方法至今，我目睹了

    很多实践者追求和学习敏捷方法的热情不断熄灭

    在荒废的半成品中，也不断听说某些敏捷讲师将

    客户敏捷部署不落地的原因归结于企业领导的不

    理性、不支持或团队人员的素质低下。于是，我

    决心写一本书来为敏捷思维正名。事实上，我的

    敏捷实践也历经了长达8年的探索，尽管我有着

    得天独厚的成长环境和开明的企业平台，但我所

    走过的路，包括部署敏捷方法、推行新工具、培

    养敏捷团队、改良和变革企业流程和模式，每一

    步都布满荆棘。不过，坚持到今天，相信很多有

    过相似经历的人一定像我一样，正在品尝努力付

    出所结出的硕果。但是，至今也没有一部深度探索敏捷思维变革和企业级敏捷转型的书籍出版，于是，2013年春节，我开始了本书的写作。

    第1章引出“何为敏捷”的问题，从Scrum方法

    出发，展示敏捷的价值，介绍敏捷方法的基本构

    成。同时，该章还将以IBM公司为案例，解析

    IBM作为一家有先进管理理念的大型企业，在面

    临外来挑战和内部革新的内驱力时，为何选择敏

    捷作为自身变革的策略，展示企业敏捷转型中可

    能面临的挑战和光明前景。

    第2章通过一些典型案例，分析敏捷转型困

    境，总结敏捷实践误区，指出Scrum等核心敏捷

    方法的局限性，特别是与国内企业相结合时所暴

    露出来的水土不服问题。这一章还介绍了项目经

    理的重要作用，对比了传统项目管理模式和敏捷项目管理模式，向敏捷项目管理转型的企业提出

    了忠告和建议，并在最后总结了13条“敏捷实施

    法则”。

    但是，仅仅照搬别人的成功方法还不能保证

    改革的成功，必须活血化瘀，疏通承载方法的实

    体，即“人”与“工具”的任督二脉，使得敏捷转型

    平滑、系统地进行。根据“人”的职业养成阶

    段、“工具和技术”的成熟度、“政治、架构、企业

    文化”的环境差异，“流程”也需要适当裁剪。必须

    让团队、团队负责人、产品负责人看到，风险可

    预期、转变非颠覆、目标可实现，他们才能有信

    心并自发地配合企业由下而上的变化。

    第3章介绍了敏捷扩展模型(ASM)和规范

    性敏捷交付(DAD)方法。DAD是Scrum、Lean、Kanban等方法的复合体，本章主要讲解该

    方法的特色，例如重要角色及其不同于传统敏捷

    的典型实践。为了清楚地分析DAD方法，与第2

    章Scrum房地产公司的小故事呼应，本章讲述了

    一家DAD房地产公司如何通过自身的优势规避来

    自政府规划的重大风险，建造楼盘并取得项目成

    功。本章以IBM Rational中国的转型为例，分享

    了以“工具+流程+人”为框架的敏捷转型实践。此

    外，还讲述了传统服装行业中DAD方法的应用，并在最后以“敏捷开发者的一天”的故事来完整描

    述一个大型组织中敏捷方法的成功落地。

    第4章介绍了以敏捷思维开发商业模式的方

    法，并通过ASM因子的调整得到了适合10人以下

    初创团队的敏捷方法，同时指出初创团队成功的

    关键在于建设敏捷团队，以及团队领袖、带头人作为灵魂人物在敏捷转型中的重要性。此外，本

    章还讨论了敏捷团队建设的四个阶段和防止人才

    流失的方法，以及人格测评对招聘甄选和岗位匹

    配的影响。

    第5章讲述人才培养中如何使团队自发地做

    到“自我管理、自我认知、自我控制”，特别是在

    团队建设、团队协作方面，通过几个小故事模

    拟“三自”培养方法，手把手地教你如何通过心理

    学方法精细地打造一个“轻管理”的敏捷团队，分

    享“沟通和倾听”的方法与技巧，降低团队建设中

    的“信任”成本。

    第6章的主题是“非凡的测试”，这是因为敏

    捷测试实属不易，有太多经验需要分享。同时，这一章也讲述测试生涯规划，作为DAD敏捷方法的推崇者，详细讲述“独立测试”的必要性，测试

    的“决策影响力”、“投入产出效益”，“自动化测

    试”的策略和规划方法，以及“自动化工具”的选

    择。通过“敏捷测试工程师的一天”的故事分享，帮助测试者在工作中学习如何实现更高的自我价

    值。

    目前，对于研发工作，我已经渐行渐远，而

    开始深入市场和客户需求、客户关系的梳理工

    作。但每当与客户们谈及其需求、趋势，我们都

    会延伸到流程、管理，以及关于持续改进理念的

    探讨。通过这些交流，我不仅收获了客户的信

    任，也听到了更多有价值的观点，遂在附录中分

    享了有关敏捷思维和敏捷转型的常见问题和回

    答，并大胆推断了第二代敏捷“DevOps”——持续

    交付软件驱动的创新。此外，还介绍了一个以完整的IBM敏捷方案和敏捷实施体验帮助团队深入

    了解IBM规范性敏捷方法的敏捷大赛活动，通过

    在线评分系统展示了一套简单的敏捷成熟度度量

    体系。

    谢明志

    2014年9月第1章 敏捷思潮

    1.1 变革悄然而至

    1.2 最简单的敏捷交付

    1.3 百家争鸣

    1.4 Scrum

    1.5 敏捷旅行

    1.6 敏捷实施报告

    1.7 案例分析：IBM的敏捷转型之路1.1 变革悄然而至

    新工业时代已经到来，为了迎接这场静悄悄

    的工业革命，产品交付团队中，从工程师到项目

    经理都在极力做出自我调整。医药、软件、汽

    车、集成电路等行业客户对新产品的不断需求以

    及行业研发成本的不断攀升，标志着从计划性开

    发方式到自适应式开发方式的重大转变，这个转

    变使得那些仍然坚守预见性的旧思维和旧规则的

    工程师、项目经理陷入了大混乱，因为旧思维方

    式正在迅速退出历史舞台。

    2002年中期，加拿大多伦多市的Alias System

    公司开始开发Sketchbook Pro，这是一个与微软的

    Tablet PC操作系统几乎同时发布的软件包。起初，它的管理和开发团队并不确定开发计划需要

    包括哪些细节，但团队成员有一个明确的产品构

    想和商业计划，对于产品需要具备哪些功能有大

    体的想法。他们没有积极地参与市场营销，但有

    一个总体设计架构，并且每两周提交一次新测试

    完成的功能，然后根据产品测试的实际情况调整

    未完成的工作计划。最终，在微软发布日期(11

    月)，该产品同步上市，并因其高质量标准在市

    场上取得了空前成功。

    在汽车业，日本丰田公司的副总裁大野耐一

    综合了单件生产和批量生产的特点，创造了一种

    在多品种小批量混合生产条件下高质量、低消耗

    的生产方式——准时生产(Just In Time，JIT)。

    JIT生产方式的基本思想是“只在需要的时候，按

    需要的量，生产所需的产品”，也就是追求一种无库存或库存最小的生产系统。丰田公司始终要

    求以用户的需求为生产起点，强调物流平衡，追

    求零库存。生产节拍由人工干预、控制，重在保

    证生产中的物流平衡，每一道工序均要保证对后

    道工序供应的准时化。

    上述产品开发方法指出了一个非常关键的问

    题，当研发成本减少到一定程度时，产品开发的

    整个经济学就会发生变化——以计划性、合规性

    为基础的开发流程转变为以适应性为基础的流程

    (构想、探索、适应)。这种演变是一种进化过

    程，就像生物进化一样，但是它要比自然界的进

    化迅速得多。生物进化的流程是试验(突变和再

    结合)、探索(适者生存)和改进(产生更多的

    生存者)，而产品开发流程越来越类似这个流

    程。开发过程的不确定性增加、进度不断被期望

    压缩，研发任务将不仅仅局限于工作室内部完

    成。新的营销理念需要我们从客户参与管理和研

    发开始，还要以高质量为目标，对于服务精度和

    速度的要求也不断提高。因此需要创新，需要适

    应新环境的新研发过程，以更有效地增加产品价

    值并保持竞争优势。

    事实上，大型公司对变革和创新的诉求比小

    型公司更加强烈，因为大型公司往往在新产品和

    交付新产品之间存在着更大的差距。新投放的产

    品失败率高达59%，这个数字从20世纪90年代早

    期以来几乎没有变化。而且，半途而废或者(在

    市场上)失败的产品消耗了46%的产品开发资

    源。虽然少数侥幸的公司还可以挽回败局，但真正成功的公司则越来越多地在实施敏捷交付方

    法。

    2006年的IBM全球报告(见图1-1)指出，鉴

    于市场和竞争压力，面对多元化的变革，如果不

    能快速适应，那么企业赖以生存之基本，或者当

    下各种项目的最终价值可能会受到影响，甚至可

    能失去商业价值。因此，CEO们认为需要具备在

    项目进行的过程当中根据需要做出变革的能力。

    如果项目团队不能够在项目进行过程当中积极地

    对刺激进行反馈和变革，问题可能会接踵而来。图1-1 2006年3月IBM全球CEO调查报告CEO们皆希望对项目进行有效的变革管理。

    这个过程应该包括对变化的识别和判断，对变化

    的商业价值的判断，对变化会给项目带来的冲击

    和影响的判断，并将相应的信息提交项目投资人

    进行评估，最终由项目投资人决定是否将变化引

    入到项目当中。如果变化被引入，项目投资人还

    应该考虑变化对项目的影响程度，并且为之配备

    相应的额外资源，如延长时间和追加资金预算

    等。2006年，IBM决定在公司推动模块化设计以

    提升整合能力的设计思路，并且采用简单、迭代

    的敏捷开发过程作为项目组织和实施的重要决

    策。

    敏捷绝不再局限于研发阶段，而是贯穿软件

    的生命周期，从产品的抽象概念，到客户渐渐体

    会到产品的真正使用价值，再到解决方案在组织内获得成功，敏捷的价值无不凸显其中。若用一

    言以蔽之，敏捷的核心价值是充分地将人的时

    间、精力、金钱始终集中在最有业务价值的部

    分，并以风险最小的方式将可用的产品推向市

    场。1.2 最简单的敏捷交付

    如果用敏捷方法生产钢笔，敏捷规划了四个

    重要功能组成部分，即笔芯、笔杆、笔帽和雕

    花，相应功能若投入市场可以获得的价值分别为

    50、30、15和5。倘若每项功能开发所需的成本

    一致，时间都是1个月，那么敏捷开发就是要将

    每个月的开放力量投入到最有价值的部分，并依

    次类推。那么在没有生产规划的情况下，最开始

    的迭代应该将资源投入在钢笔笔芯部分，因为这

    个部分可以带来最高的价值。而第一个迭代完成

    时，客户体验到了用钢笔书写的刚劲有力、笔锋

    回转、酣畅淋漓，因此决定了第二次投资，即为

    钢笔打造第二项重要的功能——笔杆，一个可以

    方便把握的笔杆，一个可以保护笔芯、防止墨水侧漏的笔杆。当我们在第2个月全力完成此功能

    后，客户便拥有了第二个发布的功能。现在重新

    排列未完成的工作，此时客户给出重要的指示，决定放弃在笔帽上的雕花功能而选择一个既可以

    将钢笔别在衬衣口袋又能够保护鼻尖的笔帽作为

    第三项最重要的功能。因此，最终我们仅仅用3

    个月就开发出来价值为50+30+15=95的新产品

    ——钢笔。节省下的一个月时间将投入到第二代

    钢笔的研发中，很快，我们设计出第四项新功能

    ——节省墨水50%。因为每个月都能够从市场上

    获得产品推出的反响，所以我们将新功能的价值

    评估为50。也就是说，我们用了4个月的时间，使用敏捷方法生产了145的价值，而且一共发布

    了4次产品，产品投产30天后，我们就收获了价

    值为50的回报。1.3 百家争鸣

    如果用传统开发方式，也就是瀑布式模型来

    开发钢笔，将产品的架构划分为数据层、逻辑

    层、应用层和接口层，团队也划分为相应的4个

    平行开发团队。每一层的架构和设计都需在代码

    构造前完美地完成，因而为了实现产品的按期发

    布，四个团队都不能独立将自己的产出在4个月

    内的任何时间向外发布，也就无法评估笔杆上的

    雕花是否比新加入的“节约墨水”功能更吸引用

    户。所以，最后产出的产品虽然有

    50+30+15+5=100的评估价值，但在这个过程中投

    资者只得一次性投入4个月的资金，直至4个月后

    才等到第一次面向市场的机会；而此时同类产品

    的竞争优势更加可观，产品实际带来的利润价值并没有预期的大。

    图1-2给出传统开发过程与敏捷开发过程的对

    比。

    图1-2 传统开发过程与敏捷开发过程对比

    在此不过多列举敏捷方法，但值得一提的是

    核心的敏捷方法Scrum，以及可以与Scrum媲美的

    敏捷方法论。XP(eXtreme Programming)更加适

    合3~5人的小型项目团队，DSDM(DynamicSystems Development Methodology)与Scrum一样

    更加适合大型团队的项目开发，还有Lean等方

    法。这些方法其实都可以在IBM的某些项目中窥

    见一斑，后文将具体讨论。1.3.1 极限编程

    极限编程(XP)是由KentBeck在1996年提出

    的。XP是一种注重协作、快速和早期软件创建的

    有技巧的开发实践方法，适合10人以下的团队。

    XP是一个轻量级的、灵巧的软件开发方法，同时

    也是一个非常严谨和周密的方法。它的基础和价

    值观是交流、朴素、反馈和勇气，即任何一个软

    件项目都可以从四个方面入手进行改善：加强交

    流，从简单做起，寻求反馈，勇于实事求是。XP

    是一种近螺旋式的开发方法，它将复杂的开发过

    程分解为一个个相对比较简单的小周期，通过积

    极的交流、反馈以及其他一系列的方法，开发人

    员和客户可以非常清楚开发进度、变化、待解决

    的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

    极限编程的基本原则：

    ·通过客户、开发团队、项目经理三方共同

    参加的会议来确定开发计划。

    ·小版本发布：尽快发布，尽早发布。

    ·通过系统隐喻(metaphor)让每个人了解

    整个系统。

    ·简单设计：为明确的功能进行最优的设

    计，不考虑未来可能需要的功能。

    ·重构(refactoring)：不断优化系统设计，使之保持简单。

    ·单元测试：先写测试，后写代码。·结对编程(pair programming)：系统的每

    一行代码都是两个人用一个键盘完成的。

    ·代码集体拥有：开发队伍中任何人可以修

    改任何其他人的代码，代码不属于某个个人。

    ·持续集成：至少每天将整个系统集成一

    次，保持一个能运转的系统。

    ·40小时工作制：保证休息，保持体力。

    ·现场客户：客户自己也是软件开发队伍的

    重要一份子。

    ·编码标准：必须有统一的编码规范，确保

    代码的可读性。

    关键词 测试驱动，结对编程，持续集成，重构，小版本发布，沟通。1.3.2 水晶方法

    水晶(Crystal)方法论由Alistair Cockburn在

    20世纪90年代末提出。他把开发看做是一系列的

    协作游戏，而写文档的目标是帮助团队在下一个

    游戏中取得胜利。水晶方法的工作产品包括用

    例、风险列表、迭代计划、核心领域模型，以及

    记录了一些选择结果的设计注释。水晶方法也为

    这些产品定义了相应的角色。然而，值得注意的

    是，这些文档没有模板，描述也可不拘小节，但

    目标一定要清晰，即满足下次游戏开始的条件。

    对于水晶方法论，根据方法论的轻重可以分

    为透明水晶和橙色水晶等。透明水晶一般适用于

    轻量级的团队。不管是哪种水晶，都会对团队的角色、团队的工作项和产出、核心实践、支持过

    程等进行定义。

    关键词 协作，角色，文档，迭代，风险管

    理。1.3.3 动态系统开发方法

    动态系统开发方法(DSDM)倡导以业务为

    核心，快速而有效地进行系统开发。可以把

    DSDM看成一种控制框架，其重点在于快速交付

    并补充如何应用这些控制的指导原则。

    DSDM是一整套的方法论，不仅仅包括软件

    开发内容和实践，也包括了组织结构、项目管

    理、估算、工具环境、测试、配置管理、风险管

    理、重用等各个方面的内容。

    DSDM的基本观点是，任何事情都不可能一

    次性圆满完成，应该用20%的时间完成80%的有

    用功能，以适合商业目的为准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求(传统方法一般是需求固

    定，时间和资源可变)，交付所需要的系统。对

    于交付的系统，必须达到足够的稳定程度以在实

    际环境中运行；对于业务方面的某些紧急需求，也必须能够在短时间内得到满足，并在后续迭代

    阶段中对功能进行完善。

    DSDM的基本原则：

    ·活动用户必须参与。

    ·必须授权DSDM团队进行决策。

    ·注重频繁交付产品。

    ·判断产品是否可接受的一个基本标准是符

    合业务目的。·对准确的业务解决方案需要采用循环和增

    量开发。

    ·开发期间的所有更改都是可逆的。

    ·基本要求是高层次的并区分优先级(以在

    低优先级的项目上获得一定的灵活性)。

    ·在整个生命周期集成测试。

    ·在所有参与者之间采用协作和合作方法。

    关键词 以业务为中心，用户参与，迭代，快速交付，团队协作和沟通。1.3.4 精益生产

    精益(Lean)管理的思想起源于丰田公司，旨在创造价值的目标下，通过改良流程不断地消

    除浪费。这种方法现已被广泛用于生产制造管

    理，对于IT系统建设，精益开发的常用工具模型

    是价值流模型，如图1-3所示。

    图1-3 精益方法的价值流模型(括号内代表浪费的时间)

    精益开发的基本原则：

    ·杜绝浪费：将所有的时间花在能够增加客

    户价值的事情上。

    ·推迟决策：根据实际情况保持可选方案的

    开放性，但时间不能过长。

    ·加强学习：使用科学的学习方法。

    ·快速交付：当客户索取价值时应立即交付

    价值。

    ·打造精品：使用恰当的方法确保质量。

    ·授权团队：让创造增值的员工充分发挥自

    己的潜力。·优化整体：防止以损害整体为代价而优化

    部分的倾向。

    上述方法都是流行的敏捷方法。图1-4是

    VersionOne在2013年发布的敏捷方法的使用情

    况。最主流的敏捷方法仍然是Scrum，下面来看

    看Scrum是什么。图1-4 敏捷方法的使用情况1.4 Scrum

    1986年1月的《Harward Business Review》期

    刊登载了一篇题为《The New New Product

    Development Game》的文章，其要义说的是：“原

    有的‘接力跑’式的产品开发模式一定程度上违背

    了以人为本、最大化生产力、灵活生产方式的原

    则。相反，另一种独特的团队，采用‘橄榄球’式

    的团队合作方式——整个团队合作无间，灵活机

    动地接球、传球，并作为一个整体迅速突破防线

    ——这可能更加适应今天更具挑战的市场需

    求。”

    这就是Scrum源起的故事，从产品研发的角

    度来理解这个恰到好处的比喻，可以更好地理解Scrum的精髓：

    ·Scrum使我们能够专注于如何在最短的时

    间内实现最有价值的部分。

    ·Scrum使我们能够快速、经常地监督实际

    产品的发展状况(每两周或一个月)。

    ·按照商业价值的高低先完成高优先级的产

    品功能，采用自主管理模式，凝结团队智慧创造

    出最好的方法，因而效率提高。

    ·每隔一两周或者一个月，就可以看到实实

    在在的可以上线的产品。此时，可以进一步决定

    是继续完善功能实现更多需求或者直接发布。

    Ken Schwaber在他的书中指出，Scrum不是一

    种构建更好产品的方法，也不是快速构建高质量软件的方法。Scrum是一种工具，一种可以帮助

    我们找到用来快速构建高质量软件的要素的工

    具。1.4.1 发源与发展

    Scrum之父Jeff Sutherland于1993年在Easel

    Corp提出了Scrum的方法，而大师Ken Schwaber创

    作并出版了三本有关Scrum的书：《Agile Project

    Management with Scrum》、《Agile Software

    Development with Scrum》、《Enterprise

    Scrum》，Scrum自此开始坚实地扎根于软件行

    业。

    2002年，Ken Schwaber和Mike Corn联合创办

    了Scrum Alliance(Scrum联盟)。在发布后的10

    年内，Scrum相继被微软、雅虎、谷歌、飞利

    浦、西门子、IBM、第一美国不动产经纪公司等

    知名企业采纳，所涉及的领域已经超出了软件研发的范畴，涵盖嵌入式系统、游戏、网站、手

    机、网络交换设备等众多领域。1.4.2 自我管理

    Scrum方法并没有特定的工程实践惯例，但

    是定义了几个角色，例如，团队(Team)、团队

    负责人(Scrum Master)、产品负责人(Product

    Owner)，以及角色相应的职责。团队这个角色

    被注入了“自我管理”的使命，团队成员会主动朝

    着产品研发的进展方向规划自己的迭代计划、日

    计划，并主动完成工作。产品围绕着产品清单

    (Backlog)展开，这个清单作为一个容器容纳所

    有待完成和已完成的工作项，而每个工作项都可

    以继续拆分和重新排列优先级，当Scrum开发开

    始时，团队将从中选择重要且能够完成的产品清

    单，在2~4周内完成这些产品清单的发布。产品

    正是通过一次次的迭代(Sprint)，由增量构建的产品清单所组成的。

    Scrum同XP、水晶等方法一样均属于敏捷方

    法范畴，敏捷宣言强调，在项目实施过程中：

    1.拥抱变化(embrace the change)

    无论多么明智、多么正确的决定，也有可能

    在日后发生改变。因此，团队要充分理解利益关

    系人(Stakeholder)和客户代表为什么经常提出

    新的需求，一句话，“唯一不变的是变化”。团队

    要相信利益关系人做出的每次决定和需求调整都是将产品开发推向更正确的发展方向，新变化将

    进一步降低风险，实现团队最大化利益，这是适

    应市场变化的必然行为。

    而在接受变化的同时，我们应该积极地向利

    益关系人和客户代表反映开发过程中暴露出来的

    可能的设计缺陷和错误。在实际工作中，团队成

    员应该用优先级制度来划分事情和目标的先后顺

    序，在迭代周期内，对于还没有最终决定的设计

    方案，可以置后实现、测试，不用急于投入资源

    展开全面的开发、测试活动。这样一来，开发、测试团队也将更加适应，真正拥抱变化。

    2.客户的参与(with customer representative on

    site)

    首先，谁是客户(Customer)，谁又是客户代表(Customer Representative)？利益关系人可

    以理解为客户、产品的最终使用者(End

    User)、内部使用者(Insider User)和商业伙伴

    (Business Partner)。利益关系人作为团队中最

    了解业务的人，将帮助开发团队快速达到目标和

    做出适时决策。开发团队拥有很好的技术，但在

    业务方面需要利益关系人的帮助。通常在敏捷的

    开发项目中，当团队中的任何一个人需要帮助

    时，只要简单地邀请大家参加一个15分钟会议，或一封邮件、一个电话便可以解决。

    但是，如果利益关系人各执一词怎么办？为

    解决这个问题，将产品负责人引入到讨论中来，作为利益关系人的代表，有权在分歧中做最后抉

    择。因此，通过客户代表的参与，团队更好地了

    解了所做事情的价值和意义，其工作效率也因而得到很大提高。

    利益关系人能够帮助团队中的每一个人更

    好、更快地完成工作，他们的直接参与成为了敏

    捷开发、敏捷测试的重要前提。

    3.较少的文档(with less documents)

    敏捷开发更重视生产出可用的产品而不是详

    细文档，但文档又是敏捷与传统开发、测试中不

    可或缺的一部分。传统开发的文档在敏捷开发里

    仍有大用，只是原来十来页的内容精炼到现在的

    一页半页。

    敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈

    词滥调和空头支票。复杂的文档说明只能增加沟通成本，因而敏捷开发、测试的文档不需要长篇

    累牍，而是简洁清晰。任何一段清楚的文字，甚

    至一张图片、照片、一封会议记录邮件都是我们

    认可的敏捷文档。因为任何沟通方式和载体都是

    为了帮助团队进行更高效的交流和沟通，只有团

    队保持着沟通上、理解上的一致，才能够充分发

    挥出团队的最佳战斗力。凡是利于有效沟通的方

    式，敏捷团队都不会舍弃。

    4.最大化的生产力(maximize productivity)

    敏捷开发模式要最大化地提高团队的工作效

    率。无论是依靠剪除冗余的文档，还是提供民主

    的、通畅的沟通平台，都是为了帮助团队能够集

    中有限的精力处理有意义的问题。据调查，通常

    人会在两个或多个任务并行的情况下产生最高工作效率，而敏捷正是通过各种方法得到团队的最

    大生产力。

    敏捷开发的Scrum模式，要求团队成员在计

    划阶段主动制定迭代周期的所有工作任务，因

    此，从开始迭代活动的那一刻起，团队已经在多

    重工作的压力下紧张工作了。而在日常的迭代生

    产活动里，各个成员需要当众简单汇报当天的工

    作进度并制定下一个24小时的工作计划。因此，通过增加敏捷人员的工作透明度，无形之中，团

    队成员的生产力进一步得到提高。

    5.自动化冗余工作(automate the redundant

    work)

    将团队成员从冗余的劳动中解放出来，无论

    是自动化测试还是自动化工具的开发，只要能够节约成本，都是敏捷开发、敏捷测试的目标。

    6.民主的团队(democracy in team)

    敏捷团队是一支民主的团队，团队关系是平

    行的，每个团队成员能够平等地参与讨论、决

    策。传统开发的垂直式机构在敏捷开发中已经过

    时。

    7.尊重团队(respect to team)

    敏捷团队的决定权在团队自己手中。无论是

    产品设计方案还是产品的功能实现，都是团队决

    定的最佳结果。团队脱离了任何一个成员的工作

    都是不完整的，所以我们应当足够尊重其他成员

    的劳动果实并表达对其他成员的充分信任。尊重

    团队、尊重团队中的每一个成员都是敏捷开发的原则之一。1.4.3 七经八络

    如图1-5所示，一个完整的Scrum的项目周期

    可以由一组迭代周期组成，这个周期也可以与极

    限开发(XP)的迭代周期类比，一般典型的迭代

    周期为2~4周，最多一个自然月，太长就失去了

    敏捷的意义。但这只是一般而言，真正的迭代长

    短由产品负责人决定，必须保障需求变化不影响

    产品研发。一个固定的周期能够创造出更优美的

    节奏感，我们用时间盒子(Time Box)来形象描

    述这个节奏，而所有产品的设计、开发、测试全

    部需在一个迭代周期内完成，时间盒子必须严格

    执行，每个迭代都是如此。图1-5 Scrum的标准流程

    Scrum的重要参与角色是产品负责人、团队

    负责人和团队。

    产品负责人的主要职责是定义产品的功能，并决定产品发布的日期和内容，在和投资人的谈

    判中，产品负责人负责规划产品的投入并对产出

    负责。产品负责人需要始终保持着对市场和来自

    客户的阶段性需求和反馈的敏感度，并根据这些变化对产品所需开发的功能模块进行优先顺序排

    列，在拥有多位业务人员的团队中，产品负责人

    尤其需要统一团队对需求的定义和优先级排列。

    在迭代开发的流程定义和产品的计划发布时，产

    品负责人需要合理地调整迭代主题和迭代周期长

    短；在产品阶段性验收时，产品负责人还需要参

    与并决定迭代成果是通过验收还是拒绝交付。

    团队负责人的主要职责是对项目进行直接管

    理，领导团队掌握Scrum的方法和实践，并体现

    其价值。当团队在产品研发过程中遇到问题时，团队负责人的首要责任是利用资源直接或间接协

    助其解决问题，以确保团队胜任其工作并保持高

    效的生产率。团队负责人需要保护团队不受外来

    的无端影响，让团队能够在良好的工作流程和环

    境中紧密合作，发挥出团队中各成员的职能价值。

    团队的主要职责是完成迭代中的设计、构

    建、测试、维护等工作。所有成员均分享团队的

    一致目标，懂得如何配合，且无需外界过多监管

    而独立完成工作，也愿意在需要的时候帮助团队

    其他成员完成艰巨的工作。如图1-6所示，最佳的

    Scrum团队成员由5~9名成员组成，虽各司其职，如开发、测试、需求分析、图形界面设计等，但

    在工作中均表现为能力综合的多面手。良好的团

    队能够自我管理并有较强的自知力、自制力。而

    在一个迭代、甚至多个迭代中团队成员均应全职

    工作，即全心全意地从事一个项目，个人职能在

    当下迭代中最好是固定的，而在新的迭代开始后

    可以转换角色。图1-6 Scrum团队组成

    在Scrum的游戏规则里，主要有迭代计划会

    议、例行会议、迭代评审会议和迭代回顾会议四

    项主要的活动。

    迭代计划会议。计划会议标志着迭代的开

    始，所有成员都需要参加，目的是通过分析、评

    估已有的产品清单，选择一些成为当前迭代的目

    标；决定如何通过协作完成当前计划，从选出的

    产品清单中细分，可以以人时为单位，或者以故

    事点为单位，团队成员领取工作项并评估所需要的工作量。在计划会议上，产品负责人和团队负

    责人领导会议的进行。其中，产品负责人需要确

    认哪些工作项最有商业价值，参考团队在技术角

    度的复杂度和可行性分析，设定当前的迭代目

    标。团队负责人则主要负责记录和协调团队工作

    项、计划的认领，在已有产品之上构建新的迭代

    内容。当迭代认领的工作项产生相互依赖时，团

    队负责人必须非常清晰地引导团队做出合理的工

    作项评估和必要的风险评估，并及时同团队和产

    品负责人沟通。团队的主要目的是根据所需要的

    最有价值的目标，尽可能按照价值队列来完成工

    作项目。而当团队成员认领的工作相互之间有依

    赖关系和关联关系时，需要考虑可行的计划和方

    案，以使自身的工作能够在不受干扰的环境中开

    展，且使被依赖工作项提交时间点尽可能对其他人产生小的影响。再者，就是将工作量细分，最

    好不要超过32个工作小时(如果以4周为迭代周

    期)，而细分越详细，对工作量的评估也越准

    确。图1-7给出了迭代计划中迭代工作项工作量细

    分的示例。

    图1-7 迭代计划中迭代工作项的计划展开

    例行会议。例会是一个禁止闲聊和废话的会

    议，所以要求大家每天都站着开，这个会不是为

    了解决问题，而是为了给团队一个完整的画面

    ——我们在哪里，我们将去向哪里？在例会上，无关的人，即使是经理，只要不是团队成员、团

    队负责人和产品负责人都不需要发言。会上大家

    会交换彼此的承诺，交换方式则是回答以下3个

    问题：

    1)过去的24小时，我做了什么？

    2)将来的24小时，我要做什么？

    3)现在我有什么工作被阻碍，或者我可能

    有什么工作会影响到其他人？

    会议时间尽量控制在最短，说话的时间控制

    在1~3分钟，不需要阐述细节，也不值得展开讨

    论。在队员回答问题的时候，尽量不要打断，团

    队负责人如果没有很好的协同工具，则需要即刻

    记录并投影出来，让每个人都看得到。迭代评审会议。迭代评审会议意味着迭代结

    束。评审会议需要团队演示新增部分的功能，还

    要和技术利益关系人演示底层架构的实现；如果

    是非正式的评审会议，即没有客户参与的情况

    下，仍然需要提前准备，但是时间最好不要超过

    2~3小时。所有的利益关系人、团队成员都需要

    参加会议，团队需要虚心接纳产品负责人和其他

    各位利益关系人的意见，在时间允许的情况下，尽可能做出充分的响应，即使没有能力回答或需

    要调查研究后给出反馈也需要在会上给出回复的

    时间期限。最后，通常产品负责人将会给出结

    论，即此次迭代是否完成了计划的工作，迭代是

    否成功。在累积了一定的基础功能后，客户将被

    邀请加入评审会议，此时的评审会议需要更正

    式。迭代回顾会议。迭代回顾会议是为了总结工

    作中的经验和教训，是保证团队持续性进步和提

    高的重要工作，一般在1~2次迭代完成后，团队

    成员、产品负责人、团队负责人通过讨论和自我

    剖析，分析在当前环境下最迫切的问题和所需提

    高的能力，大家尽可能地针对自己的工作提出改

    进意见和方案。团队负责人需要做好调节会议气

    氛的准备，避免讨论陷入僵局或者争吵。1.5 敏捷旅行

    分解钢笔的再造过程让我们了解了什么是敏

    捷，而下面的故事将会说明，敏捷不仅仅在制造

    业、IT行业和软件研发中有价值，相对于谨遵计

    划、对抗性沟通、以文档和活动为驱动的传统交

    付方式，敏捷方式的灵活、以结果和事实驱动过

    程的交付方式让我们更加关注产品本身的质量，而不是时间和预算的控制。我们来看看这样的旅

    行故事。

    你和你的家人计划出游，首先进行敏捷规

    划：去几天？去什么地方？几口人出行？坐什么

    交通工具？除了这些问题，还有一个终极目标：

    保证大家绝对愉悦，增进家人感情，并且安全、按时返回。需求并不多，就是简单的“快乐之

    旅”，不管去哪，和家人一起就好。或许会有一

    大堆待完成的任务，放在那里，不要把那些当成

    负担，只有当你做出承诺时，它才会成为你的既

    定目标，在这之前，无论任务放在那里多久，它

    都有可能被改变、被重新解释、甚至被放弃。所

    以，无需详细计划景点或时间，而只需要一个大

    体的构想。

    你将这次出行定为四天，第一天主要完

    成“去”的工作，第二三天在目的地玩耍，第四天

    返回。日出而作，日落而息，这是生活经验，因

    此应该选择一个可控的频度，阶段性地开展旅行

    计划：早晨检查车况后驱车前往目的地，临近傍

    晚时分，找到下榻的酒店，和孩子们享受一顿丰

    盛的当地晚餐，搂着爱人数着星星，然后储蓄能量迎接第二个天明。

    第一天的行程中，原计划的抵达目的地时间

    不得不向后推延，因为可能遇到堵车、施工或者

    更难以预料的交通管制等突发事件。在必要情况

    下，要选择其他路线，或者干脆接受这样的风

    险：等待直到道路通畅。同时，你的“客户们”可

    能有许多新点子：大一点的孩子希望在河边停下

    来看看清风扶柳、小鸟归巢，妻子希望在经过一

    座城市的时候参观那里的自然博物馆，而小儿子

    可能因为空间太拥挤需要下车放松放松。总之，行程、计划、速度都可能被突发情况所影响，尽

    管如此，仍然要让大家开心、安全并可以按时返

    回。就这样，第二天依然耗费在路上，傍晚时

    分，当一家人终于满怀兴奋地步入目的地的大酒

    店，孩子们和妻子开了花的笑脸一定令你十分感动。然而，目标飘忽不定甚至无法预计，原本要

    去的博物馆因为下水管道破损早已闭馆，但你用

    卓越的领导力和沟通能力让妻子很快从不快中解

    脱出来，她放弃了不合时宜的目标，和你一起着

    手定制了下一个替代目标，那就是利用这段闲暇

    时间去当地的温泉泡个热水澡。

    最后一天，依依不舍地告别目的地，而当你

    们异常顺利地回到家里时，才发现自己变得更能

    够适应一路风尘，知道苦中作乐，懂得现实中真

    情最令人感动，你们的心和身体都得到新的提

    升，感情也更加融洽。

    在旅途中，最为重要的就是合理安排休息时

    间，保证旅行进展的可持续性。你无法想象如果

    因为第一天计划延期而放弃休息继续赶路将会是什么结果，或许会早些到达，但是，或许会……

    你亲见了道路边的一次车祸，想想还是可持续性

    地开展旅程更值得。况且，你的客户们似乎没有

    因为拖延而产生不快，因为你让他们得到了他们

    真正想要的，那就是一家人的天伦之乐。有时

    候，真的很难了解客户想要什么，或者你的客户

    表现得什么都想要。记住，让客户一开始对一些

    可以设定的目标清晰定义并诚恳认同非常重用，不要过早地、不切实际地给出承诺，因为一旦给

    出承诺，就要尽可能做到言必信、信必果。

    旅行的故事让我们不由地联想到自己的状

    况，大多数埋头工作而很少抬头看路的人可能会

    不明觉厉；而对于那些不仅能做好本职工作，又

    有大局观的职场达人、创业精英来说，他们会对

    敏捷的价值更有认同感。事实上，这种价值正在于适应了变化且巩固了团队的信任。

    然而，即使理解了前面讲述的所有敏捷方

    法，要在实际项目中实现敏捷仍然存在困难。原

    因是我们在讲述核心敏捷思想时，为了突出其要

    领，有意忽略了一些细节，例如，团队规模、技

    术复杂度、企业架构和企业规范的限制对团队实

    施敏捷的影响等。

    决策者决定采用敏捷交付往往都发生在“行

    至水穷处，坐看云起时”的那一刻，企业的敏捷

    演变过程周而复始，就好像历史和物种的进化，永远不会停滞。因此，无论任何时候，企业都将

    处在敏捷转型道路中的某个阶段，并展现出不同

    的状态。那么，这些企业是否遇到了一些共性问

    题，是否都尝到了普适的硕果呢？我们来看看2008年的敏捷实施报告。1.6 敏捷实施报告

    从2008年Dr.Dobb的敏捷开发调查报告(见

    图1-8)可以看出，使用敏捷开发方法后，82%的

    团队的生产率得到提高。从生产钢笔的例子即可

    看出，敏捷开发团队单位时间生产出了比传统开

    发团队更大的价值，自然生产率更高。敏捷开发

    在激励团队、凝聚有效生产力、降低损耗、消除

    部门墙等方面都有很好的表现，也铸就了敏捷开

    发在生产率上的卓越性。质量源于客户体验，客

    户体验产品时满意度高则说明质量好，高质量的

    产品需要具备吸引眼球的界面、充分理解客户的

    简单化操作流程、可以定制的符合多种环境的配

    置需求，且处理速度能满足客户的最低容忍程

    度，而这些功能与非功能的需求在敏捷生产中通过和客户的不断交互逐步明确，目标也不断进行

    重新定位。市场就像一个游走的目标，敏捷方法

    就是跟踪目标的箭矢，即使目标在运动也能够击

    中靶心。图1-8 2008年Dr.Dobb全球敏捷实施报告

    2013年VersionOne的年度敏捷调研报告(见

    图1-9)中，在问到敏捷项目失败的主要原因时，认为敏捷项目并没有失败的占18%。而认为敏捷

    项目失败的人中，由于企业文化与核心敏捷价值

    冲突导致失败的占12%，外部压力使得公司的理

    念和文化遵循瀑布进程的占11%，组织或沟通问题导致失败的占11%。

    如图1-10所示，在此次调查中，当问起究竟

    是什么组织问题影响了敏捷项目的成败时，大多

    数人选择了“团队缺少凝聚力”(34%)，或者“未

    能实行以团队目标为主的思想”(28%)。图1-9 2013 VersionOne 7th敏捷调查报告之敏捷项

    目失败的原因

    图1-10 影响敏捷项目成败的组织问题1.7 案例分析：IBM的敏捷转型之路

    IBM软件集团是一个庞大而复杂的组织，从

    2009年的软件部规模来看，全球26065名员工广

    泛分布在世界各地，拥有超过500个于各个时期

    收购的小公司以及相互独立的产品线，大量的独

    立工具和开发平台在公司内被采用。IBM的五大

    品牌行事作风迥异，很难用一种流程、一种组织

    结构来进行统一。

    为了促进发展，各品牌组织均开发了自己的

    经营策略，以适合其业务所在的市场。然而，IBM为所有的品牌都定义和秉持了一套共同的技

    术策略：

    ·开放的计算：为了创新并确保客户体验的自由度，客户端必须保持灵活性，这种持续的发

    展和推演需要基于技术和产品自身的价值而非自

    身的局限性。

    ·SOA：为了实现产品的灵活性和资产的重

    用，SOA(Service Oriented Architecture)是一套

    可以在分布式系统的设计和实现中将系统的业务

    模式与IT实现紧密关联起来的方法。

    ·彻底简化：尽最大可能增强产品的实用

    性。

    ·产品整合力：从商业价值出发，确保中间

    件的产品能够易于集成，并提供适于客户环境的

    完整解决方案。

    ·产品研发的3C品质：消费性(Consumablility)、模块化(Componentiza-

    tion)和社区(Community)三个原则，聚焦于改

    进开发流程和开发过程本身。

    对于软件部尤其提倡3C原则，以有效推动业

    务成长并提高生产效率。消费性影响软件的销

    量、支持的成本和客户的满意度(这反过来又影

    响了销售)。模块化使得功能相同的组件被抽象

    出来，并根据需求进行聚合，从而将产品有效推

    向市场，且降低成本，快速交付，驱动大回报。

    而所有这一切都取决于我们作为一个单一的软件

    部社区的技术深度和广度。在扩大社区格局的同

    时，团队也收获了相互协作和勇于创新的硕果，这也正是我们的竞争对手所羡慕的。

    3C原则带来的产品的质量提升，还仅仅是在以产品为中心的主流市场获得的成功体验，但

    是，当市场发生巨大变化时，战略又将产生变

    化。2006年的互联网高潮后，软件部受到全球IT

    经济低迷的冲击，股票开始下滑，面对开始失去

    信心的股东、董事会，为了生存，IBM不得不将

    战略导向从稳定业务转向了动态业务，提出“随

    需应变”的核心战略，软件部由此提出了敏捷研

    发方法，最大化地提高生产力，将产品更快、更

    好地推向市场。1.7.1 转型历程

    IBM的敏捷转型并没有残酷的清洗，反之，转型过程自然而和谐。IBM首先选择了一部分项

    目作为敏捷推广的先驱，通过招募以及内部发

    掘，培养了一批敏捷实践者和推广者，并把这中

    间最优秀的敏捷大师组成CoE(Center of

    Excellence)，由IBM副总裁直接领导，对全球所

    有软件部门进行敏捷培训。2008年，当我被提名

    参加中国研发团队的首批敏捷培训时，我已经谙

    熟敏捷测试，而我们是直接接受CoE团队培训的

    第77批学员，在那里，我认识了我的导师Scott和

    IBM推广敏捷的执行副总裁Sue。从此，我热爱上

    了我的事业并知道我将向何处寻觅我的目标。2006年或更早，IBM QSE社区作为IBM内部

    最权威和最大的技术社区，开辟了敏捷专区，分

    享各类相关的敏捷资料。2010年，敏捷社区注册

    人数已超7000人，阅读社区中来自不同国度的满

    怀热情的敏捷实践者提出的问题并给出回答，是

    我当时乐此不疲的事情。我从社区里大量下载大

    师级敏捷领导者发表的关于敏捷开发、持续化集

    成、测试驱动开发等核心敏捷实践的经典原创文

    章，不久，我也开始发表自己的文章，虽然每每

    只是窥见一斑，但我的文章拥有大量真实的数据

    和作为实践者的谏言，因此颇受欢迎。2008年，我将部分有关敏捷测试的文章第一次发表在中文

    的DW网站上，这篇文章使我收获了更多的勇

    气。

    2007年，有一篇发表于敏捷社区的文章，内容是转载了IBM跨软件部各个部门、产品线正式

    启动敏捷和精益方法的推广声明。

    声明的大意是：“我们均已意识到持续增长

    的业务压力，这就要求开发团队更具灵活性并能

    将产品更快地投入市场。敏捷和Lean开发方法，旨在将最有价值的部分传递给客户，去除“浪

    费”，授权团队有效地面对和处理复杂的业务，这些均已成为我们在软件领域的目标和信念。一

    些先驱团队尝试在IBM内部推行敏捷方法已有一

    段时间，我们相信，软件团队有能力成为敏捷实

    践的最佳推广部门。”

    2008年，软件部总裁在其个人年度计划

    (PBC)中包括了关于敏捷实践的两个重要条

    目：·加快敏捷实践的普及，并运用Lean的原

    则，提高开发者的工作效率和对客户需求的响应

    速度。

    ·将IBM的“可扩展敏捷”业务模式展现给

    客户。

    与此同时，总裁的个人规划被自上而下地推

    动到每个IBM员工的年度计划中，无论是管理层

    还是技术层，都承诺了与敏捷相关的目标，因

    此，软件部各个组织和团队都积极地希望做得更

    好，取得更好的年终绩效，成为其他团队借鉴的

    榜样并以此为殊荣。在这一年里，几乎所有人都

    在思考和学习如何在自身的工作中使用敏捷方

    法，以及如何配合团队实现敏捷目标。中国开发

    中心的员工也大量注册到IBM QSE的敏捷社区，主动成为敏捷的倡导者和实践者。主导的团队成

    员还自发组织成立了中国的敏捷社区，相互分享

    经验并帮助解决敏捷实践中遇到的各种问题。

    2010年，仅中国区注册的敏捷社区成员约为750

    人，全球有6000余人注册，领导团队成员达到12

    名。与此同时，敏捷专家组(CoE)成立，帮助

    IBM实现精益和敏捷转型。CoE的主要任务有两

    项：寻找能够适用于多团队的行为模式；开发出

    更优秀的适用于IBM团队的新行为模式。1.7.2 品牌的力量

    网易创始人丁磊经常跟他的员工讲《老鹰》

    的故事——一枚鹰蛋不幸落入了鸡窝，母鸡孵化

    了小鸡和小鹰，带着它们吃着农场主洒下的细碎

    的谷梗。当它们成群地在乡间踱步时，小鹰没有

    一次扇动翅膀飞起，也没有怀疑过自己的模样。

    小鹰慢慢长大，直到有一天，鹰妈妈发现了小

    鹰，把它叼到悬崖上的鹰巢，告诉它：“你是

    鹰，你属于蓝天，你能够飞翔。”然后把小鹰一

    把推下悬崖，于是小鹰挣扎着张开翅膀，飞了起

    来。这个故事蕴含的道理是，每个人、每个团

    队、每个企业都有潜在的能力，不要被习惯所遮

    盖，不要被成功经验蒙蔽，不要忘了远大的志

    向，要不断激励自己，让自己飞起来。这个故事对丁磊产生什么影响我们未必得知，但是从他带

    领的团队来看，这是梦想的开始：向往飞翔，成

    就未来。

    愿景对品牌的建设尤为重要，缺少愿景，品

    牌建设只能在激烈的竞争中迷失方向，在“合

    理”的业务延伸中失去衡量的标准，致使发展受

    阻。良好的品牌愿景给员工、客户、股东、社会

    一个理想的世界，帮助企业找到前进的方向。

    IBM的品牌历经起伏。1993年郭士纳接手

    IBM的时候，IBM正面临着前所未有的困境，IBM品牌等同于“古老、高傲、尾随新一代高科技

    公司之后”。郭士纳就任IBM舵手之位后，采取了

    紧急止血的业务运营措施，扭转了逆局。面对信

    息公路的高速增长，客户对整体解决方案逐渐倚重，对不同供应商的产品组装越来越没有耐心；

    芯片的计算速度、存储成本也越来越无足轻重。

    因此，IBM决定放弃文化传承的讨论，而是将公

    司从一家大型主机制造商转变为同时提供硬件、网络及软件整体解决方案的供应商。十年励精图

    治的变革使IBM品牌终于摆脱了困境，而在新一

    任CEO彭明盛上任时面临的是一种新的挑战：如

    何使员工不再回到自满和安于现状的老路上，如

    何通过理想和抱负来鼓舞他们继续前进。因此，对于IBM来说，确立一套新的企业价值观成为公

    司任务的重中之重——这绝不是只做表面文章的

    空话，而是要让价值观成为团结和激励员工的有

    效手段，其实质就是要运用价值观进行管理。

    IBM公司凭借创新的服务理念和卓越的执行能力

    连获“2006年度中国最具价值IT服务商”、“金融行业专业服务满意奖”和“电信行业专业服务满意

    奖”。又一个十年过去，如今的IBM正在面临巨大

    的格局变革，从稳定业务转向动态业务，以新的

    软件系统结构满足丰富却变化的客户需求。1.7.3 核心竞争力

    为了做好全球资源整合，树立新的百年基业

    长青的成功企业，在如今的市场上取得更大的成

    功，IBM在战略上再次做出调整。IBM品牌战略

    团队认为，IBM的团队和个人应该具备新的能

    力，为了帮助员工与时俱进，培养新的能力和工

    作方法，也为公司未来的成功奠定基础，IBM的

    品牌核心竞争力的有了新的定义。

    1)拥抱变化。IBM员工应当专注于已经发生

    以及将来可能发生的变化，这个变化会发生在我

    们或客户身边，面对挑战，我们要有能力找到问

    题的突破点并向前迈进。

    2)成就客户。IBM员工要以实现客户当前和未来的愿望为目标，并为成为客户的合作伙伴而

    感到骄傲。我们和客户协同创造的解决方案和收

    获的成功经验，都将会转化为企业和社会的宝贵

    财富。

    3)全球协作。IBM员工遍布全球，因此必须

    精于合作。我们需要跨越团队、领域、思想、学

    科、国家和文化的界限，通力合作以寻找正确的

    结果。作为全球一体化的企业，我们建立了自己

    的专家网络，鼓励员工使用集体智慧，以集体领

    导力带领IBM改造市场、社会和世界。

    4)用系统的眼光行事。IBM员工是系统思考

    者。我们帮助客户、同事和世界理解并设计系统

    ——它是如何感知、关联和分析信息，发掘潜在

    模式，并将知识转化为信念和行动。无论系统中的问题属于技术、经济、社会、文化或自然范

    畴，这种系统性的观点使我们能够甄别出“真”的

    问题，并在适当的时间、以正确的方式采取明智

    的行动，同时敢于承担风险。

    5)建立互信。无论在IBM的内部组织或客户

    中，还是在发展、变化的外部世界中工作，IBM

    员工应善于建设“全方位的信任”：即使有不同的

    愿望、意图、约束和文化，我们都可以找到共同

    点。以诚信行事构建人与人的关系，即使未能达

    成一致，也应明确意图、确保开放和对信任的坚

    持。要知道做什么和怎么做，并有足够的激励来

    实现目标。一旦发现信任被侵蚀，我们必须立刻

    担当责任并迅速弥补。

    6)厚积而薄发。IBM的价值主张和商业模式植根于专业的知识。因此，需要不断加深专业

    性，成为IBM有价值的员工、合作者、领导者。

    员工可以通过反馈、辅导或者从有挑战性的任务

    中学习，从而发展技能和职业。

    7)持续改进。IBM员工都致力于建设一个更

    好的IBM公司和一个更好的世界，这是IBM公司

    在过去的一百年所致力完成的。我们的求知欲和

    不停息的进步不断为企业注入能量。今天的世

    界，未来难以预测，IBM员工正在积极寻求我们

    还不知道的和我们尚未想象到的。因此，我们培

    养开放的环境，尝试新的方法。我们重新思考假

    设，提出探索性的问题，掌握新情况，发掘机

    会，并创造新的市场。我们乐于结交拥有不同背

    景、文化、语言或工作作风的合作伙伴，这是我

    们适应不断变换的基因所决定的。8)沟通与影响。沟通的目的是相互了解，建立一个共享目标并分享成果。沟通始于倾听，要确保人们的想法和顾虑都能被我们听见。我们

    以专业的角度专注于简单、清晰的沟通，尤其是

    在复杂环境中，我们需要解释不同的概念、战略

    和意图，我们会利用对他人观点的理解来丰富自

    己，这种态度和方式让我们受益，即使在困难的

    话题上，或者不受欢迎的环境里都能够以最及

    时、最有效的方式进行沟通。

    9)帮助其他IBM员工成功。IBM品牌是关于

    IBM员工的，以及IBM员工如何出现在世人的面

    前。这不仅仅限于面向客户的IBM员工，每一个

    IBM员工都力争把最好的一面、最优秀的自我展

    现在工作中。为了帮助员工成功，要确保他们有充足的资源、持续的支持和清晰的里程碑。我们

    会彼此分享见解，讨论面前的挑战并排除障碍。

    我们承认他人的贡献，对他们的想法给予鼓励，并帮助每个IBM员工找到自己的内在驱动力。我

    们创造一个让员工感到目标一致且可融入的环

    境，以激发他们强烈的欲望并协同行事。1.7.4 敏捷品牌

    IBM的品牌愿景规划出公司明天的优势、使

    命和价值观。品牌愿景不仅使员工看到了高瞻远

    瞩、力拔头筹、高效协同的未来，也让客户对

    IBM更有信心。构建明确的品牌愿景需要企业对

    内外部环境进行非常透彻的分析，并真正从内外

    部环境需要出发，理解自己应该与客户建立一种

    怎样的关系，这是值得许多企业高度注意的问

    题。在很多情况下，企业容易遇到的问题是：单

    纯地从个人意志出发理想化地定义自己的品牌意

    义，如“为客户创造价值”、“努力奋斗”等，而敏

    捷方法论在软件部的试行和最终采纳则是源自内

    外环境的需求，针对可能存在的不确定性，敏捷

    实施的重点在于：·在发展进化、协同配合和自我管理规则下

    持续高质量的交付。

    ·延展敏捷开发方法论，使其成为解决整个

    软件、系统工程全生命周期模式的方法论。

    ·基于风险和价值驱动的方式来生产有价值

    的产品和解决方案。

    ·从共性的规范性敏捷交付方法中，透析并

    实现独特的个性需求敏捷。

    敏捷思想强调价值、沟通与合作、质量、增

    量型，这与品牌价值自然融合，也是许多公司同

    IBM一样在坚持使用敏捷方法推动软件项目发展

    的原因。敏捷方法并非一成不变，就目前行业统

    计数据来看，超过76%的团队正在使用多种敏捷方法，而且坚信敏捷方法可以使企业获得成功。

    与传统的开发项目相比，敏捷开发项目有更可观

    的成功率、更强的软件和系统生产能力、更高的

    客户满意度、更佳的投资回报率(ROI)，并且

    能够更快地将产品投向市场。1.7.5 成功转型

    IBM敏捷转型的结果如何？不妨阅读一篇来

    自G.P同学的文章，《How IBM Saved300Million

    by Going Agile》(如何通过敏捷赚取30亿美

    金)，果然大象舞蹈得更加敏捷了!

    “怎样才能使世界上最大的软件组织更加灵

    活、更加适应市场？您可能已经读过或听说过，任何我们的专家和思想领袖，如斯科特·安布勒、布鲁斯·道格拉斯、沃克·罗伊斯都会歌颂敏捷开

    发和IBM的敏捷交付方法。IBM Rational团队坚

    信，不管你有多大的软件开发团队，你都可以从

    敏捷转型和敏捷方法中受益。”

    敏捷技术果真能够运用至像IBM软件部一样大小的“店”吗？这个巨大的组织，我们称

    为“SWG(软件部)”，已经成功尝试了敏捷转

    型。而这在一开始显得颇具挑战，毕竟，我们已

    经看到过去十年SWG业绩的稳步增长，我们还需

    要采用新的技术吗？而当时的SWG领导团队做出

    了最正确的决定，从而带来了今天的成功。

    采用敏捷方法将帮助任何一个组织提高生产

    力和利润，而这远优于其之前采用的相关措施。

    几年前，软件部开始了敏捷软件开发实践及相关

    敏捷开发产品的研发。为了适应他们的需求，我

    们开发出适合敏捷环境的工具，包括用于协作的

    Rational Team Concert、用于协助组件复用的

    Rational Asset Manager，以及用于团队会议和消

    息功能的Lotus Connection，而这些工具也非常适

    用于跨国或者分布式团队开发环境。如果需要通过数字说明敏捷转型的结果，那

    么，IBM软件部因为推行敏捷，节省了超过30亿

    美元的软件研发成本。截至2012年，80%的IBM

    软件开发团队使用敏捷开发，员工人数超过

    62000人(2011年下半年为57000人)，跨越346

    个产品领域均使用了Rational Team Concert，帮助

    所有人实现了项目实时可视性，保证了项目的健

    康并行。

    而敏捷方法并非只在软件领域发挥出优势，IBM系统和科技集团软件开发人员克拉克·杜德克

    说：“我们以前使用配置管理版本控制，这需要

    一个漫长的代码检查过程。Rational Team Concert

    的引入有利于代码协作，团队能够更好地实现工

    作项跟踪。而与此同时，系统部的同事正在使用敏捷方法和工具进一步改进他们的工艺和生产

    率。”

    敏捷为IBM带来的商业价值更多地是帮助企

    业、团队发现哪些要素需要用来构建质量更好的

    产品，或更快地将工作成功迅速地转变成商业价

    值。这既包括了“过程、人”在提升效率后产生的

    价值输出，也包括了其他帮助我们走上敏捷之路

    的工具(例如RTC)所带来的直接收益。30亿远

    远不及“敏捷的引入”带给IBM的全面商业价值。

    但对于“过程、人”等环节发生转型后所产生的价

    值，因为这个过程缺乏“可逆性”和“有效度量

    性”，我们没能给出这部分的价值度量。而对于

    RTC，它并非一个可以替代的没有灵魂的简单工

    具，RTC已经融合了敏捷流程模板、代码和敏捷

    主义的思想，成为IBM团队所认可的不可以替代的“智慧工具”，成为如今最好的“整合团队敏捷度

    和企业项目透明度”的工具，尽管它还有缺陷。第2章 敏捷落地艰难

    2.1 敏捷实践误区

    2.2 理论的局限性

    2.3 传统团队践行

    2.4 敏捷实施法则13条

    如果在IBM做个调查，几乎80%的敏捷研发

    人员，无论是做技术还是做管理，恐怕都会告诉

    你他们使用的是Scrum。而当你深入地了解他们

    的工作、流程、方法、交付结果时，却发现此

    Scrum非彼Scrum。

    尽管大家对Scrum的理解不同，但我们必须承认，大多数IBM中国的研发项目敏捷转型确实

    是从Scrum开始普及的，从而衍生出IBM的核心敏

    捷(Core Agile)、规范性敏捷交付(Disciplined

    Agile Delivery，DAD)和可拓展敏捷模型(Agile

    Scale Model，ASM)等。

    Scrum这种核心的敏捷方法对开发团队来说

    的确重要，就连RTC工具发布了大量的“开箱即

    用”的Scrum流程和模板。除了IBM，业内的同行

    也大量使用了各种核心的敏捷方法。2.1 敏捷实践误区

    团队接触Scrum一两个月后，往往自认为对

    Scrum的方法和流程已经足够了解，此时容易犯

    下几个小错误。但如果不能及时加以纠正，小错

    误将可能导致更大的错误，以致阻止Scrum或者

    其他敏捷方法的正常实施和组织的顺利转型。

    1.越频繁变更越“敏捷”

    进入这个误区的人不在少数，大多数人认

    为“快”就是敏捷，Scrum中的迭代周期如能缩

    短，团队将会更加灵敏。有些团队成员一边“享

    受敏捷的礼遇”，一边“开着小差”，觉得自己隔三

    差五给团队个交代就可以了。于是，想到哪里设

    计哪里，不和客户保持经常的接洽，更不会管理客户需求，只要是客户说的，无论成熟与不成熟

    都扔给开发团队。这导致了产品三天一小改、一

    星期一大改，这样的“Scrum”开发模式把团队完

    全弄懵了，还没明白过来是怎么回事，就被告

    知“进入下一个迭代了”，一边重复工作，一边又

    被灌输越“快”就是越“敏捷”。这种做法显然可

    笑，因为敏捷的增量型递增模型完全不存在，团

    队变成了“无头苍蝇”。

    不得不指出，这种现象经常发生在互联网行

    业，这个行业的客户其实就是普通大众，对于一

    项网络功能，一半客户稀罕、另一半不稀罕是经

    常发生的事情。例如，针对网页中的Flash动画，如果询问用户，喜欢和痛恨Flash的差不多一半一

    半。如果不仔细观察和分析这类普通大众的需

    求，很有可能今天加一个、明天再去掉一个Flash，并且开始争辩哪种方式最好，既浪费时间

    又耗费团队的精力。

    实际上，如果仔细分析，就会发现痛恨Flash

    的用户其实是不喜欢使用不当的Flash，那些大而

    复杂的Flash下载时间长，用户没有兴趣完整地观

    看。所以，设计过程中变化不可避免，但绝不要

    用“缩小迭代周期”、“短频快”的做法来遮掩设计

    的缺陷。

    所谓“武功唯快不破”的只是小说，而不是敏

    捷开发。

    2.“自我管理”等于“随心所欲”

    我们鼓励自我管理是因为一线的员工比以往

    更聪明、更训练有素，我们发现员工的高效率来自充分明确自己的工作，并以最好和最省力的方

    式来实现。而且，员工在自己处理的问题时，往

    往表现出高度的集中和快速的提高。自我管理是

    授权给员工自己设定目标，将工作当做自己的事

    情来做。在一个高信任、低敬畏的组织里，员工

    不需要太多的监管，但是他们需要理解和支持，而不是“老板”时时在左右。

    自我管理制度和“层级组织制度”针锋相对，在新的制度里我们不希望见到“老板”、“总

    裁”、“管理人员”的字样，这些高级头衔并不代表

    有能力“Lead(领导)”低级头衔。一个领导的影

    响力来自他展现出来的做事能力，以及作为团队

    建设者的卓越性，这类人往往为团队成功做出了

    较多的贡献。但自我管理制度仍然有界限，无政府主义和

    滥用权力是不允许的。一个自我管理的团队是高

    效的管理系统，自由度不是无限的。美国的

    Whole Foods连锁超市，其最基础的组织单元不是

    门店，而是团队。Whole Foods的团队是零售业史

    上空前的自治团队。每个门店约由8个团队组

    成，他们对门店的各个环节进行管理，从食品加

    工到收银结算。按规定，每位新来的同事都会被

    分配到某一团队，经过4周的试用，团队成员投

    票决定这位新同事的命运——新同事需要获得23

    以上的赞成票以获得全职岗位。Whole Foods的决

    策者相信，关键的决策问题应当由那些受该决策

    结果影响最大的人做出，例如，雇用谁的问题就

    应该由未来和他共事的人决定。Whole Foods的团

    队绩效考核是透明的，绩效超过一定额度的团队得到更多的奖金；如果一个团队将一个懒散的成

    员纳入团队，他们下个月的奖金就可能减少!事

    实上，如果这些团队成员没能勇敢地站出来反对

    那些滥用权力的团队领导，或者没有否决雇佣低

    效率的新员工，就不算真正的自我管理。而这种

    高度的自治、自我管理方式向我们证实了一个道

    理：员工自我管理并决定自身的成败，而不由管

    理人员决定，自我管理绝没有变成“随心所欲”。

    3.年轻的团队最有“创造力”

    这是肯定的，但是，没有经过“培养”的新

    人，在没能判断其是否可以独立工作之前，不要

    急于让他上岗。对新人的培养、新团队的建设是

    绝不能忽略的。事实证明，入职过程很少能在极

    短的时间内完成，一般需要2~3个月，而IBM会用6个月完成新员工入职的一系列培训，包括法律

    法规教育、公司文化熏陶等。

    当然，并不是刚入职的员工不能成为Scrum

    团队的一员，有很多刚入职的员工是明日之星，只是不能将工作放心地交予没有基础的员工。年

    轻的团队需要教练、需要引导、需要有经验的人

    带着走入这个有声有色的圈子，还需要理解流

    程、通晓团队中的各项职能、理解如何定义工作

    的“完成”，然后才有能力上岗。一支团队从组建

    到完全释放每个人的能力需要经过团队初建期、过渡期、风暴期和成熟期四个阶段。在IBM的几

    乎所有工作项目中，都有比较近似的团队初建过

    程，也就是团队成员在一起共同分享和探讨下面

    这些问题，确保所有人都做好了准备。·互相介绍背景。

    ·给予团队一个名字。

    ·确定团队定期召开会议的时间和地点。

    ·分享团队的一般工作流程，介绍团队工作

    中的主要递交物。

    ·教会新人如何判断工作已经“完成”。

    ·建立团队的独立规则，例如请假需要跟负

    责人提前沟通等。

    ·如果需要，确定团队定期培训的时间和培

    训内容等。

    任何团队都必须融入组织中。IBM的组织结

    构是矩阵式的，一般员工都有三个“领导”。第一个是行政经理，负责批复假期、做入职手续、离

    职手续。如果员工需要资源，一定要先找到行政

    经理，因为他离员工往往最近，没有人能够像他

    一样更好地支持员工，我们可以叫他“经理”。第

    二个是职能经理，负责员工的工作绩效考核，和

    员工一起制定工作季度规划、年度规划。员工要

    经常和职能经理保持畅通的交流，这样功劳、苦

    劳才会记载在功劳簿上，我们可以叫他“老板”。

    最后是员工所参与的项目中具备相同职能的一

    个“老人”，我们姑且叫他“Lead”或者“Technical

    Lead”，这个人身先士卒，极有威望。对于入职

    的新人，我一般都建议他们去学习Lead的工作方

    法：你看他怎么干，你就怎么干，一定没错的。

    我们需要Lead参与团队的培养，Lead需要分

    出一部分时间来做团队的“领导”、“教练”、“老师”，学会时间管理和授权，让自己专注于更有

    价值的工作，而将执行和具体的操作交给团队的

    新人，同时做好以下几件事情：

    ·在老板和利益关系人面前代表团队做出承

    诺(例如工作时间、交付期、工作范畴)，任何

    时候都不需要告诉老板和利益关系人你还需要和

    团队商量后再确定，第一时间代表团队做决定，要果决。

    ·监控团队的工作进度，最好是通过系统监

    控，不要在团队认真工作时打扰团队。

    ·如果出现问题，必须立刻参与进来，判断

    和解决主要部分，并将一部分工作交由新人来

    做。·对团队新人需要经常表扬，必要的时候批

    评，棍子和糖都需要。

    ·分配工作，让每个人都充实起来，多给予

    员工支持。和新人的沟通一定要到位，不要简单

    粗暴，一定要让他们认为工作是可以承受的，才

    能够放心授权。

    ·经常帮团队申请资源，比如聚会、活动

    等，但是一定要让团队有机会展示自己。我的经

    验是，团队曝光率越高、占用资源越多对团队越

    好。

    不过，对新人不能太“民主”，尚不能任由新

    人自己从Scrum的产品清单中选择工作项目。还

    有，和利益关系人的沟通也要一步步放开。这绝

    不是“反”敏捷，而恰恰是非常务实的经验之谈。让年轻人先将那些“天花乱坠的想法”收敛起来，虚心学习他人的智慧，懂得尊重前辈，不跳跃、不敷衍团队建设这个自然过程，才可以形成良好

    的团队氛围并奠定扎实的基础。对于年轻人来

    说，先学会“规则”，看到“边界”，虚心学习，这

    一切都将对他们的个人发展产生积极影响，他们

    会看到成长后将有更多的自由选择空间，包括喜

    欢的工作和喜欢的工作方式，也会期待将来的一

    天成为“Lead”，可以有“弟子们”的帮忙，做更有

    成就感的工作。同样，对于资格已老的团队员工

    来说，通过悉心帮助成长起来的新人让他们有更

    多的时间去做更有价值的事情，包括许多以前很

    难做到的事情，并带来成就感。而且，“师生关

    系”潜移默化地消除了“长江后浪推前浪”的不安，老员工心态会更平和，也能看到更远的人生。总之，团队建设初期，或者新人刚加入团队

    的一段时间，建议经过培训和教育再参加Scrum

    工作模式。团队Lead扮演了重要的明星Scrum成

    员的角色，在团队中既要做导师、教练，又要在

    Scrum团队中承担工作。所以，一个比较好的组

    织方式是，Lead直接参与Scrum团队的各项工

    作，而新人在入职的一段时间里跟随Lead参与

    Scrum的所有活动，但是不发表意见，只做聆听

    者、学徒和主要的执行者，Lead会给出新人的一

    切工作安排并负责与其他Scrum成员和利益关系

    人沟通。

    4.不了解项目的产品负责人

    产品负责人(Product Owner)的主要职责是

    定义产品的功能，他的任务包括倾听用户需求、负责产品功能的规划等。后端的工作也需要产品

    负责人，如解决各种问题、处理组织关系、有效

    地和研发团队沟通产品的功能需求和设计等。产

    品负责人的问题是忽视燃尽图和整体产品研发进

    度的跟踪。“无论如何，那不是我的主要工作，团队负责人和项目经理、开发经理应该更关心燃

    尽图”，一个资深的产品经理甲曾经对我如是

    说。又有产品经理乙曾对我说：“产品负责人负

    责思考需要开发什么，而开发团队、开发经理负

    责如何开发，所以，燃尽图不是我的工作。”

    不关心进展和状态的产品负责人很少有兴趣

    了解迭代的过程，也不了解团队当前遇到的问

    题、关心的话题、需要的帮助。所以，在迭代后

    期，会出现由产品负责人引发的不必要的需求变

    更。不经常、甚至不愿意和团队保持通畅的沟

    通，因为那些对他们来说是浪费时间和效率的做

    法，与团队进行针对需求和设计的讨论对他来说

    也是对自己尊严和地位的挑战，因而，很难让团

    队能够“转身就可以和产品负责人讨论一个必要

    的细节”。相反，产品负责人更愿意一次性交付

    给团队全部需求和设计，同时给出详细的要求，甚至对自己的杰作有着另一种苛刻，细致到

    了“完美”的程度，而这样的需求和设计对于团队

    而言形同“一纸文书”。产品负责人愿意将和团队

    面对面的沟通回归到电子邮件或其他书面沟通方

    式，而这种做法深深地伤害了团队对自身工作的

    认可和参与新模式下研发工作的热情，团队会怀

    疑自己是不是真的找到了“为自己工作”的热情，面对产品经理，他们会觉得“低人一等”、“受人支配”。产品负责人“独立”工作的态度和方式也将阻

    碍“有深度的思想”传达到位，同时将增加团队内

    部的沟通成本并损失一定程度的工作效率。

    显然，这样的产品负责人仍然会给自己找不

    少“麻烦”，倒不如保持平常心，把自己和团队放

    到一个水平面上，更多地关心和尊重团队。比

    如，认同团队在设计细节上有着更为精准的定

    位，在产品质量和验收上是更为直接的受益者和

    关系人。而且要关心团队进度，如果团队正处在

    峰值工作，应该避免给团队更多压力；如果团队

    正处在高效率、健康的工作状态中，可以将新的

    产品清单增加到迭代中。这些都需要产品负责人

    看懂各种状态的燃尽图，那么我们来了解一下燃

    尽图如何体现项目的状态和进展。(1)发布燃尽图

    在图2-1中，实线部分描述出实际发生的每个

    迭代所增加的工作量(用故事点计算工作量)，实线的曲率表示开发的速度，即单位迭代所完成

    的工作量，曲率上扬表示增量开发继续在先前的

    工作基础上增加了新功能，曲率下行则表示以前

    开发的故事已经被放弃(虽然不愿意看到，但是

    几乎不可能杜绝)。虚线部分代表发布计划，表

    示对这个发布燃尽速度的大概规划，这条曲线只

    作为参考。图中第二个迭代完成的工作量落后于

    计划，这意味着以后的工作强度要比计划的大，或者计划部分的工作量有可能需要从发布计划中

    剔除掉。图2-1 发布燃尽图

    (2)迭代燃尽图

    迭代燃尽图(见图2-2)即在一个迭代内标示

    工作量完成的进度，图中的虚线部分是每天实际

    发生的工作量，实线部分是计划燃尽曲线，这个

    图是用“减法”思考的，随着时间的推移(天小

    时)曲线从最高点滑向“0”。图2-2 迭代燃尽图

    如果你是产品经理，燃尽图所表示出来的信

    息你能够都读懂吗？看看图2-3的分析，你就会明

    白了。图2-3 如何读出燃尽图背后的故事

    这张图是我在管理团队项目时的实际燃尽

    图，折线部分是实际发生的燃尽曲线，我们从上

    至下看看几个被圈出部分所代表的含义：

    1)因为没有更新工作项进度，或者没有统计每天的燃尽工作量，或者工作量阻滞了，这个

    区域燃尽曲线是水平的。

    2)当时间进展到周六、周日，大家通过加

    班赶上了原来被阻滞的进度，情况还算不坏，但

    看得出来大家很用功、很辛苦。

    3)第3个和第4个圈出的区域显示曲线的下

    行突然被打断，而实际情况是并没有工作被阻

    滞，也没有忽略统计，结果只有一个，就是团队

    低估了工作项(Over Commit)，在开始迭代的第

    二周，团队增加了对该工作项的评估工作量。

    4)第5个圈出的区域有陡峭的曲线，这显然

    不合乎我们对团队工作能力和开发速度的认知，后来发现，这主要是由于团队对已完成的几个工

    作项有过高的估计工作量(Under Commit)导致。

    5)第6个圈出的区域也有较陡峭的曲线，原

    因是在迭代的后期，大家担心时间不够，怕拖了

    团队的后腿所以真的非常用心，也非常高效，而

    且周六也确实在加班。

    可见，产品负责人学习读懂燃尽图，对于团

    队的工作速度、能力认知非常有帮助，能够明白

    团队的辛苦，了解当下团队的工作强度，帮助产

    品负责人做出判断，何时“见缝插针”，何时“减轻

    工作负担”。

    5.好大喜功

    中国式敏捷很像盲目的城镇化。有些人简单

    地理解城镇化就是钢筋混凝土的高楼大厦和复杂的交通设施，殊不知城镇化是一项历史过程，伴

    随着物质和精神文明的进步，产业功能的转变，和住房、教育、工作、就医、资源配置等一系列

    变化。敏捷也不是简单地叠加众所周知的最佳敏

    捷实践，如测试驱动开发、迭代、持续化集成，更不可解释为更好、更快地开发产品。敏捷首先

    将项目开发中的资源优先配置在高价值的需求

    上，通过增量型的产出和验证使得产品以最快的

    速度进入市场并成功盈利，进而带来了一系列的

    沟通、技术、过程、组织的变革。这是一个历史

    过程，盲目模仿可能会得到最快的结果，但一定

    不是有生命力的结果。忽视敏捷转型过程，仍然

    过份强调效率、时间、成本，鱼和熊掌皆想得，甚至从原来一个月一次的发布变成像网页开发一

    样一天多次发布才甘心，这些都是中国式敏捷好大喜功的表现。过速的敏捷转型、盲目的跟从、不依附客观条件而妄想的敏捷世界让我们又要深

    思，为什么敏捷，敏捷是否有效，或者敏捷转型

    如何做到稳健且波澜不惊？2.2 理论的局限性

    在我们不断加深对Scrum的理解，并使用敏

    捷方法改进日常工作和生活的同时，却发现了

    Scrum在指导研发工作，特别是复杂的软件研发

    时存在很大的局限性：Scrum涵盖了软件开发生

    命周期中的构建阶段，却缺乏对团队的初始创建

    阶段、项目启动、软件即将发布以及软件维护阶

    段的指导价值。

    我们要否定Scrum吗？不!在否定之前，我

    们还需开放性地问问自己，Scrum真的没有对构

    建初期、发布阶段的工作产生任何作用吗？我的

    答案是，Scrum方法的确没有对这些阶段的研发

    有任何指导，可是我们聪明的大脑非常愿意修复这个缺陷，对于所有方法论没有制定或涵盖的部

    分，我们的大脑延伸了Scrum方法，尤其是四句

    敏捷宣言。这就可以解释为什么大家在“没法可

    依”的情况下，仍然默契地、毫无顾虑地在软件

    完整生命周期的各个阶段坚守Scrum原则。

    当团队有勇气和智慧批判地继承权威理论的

    时候，无论对与错，都要赞许他们追寻真理的愿

    望。我非常愿意和团队的“明白人”探讨并将经验

    和心得贡献给IBM敏捷领导团队，也正是因为我

    不怕犯错，勇敢地挑战了Ken Schwaber的Scrum方

    法，后来我才能加入IBM的敏捷领导团队，成为

    2010年的IBM Scrum Fellow。在之后的一年半时

    间里，我又参与了IBM敏捷方法论DAD、分布式

    敏捷挑战以及ASM的研发。在详细介绍DAD方法之前，通过一个例子来

    找找Scrum的局限性何在，以及我们将如何应

    对。

    某房地产开发公司相信，盖好的房子，就必

    须按照客户需求不断改进，掌控好用料和工序先

    后，把握好现金流量，不冒进不头脑发热。按照

    敏捷主义原则，公司的价值追求是务必让客户满

    意，这样可以少花费因不按照需求工作带来的成

    本消耗。

    然而，设计部门对于市场预期不准，对于购

    房者的分析不细，这会花费大量的时间，而这个

    结果本身又随着时间和格局的变化而不同。设计

    部迫切需要设计出大卖的房子，单凭经验判断和

    大胆预期自然不是最好的解决方案，于是依照Scrum的构建方法，设计部门打算先设计最可靠

    的部分，例如先占地，将地基和房屋的支撑结构

    构建出来，剩下的就走一步看一步吧。

    同时，开发商也没有充足的资金来支撑整个

    项目，银行向房地产行业放贷的口子缩紧，只能

    拿到以往项目14的资金。但是，项目不能再等，必须开始。项目资金需要通过其他方式募集，或

    者等待房子构建完一部分再从购买者那里筹备。

    尽管充满挑战，这家创新型的房地产开发公

    司依然认为最重要的不在于是否遵循了原计划或

    者不逾期不超支，而在于对客户需求的理解和执

    行到位，因为如果出了问题，将会自己担负责

    任。这就是以Scrum为核心。

    房地产公司开始建房了，设计部门、工程部门和验收部门一起工作，结构设计、施工、验收

    遵循一个个迭代来完成(见图2-4)。第一个月结

    束的时候，市场需求基本清楚；第二个月中，利

    用第一部分投资完成了地基的打造，并且在四方

    的土地上树立了4个结实而高大的立柱，这4个立

    柱将支撑起最好的房子：至少团队是这么认为

    的。当第二个月的工作完成时，房地产公司拿到

    了准售合同，他们提前售出20套房子，来这里看

    房子的客户对地理位置和房屋效果图，以及工地

    上如火如荼开展的工作很有信心，开发商很快将

    这部分钱用于第二期的投入。就在这20位房主签

    约的时候，设计团队从客户们那里了解到，他们

    不再喜欢老式的平顶建筑，而是喜欢复古的尖顶

    房。第三个月结束时，这个设计理念很快被第二

    期投入的团队开发出来了，房屋验收以后已经初具规模，有坚实的“骨骼”和漂亮的“房顶”。不但

    之前的20位房主愿意付清剩下部分的尾款，而且

    吸引来10位新的客户，他们也愿意付12房款，并

    提出了自己对于外墙特色的建议：红色的复古砖

    墙，但是需要有美丽的花纹，有蔓藤在攀爬一样

    的效果。终于，最后一个月到了，开发商有了充

    足的资金完成剩下的工程，和客户之间的沟通让

    彼此的合作更加顺利，外墙工作完成得非常好也

    非常迅速，并顺利通过验收，于是有了一个皆大

    欢喜的结尾。

    图2-4 使用Scrum建造房子可是，真的皆大欢喜了吗？不久以后，政府

    修建的一条高速公路从距离此处100米的位置通

    过。在高速公路施工期间，房主们纷纷抱怨噪音

    和光污染，大批住户搬出了住宅。最终，房地产

    商因为没有提前发现风险并进行规避而损失不

    小。

    事实上，高速公路的修建带来的只是小的损

    失。当第三个月完成了房顶的构造之后，因为低

    估了先封顶后建房的技术风险，不得不在第四个

    月完成外墙修建工作时启用巨型吊车将房顶吊起

    施工，这个成本是之前没有考虑进去的。突如其

    来的问题让开发商损失很大。

    开发商开始反思，造成损失的原因主要是没

    有对环境、政治因素进行规划，也没有重视项目中的技术风险。实际项目需要考虑诸多因素，那

    么如果在开始项目的第一个迭代前，进行初步规

    划并考虑风险因素，并将其与价值论结合起来，这样的构造方式岂不是更加合理？

    其实，IBM敏捷方法DAD的诞生便源自于我

    们对Scrum和其他核心敏捷方法在复杂环境中的

    思考和怀疑。这些方法我视为瑰宝，因为让我感

    动的不仅是方法本身的成功带来的喜悦，更多的

    是它们见证了一段宝贵的历史。IBM的领导团队

    心态开放，充分理解和接受新思想，山穷水尽疑

    无路之时，我们仍不放弃真理，经历了诸多痛苦

    与挣扎，批判与接受，直到改良落定，柳暗花明

    又一村。2.3 传统团队践行

    迄今为止，社会上有许许多多敏捷培训课

    程，但是说起敏捷转型，团队既需学习成熟的敏

    捷方法，又需要资深的敏捷实践者、敏捷教练引

    导团队循序践行。敏捷的开发者、测试者、业务

    和需求研发者或者是管理者都需要找到自身的重

    新定位。事实上，我们在重新构建一套项目研发

    管理流程和方法，这个过程中，我们或多或少都

    会有疑惑：项目管理方法PMBOK和敏捷项目管

    理有什么区别和关系？传统软件研发体系中的项

    目管理过程和敏捷项目管理过程有什么区别？传

    统项目的项目经理在敏捷环境中是否需要学习新

    的技能或面临淘汰？简单地说，敏捷方法的一切努力都基于一个

    目标：节省研发成本，降低运维费用，提升利润

    点。敏捷方法因此才得以推广。需要长期的投入

    过程、由厚重而具体的计划驱动的传统项目研发

    方式很难适应变化的市场，因为，再好的设计也

    会过期，也需要发生变化，计划投入成本的首要

    考虑是节省。对此，传统项目经理并不会站在对

    立面，面对新模式，管理者需要做的仅仅是将项

    目的庞大计划拆分成细小的迭代计划，并且认可

    调整期待目标的必要性。2.3.1 挑战传统管理

    传统项目经理的华丽转型还需要一点点“破

    茧而出”的勇气。在敏捷转型完成之前，需要传

    统项目经理一步步完成自适应的转型，将原来惯

    于为团队做出裁决、管理团队的高姿态慢慢放

    下，从“管理”过渡到“支持”，放弃约束和命令，迎合和培养一支能够自适应、自我管理的团队。2.3.2 PMBOK理论

    敏捷和计划驱动的开发方式都符合“项目的

    金三角”理论(见图2-5)，也就是成本、进度和

    范围的三重约束。但是，传统项目基于的是计划

    驱动的需求，因为只有这样，进度和成本才可以

    估算，风险才可以控制。而敏捷方法的项目范围

    总是在不断变化，即使客户没有要求这个范围发

    生必然变化，我们也不得不做好变化的准备。在

    敏捷方法中，由于范围的灵活性，进度和成本不

    可能保持固定。如果假设进度或成本不变，则这

    个范围的变化一定是动态平衡的，即变化后又回

    到了原点。总之，规律谁也逃不过，因为，只有

    符合规律的项目才不会成为“死亡竞赛”。图2-5 项目的金三角约束理论

    但是，现实中让项目经理头疼的事情是，利

    益关系人和客户压根就不买金三角理论的账，项

    目经理的责任不再是做出独立决策，而是更好地配合持续改进，配合团队在更短的时间内产出更

    多的价值。用三角理论的方式讲，就是保证范围

    扩大的前提下，不对进度和成本进行修改。

    为了突破金三角的诅咒，项目经理、团队、利益关系人必须做好一件事，那就是提升团队的

    责任感，增加团队的自我管理空间，界定项目经

    理的工作，不需要项目经理对太多的事情进行控

    制，以更好地适应自我管理的团队环境，这也正

    是核心敏捷原则之一。

    项目经理的角色需要从管家型“控制”转变成

    仆人式“领导”，重点在于促进和合作。下面通过

    PMBOK知识领域映射到敏捷实践方式，讨论项

    目经理应该有怎样的专业变化，以及如何使之自

    然过渡到敏捷软件开发方法。项目经理要善于观察，并学习如何引导团队

    在全新环境中可靠地应对变革，而不是强迫团队

    符合规划的安排。这需要有勇气让团队自己做出

    决定，而不是被告知该怎么做。这意味着团队成

    员有了更多的个人责任，并要求项目经理有更强

    大的协调和配合技能。在开始阶段，最难的就是

    让项目经理适应新角色。项目经理的责任是培养

    团队凝聚力，营造良好的团队沟通氛围。虽然并

    不是每个人都愿意做出转变，但是，我看到了许

    多项目经理的成功转变，其努力也让团队收获了

    巨大的回报。而任何时候，我们都必须清楚，总

    有人不喜欢敏捷，总有人拒绝变化，所以不要强

    求所有人都参与。

    有意思的是，在深知项目管理协会(PMI)

    和敏捷理念有所差异的前提下，我和PMI的资深顾问，CMMI5的认证评审委员会成员进行了多次

    讨论，发现项目管理知识体系指南(PMBOK)

    确定的做法都与敏捷实践可以很好地兼容，当然

    也有不同。

    例如，能力成熟度模型(CMMI)指数指

    出，PMBOK是最佳的实践方针，组织必须行使

    自由裁剪的权力，如项目管理、需求管理，团队

    管理等。事实上，敏捷方法，以及我们提出的纪

    律和风险与价值驱动模型，都将符合CMMI，就

    像传统的瀑布方法和CMMI兼容一样。如果非要

    说有什么不同(除了基本的命令、控制与自我管

    理)，那也仅仅是何时以及如何将这些行为可靠

    地执行，以及敏捷实践中的新词汇罢了。

    PMBOK指出，初始化、反复计划、监管、执行和退出是标准的项目管理流程(见图2-6)。

    而IBM的DAD更能反映真实的软件项目开发过

    程，其项目管理流程为初始化、反复计划、迭代

    审视与改进、迭代构造、迭代交付过程(见表2-

    1)。初始化阶段兼顾考虑商业视野和初步的功

    能计划列表，确定构造过程中需要做什么。到了

    反复计划阶段，这个商业视野定义过的先进产品

    列表将作为一系列可以实现的功能，并被规划到

    迭代周期中去。迭代构造是产品通过一个增量迭

    代过程，从无到有的产生过程。迭代审视与改进

    过程是项目负责人和团队实际完成项目后，对项

    目的利益关系人做出总结性汇报的过程，当然还

    有不间断地对项目风险、结果监控和管理的过

    程。最后是交付和退出，在这个过程中，团队有

    机会看到客户对工作成果的真实反馈，了解利益关系人对产品的进一步需求。图2-6 PMBOK过程

    表2-1 PMBOK与DAD的异同阅读PMBOK可以发现，五个主要的知识点

    在项目管理领域受到了足够的重视，它们是集成

    管理(Integration Management)、范围管理

    (Scope Management)、项目时间管理(Project

    Time Management)、质量管理(Quality

    Management)和人力资源管理(Human Resource

    Management)。对于每个知识点，PMBOK所定

    义的实践活动与敏捷软件研发各阶段的实践活动

    有着截然不同的定义(见图2-7和图2-8)。图2-7 PMBOK与敏捷迭代阶段映射图2-8 PMBOK与敏捷版本发布阶段映射

    1.集成管理vs敏捷多级计划管理

    在集成管理领域，最为重要的交付物是项目

    的计划文档，这个文档由项目经理负责和交付。

    而敏捷研发过程中，因为尊重仅仅足够和及时的

    原则，所有的计划和设计都是在团队中历练出来的。计划文档也是有的，但只不过是一个简单的

    发布计划文档和一些迭代计划文档。敏捷计划文

    档不会详尽解释范围、工作分解结(WBS)、进

    度、假设和管制，敏捷项目的项目经理更关注计

    划的过程而不是结果，因此将轻量级的文档仅仅

    作为项目团队理解目标，达成一致的手段。为了

    符合流程上的标准，我们将白板、录音作为“文

    档”或者“计划”保留在项目公共区域里，例如，通

    过Rational协同工具和工具视图做到“自动

    化”与“品质”同在(见图2-9)。

    再如，只用简单的白板加上有颜色的便签，就可以将计划的关注目标呈现清楚(见图2-

    10)。这种方法适用于集中的团队开发，在一间

    封闭开发的房间(war room)将所有重要的资源

    和信息公开，使大家在行动和思想上达成统一。图2-9 使用Rational工具使计划和项目透明化图2-10 使用白板和各种颜色即时贴做计划和项

    目跟进

    如果既没有足够的资金购进高级工具也没有

    华丽的war room，用EXCEL做出简易的产品清单

    并记录每日团队的工作量，自动绘制燃尽图，效

    果也很好(见图2-11)。

    2.PMBOK范围管理和项目时间管理vs敏捷范围管理和时间管理

    “规模扩张”一直是传统项目的祸根，如要求

    项目经理积极响应客户的业务需求、响应行业的

    点滴变化、响应突破瓶颈的新技术，并在开发过

    程中不断学习和改变，这样的项目经理一定要

    得“变化恐惧症”。在PMBOK中，范围规划、定

    义、验证和控制都被给予极大关注，并且是计划

    驱动的，不希望更改的范围变大。不同的是，敏

    捷方法希望拥抱范围变化，迎接业务需求，响应

    市场、行业、技术的变革，并对过程和效率有着

    持续改进的热情。在尽量稳定成本和进度的前提

    下，努力实施客户定义或者接受的最高价值。图2-11 使用EXCEL做计划和项目跟进

    项目的范围变更和时间管理常常使项目经理

    陷入慌乱。假设项目是由一个个固定的时间周期

    ——时间盒子构成的，失败的项目管理便是将堆

    砌功能的“砖头”一个接一个地扔到单一脆弱的时

    间盒子里，直到时间盒子爆炸。实际上，我们往

    往会关闭这个对话框，让迭代发生，并生产另一

    个时间盒子，将“砖头”扔进新的盒子里。由于我

    们一次只做一个盒子的装载，极致地完成一个盒

    子的工作，因此我们很难预计在未来的一段时间

    里能够完成多少工作。事实上，项目经理经常会

    疑惑：用这种新的、灵活的方法来规划和管理范

    围听起来很不错，但问题是，当老板和客户问我

    需要多少时间来完成项目的时候，我该如何回答？

    对于时间管理和范围管理，不管使用什么办

    法，当被问到长远目标或计划时，项目经理往往

    要扮演先知和算命者。项目经理不可能真正准确

    地回答这个问题，即使使用传统的项目管理方

    法，也不过是基于专家判断和历史分析的猜测罢

    了。罗恩·杰弗里斯，敏捷和极限编程的共同创始

    人之一，曾告诉项目经理可以这样回答这个问

    题：

    “现在，这似乎是一个200点工作量的项目。

    根据我们在其他项目上的工作速度和效率(或随

    机猜测)，考虑N位全职程序员的团队规模，并

    考虑您将亲自参与这个项目，这种规模的项目将

    需要4~6个月的时间。然而，我们将每两个星期交付一版软件，并以“您满意为止”作为这些功能

    实现的标准。一个好消息是，如果感到不满意，您可以让团队停下来。还有个更好的消息，如果

    在所有预计的功能完成之前就已经非常满意，您

    也可以让我们停下来。而您也有更多的责任，就

    是与我们积极合作，让团队理解您满意的是什

    么。最后，也是最好的消息，只要现有功能足以

    使程序看起来非常有用，您可以要求我们随时准

    备软件的部署。在项目进展的同时，我们将看到

    交付效率，且对项目时间估计的准确度也会提

    高。”

    在敏捷软件开发中，范围规划是作为发布计

    划(Release Planning)的一部分完成的。项目工

    作范围的定义，和项目时间管理领域中定义的实

    践活动都是敏捷开发领域迭代计划(IterationPlanning)的一部分。迭代计划对其中的每个功

    能进行阐述、优先级设定、工作量估计和工作分

    发。敏捷软件开发与PMBOK定义的关键区别在

    于，规划和设计工作只是针对独立工作的一个功

    能或者一段完整代码而言，并不是针对整个系统

    上某个层面的技术、架构、文档和函数。对应于

    PMBOK的定义，敏捷开发也有“范围核实”，在迭

    代结束时，由产品的利益关系人客户进行审查，用户测试体验通过即代表工作完成。

    3.PMBOK质量管理vs.敏捷质量管理

    另一个发生了巨大思想变革的团体是软件研

    发团队的质量评估(QA)和测试人员。习惯了

    根据开发者提供的设计文档和详细说明来验证产

    品正确性的过程，就仿佛置身于无人驾驶飞机的机舱，只能通过感官感受飞机的状态而无所作

    为。在PMBOK定义下的QA和测试人员所期望的

    测试是对所交付产品的不规范进行校正，在等待

    产品交付的时间中陷入焦虑，而在产品交付的最

    后紧要关头冲锋陷阵。

    敏捷测试和质量评估在软件周期时间表上开

    始渐渐左倾。质量评估和测试人员从产品的需求

    分析阶段就已经开始参与，一直保持充沛的精力

    和积极的影响，参与决策整个产品生命周期。由

    于采取增量开发方式，在每个迭代中，质量评估

    都在集中测试当下最为重要的可交付功能和有价

    值的非功能点，而不是等待某事务被“扔过围

    墙”而开始工作。而且，随着迭代工作和产品功

    能的累积，质量评估需要不断寻找更为高效和便

    捷的技术，将自身从低价值的重复劳作中解放出来，关注最有价值和新价值的质量保障工作。因

    此，必须在GUI、API、系统集成等方面研发自动

    化测试。

    通常情况下，PMBOK要求的质量管理计划

    应该包括：定义质量保障的目标和范围，确定执

    行标准质量保证工作的技术和方法。敏捷的质量

    保障团队成员仍应满足这一要求，并与项目团队

    一起工作，确定使用的工具和技术，以书面形式

    提交测试结果。同开发人员一起验证定义并确定

    执行目标是很重要的，因为单元测试将有助于自

    动化回归和验收测试。产品负责人也必须参与，因为他们应该帮助团队明确定义并运行验收测

    试。在敏捷实践中，每个人都有责任定义、维护

    和提高产品的质量保障体系。质量保证的重点之一是预防缺陷。在敏捷研

    发中，QA团队与开发团队有着相同重要的决策

    影响，QA对质量保障工作的承诺在整个项目生

    命周期中起着至关重要的作用，关乎发布的成

    败。在项目前期，QA对需求的充分分析可以帮

    助开发人员编写更好的代码，更多的假设场景被

    程序员和测试人员作为后续开发、测试计划的有

    益参考。测试人员站在用户体验的角度，为产品

    负责人对整个产品的准确规划和定位提供更有效

    的保证。

    质量保证的另一个重点是找到质量缺陷，通

    过与开发者和程序员的合作将这些缺陷消除掉。

    敏捷研发中，这类工作也是在迭代内完成的。与

    PMBOK中定义的缺陷发现和消除工作一样，一

    般团队会使用自动构建、冒烟测试、自动化回归测试、单元测试、功能性测试、探索性测试、验

    收测试来完成对缺陷的消除工作。不同的是，敏

    捷研发中，质量缺陷的发现和消除工作人人有

    责，没有人能够免于因为缺陷而未能满足客户期

    望而产生的问责。

    4.PMBOK人力资源管理vs.敏捷人力资源管理

    一旦收购完毕，公司需要对新团队和每位新

    员工做出组织规划和团队发展计划，这也正是

    PMBOK定义的组织规划和团队发展过程。

    PMBOK组织规划明确指出，需要为员工定义角

    色与职责，团队发展就是要发展个人技能和个人

    竞争力(PMI，2000)。在敏捷领域，团队发展

    计划的重点是组织一个跨职能团队，使其能够在

    各种环境下正常运转，实现团队自我管理。建立跨职能的团队意味着开发团队不再

    有“门派”区分，而只有角色区分。敏捷开发团队

    的目标清晰，即创建可工作代码，增量并产生可

    用的产品。这个过程需要所有关键角色：测试人

    员、分析师、架构师、技术信息开发者、行业专

    家、客户产品负责人，以及团队领导(项目经

    理，团队负责人等)。这些人具备不同的特定技

    能，但作为团队一员，以及后续成熟的敏捷团队

    发展计划的一员，每个人均会更多地了解他人的

    工作并理解他人的努力，逐渐变得更愿意帮助和

    自己不同角色的人，进而拥有多项专长。拥有一

    个跨职能的团队，意味着有一群人致力于让客户

    满意，并能够通过互助和协作来实现目标。

    敏捷团队能够完成自组织的转变，归因于对

    于团队目标的共识，和持续地、规律地改进产品和产品研发过程。在这个过程中，团队合作紧

    密，并坚持不懈地寻找解决问题的方案和完成目

    标的途径。团队负责总计划、总执行，以及审视

    产品研发和过程改进，自我导向地将团队不断推

    向新水准。

    对于项目经理而言，这又是一个艰难的思想

    转变，当项目经理认识到不再需要指挥一个团队

    时，他们开始紧张焦虑，不清楚自己的角色将会

    怎样变化。实际上，在敏捷团队中，项目经理将

    从“指挥官”变成以支撑团队为主要工作的“仆人领

    袖”。团队机制不会自行发生转变，尤其在团队

    还未熟悉敏捷方法时，需要强有力的领导帮助他

    们学习如何做出“团队决策”。作为一个“仆人领

    袖”，需要学习如何促进协作，培养团队持续反

    思的习惯，帮助团队做得更好。2.4 敏捷实施法则13条

    定义最佳实践需要先明确环境，即明确什么

    样的组织在什么流程下如何有纪律地交付后，讨

    论“最佳”或者“误区”才有意义。下面基于IBM的

    实践和经验教训来分享敏捷实施的13条经验。

    1.及时清理产品工作清单

    当团队持续更新产品的工作清单(product

    backlog)时，产品负责人和团队负责人需要密切

    关注列表项目中高优先级的工作，并使其比重始

    终处于一个健康的范围(1：10~1：3)。在迭代

    计划阶段，需要审阅产品列表，并根据经验和承

    受能力调整产品清单数量。根据收集到的需求、用户的最新反馈和经验

    知识，我们可能决定把一些对当前版本没有附加

    价值的用户故事从产品清单中删掉。或者，有些

    用户故事经过重新审阅，尽管对当前版本有意

    义，但因为不那么紧急，产品负责人仍然可以将

    这些故事和任务的优先级降低。

    产品清单不应该成为一个储藏间，将所有可

    能会穿但又不想现在尝试的新旧衣服全部堆进

    去。当产品负责人将一个优先级不高的故事放进

    产品列表时，必须有充足的理由。

    其实，产品清单中用户故事的数量将与这个

    敏捷团队的生产能力、承受能力密切相关。累赘

    的产品清单会对团队积极性产生负面影响，进而

    压抑生产力。当工作趋于轻松、团队趋于稳定时，产品负责人可以加入几个新的用户故事；但

    当团队的需求产生了比较大的变化、团队工作节

    奏紧张时，产品列表最好仅仅保留一两个月的工

    作量，而且，请果断地将不适合留下的工作项从

    产品列表里删掉，如果它真的是个好故事，你一

    定会在其他场合再次听到，到时候再把它放回来

    吧。

    2.迭代规划会议不宜超过1小时

    IBM有很多组织迭代计划会议的方式。有些

    团队会每个迭代组织一次独立的会议，一次性规

    划好所有迭代任务；还有些团队会每周组织一次

    会议，或者随时需要随时会晤，清理产品列表并

    制定迭代计划。后者的优势是让团队经过每周的

    必经日程，很快养成适宜的工作节奏，减少因调整用户故事大小、细分任务所带来的不可避免的

    打扰。

    规划会议的时长不宜太长，人往往只有

    40~60分钟的关注度，所以，应该给每次规划会

    议一个时间限制，保障团队对规划事宜的专注。

    Scrum的先驱者之一Peter Deemer有一个普遍的建

    议，就是团队使用5%~10%的迭代长度来设定迭

    代规划时间。例如，周期为一个月的迭代规划会

    议长度加起来不要超过1天。

    IBM在柏林的STG(System Technology

    Group)团队每个迭代只会晤一次，用来决策迭

    代规划：“我们每两个星期有一次规划会议，这

    样使得规划会议的时间比较短。我们的审查和规

    划会议在隔周周一举行。在周三之前，有一个可以称为“设计”的会议，但是它不是真正的设计会

    议。我们聚在一起，打碎用户故事，架构师也会

    参加这次会议，但他们并不总是参与迭代规划会

    议。”

    HongXue Han，一位杰出的IBM STG的研发

    工程师，也提及了有关规划和“设计”的会议：“在

    我们的工作环境中，团队负责人与产品负责人将

    决策要在迭代中实现什么目标，以及要做哪些工

    作。然后，他们会召集团队开上一个设计会议，产品负责人将向团队介绍他们想要做的内容。这

    个设计会议只是为了产出一个高阶设计，旨在了

    解研发阶段可能的外在依赖和技术风险。当团队

    知道要做的是什么后，团队会坐在一起讨论迭代

    规划。”然而，不是所有的团队都有一个独立的会议

    来确定迭代计划和调整产品任务列表。事实上，我们是否需要坐在一起讨论迭代规划取决于是否

    有新的任务和项目将要放入或取出产品任务列

    表。显然，倘若计划被频繁更改，产品负责人经

    常召集团队参与会议将会严重影响团队的生产

    力。

    3.迭代规划会议只做该做的

    迭代规划会议的目的是让团队思考在下一个

    迭代里完成什么工作以及怎样完成这项工作，并

    达成一个共识。整个团队需要为迭代规划，并为

    之做准备。这需要我们重新梳理当前的产品清

    单，了解整个团队的工作效率，并整理在迭代之

    前收集的信息。在IBM，迭代规划会议由两个连续的会议组成，在第一个会议里，团队决定要做

    什么，包括：

    ·讨论产品愿景。

    ·讨论并确定哪些用户故事在清单列表里具

    有最高优先级。

    ·确定哪些用户故事需要在这个迭代里面完

    成。

    ·确定迭代的目标。

    在另外一个会议里，整个团队要决定怎样完

    成这些工作，包括：

    ·设计工作途径。

    ·细分和估计期待完成的工作项(细分粒度要适当)。

    ·同每个成员确认能够完成的工作任务。

    ·提交到迭代任务列表。

    事实上，团队成员的地理位置分布以及团队

    规模都会对迭代计划产生影响。IBM的项目规划

    中，因为全部成员通常不在一个时区，两个会议

    也并不是紧接着进行的。而对于规模较大的团队

    来说，IBM的迭代规划也是不一样的。因为有更

    多的成员来开发产品，我们必须考虑到团队之间

    的依赖，而且应该比规模小且集中的团队有更多

    的迭代。规模较大的团队应该促进小组之间的深

    度合作，以及特殊技术方面的交流和共享。产品

    负责人，甚至产品负责人团队需要在不同小组的

    产品清单之间协调优先级。只有这样，小组之间才能配合起来，到迭代结束时，团队才能交付一

    个可以发布的且稳定的产品。

    为了有效地完成这个重要会议，IBM的团队

    在迭代规划之前都会收集和了解如下信息：

    ·产品负责人应该有一个需求(用户故事)

    列表，并且按优先级由高到低排序。这个列表会

    放在团队可以访问的数据库或者“产品清单”的

    最前面，供整个团队使用。

    ·理想情况下，用户故事会有一个基本的行

    文格式：“作为一位……，我需要做……，因

    为……”，经过迭代规划会议讨论用户故事的内

    容以及它们在交付时能够被用户或者利益关系人

    接受的条件。整个团队必须充分理解用户故事。·用户故事应该有一个相对准确的工作量估

    计，如果需要，还应该把用户故事工作量拆解成

    适合在这个迭代内完成的量，再进入迭代会议进

    行讨论。

    充分的准备是平稳、成功的迭代规划会议的

    基础，能避免令人沮丧且漫长的会议活动。但

    是，如果不幸失去了上面这些提前准备的要素，也并不意味着世界末日的到来，只是会使规划会

    议的时间变得更长，而且会给大家增加更多的挑

    战。

    4.团队在迭代规划中的自我管理

    所有成员必须在一起探讨并承诺能够完成的

    工作，确定团队的工作任务，以及怎样一起完成

    这些工作。仅仅由一些代表来承诺团队的工作是不合理的。所有成员都应该自己提交各自能够承

    诺的那部分工作规划。

    对于规模较大的团队，确保每一个对工作有

    责任感的成员都能参加迭代规划会议是很重要

    的。无论在不在同一地区，当下最重要的就是团

    队自己能够获得认领工作的全部权利和责任，当

    团队成员认同并承诺了这部分任务后，就意味着

    团队要对这项任务负责。

    IBM确实有一些实际的例子，不同时区的小

    组或许会选择一些代表来参加迭代规划会议，但

    整个小组都需要参加迭代规划。假设有3个组，每个组有9个组员，从一个一般产品的最高优先

    级的任务列表清单里选取任务。开始，这3个组

    委任代表在迭代规划会议上提供了最初的工作估计，然后，代表回去和组内成员讨论这些任务是

    否合理，并确定是否需要修改。所以对于这次迭

    代规划会议，确实27个小组成员都参与其中了。

    对于一些独立的组，每个组还应该遵从各自

    的迭代规划会议。

    5.不同时区组的迭代规划会议

    不同时区的组需要找一个整个组都能参加的

    时间来进行迭代计划(Sprint Planning)。对于不

    同时区的组，有时候工作时间是没有重叠的，因

    此，有一些组员就需要在他们的正常工作时间外

    来参加这个会议。

    开启一个Scrum项目后，通过一个大家都能

    访问的计划工具可以帮助不同时区的同事沟通。每一个参加迭代计划会议的人都可以看到产品清

    单、用户故事、迭代任务清单和工作量的估计。

    另外，通过访问这个分布式的工具，不同时区的

    组还希望有一个桌面共享工具。一般我们还可以

    指定一个同事每次记录下组内的讨论或者达成的

    共识，并且更新到计划工具里。

    6.与远程团队的会议

    当团队人数超过10人时，我们的每日站立会

    议就会显得很熬人，一人一分钟陈述，即使不被

    打断，时间就已经近15分钟。所以，我们提出了

    采用“Scrum of Scrum”的方式组织会议，即每7~9

    人组成一个Scrum团队，每个团队再选取1~2名代

    表参加高阶的Scrum会议。

    IBM的研发项目中，超过100人的团队非常之多，尤其是分布式环境下，某一地区可能集中了

    属于某Scrum团队的20名成员，而Scrum会议的形

    式基本是全团队参与。

    位于分布式环境下的大型团队，让来自世界

    各地的团队成员参与一个会议，尤其是当不同地

    区之间没有相互交叠的工作时间时，绝非易事，况且，团队还需要接受文化差异、语言障碍带来

    的挑战。当很多不同国家、地区的同事参与到项

    目中来，我们要面对的一个大挑战就是寻找一个

    最佳的会晤时间，并期望这个会议时间是大多数

    同事愿意的、或者可能愿意的。

    分布式会议需要远程会议设备，这种会议的

    效果通常远不如面对面的会议，因为除了耳朵以

    外，还需要眼睛、肢体参与沟通。事实上，有几条分布式团队的电话会议实践经验可以分享：

    ·至少提前2天发出会议邀请，如果没有会

    议系统，那么会议时间的格式最好有完整的年、月、日、时、分等。因为，2014年1月7日，在美

    国是1714，在日本是1417，而在西班牙是

    7114。所以，如果时间戳是“17”，那么将会

    误导与会者。并且，还要在会议前30~120分钟发

    出会议提醒，提醒大家会议将准点进行。

    ·提前5分钟拨打电话会议，这样不会因为

    你的拨入打断正在进行中的讨论，也会有足够的

    时间处理可能出现的技术故障。

    ·在“YesNo”之后，跟随一个完整的陈

    述否定句来表达正确的用意。实际上，许多国

    家对于“Yes”和“No”有不同的理解。例如，你的问题是：“你不希望开发这个功能，是

    吗？”如果答案真实，且的确不希望开发，那

    么，通常美国人的回答会是“No，I don’t.”而

    我们中国人会说：“是，我不希望”。所以，在“YesNo”后面要跟随一个完整的称述否定

    句来清晰表达你的意愿。

    ·让语言尽量简单，不要使用过长或俚语、成语等丰富的句子。当我们用非母语沟通时，一

    定不希望对方使用俚语或者某个电视剧上的笑话

    来活跃气氛。

    ·给每个人一个表达机会。在会议中，那些

    外向的同事常常积极发言，迫切成为中心人物；

    而内向的同事似乎非常适合做总结，我们应该安

    排这些同事在最后发言。·如果几个人在一个会议室，使用一台电话

    拨打进入电话会议，那么，请在他人讲话的时候

    避免交头接耳。在必须沟通的时候，也请对准话

    筒，大声说出他的名字，就像他也在电话另一头

    样，这样做会让所有与会的人感到被尊重。而在

    无需发言的时候，尽量将自己的电话静音。

    ·当你没有听清楚，或者觉得有必要澄清

    时，请尽可能地提出来：“我的电话出现了些噪

    音我的电话网络应该出了问题，能请您重复一

    遍刚刚提出的观点吗？”

    ·使用协同工具，分享开发文件，使用对话

    机制将某一话题的探讨用文字表达出来。事实

    上，越是分布式、远程对话的团队，文档和文字

    的沟通越为重要。7.处理工作间的依赖关系

    开发团队成员需要寻找合理的方式最小化产

    品列表中用户故事的相互依赖。一个完整的、优

    秀的用户故事是独立的，无需任何依赖。在复杂

    领域和分布式团队项目中，去除依赖性更为重

    要。如果团队在工作上彼此有了依赖性，就很可

    能需要一些额外时间和精力来协调不同团队的配

    合。如果处理不当，还很可能因为彼此工作任务

    的依赖性导致其中一个团队不能够完成计划任

    务，或工作遇到障碍。

    IBM建议将依赖性划分成三类问题来处理

    (见图2-12)：图2-12 三类依赖性问题

    ·简单依赖。

    ·外部依赖。

    ·复合依赖。

    简单依赖关系即一个用户故事依赖于另外一

    个能够独立的用户故事。消除这种单向依赖关系

    的一种方法是合并或拆分用户故事，使之成为新

    的用户故事集。如果这么做是不可能的，替代方

    案是为独立的用户故事设置比依赖于它的用户故

    事更高的优先级。那么团队将在迭代早期解决独

    立的用户故事，之后再解决相关的用户故事。外部依赖关系即一个用户故事依赖于外界团

    队的工作。在这种情况下，团队需要协商整合和

    交付日期，并调整该用户故事的优先级。负责该

    用户故事的小组不应该在外界团队还未完成其交

    付的前提下，承诺在当下迭代内完成这个用户故

    事。在特殊情况下，受依赖影响的团队可以安排

    虚构的接口，模拟外部组件的数据、数据通信或

    者Web服务，但这是有风险的。因为系统在真正

    的外部组件整合进来之前，是潜在不可交付的。

    外部依赖关系的例子包括：接口、数据馈送和

    Web服务。另外，在处理外部依赖关系的工作

    时，团队往往需要在迭代规划前考察和评估外部

    团队完成工作的能力与时长，这将对我们的迭代

    规划产生影响。

    交织在一起的相互依赖关系即两个或多个用户故事是相互依存的，每个用户故事都不可以独

    善其身完成而不依靠其他故事的推进。理想的情

    况下，团队应该想办法打破所有的依赖连接或寻

    找方法把交织在一起的依赖关系转化为简单依赖

    关系。实际上，IBM的项目中，产品负责人和团

    队负责人还有架构负责人肩负了分解复杂依赖关

    系的责任。

    8.有效的团队协作

    没有人能独奏交响乐，它需要整个乐团的合

    作。

    ——H.E.Luccock

    在大规模分布式的企业环境中，对于团队来

    讲，尽早交付有商业价值的解决方案是极为显著的变化之一。以前，开发团队的成员需要几个月

    的时间才能完成最后的交付；而现在，他们每两

    周就要交付出可运行的软件。

    产品经理转变为产品负责人，他们每天都要

    积极地协调利益关系人与开发团队之间的沟通与

    工作，从而完成每个迭代周期的有价值的软件交

    付。开发团队、产品负责人、团队负责人以及其

    他的利益关系人要在整个开发过程中一起认真地

    考虑产品的商业价值，而不是仅仅在项目的开始

    和结束。

    以前，经理可能会容忍阻碍项目进展的问题

    持续几天甚至几周的时间；而现在，在每两周的

    软件交付周期中，这种现象不可能再出现。因为

    团队负责人和产品负责人提出的问题往往要求他们在24小时之内解决。

    所有这些显著的变化促使团队交付的软件可

    以满足利益关系人最小化失败风险的需求，这个

    过程也对团队高效协作提出了更高标准。

    IBM团队总结出3种非常有价值的实践方法，可促进在迭代周期中的分布式协作，并帮助团队

    按时完成任务：持续集成(Continuous

    Integration)，自动化测试(Test Automation)和

    代码审核开发(Code-Review Development)。下

    一章将会分享一个主人公的故事，通过这个故事

    详细介绍这3种实践方法，以及它们如何帮助分

    布式团队快速定位、分析和解决问题，如何提高

    团队成员之间的协作和效率。

    9.用文档克服距离很少、甚至没有重合工作时间的分布式团队

    可能需要更多的邮件和其他书面文档来保持成员

    之间的有效沟通。IBM的团队经验告诉我们，文

    档能使团队更快达成一致并保持共识。

    当团队会议中某一种语言不是所有成员的母

    语时，书面语言也许是更加可靠和精准的沟通方

    式。非母语发言人更容易理解的是书面语言，这

    也是为什么我们应在口头讨论中加入一些文本沟

    通方式作为补充，如聊天工具或文档。

    很多团队会使用在线聊天工具或者屏幕共享

    工具来记录、分享会议的讨论要点。这不仅能保

    留讨论内容，也有助于非母语成员更好地理解和

    掌握要点。随着会议的深入，团队负责人应该以

    文本方式记录下所有要点，并试着问自己：·我是否精确地记录了大家关心的问题？

    ·我是否精准地掌握了大家将要做的事情？

    10.使用合适的工具

    Scrum更加重视个人、人与人的协作，而不

    是流程和工具。尽管工具可以帮助团队完成任

    务，但它不能创建一个高效的团队。在分布式环

    境中，虽然工具和有效的实践方法可以帮助团队

    成员更有效地沟通，但更重要的是要确保引入的

    工具可以帮助大家完成必须的工作。

    比如，一个分布式团队正考虑在日常迭代会

    议中引入分布式协作工具，首先要评估工具带来

    的价值与花费的合理性。使用虚拟会议室进行日

    常Scrum会议虽然看起来很酷，但如果进入会议室都要花上几分钟，那么它也就没有什么使用价

    值。因为，通常的日常Scrum会议只有15分钟左

    右。一个简单的电话会议就足以解决问题，为什

    么还要寻求那么昂贵的方式呢？

    所以，设计一种最合适团队协作的敏捷开发

    工具，需要从活动价值出发，以人为本地进行工

    作效率改进，将价值作为灵魂，将方法框架融入

    工具，延展工具的功能，特别是提供定制和扩展

    的空间，使得工具既能够满足当下工作的需求，保障团队的敏捷性，又可以整合敏捷研发全生命

    周期中各个有价值的活动交付过程，充分体现项

    目开发的透明度。

    总之，关注的重点应在DAD的核心原则上，千万不要因为拥有工具而一定要使用它们。11.重视团队精神

    所有的团队成员，包括产品负责人、利益关

    系人，通过协作共同交付一个产品或解决方案。

    每一个团队都应该是一个完整的多功能团队。这

    些团队应该分别工作在尽可能多的、各自独立的

    产品功能点上，而不是产品的组件上。从而可以

    最小化依赖关系以避免开发进程拖延的风险。

    在一个全球化分布式开发环境中，由于沟通

    的延迟，团队成员无法在同一时间段工作，容易

    出现状况。这使得大家不得不更加努力地工作以

    防止出现“我们”与“他们”的观点，造成不必要的

    分歧。为此，可以尝试问自己一些问题：

    ·你是否联系过在不同国家、不同时区的同

    事？·你是否尝试过通过电话交流，而不仅仅依

    赖延迟的邮件？

    ·假如你是一个相对集中分布的小组中的一

    员，而整个团队还包含一些分布在其他地区的成

    员，你是否尝试过邀请这些“边缘”成员加入到

    即将举行的临时会议中？

    ·在你决议要缺席某一天的会议时，你是否

    提前给其他组员提供了有用的最新信息呢？

    ·由于时区的问题，你是否让在另一个时区

    工作的同事总是留到很晚？

    ·休息时候的临时讨论，团队的其他成员是

    否参与进来了？·你采取何种措施来验证团队成员是否如预

    期地掌握了交流中的要点？

    ·当谈及到在不同地区的团队成员时，在语

    言上，是否有使用“其他国家的团队”或者“其

    他团队”等词汇的习惯呢？

    ·是否给团队成员贴过标签(如“在罗马的

    成员经常迟到”或者“他们从来都没做对

    过”)？

    ·是否不同地区组员之间的依赖关系过于紧

    密，以至于每天交流过于频繁？

    12.缩短迭代周期

    如果利益关系人不断地催促团队并经常打断

    团队工作，一个比较好的解决办法是缩短迭代周期。在一个周期为4周的迭代中，利益关系人需

    要平均等待2周，团队才能完成他们的需求(如

    果这个需求优先级足够高的话)。而在一个周期

    为2周的迭代中，利益关系人平均只需要等待1周

    的时间。

    沟通方面的不同步可能会致使分布式团队需

    要一个稍长的迭代周期。这显然降低了工作效

    率。而较短的开发周期可以使团队成员把每一次

    的交流沟通都当成紧要事情处理。

    开发周期越短，团队就有越多机会改进整个

    开发流程，并迅速适应。较短的开发周期同样意

    味着当利益关系人增加新的需求时，团队完成任

    务所需的时间更少。

    总之，较短的迭代周期不仅能使团队更迅捷的响应利益关系人、产品负责人的需求，还能使

    团队更迅速地适应变化。

    团队应该尽量找到符合自身的迭代周期。当

    周期过长时，会妨碍讨论新的高优先级任务；当

    周期过短时，除了成员间的任务说明之外几乎做

    不了其他事情。选择时最好考虑不产生需求变化

    的最长时间，即能够保护团队迭代工作不被打扰

    的时间。

    13.思而不学则殆

    有些敏捷理论犹如风筝一般，表面高大上，实际却脱离实际，难以自圆其说。因为没有足够

    支撑其理论的经验和实践，这种会议、课程、咨

    询活动常常会陷入彼此争论的苦战，浪费了大量

    时间。记得常有朋友抱怨一些“教练式”的培训，培训师的思想“高度”远远超出了企业、团队能够

    接受的水平，痛斥组织之臃肿腐败、抨击人性之

    不古，内容理想有余，但不接地气。一段时间下

    来，咨询、培训都无法顺利进行。于是，培训师

    就开始指责和推诿，认为接受培训或咨询的人员

    素质不高，领导支持也远远不足，所以只能做成

    现在这个样子……

    其实，很多培训师掌握了“足够”的敏捷知

    识，但是，敏捷培训师更要具备多年的实践经

    验，不仅做过敏捷开发、测试、业务分析、需求

    设计、团队管理等，最好也做过传统的研发和管

    理工作，厚积而薄发才是培训师的根本。而对于

    希望成为培训师的朋友而言，即使目前没有这么

    多的经历，至少要在一线技术岗位奋战过，拥有

    一定的知识并通过不断的学习和实践来累积经验。

    关于知识和经验，心理学认为，人的大脑不

    善于对二者进行区分。换句话说，读书、学习是

    非常好的事情，但是如果我们没有经历过，学习

    也未必会有成效，甚至会因为学习阻碍了我们的

    成长。

    举个例子，假设我们在阅读一本书，并且从

    书中获得了知识。之后，当我们看另外一本书

    时，虽然文笔不同，但是内容几乎相同，于是我

    们会这样说：“这些我明白，在另一本书里，谁

    谁说过……”甚至还会说：“这本书写的什么嘛，不怎么样啊，其实我告诉你是这样的……”无论

    是否亲身经历过，可能都会有这种反应，这恐怕

    就是大脑制造的麻烦。我们通过阅读、学习获得了知识，但是却使我们失去了成长的机会，听起

    来真是讽刺。读书太多，知识和经验的平衡就将

    被打破(见图2-13)。因此，有一种智慧会要求

    我们通过增长经验或者输出知识，即“倒空”的方

    式来重新建立平衡。正如罗曼·罗兰在《约翰·克 ......