在一家以敏捷开发和咨询著称的公司工作了(jin)一q了(jin)Q以下是我当前对敏捷的认识：(x)
1. 敏捷宣言Q?br />
个体与交?nbsp; 胜过 q程与工?br />可以工作的Y?nbsp; 胜过 面面俱到的文?br />客户协作 胜过 合同谈判
响应变化 胜过 遵@计划
以上是大家熟(zhn)的四句言Q但q有一句话也许常被忽略Q?#8220;卻I虽然右侧条目有其价|但我们更重视左侧条目”。这句话也放在了(jin)宣言不显著的地方。宣a?a >官网背景是几位敏捷先贤讨论问题的画面Q中间的大胡子应该是老马QMartin FowlerQ。这副背景画颇有宗教油画的风根{?br />
2. CMMI
一 个叫德里?#183;布鲁克斯的h曄领导开发过一个失败的大型计算机操作系l：(x)System/360。他dq个目后写Z(jin)古典名著《h月神话》。接替布鲁克 斯来擦项目屁股的人叫做瓦?#183;汉弗里。汉弗里惊讶的发现这么大的项目居然没有正式严格的计划Q不知道汉弗里到底经历的多少ȝ(ch)Q他退休后加入?jin)一个五角大 楼开办的软g工程学院Q在那儿他和同事们徏立了(jin)软g成熟度模型（CMMQ，其中最有名的是其五个台Ӟ(x)
台阶一Q组l基本没做啥
台阶二：(x)l织做一些计划，跟踪Q配|管理工作，也讨量保证等话题
台阶三：(x)l织为各U活动定义了(jin)q程
台阶四：(x)l织有了(jin)准Q活动可以跟t和度量
台阶五：(x)l织有持l改q的q程
有时Q敏捷和CMMI被h们一赯ZҎ(gu)Q从我对它们目前的了(jin)解来看，两者似乎没太多联系。而且CMM5?#8220;持箋改进的过E?#8221;g?#8220;敏捷”q敏捗?br />
3. Scrum
我第一ơ真正对敏捷产生兴趣是两q前听说?jin)这个词Q随后参加了(jin)公司的Scrum的兴小l，也读?jin)些Scrum的书Q其中对q本?象深刅R有一阵子q傻乎乎的自q自己写BacklogQSprint和StoryQ还x下Burning down chart。对于很多hQ或许Scrum是敏捷Q敏捷就是Scrum。依我看来，Scrum像是CMM3 + 敏捷Q或者是Z敏捷理念的开发流E。有的是：(x)几乎每本Scrum的书和文章都要提C鸡和猪的故事。Scrum之所以流行可能是其提供一整套可操作的 q程Q容易上手，如同方便面一般方ѝ但是教条的执行Scrum我看q真一炚w不敏捗?br />
4. 极限~程QXPQ?br />
极限~程的名字v得颇有邪教的感觉。XP要比Scrum历史(zhn)久Q但没有Scrum那么行。XP中的TDD和结对编E常常引起很大的争议。在我一q的XP实践中，我却很对q两个玩意生了(jin)极大的兴。?br />
反感TDD的h往往是没有真正尝试过TDD的hQ想玩玩TDD的最x式也许是跟一个熟(zhn)TDDE序员结对一?x)儿。很多场合下Q用TDD开发非常有ƈ且能写出高质量的代码。但是Q何时候都教调的用TDD不一定能带来多大好处Q测试代码也有维护成本的?br />
?于结对编E，大多Ch都是很难理解的。有些拥有结对编E经验的E序员对它又爱又恨。结Ҏ(gu)大的好处或许是知识传播，惛_?fn)某U技术时和一个高手结Ҏ(gu)效率 非常高的方式。新人加入团队，和老成员结对能非常q速的q入状态。但是两个水q_异不大，但开发习(fn)惯E异的人坐在一L(fng)队是一U煎熬。一个经常发生的事情 是：(x)l过长时间无意义的讨论甚至争吵后Q双方妥协写ZD|中的代码Q这D代码仅仅是折中的而不是最好的代码?br />
5. _QLeanQ?br />
?捷宣a已经发布十年?jin)，已经不是新鲜玩意了(jin)。业界需要点新潮点的词汇。精益来自于丰田公司的生产模式。在朝鲜战争时期Q丰田汽车公ؓ(f)?jin)?f)军提供更多?U的汽RQ来自丰田hl公司的大野耐一Ҏ(gu)以往的经验ƈ通过不断的实践发明了(jin)丰田生方式。这U生产方式在学术界被UCؓ(f)_生。精益生产中有不实践跟 一些敏捷开发实践不谋而合Q如自动化，可视化等。但是生搬硬套精益思想中的一些理念到软g开发中多少有些别扭?br />
6. 敏捷实践
以下是我接触q的敏捷实践Q?br />l对~程Q尤光合老h带新人，和老艺Z帮带很像Q和高手l对真是职业生(dng)的幸?br />TDDQ有，值得试
站立?x)议Q不错的交流方式Q站?x)讲I简短不展开Q有问题?x)后交?br />故事卡：(x)一U很有效的需求分析方?br />故事墙：(x)可视化项目进展，很有，但我个h认ؓ(f)作用不大
燃烧曲线Q没感觉Q或许客户喜Ƣ看
回顾?x)议Q回会(x)议的召开需要些技巧，需要个好的L方式Q确实能暴露问题
Show Case:需要客户配合才有作?br />重构Q啥也不说了(jin)Q最爽的?/p>
q代开发：(x)讨厌僵化的P代开发，q代计划q是有弹性的?/p>
看板方式Q来自精益生产，能够取消q代Q减浪费，?br />持箋集成Q见7
7. 持箋集成
每当Build成功Q就有小鸟唱歌；Buildp|是一声闷P团队中必L人站出来为此负责。这U开发模式我d才刚刚接触到Q但恐怕我的职业生涯会(x)M开它了(jin)Q我认ؓ(f)它是最有用的敏捷开发实c(din)甚x些同事对持箋集成的评h持箋集成是敏捷?br />
8. 传说中的敏捷团队
传说中的敏捷团队Q每个h都是多面手，沟通畅通，有效协作Q共同成长ƈ且持l改q，?j)?j)盔R，众志成城Q快速响应变化，为客户带来最大的价倹{我怿q样的团队是存在的，因ؓ(f)我现在所处的目团队已经让我看到?jin)敏捷团队的雏Ş?br />
9. Martin Fowler
有幸和老马有了(jin)一ơ面寚w的交，和老马介绍?jin)下我们的项目，但他也没有给Z么徏议?br />最后我问了(jin)两个问题Q?br />我：(x)(zhn)是我的偶像Q请问我如何才能成ؓ(f)一个像(zhn)这L(fng)软g开发高手？
老马Q我无法回答Q我不是开发者了(jin)Q我只是个演说者?br />我：(x)目中和客户交流Q客戯你们不用搞太多测试和TDD之类Q我们希望你们做的更快些Q多实现功能Z。我认ؓ(f)我们的主要目的是为客户多交付价|所以我们确实应该减测试的力度Q?zhn)怎么看？
老马Q你需要权衡（Trade offQ，但在我看来写试只会(x)让我更快些?br />
10. Ҏ(gu)L(fng)质疑
Martin Fowler: 软g开?#8220;教父” | |
(2008-07-08 14:47:18) | |
他改变了(jin)人类开发Y件的模式Q他被开发者们ؓ(f)“教父”Q他从不与媒体谈论技术以外的事情。这个谜一L(fng)U学家Martin FowlerQ终于首ơ敞开?j)扉Q讲q自q故事?/p> “Martin FowlerQ?#8221;“Martin FowlerQ?#8221;6?1日，在第三届“敏捷中国”技术大?x)北京开q式上，q千名技术开发h员都表现出异常的兴奋?/p> 在观众热烈的掌声和兴奋的期盼中，蓄着大把胡子、穿着衬衫、一w休闲打扮的Martin FowlerC讲台Q开始侃侃而谈。没有讲E，也无需讲稿Q因为有x术的一切，他早已烂熟于?j)?/p> ?#8220;意外”?#8220;教父” 从上个世U?0q代开始，Martin Fowler׃直从事Y件开发工作。说赯上这条\的原因，他的回答却很?“其实q是个意外。我在学校学的是计算Z业，我觉得很感兴，ql从事这个工作?#8221; 上个世纪80q代中期Q正是Y件行业蓬勃发展的时期QMartin寚w向对象开发这个新领域发生?jin)兴。他开始把面向对象的思想应用到商业信息系l的开发中去，q很快成?jin)这斚w的专家。而正是这个兴，让Martin遇到?jin)对他生终w媄(jing)响的人?/p> “他叫Jim OdellQ也是一个技术专家?#8221;Martin说。那时候，Martin在当时美国最大的一家咨询公司工作，负责软g开发技术方面的工作Q而Odell作ؓ(f)一个独立的软g咨询师，恰y跟Martin在同一个工作组Q共同从事一些面向对象开发的研究?/p> “当时我们一起做概念建模Q还有驱动开发。我非常享受跟他一起工作?#8221;说vq些QMartin的眼光从深邃开始变得闪烁，g陷入?jin)深q回忆之中?/p> 随后Q在Jim Odell的鼓׃QMartin也开始写书。他的思想Q从面向对象开发到重构Q从UML建模到XP开发（极限开发）(j)Q开始越来越多地被h?jin)解Q他成了(jin)开发h员心(j)中的大师?/p> 2001q?月，17名像Martin Fowlerq样、在软g开发各领域有所建树(wi)的大师们Q汇聚在犹他州Wasatchp中的一处滑雪场内，?天的旉放松、讨论。他们想改变传统的以文档为驱动的、笨重的软g开发模式?/p> 于是Q在q个非正式的集会(x)上，诞生?jin)一个在软g开发历史上h里程意义的“文g”Q这是?qؓ(f)U颂的《敏捯Y件开发宣a》，?#8220;出生在英国的Martin FowlerQ则让全国人学?x)?jin)‘AgileQ敏P(j)’q个词的发音”。《敏捯Y件开发宣a》的|站上这栯载Martin?/p> 传统的Y件开发，开发者得先研I清楚用h有的需求，再开发出一套完整的Ҏ(gu)。这不仅使得开?周期长，而且整套Ҏ(gu)中决不允许有MU漏Q否则用L(fng)需求就无法满Q而对开发者来_(d)更改也非常困难。而敏捷开发则是从用户核心(j)需求入手，在短旉?拿出一个原型，然后Ҏ(gu)用户的其他需求增加模块，同时修改和完善，属于“可以让汽车一边跑Q一Ҏ(gu)轮子”的开发方式，非常适合对开发周期要求越来越短的?业Y件开发?/p> 敏捷开发彻底改变了(jin)人类开发Y件的模式?/p> 低调的自׃义?/strong> 事业上的巨大成就Q让Martin Fowler被技术h员奉拜的对象Q但他却低调得让人难以捉摸?/p> 照理_(d)“教父”U的人物应该游走在全球各大城?jng)之_(d)频繁地参加各U学术交和演讲。而被技 术开发h员视为全球最受欢q的演讲者之一QMartin Fowler却很参加这cL动。Martin? “我觉得h们给我的x太多?jin)，我不喜欢被关注。我是一个普通的人，住在普通的房子里，开普通的车，吃普通的饭，有时间就去骑骑自行RQ或者和我的d 去郊游?#8221; p“教父”q个U呼Q他l出的惟一评h(hun)也只有两个字——奇怪?#8220;q个名字是别人给的，我谈不上喜欢Q也说不上不喜欢。就是有点奇怪，因ؓ(f)教父在电(sh)影和说里，都是强盗那样的h?#8221; 相比之下Q每每在做自我介l时QMartin Fowler更愿意称自己?#8220;作家和咨询师”Q而他最喜欢的工作，则是现在的状?#8212;—每天主要的精力都用来写书和钻研自己感兴趣的Y件技术?#8220;写书是我最大的享受Q这L(fng)生活很自由?#8221; 的确QMartin是一个不折不扣的自由M者，他做事的理由永远很简单，是感兴。也因ؓ(f)如此QMartin做了(jin)很多q的独立软g咨询师，为的是“独立工作的公正性和创造?#8221;。直?999q_(d)他开始ؓ(f)ThoughtWorks做一些咨询工作?/p> ThoughtWorks完全开攄工作I间让Martin感到惊讶Q他发现在这里工作，沟?是完全^{的。而更重要的一点就是，Martin发现QThoughtWorks的工E师都有很强的技术能力，有些甚至不比自己差，只是不如自己有名。?且他们离商业软g开发非常近?/p> 因此QMartin最l决定接受ThoughtWorks的加盟聘书，而且无论多忙Q都?x)特意去各个目l走赎ͼl别Z些意见，也从别h那里?jin)解商业软g开发的最新动向?/p> 采访手记 d技术就隑֏ 在采访中QMartinl自׃?jin)这样一个定义，“一个喋喋不休的?#8221;?/p> W一D到Martin的时候，他刚跟技术h员结束讨论，原定上午10点开始的采访Q因此推q了(jin)15分钟。进入采访的?x)议室，q个l腮胡的男hq沉在刚才的兴奋中Q很用力地握?jin)握记者的手?/p> 但当得知记者此ơ采访的目的q没有太多地x技术时Q我在他怸看到?jin)很明显的失望，浅地说了(jin)一? “噢，好吧。我喜欢说技术，不喜Ƣ说自己的事情，所以我看情况，能说多少p多少吧?#8221; 正如Martin自己所_(d)他不喜欢被太多地xQ所以采访开始得q不利?/p> 管如此QMartinq是很认真地配合着采访Q比如，当在提到一些书c、h名时Q他都会(x)非常仔细地写下来Q就像对待Y件开发一P量做到严}?/p> 而这些小l节Q也透露?gu)个Y件开发大师n上的一些特质。当问题一旦与技术相养IMartin 的话虽然不是太多Q但可以很明昑֜感受C的目光会(x)变得炯炯有神Q手势也?x)比以前多v来。如果问题和技术没什么关p，比如他事业中的一些经历，或者家人?朋友Ӟ他就?x)很认真地想一惻I但谈的就很少?/p> “在Martin的头脑中Q兴奋点g只有技术?#8221;ThoughtWorks的员工告诉记者?#8220;Martin很不喜欢接受采访Q除非纯谈技术，否则对他来说直是受罪?#8221; (李响 计算Z界报) |
]]>
我是一个幸q的家伙
——Martin Fowler北京访谈
孟岩 / 记?/span>
2005 q?月初QThoughtWorks首席U学家、技术思想大师Martin Fowler来到北京。尽这ơ访问行E繁忙，他还是在d北京的前一天晚?抽时间接受了(jin)我们《程序员》杂志的采访。很明显Q连日来马不停蹄的奔波演讲他相当疲劻I但是正如他自己所_(d)他用说话的方式写作，用写作的方式说话Q即 使是在我们不长的交谈中，他仍然给我们带来?jin)很多深ȝ启发?/span>
记者：(x)(zhn)现在是一位对软g开发社有着重大影响力的人，Ҏ(gu)来说Q?zhn)认?f)取得成功最重要的三个因素是什么？
MFQ我认ؓ(f)Q排在前三位的是q气、运气和q气?/span>
记者：(x)q太让我们惊讶了(jin)Q难道?zhn)把(zhn)的成功归lؓ(f)q气吗？
MFQ?我说我有好的q气是因为恰好在合适的旉做了(jin)合适的事情Q比如：(x)在面向对象兴L(fng)时候，我恰好加入了(jin)一个用面向对象的先锋团队Q随后我又恰好接触了(jin)刚刚 兴v的徏模技术；1997q我撰写?jin)《UML Distilled》，恰好赶上?jin)UMFL的大行Q之后我恰好加入?jin)C3目Q从而见证ƈ且参与了(jin)敏捷?法的诞生Q这?#8220;恰好”?jin)很多次Q所以我说我真的太幸q了(jin)?/span>
记者：(x)我想q么多连串的q运应该也是(zhn)付出努力才得到的?/span>
MFQ?我不知道Q但是我却是在做每g事情都非常投入，可以说是兢兢业业Q一丝不苟。你知道Q我不是一个喜Ƣ预未来的人，所以从不把旉花在无休止的?ch)躁和争?上，而是可能投入眼前的工作。当然像我这L(fng)Z很多Q所以我_(d)能够站在现在的位|上Q真的完全是靠运气。当?dng)提到写作Q我认ؓ(f)我还是个不错的?者，g有天赋的表达能力?/span>
记者：(x)是的Q我前不久读?jin)(zhn)的《企业应用架构模式》一书，(zhn)的表达能力点给我们留下很深的印象。说到所谓的“企业开?#8221;Q究竟什么叫“企业开?#8221;Q它I竟有什么特点？
MFQ?企业开?#8221;是一个很含糊的词Q我一般用它来指代所谓业务Y件开发，以区别于传统的Y件品开发。企业开发通常要和数据打很多交道，而且旉和资金的压力?大，客户的需求多变，而且需要多ơP代和大量集成性工作。企业开发是要遵守一pd业务逻辑的，而正如我在《企业应用架构模式》一书中所说的Q这些业务逻辑 最大的特点是没有逻辑?/span>
记者：(x)那么(zhn)认Z业开发者所面(f)的最大挑战是什么？
MFQ如我所_(d)企业应用的业务逻辑l常是没有逻辑性可a的，因此Z(jin)?jin)解它，开发者必M断沟通和交流Q只有不断的沟通和交流才能开发出用户真正需要的软g?/span>
记者：(x)(zhn)觉得企业开发当前最重要的趋势是什么？
MFQ?我觉得眼下最有趣的趋势是Z正在竭尽全力地寻扑ց一件事情最单的办法Q怎样用最单的Ҏ(gu)构造大型的复杂的应用程序和企业解决Ҏ(gu)。比如说Q在 Java开源社中出现的以SpringZ表的轻量U容器。以?qing)Ruby on RailsQ它Ҏ(gu)“?fn)?#8221;来自动设定很多元素，大大提高?jin)开发效率， 也简化了(jin)开发过E?/span>
记者：(x)看来(zhn)对于Python和Rubyq样的动态语a非常感兴，是吗Q?/span>
MFQ坦率地_(d)臛_在目前的情况下，大型的、复杂的、严肃的应用E序q是以Java?NETZQ但是对于一些小的应用来_(d)Python和Rubyq样的动态语a实展现Z些让得非常有的Ҏ(gu)，我本人就是一个Ruby的爱好者?/span>
记者：(x)有的企业开发者认为，目前的企业开发效率已l够高?jin)，只要目前的工具和框架掌握得很好Q就可以高效率地开发出高质量的企业应用。?zhn)觉得我们的效率真的够高了(jin)吗Q?/span>
MFQ不Q我q不是这栯为。我们的开发效率还有很大的提高I间Q尤其是如何快速、清晰地?jin)解客户需求，q将其{化ؓ(f)W合要求的应用程序。这个过E对于我们目前的企业开发来说还是太慢了(jin)?/span>
记者：(x)可是Q我们几乎不需要做M大的设计工作Q体pd架构是确定的Q还有很多框架在辅助我们Qƈ所有有的设计工作都代替我们做?jin)，在这L(fng)开发过E中Q趣味何在？
MFQ?如何快速而准的满业务需求，对业务逻辑q行建模才是有趣的事情。而像O/R Mappingq样的事情，是非怹呌枯燥的。对我而言Q绝不会(x)认ؓ(f)?写一个O/R Mapping的工h一件有的事情。它与业务本w无养I而只是作为基设施而存在。有q样的工h觉得非常好，但是我认为更重要的，q?是把握客户对业务的需求?/span>
记者：(x)好吧Q那让我们来谈谈面向对象的思想Q这可以说是当今企业开发的L思想Q我记得(zhn)曾l在书中说过Q面向对象得构造大型复杂系l成为可能，但是现在SOA正在兴vQ?zhn)觉得q是否意味着面向对象要过时了(jin)呢？
MFQ?当然不，谈到服务Q其实在服务的背后仍然是面向对象Q服务是暴露功能的一U方式，而在背后提供功能的，仍然是对象。而且开发这些功能仍焉要大量面向对?技术。总而言之，服务x的是如何对外暴露接口Q而在q些接口背后的构建工作仍焉常复杂，面向对象些工作提供了(jin)一U很好的解决Ҏ(gu)?/span>
记者：(x)在中国，׃一般企业的理q不成熟Q所以客L(fng)需求变化频J而且剧烈Q很难保持接口的E_Q有为面向对象在q种情况下ƈ不适合使用Q因此把希望寄托在SOA上，(zhn)对此如何看待？
MFQ?我觉得这U观Ҏ(gu)很奇怪的Q说到接口的不稳定，无论是对对象q是Ҏ(gu)务都同样是存在的。在服务中也需要像契约q样的手D对外发布功能，因此同样存在接口?E_的情形。所以SOAҎ(gu)解决不了(jin)q个问题。我认ؓ(f)q更多的是一个开发方法的问题Q例如敏捷开发中Q频J地改变对象的接口，通过与客L(fng)密切交流来了(jin)?和满业务需求，同时通过重构来调整应用程序的内部l构Q这栯会(x)使接口尽早稳定下来。同时也应该为接口的q化提供一U行之有效的手段。这个问题确实不 好回{，q说的只是一个基本思\?/span>
记者：(x)问?zhn)一个具体的技术问题。在很多企业应用中，Z都会(x)开发一个数据访问层Q这是ؓ(f)什么呢Qؓ(f)什么不直接在业务逻辑层中存取数据库？
MFQ我本h喜欢在不同的地方作不同的事情。业务逻辑是一回事Q存取数据库是另外一回事Q所以它们不应该U缠在一赗这是主要的理由。还有一个次要的理由Q设计一个数据访问层Q一旦数据库发生变化Q移植v来会(x)快得多?/span>
记者：(x)但是q样的设计也有缺炏V当我们要改动数据表l构Ӟ往往需要相应地在数据访问层做改动，接着在业务逻辑层作改动Q有时甚臌改表现层。这不是很麻?ch)吗Q?/span>
MFQ哈Q这是h们经常抱怨的事情Q但是这是所谓的trade-off。分层在带来一些好处的同时也带来了(jin)q样的麻?ch)?/span>
记者：(x)再说说单元测试。很多h不愿意进行单元测试，是因为时间的压力太大?jin)。如果项目时间很紧张Q难道我要花掉一半的旉来写单元试Q?/span>
MFQ当?dng)因?f)单元试能够使你更快地完成工作。无数次的实践已l证明这一炏V你的时间越是紧张，p是要写单元测试，它看上去慢，但实际上能够帮助你更快、更舒服地达到目标?/span>
记者：(x)道理固然如此Q但是实际上很多人没有心(j)情去写完备的单元试...
MFQ在q种情况下，你可以只写那些确保代码在正常情况下正常工作的单元试Q不必应对各U各L(fng)错误情Ş?/span>
记者：(x)即ɘq样也还是很?ch)h。我发现自己l常在测试一些显而易见的事实Q比如一加一{于二，q经常把_֊攑֜一些不重要的测试上?/span>
MFQ什么叫重要Q什么叫不重要？q是需要逐渐认知的，不是惛_然的。我为绝大多数的模块写单元测试，是有点烦(ch)人，但是当你意识到这工作的h(hun)值时Q你?x)欣然的?/span>
记者：(x)(zhn)能l中国程序员几个忠告或者徏议吗Q?/span>
MFQ?对全世界的程序员我都是那么几条徏议。第一Q每q学?fn)ƈ熟(zhn)一个新的编E语a。坚持几q_(d)你对于程序设计会(x)有非常深ȝ见解。第二，学习(fn)试驱动开发，q?U新的方法会(x)改变你对于Y件开发的看法。第三，劳逸结合，不要Ll得紧紧的，爬爬山，跌舞，l常放松经Q你?x)发C更有zd和创造力。我的一些最?的想法就是在山顶上萌发的?/span>
]]>