This page has moved! The new URL is: http://softwarepractitioner.org/articles/agile.shtml. You will be redirected to the new address in five seconds. If you see this message for more than 5 seconds, please click on the link above!
胡健
Alistair Cockburn 是一位国际知名的软件开发专家。他在1991年受IBM之邀对一个OO项目设计一套方法。 作了一番文献查阅 之后，感到非常不满意。失望之余，决定下问项目开发组，请教他们认为什么是最好的工作 方式。结果就这样讨论出了可行的方法过程。这给了Cockburn极大的启发，他并且还注意到 程序员们所用的语汇和文献上的大不一样。 这真是“柳暗花明又一村”。他从此一发不可收拾，积极造访其他项目， 考察这些项目是怎样运作的。在与项目组成员的交谈讨论中，他特别注意他们所用的语汇，并加以 吸收。
通过这些采访和自己的二十几年的开发和管理经验，Cockburn发展出了一套软件开发的思想， 包括什么是软件开发，软件开发人中人的特点，开发团队应如何组织，怎样选择开发过程等。 他最近的新书 Agile Software Development 全面系统地阐述了他的思想，建立了他的一套独特的 话语系统（大部分语汇是多年来在项目造访中积累起来的）。 其实，在书的草稿中（draft version 2b1），Cockburn曾说过 写作这本书的原因之一就是他认为他目前的语汇已经能与绝大多数 的项目开发人员的语汇基本一致了，可以把它们整理出来了。
此书大致可分为四个部分：软件开发的性质，作为开发主体的个人，相互合作的团队以及方法过程。
讨论软件开发，首先得对软件开发有个定义或定性(即什么性质的问题）。 软件开发是什么呢，有几种有代表性的说法：
作者认为这些说法都对，同时又都不对。 狭义地说，编程本身是一种个体的、富灵感的、逻辑性强的活动， 但现代的软件开发更是一种群体的工程活动。
为了进一步揭示软件开发的特点，作者（有些出人意外地）把目光投向了游戏。作者对游戏的种类进行 了分析，并详细比较 了攀岩与软件开发共有的特点，如：合作与目标寻求、团队、技能、训练、工具、资源有限、计划、 修正、乐趣等等，最后把软件开发定性为：一种创造与交流的合作游戏（a cooperative game of invention and communication）。 游戏的首要目标是交付正确工作的系统，次要目标是生成一些“沉淀”（residue）产品 为下一次的游戏进行积累。
游戏的参与者有项目出资人、管理人员、应用域专家、软件设计开发人员、测试人员与文档写作人员。他们 需要互相帮助合作以达到目标。其中，开发人员扮演着重要的角色，他们要完成的主要动作是：
简言之，这场游戏中所见的只是人的创造性思想以及这些思想在人和人、人和计算机之间的交流。
如此说来，人的因素应当是软件开发中最为重要的了。作者在广泛的项目采访中也发现， 一个项目的成功与否，人的因素起着决定性的作用。一个成功的团队几乎总是 能做出需要的系统，这与技术和软件开发过程没什么必然的联系。 但软件开发中对人的研究却出奇地少。根据作者调查， 第一本这方面的专著是 Weinberg 在1969年写作（正是软件工程的观点兴起之时 [4]）、1971年出版的 The Psychology of Computer Programming （此书的“银版”－－ Silver anniversary edition 于1998年出版）。在沉寂了15年之后，DeMarco 和 Lister 写了 Peopleware: Productive Projects and Teams。有趣的是，又是15年过去了，作者的这本 Agile Software Development 可能是这个领域的第三个“里程碑”了。
作者在1994年就明确地提出了人是“非线性”的观点。这种非线性表现在，给一个人双倍的输入 （如双倍的时间，或双倍的报酬诱惑），你不能期待着他就能做到双倍的输出（双倍的思考质量，或 双倍的代码行）。在这本书中，作者更进一步地讨论了人的特点，特别是这些特点在软件开发中的作用。
首先，人是不可预料的。作者用了一个有趣的摩登单词 funky（这里有“奇异”，“复杂”，“不可思议”之意）来描述个人。人的 funkiness 表现在
人也是非常多样化的[5]。有人善抽象思维、有人喜具体细节， 有人夸夸其谈、 有人沉默寡言，有的领导专行独断、有的上司民主亲善，等等。人的多样性也可以解释为什么文献 里记载的软件开发方法过程如此之多，这是因为每一种方法都可以找到 自己的一群支持者。
人的哪些弱点会导致一个项目的失败呢？作者归纳了五条：
那么，人有哪些特点会使一个项目成功呢？作者归纳如下：
作者列出了相当一些良好的工作方式，它们虽然是对个人而言， 但要有效地实施却有赖于个人和管理层的共同努力。偏重个人的方式有：
而以下这些方式则需要个人与管理层的共同努力：
现代的软件开发，几乎不太可能一个人包打天下。软件开发活动是一种群体活动。要使这个群体 有效地运转，作者认为最重要的莫过于成员之间的相互交流与合作了。
信息对流（convection currents of information）是作者的一个语汇，它用热气流动 来比拟信息的流动。一个人的存在、他的姿势、他的声音、他的脚步， 都是在向周围环境 放射着信息，为别人所接收。同时，他也接收着别人放射出来的信息，从而形成了信息的对流。
作者详细分析了一个最常见的问题与解答过程，假设A知道一些信息，而B正需要这些信息。那么 要考虑：
作者从两人的工作地点来对这两个问题进行了分析：
答案是不言而喻的。
作者还提出了“渗透交流”（osmotic communication）的概念。这是指在一个公用的 的办公室里，你在专注于自己工作的同时，会不由自主地听到一些背景声音，如别人正 在讨论某个问题，并能从中不自觉地提出一些 感兴趣的信息。这可以使发现信息和传递信息的成本得以下降。
基于以上的观察，作者认为一个项目组最好能够都在一个（大）办公室之内，这样能最大限度地 提高信息交流的效率。更进一步地，如果项目组有不同专业的人员，如程序员和应用域专家， 他们的坐位应该混合安排，即避免分组安排时容易出现的小圈子效应。另外一点要注意的是， 如果一个大房间里有两个或以上的项目组，那么它们之间则应最大程度的加以隔离，减少干扰 流（draft）。
布置办公室时要考虑的一个重要事情是放置“信息发射源”（information radiator）。 这里，一个信息发射源一般是指挂（贴）在墙上的大尺寸的图表，这样人们过上过下时 都能看见。一个好的信息发射源应该具备两个特点：内容随时更新，看上去一目了然。 这种信息发射源最常见的内容有：总体项目进度、开发工作完成情况、系统测试情况、 系统运行状态等等。
为了提高交流的效率，作者还以两人在一个白板前的讨论为例，详细分析并列出了11项交流 的要素（modalities in communication）。它们是： 物理上的近距离性（physical proximity）；三维性（three-dimensionality）；气味 （smell）；动觉（kinesthetics）；肢体接触[11]（touch）， 如拍拍肩膀；声音（sound）； 视觉（viusal）； 要素同步（cross-modality timing）；低负载（low latency），因此可以有实时问答； 信任与学习（trust and learning）；共用持久性的信息发射器 （use a shared,persistent information radiator）,如白板。作者认为具备了所有 这些要素的交流是最有效的。
如果去掉其中的一个或多个要素，会给交流带来怎样的影响呢？
作者又考虑对一个已存在的交流方式来说，可以通过增加它的要素来提高交流的有效性。 例如，作者坦言，他对“Design Patterns”[12] 中的某些模式（pattern）还是不甚了了 （并推测很多读者想必也是如此），因此建议此书可配上录象带，由pattern的作者来讲解一番，这样 肯定会帮助读者理解。
提高交流的有效性还有一个重要的问题就是很多时候需要把讨论中信息记录下来，如记录在纸张上， 或在白板上。作者称之为给信息加上“粘滞性”（stickiness）。这些记录下来的信息可以保存起来， 供以后需要时查看。作者还提到了一些具体的方法。例如，把大张的白纸贴满墙上，大家可以随时 随地在上面写写画画。一张纸画满了，就把它卷起来，标上日期，然后存放起来。
一个项目组的成员可能来自五湖四海（特别是大项目），为了一个共同的目标[14]， 走到一起来了。如何高效得去达到这个目标呢？很重要的一点是， 大家要心（尽量）往一处想，劲（尽量）往一处使。 如何做到这一点呢？作者认为可以通过如下方法让每个成员作一些小的、容易做到的改变：
这样，每个人可能只是把他的方向往目前项目的方向上调整了一点点，但产生的合力是很大的，能 取得了事半功倍的效果。
要提高集体（团队）的战斗力（工作力），还有一个重要的方面，那就是在项目组中建立起良好的人文环境。 使大家心情舒畅，愿意互相合作，互相帮助。作者从友好与冲突，团队意识和团队文化等方面讨论了这个问题。
友好与冲突（amicability and conflict）。友好是信任与合作的基础。作者把友好定义为 “愿意倾听别人的想法，说话无恶意”，并且认为可以 从一个团队内部的友好程度（amicability level），看出同事间交流时的信息开放或封闭程度。友好（与人为善） 能造成一种气氛，使大家畅所欲言，特别是不同的意见。这里作者把交流不同意见称之为冲突，并且认为 这样的冲突是必须的，没有冲突或冲突不足对工作是不利的。
建立团队意识（team building）。现代企业一般都很重视团队意识或协作精神的培养。 有些公司在开始一个项目时把所有成员拉到一个 地方去活动一两天，以使大家增进了解，在工作中能很好地合作。这种做法在实践中也很有效。但有些 程序员却不太以为然，说道：“我对我们是不是能一起烧烤或一起爬墙不感兴趣，我只对我们是否能一起做 出软件感兴趣”[15]。那么，什么是更有效的方式呢？作者引用了一些 相关文献的建议，认为最好的活动是能让大家一起做出一些只有在一起才能干出的活。
团队文化（team culture）。一个项目组往往具有自己独有的团队文化。它会受到所在的企业 或组织的文化的影响，也会受到国家民族的文化的影响。团队文化有各种表现形式，作者引用文献 着重讨论了项目组的四种组织结构：
团队文化还有一个重要方面便是职业亚文化（professional subculture），也就是每一个职业 特点形成不同工作方式与习惯，作者列举如下：
对待这些亚文化的差异，作者提出可从三个方面入手：
Methodology这个词一般译作“方法学”或“方法论”，即“study of methods”。而作者使用这个词 是用的Merriam-Webster字典中的定义：“a series of related methods or techniques。” 即“一组相关的方法或技术”。而 method的定义是“systematic procedure”，类似“technique”。作者也提到一位同行在1993年 告诉他的一句话：“methodology is a social construction。”过了两年，他才开始理解这句话 的含义，并给出自己的定义为：“A methodology is the conventions that your group agrees to。” 即你的团组同意遵循的一组习惯做法。这实际是个“social construction”（社会建设），社会性的一个 重要的方面便是协调团组成员之间的活动，促进交流与合作。下面将试着把methodology译为“一套方法”。
作者认为，一套方法需考虑的（客体）结构要素有：
对于一套方法本身（主体），作者提出了如下这些概念要素：
把这些结构与概念要素综合起来，可以为设计一套方法提供一个系统的思路。从这些要素和对个人和团队的分析出发， 作者根据自己的经验，提出了七大设计原则：
在设计方法时，应充分考虑这些要素与原则。一个重要的推论是“不同的项目应该有不同的一套方法”，作者提供了一个思路, 用一个三维坐标系统来表示不同的方法。项目组人数作为x坐标，系统要紧性作为y坐标，系统优先因素 作为z坐标。x坐标取值为1－6人，20人，40人，100人，200人和500人；y坐标取值C（loss of comfort）， D（loss of Discretionary money），E（loss of Essential money）和L（loss of Life）。这样xy不同的组合 就形成了不同的坐标格，表示一个项目的基本特征。例如，“C6”表示一个项目有6人，系统出错时会引起一些不方便。 而“D20”则表示一个有20人的项目，如果系统出错会导致损失一些金钱。对每一个xy坐标格，z实际上说明了项目的 一些其他特征。作者用这个思路来设计了他的水晶方法系列（Crystal methodology family），“D6”类称之为 Crystal Clear，“D20”类为Crystal Yellow，“D40”类为Crystal Orange。在此框架下，XP可归入C4至E14。
对于项目的具体运作，作者还从实践经验中归纳出一些“甜蜜之处”（sweet spots）[20]， 并认为如果采用的一套方法靠近这些甜蜜之处，那么开发的效率可以提高。
一套方法应该是动态的、自适应的，也就是说，一套方法要在适应开发环境中构造和生长。作者把一个软件项目比拟为 一个生态系统。系统中的各组成部分如人员个性、坐位、工作语言等都在相互作用、相互影响之中。当然，一个良好而稳定的 系统的形成与发展主要取决于项目组成员的交互作用[22]。 如果大家能理解个人、团队和方法的特征，那么他们就能更好地 选择（或设计出）一个适合于自己这个项目的初始方法并不断地发展之，而推动发展的一个关键之处在于经常性的检查与调整。 这是一个随时间而进行的过程，作者提出的具体步骤为：
我去年（2001）七月左右第一次读到这本书时的草稿（draft version 2b1）时，第一感觉就是耳目一新。对书中所 列举的对个人和团体的分析都有一些似曾相识之感（相信干过几年软件开发的同行都会有同感），但从未这样集中、 全面而详细地读过。读第一遍产生的“冲击波”消退后，我开始重读并作了一些笔记，以求更好地理解并掌握作者的 主要思路，但在阅读中却觉得材料有些零乱和重复。这本书去年底正式出版以后，和version 2b1对照着又读了一遍， 发现基本材料（我想有90％）没变，但次序和结构有些变化。很明显，作者在尽力把这些材料有机地组织起来并表述出来。
总的说来，我觉得这本书提供了一个新的角度来看待软件开发活动和新的思路来设计开发方法。书中提供的材料大部分 来自作者丰富的实践经验，对软件开发实践有很高的参考价值，值得软件项目参与者，包括出资者、管理者与开发者 反复研读。我认为美中不足的是，作者试图建立来统率这些材料的框架并非严谨完美，从结构上说，这本书给我的感觉 更象是一本结构化的技术散文集，而非严格意义上的学术著作。不过，从另一方面说，这也许是一个优点，让读者能 从这些丰富的材料中，根据自己的知识和经验来构造出自己的“理论”框架。
在这篇介绍文章中，我试图根据我的理解来勾勒出的作者的主要思路，使读者诸君对这本书有个大概的印象。 文章基本依据书的顺序，为方便读者阅读原文，再简要说明如下：
这本书和Jim Highsmith的Agile Software Development Ecosystems 是计划中的“Agile Software Development Series”（系列丛书）的两本基础书。作者称这套丛书的核心思想是：
这套丛书可分为三大类：
从这里可以看出，作者关于软件开发的思路是技能、交流与团队为纲，方法过程为目，“纲举目张”。
感谢agilechina.org的诸位同伙对写作本文的鼓励以及对初稿提出的意见和建议。
注释部分有些是正注，有些则为“胡批”，博看官一笑，不必当真。
1. Tony Hoare 是计算机科学的奠基者之一。1999年从牛津大学退休。此公老骥伏枥，志在一统。 最近几年从事的研究之一便是计算机科学的统一理论。
2. Bertrand Meyer 是现代软件工程的先驱之一，他的著作 Object Oriented Software Construction 被视为OO技术的经典。“契约设计”（Design by Contract）是他对软件开发技术的重要贡献（Meyer的 一篇关于“契约设计”的 介绍短文，参考译文见 https://members.tripod.com/jian_hu/meyer/contract.html）。 他最近有一篇文章 Software Engineering in the Academy（参考译文见 https://members.tripod.com/jian_hu/meyer/teaching.html）, IEEE Computer 2001年5月 是谈院校的软件工程教学的，也可从中较全面地了解他对软件工程的看法。
3. 本人曾经有一位同事就是人们头脑中艺术家的典型形象：长发垂背、胡子拉碴、不修边幅，
整天龟缩在一个阴暗的房间里，瞪着鬼火一样一闪一闪的屏幕。
4. 有趣的是，（19）60年代末70年代初，也是结构化程序开始盛行之时。1968年
Edsger W. Dijkstra 著名的“Go To Statement Considered Harmful”，
Communications of the ACM, Vol. 11, No. 3, 1968，打响了对“GoTo党乱动派”的第一枪。
5. 俗语说：人上一百，形形色色。或曰：林子大了，什么鸟都有。其实，林子不大，鸟的种类也未必单一。
6. 作者书中的 iterative 的含义和现在常用的意思不太一样。书中给的定义是：a scheduling and
staging strategy that allows rework of ieces of the system，所以，译成“反复”似乎恰当
一些。而incremental在书中的定义为：a scheduling and staging strategy in which peices
of the system are developed at different rates or times and integrated as they are
developed，此处译为“递增”，但其义似乎更接近于 Martin Fowler 的 The New Methodology 中的
iterative。
7. 毛主席早就说过：加强纪律性，革命无不胜。
8. 书中作者引了 Lave 和 Wenger 的 Situated Learning中的一段：“The world carries its
own structure, so that specificity always implies generality”。特殊性总是蕴涵着
普遍性，这简直就是我们从中学到大学的政治课里面学的经典原理之一。
9. 广义上说，这是一个复用（reuse）问题。
10. 这似乎有些玄得象练气功或参禅了，但准确地说可能是进入了忘我而想物（程序）的境界。
11. 郑重声明：这里的“肢体接触”与议会全武行无关。
12. “四人帮”的“Design Patterns: Elements of Reusable Object-Oriented Software”
引发了这几年的经久不衰的pattern热潮，Grady Booch 更认为这是超越Object的三个迹象之一（另两个是
多视角描述软件系统架构和Aspect-Orientd Programming）。“四人帮”之名也许来自中国文革的王张江姚
四人帮。有趣地是，pattern “四人帮”希望
他们和正宗“四人帮”推动文化大革命一样，能带来一个“设计（小）
革命”，当然不愿象正宗“四人帮”那样因为他们的“反革命”思想而末日来临。而更为有趣的是，中国曾在1980年
底审判文革“四人帮”，而计算机领域在1999年也有一次“审判pattern四人帮”，控告他们“对计算机科学犯下的罪行”，
详见
http://www.c2.com/cgi/wiki?ShowTrialOfTheGangOfFour。
13. 书上的小标题是“Teams as Communities”。这里“team”应是指项目组，偏重于“物理”上的
一堆人，而“community”更有“精神”上的同信（心）协力之意。这层意思也许老词“集体”，或新词“团队”
都可以表达出来吧。
14. 目标是系统开发。这个目标可能不是革命的，但一般来说不会是反革命的。
15. 这句话本人深表赞同，尽管有些“狗坐箢篼－－不受抬举”之嫌。
16. 老山战士当年喊出的“理解万岁”应该是放之四海而皆准的。
17. 四川新都宝光寺有联曰：“世外人法无定法然后知非法法也，天下事了犹未了何妨以不了了之。”对我等靠敲键盘
养家糊口的俗人来说，却是“做开发虽然法无定法却需有法法也，建系统总是了犹未了还得慎了了之”。
18. 曾在网上看见过一首顺口溜：一等男人外面有个家，二等男人外面有朵花，三等男人舞厅随便抓，四等男人下班就回家。
19. Jim Highsmith says:“Don't confuse documentation with understanding;
Process is not discipline; Don't confuse formality with skill。”
20. 当然，这里的“sweet spots”与圣经中的“流着奶与蜜”的地方无关。
21. 对XP的批评之一便是说XP是“hire the best, fire the rest”。
22. 金观涛在1980年代在“整体的哲学”一书中提出的组织的产生与生长的理论也许可以借鉴，即一个组织能稳定存在是因为它
的子系统之间的功能是耦合的，而组织的生长是组织从一个稳态相另一个稳态的演进。
23. 邓小平的教导：“胆子再大一点，步子再快一点”此时可用。
胡健
修改记录
Email: jian4_hu2@hotmail.com
Web:
https://members.tripod.com/jian_hu