再谈敏捷和ThoughtWorks中国咨询师

再谈敏捷和ThoughtWorks中国咨询师

前言说明

之所以用了“再”,是因为之前的两篇文章——

  • 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。
  • 我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题,以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样,只有真正知道一件事情的利弊,你才能用好它。

当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(CoolShell.cn)受到持续性的黑客攻击

本来已经过去的事,今天却又发现这两篇文章的访问量和评论又上来了,才发现原来是InfoQ的这篇文章——《虚拟座谈会:TDD有多美?》,加上很多我在评论中的观点,以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1)我对整个事情的基本观点,2)对于方法论的观点,3)对于TW中国咨询师的观点,4)还有和TW和InfoQ住来信件中的观点

————————————————

基本观点

首先,我想说明一下我的基本观点。

一、真金不怕火炼。我就像大家一样,平时总是会或多或少的埋怨点什么。大街上有人随便做个事,你会和他较真吗?不会。这个事也一样,我就像大家茶余饭后批评房价和物价一样,你们没有必要那么较真,不值得这样小题大作(除非你们真的心虚了),如果你做得好的话,真金不怕火炼,我这点批评算得了什么。你们玩的是“敏捷”不是“敏感”

二、从正反面思考。我和大家一样,喜欢思考,喜欢从正面和反面一同思考问题,我有质疑的癖好,我希望大家都有这样的思考方式。注意,质疑的结果不是为了质疑而质疑,而是去寻找完整认识的一种方法

三、观点的自由。我不是一棍大打死一片的人,我不完全否定敏捷(我的那两篇文章都有一再说明过了),同时我也不会完全同意敏捷。我不会因为敏捷有不好的地方我一棍子打死,我同样不会因为敏捷的好处就大唱赞歌。任何事物都有好有坏,我寻求的是自由地发表我的观点。我反对观点的极端,但我追求观点的自由

四、观点的不同。观点只有不同才会让人思路完整,观点只有不同才会迸发出火花,世界的进展正是因为有不同的观点。如果敏捷的咨询师和信仰者们不接受不同观点,不接受批评,那么你们将无法进步和发展,如果你们妄图让所有人都持认可敏捷的和谐观点,那么你们将会变得邪恶。没有批评,赞美也会变得没有意义

————————————————

对于敏捷方法论的观点

一、没有好的方法,只有适不适合的方法。正如没有好的设计,只有适不适合的设计一样。喜欢足球的朋友都知道,世界级的足球队中,巴西队玩的是个人艺术足球,德国队玩的是整体和纪律性足球,意大利玩的是防守型足球,但是他们都有夺世界杯冠军的实力,如果你硬要让巴西队去整意大利的风格,或是让德国整巴西的风格,那就悲剧了。敏捷是不会是适合所有人所有项目的,就像不是所有的人都有运动的天赋一样

二、软件开发的中心是人和项目,而不是方法。千万不要把方法放在中心,改变项目的性质和人的习惯去适应这个方法。正确的方法是,以人和项目为中心,了解项目中所有人的想法和做事的风格,以及项目的性质,从而决定采用什么样的方法。大家可以看看InfoQ上那几个“专家”关于TDD的对话,除了Google的测试经理外,其它人从到到尾谈的都是TDD方法,谈的都是如果要TDD,人应该怎么怎么样。这就是敏捷最大的问题——教条主义横行,以方法论为中心横行。我批判的就是这个!

三、好的方法不是讲出来的,而是在实践中改善出来的。好的方法不用去讲出来的,而是从团队内部自发出来的。如果敏捷方法论很不错的话,那么应该会在现实中体现出来。真正好的方法是团队内部根据自身情况在不同的项目上使用的不同的方法。(注:请不要使用XUnit, Spring,ANT等程序框架举例,因为那些项目的用户是程序员)

四,方法论不是一种理论。敏捷的鼓吹者说,TDD让你更关注设计,TDD更能了解需求。理论上,你可以把TDD拔到这样的高度,甚至更高的高度。可是具体实践上呢,你会发现在有压力的状态下你的程序员关注得更多的是测试过不过,在和用户沟通的时候,你会发现,根本没有一种好的方法论可以把需求完全搞清。如果TDD可以完全搞清需求,还要迭代干什么,直接waterfall了(其它关于TDD的观点请看我的文章《TDD并不是看上去的那么美》)理论和实际的差别的很大的。

————————————————

对于ThoughtWorks咨询师的批评观点

对于 下面这些言论,我就不一一点名了,因为我觉得这和咨询师没有关系,这和TW中国公司的管理理念有关系。

  • 中国ThoughtWorks某些咨询师通常在加入公司很短的时间内(1-2年),基本上都以被冠以“高级咨询师”。1-2年能做几个项目?我以为能给人做咨询的人都是在技能上让人佩服的那种人。20出头还是埋头苦干,努力学习,积累经验的时候,经验都不够,就可以给人咨询。
  • 中国ThoughtWorks某些咨询师们,喜欢翻译国外的书,但从不自己写书,他们喜欢blog,他们的blog里都里大量的Agile的方法,而很少有对技术的见解,以及技术细节知识性的文章,在他们的blog中,你很难看见代码。
  • 中国ThoughtWorks的咨询师们,喜欢参加各种研讨会,以及各种论坛,媒体采访。看看这篇文章,空洞,空洞,还是空洞。
  • 中国ThoughtWorks某些咨询师们大多都比较敏感,都是坚定不移的敏捷信徒。你别说有不同观点了,你就问个有点疑问的问题,他们就敏感了,就要反驳或是教育你了。
  • 中国ThoughtWorks某些咨询师们大多都很能说,和他们在一起,你基本上说不上话,就算说得上,他们也不会听你的,而且在不停地说教。大多数时候,他们都有很多的神一般的理论,比如:“你这不是真正的敏捷,真正的敏捷不是这样的”,“TDD中的T,是什么测试都无所谓。它就是设计。”,“TDD更强调设计,而不是测试本身。所以,TDD并不适用于菜鸟程序员。”,“你是在用锤子拔钉子”,“敏捷不需要文档,代码不需要注释”,“能学会的人他不需要看这些文字,不能学会的人他看了也是白看”,“它不是对不对的问题,它是可笑的”,“要使用一种设计方法,你就必须(1)会做设计;(2)做设计。它难在有些项目不做设计,有些人不会做设计”……

大家可以看看InfoQ的这个针对本章文章的讨论,注意熊节同学的观点,他是在谈TDD呢,还是在说我呢?可见他是带着目的来参加这个讨论会的。但是大家有多少人看明白了他在说什么?他除了敏感,除了那些“神一般的观点”,你真的实在不知道他在说什么,你是不是和我一样,对他的发言感到很空洞呢?(熊节同学可能以为InfoQ把我邀请去了,其实我没有去。大家可以去看看,那不是讨论,那是一群TDD的信徒们在自己炒作自己呢

我不厌其烦地再给咨询师们提那个建议——咨询师就像裁缝,不是只为设计时装的设计师,你们做的是量体裁衣的活儿。对于不同的身材,不同的体质,要用不同的财料和尺寸; 对于不同的性格,将会是不同的风格; 对于不同的场景,也将会是不同的服装,游泳和出席宴会是两种不同的服装。服装的好坏不是服装本身漂亮不漂亮,而是合不合身,搭配地好不好,适不适合相应的场景,着衣的人感觉到的是不是舒服

——————————————

关于ThoughtWorks和InfoQ给我的信

文章写得太长了,大家见笑了,也见谅!这是最后一段了。

1) TW的王效珅在春节前和我有几次电子邮件的往。我觉得王效珅是个很出色的公关人员,她用硬朗来形容我,把我一下子形容老了几十岁。她希望和我做沟通,希望让我和TW的咨询师谈一谈,我没有答应,也没有拒绝。春节期间还给我打来了电话祝我春节快乐,真是太让我感动了。她尊称我老师,可是我并不买帐,因为我觉得我没有资格成为老师,我也建议她也不要随便叫人老师。下面,是我给她的回信中的观点。

在谈到如何管理项目时,我这样回复她的

你可以理解成——你们就像是黄埔军校,西点军校出来的高材生,而我就则是一个天天在各种战场上摸爬滚打并被打得灰头土脸的土贼。我不相信流程和各种Best Practice,我只相信的是人。

我最关心的是软件开发中的三件事,第一个是人,第二个还是人,第三个还是人。第一个人是实现项目的人,第二个是项目的所有人,第三个是项目外周边有关系的人。我不但关心他们的想法,他们的软/硬能力,我还更关心他们的风格,他们的性格,还有他们的成长经历。这样我才能在权衡项目中那些各种乱七八糟东西的时候,懂得怎么plan,怎么run,怎么communication,怎么manage 才会是真正有效的(效果+效率)。motivate和项目有关的每个人,这才是我心中的敏捷!(这其中是需要花大量的心血的,相当的影响寿命)

在谈到是否见面时,我是这样回复她的

  • 其一,在网上,不只是我的言论对TW有微辞,需要我们每一个人每一个公司树立一个好的心态就好了(网上骂我的也很多,我自以为我的心情还不错)。
  • 其二,如果做的好,那就经得住考验,经得住质疑,好的东西一定会有好的结果,有了结果,拿结果和事实说话,这是最好的方式。
  • 其三,你说的那位技术上的同事,据你说是对我很欣赏,也常看酷壳,那么以前应该交流过才对啊,不应该是我质疑了你们的时候。呵呵。
  • 其四,我绝对不是一棍子打死一片的人(我原文中也多次提过Agile中有一些提法是不错的),但是我也不是看到一个好的就大唱颂歌的人。

2)关于InfoQ张凯峰主编的来信,原文如下:


From: [email protected]
Date: Tue, 15 Feb 2011 20:24:27 +0800
Subject: 邀请参加TDD虚拟座谈会的讨论
To: [email protected]

陈皓你好,

我是InfoQ中文站的主编张凯峰。最近你的《TDD并不是看上去的那么美》一文引起的广泛的关注,我们想就此做一次虚拟的座谈会讨论,邀请你来参与一下关于TDD的讨论。邀请的专家还包括thoughtworks的咨询师,以及其他敏捷方面的专家。以给读者更加广泛的视角和分享。欢迎参加,谢谢。

以下是问题,可以把每个问题的答案发回给我。截止时间是两天。任何问题,请与我沟通,谢谢。

请介绍你自己,以及TDD的实践经验。
TDD跟Test是什么关系呢?TDD的T就是Unit Test吗?
你认为实施TDD需要怎样的前提条件?TDD难在哪儿?
TDD之于需求、设计、代码质量是怎样的关系和影响?
你认为实施TDD容易犯的错误是什么?TDD的不足在哪些方面?
一般开发者需要多久能掌握TDD呢?请向读者推荐一下TDD的学习资料吧。

Thanks,


张凯峰 | Kevin Zhang | InfoQ China Managing Editor
InfoQ China:http://www.infoq.com/cn

我的回复如下(我老婆 说我回复得太贫了,我接受!)

From: [email protected]
To: [email protected]
Subject: RE: 邀请参加TDD虚拟座谈会的讨论
Date: Tue, 15 Feb 2011 21:45:51 +0800

张凯峰主编,您好!

谢谢你们关注我的文章,见笑了。

你们真是很厉害,相当善于发掘热点新闻。果然是媒体的专业素质。;-)

我的文章不应该有那么大的能量,一个根本没有推广的个人blog,随便发布一些自己的想法,不是自我炒作,自己的blog嘛,想啥说啥,就像大街上的阿猫阿狗一样随便发表点个人意见,不会有人在意的。哪能引得您们的关注。真是让我受宠若惊。

另外,你问到的那些问题,绝大多数的答案都在我的那篇文章里了。如果你们想转载我的文章,转过去就是了,只要注明作者和出处就OK了。千万不要用于任何的商业目的和炒作,这样我会很不高兴的。

所以,我还是谢绝这个讨论了。如果你真想找人讨论的话,执我这样观点的人并不在少数,Google一下,可以找到很多。尤其是国外的,有些作者和我一样,都是做了十几年的项目的,都是做大大小小也有20来个项目的,各种人,各种事,各种项目都经历过很多,找那些人岂不更好?

P.S,您的邮件还真强势,在“谢谢”和“谢谢”中就直接让我回答这些问题,还只限两天时间。真是个大主编,让我学到了“谢谢”的另一种用法。谢谢!

祝 工作顺利!
陈皓

我的观点就是我的观点,无论你同不同意,喜不喜欢,都是我的观点,

他就在那里,不卑不亢,不多不少

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (51 人打了分,平均分: 4.47 )
Loading...

再谈敏捷和ThoughtWorks中国咨询师》的相关评论

  1. 有些东西的价值,就是得用金钱衡量的,1w多块钱月薪的工程师有时候就是没有2w多块钱的gg来的牛逼;
    有些东西的成色,就是得用时间考验的,工作五六年的小伙子头上帽子多高他还只是个小孩。

    所谓咨询,很多时候,看着年轻的同学,资深咨询师的title,就好像站在舞台上的魔术师,你懂得。

  2. TW咨询师的是TW公司管理的问题,对于TW公司的东西,可以说说——

    1)TW公司定位不清楚。连上层都没有搞清是要做咨询,还是做外包(如果要做外包,就要放下姿态,中关村软件园中有很多外包公司是你们学习的对象)。

    2)TW咨询的策略是,通过培训和鼓吹,得到机会到用户那里当coach,最终能得到外包的机会。

    3)TW的外包项目虽然多,大多来自北美,但是都是比较小比较简单的,以Web为主。有那么一两个比较大的项目都被明星核心员工垄断了。其它人很难有机会。

    4)TW公司有一个核心圈子,有点像长老会,也就是权威,他们正在开始变得自大和傲慢。这个圈子周围是第二层圈子,是能被长老会认可以的人。其他人可能很难有话语权(敏捷中有一条就是反对权威,但TW公司内部正在形成这个东西)

    5)TW公司内的职业生涯理论上有几条,但实际上只有咨询一条。走经理路线走不了,因为只有一个经理,走技术路线又没有业务和像样一点项目或产品,只能走咨询路线。

    6)TW咨询师其实就是Developer,但是TW觉得咨询师这个title比程序员更牛。TW走咨询师通常有三条路,一是靠媒体炒作自己,通过翻译书,写blog,出席媒体活动等(CSDN过来的那几个深谙此道),二是靠嘴皮子,但是太年轻了,到了客户那边,客户懂的都比你多,业务你不懂,敏捷还没有用户熟悉,忽悠不动,三是靠扎扎实实的技术,这需要实实在在的能力和经验。后两条路太难了,所以,都去走第一条路了。

    7)能给别的公司做咨询的人对我来说,一般有要么是技术底子很强项目经验很丰富的人,要么就是对用户的行业业务相当了解的的人,要么就是管理方面的(公司组织架构调整)。TW显然很有创造性,玩了一个即不技术也不业务更不管理的咨询——方法论。所以,脱离了具体的业务,技术和公司管理,TW咨询师最终说出来的话也只有空洞了。

  3. @jnj 我也做过一些国外的项目,接触过一些对方公司聘请的consultant,要么是深谙技术,做过十几二十年开发的资深工程师;要么是某个行业或者领域里业务熟得不能再熟的老家伙。TW中国的那些嘴上没毛的二十四五的家伙,再怎么聪明,经验和资历就在摆在那里。要明白做咨询和做开发不是一回事!

  4. “大家可以看看InfoQ上那几个“专家”关于TDD的对话,除了Google的测试经理外,其它人从到到尾谈的都是TDD方法,谈的都是如果要TDD,人应该怎么怎么样”
    正如你所说,主题就是关于tdd的对话,不谈tdd谈什么?谈罗玉凤?
    你还真是像极了原来javaeye上的杰杰熊,别人说什么他都要反驳

  5. 从新浪围脖过来的。我觉得你对敏捷的看法说出了我的心声。我很惊讶居然也有人对自己在IT行业的地位带有个“土”字,我以前自称自己是程序员中的土匪的。哈哈~
    ps:熊节这个80后小朋友,我以前在gmail的敏捷中国讨论组里和他“交手”过。看起来,和他有过节的也不止你一个人了。呵呵

  6. “中国ThoughtWorks某些咨询师们,喜欢翻译国外的书,但从不自己写书,他们喜欢blog,他们的blog里都里大量的Agile的方法,而很少有对技术的见解,以及技术细节知识性的文章,在他们的blog中,你很难看见代码”
    你这段评价,我大致知道是谁了,但只是个例,tw里的高手一般都是做coach,不是咨询。他们每年90%的时间在世界各地做项目。你看到的blog估计也是特例。我所认识的tw的人放出来的代码可能你都不大能看的懂

  7. @吗啡
    让人看不懂的代码不是好代码~代码不是某位程序员的私有财产,从它被编写出来那一刻开始,它就是给别人看的。

  8. @黑暗浪子
    完全同意你的看法。我所说的看不懂不是指某种算法或功能实现上的不懂,而是一些比较底层的牵扯到语言本身词法分析之类的代码,至少我不了解的情况下很难懂

  9. 几个看法。
    1.现在鼓吹的敏捷在我看来类似中医,本身就不是一个有完整系统的方法论,充斥着一些形而上的荒谬东西,把各种零散的开发经验集合一下,吼几句“因为爱,所以爱“,不需要实证,永远正确。在方法论的级别上,它远远比不上CMMI这种可量度的体系,CMMI的杯具只是大部分地方是被CMMI的。
    2.中医很杯具,但不少中药是给力的。敏捷中相当一部分的基础组件,是走向高水平交付很好工具,如CI,小步快进的迭代,包括TDD。
    3.中药是不能乱吃的。CI基本上算是云南白药了,暂时看不到毒副。小步迭代的成本显然要高过大瀑布很多,过程控制上也要困难不少,需求稳定下来的中小型项目未必适合。
    4.TDD这个东西。TDD太威武给力了,怎样给力,Bob大叔在敏捷的开山之作中的保龄球一例中淋漓的诠释了这一点。但问题是这个从抽象到具体,完美控制逻辑层次,story粒度的例子在实际生产中做到的难度巨大,Bob大叔这样一线奋战40年以上的圣斗士,国内基本是看不到的,老美那也是稀缺资源。所以我的看法是,有能力就做一些,慢慢积累经验,原教旨的崇拜就算了。
    5.软件开发的最终目的是成功的交付,所有一切方法论都是为此服务。成功交付不仅仅看质量,成本也是衡量的一个重要方面。相当的原教旨敏捷信徒嘴上说的是没有银弹,事实上是把敏捷作为银弹了。

  10. @黑暗浪子
    @陈皓
    呵呵,熊节的个人经历决定了他不可能在某个行业,或者某个系统中有太深入。尽管其个人很聪明,对技术也很敏感。他应该还是适合在媒体做编辑、翻译之类工作。但他现在在做咨询,也只能、只有这种方式去忽悠一些东西了,而且这两年更加显得空洞了。

    TW还是有很多非常专业、值得尊敬的业务或者技术专家。国内也是,gigix只是其中一个特殊风格吧。

  11. 咨询师很多都有这个问题的,只顾咨询,其实自己平时没啥项目经验,不实践,任何方法都只是理论,每个理论在实践当中,都可以采取不同的具体步骤,有所删减,或有所增加。

  12. LZ只接触了gigixiong一个人么,我看还是多接触接触没有坏处,当然你也说了不是一棍子打死一船人,你怎么就知道TW里面没有和你心心相惜的人呢?我觉得可以接受效绅的意见,当多认识点朋友好了,lz还是当年的血气方刚啊,有愤青的感觉,不过TW里面愤青不少,你会找到和你思想一样的人的。你不是也说要多接受别人的意见么?那就直接实施吧。我相信您能找到TW里面和你一样思想的人的。

    1. 老实说,熊节还没有接触过,其它的咨询师倒是直接或间接地认识了一些。而且以前也去过TW。愤青也只是愤在“教条主义”和“以方法论为中心论”这里,我是谋事的人,不是谋方法论的人。另外,TW这个公司的东西你可以看看我前面的回复。TW就是外包公司,做大量的外包项目,从这个经历上来说,我还真和他们不一样。

  13. 对这个公司还是有一点体会的,刚刚应聘TW,失败了。
    我问过面试的某大牛一个问题,你们的业务除了做咨询和一些开源项目,还有什么,他说“主要业务是交付项目”。我问是不是外包,他犹豫了下说差不多,当时忽然觉得说错话了,呵呵。其实我个人并不是鄙视外包。
    对我这个还在为生存而工作的人来说,很艳羡他们的精美的工作环境,开放的接触新技术的氛围。
    但是也对不停见识的他们的一些作风有点点觉得不是很舒服,我接触过的TW的人都对代码有着强烈的洁癖,能写成一行的绝不写成两行,我对此表现出了无所谓的态度被鄙视了(要不然我看我同事的代码会被气死的)。
    还有个不爽的是不管说话还是博客总是汉字中间夹着英语单词(这个也许外企都这样吧)。

    gigix 之前在我们公司做过咨询,虽然说实话并没觉得对我个人或所在的项目有啥有益的东西留下,不过对他本人技术还是比较欣赏的。

    多年前上大学时初闻TW确实非常的崇拜,现在才觉得其实也并不是像之前听说的那样是IT界最向往的公司。

  14. 吗啡 :
    @黑暗浪子
    完全同意你的看法。我所说的看不懂不是指某种算法或功能实现上的不懂,而是一些比较底层的牵扯到语言本身词法分析之类的代码,至少我不了解的情况下很难懂

    第一次看到有人把代码难懂拿出来说事的。

  15. 有一个老头,正在草地上放羊,忽然走来一个年轻人,年经人走到老头面前说:老先生,我可以为您服务,我将告诉您您的这群羊有几头,作为酬劳您需要给我一头羊。

      老头还未作答,年青人就开始了工作,年轻人用笔记本电脑无线上网,链接上NASA的内部网,调动低轨道卫星,把卫星遥感成像的图片再通过软件分析,数十分钟后,年轻人再次走到老头面前:老先生,您的羊群共有763头。说完后他抱起一只羊就要走。

      老头这时叫住了年青人:年青人,如果我能猜出你的职业,你可不可以把酬劳还给我?

      可以,年轻人答。

      你是咨询师,老头说。

      年轻人很惊讶,您怎么知道?

      老头笑了:因为你具有该公司咨询人员的所有特点啊,第一、你不请自来。第二、你告诉我的分析结果是我本就知道的。第三,你根本就不懂我的羊。好了,现在把我的牧羊犬还给我。

  16. Larry :
    工作经历中遇到不少和ThoughtWorks一个德行的人,整天把敏捷挂在嘴边,好像只要用了敏捷项目就能一帆风顺了一样。还有那个熊节,真的挺不喜欢他的,看过他在javaeye和csdn的博客,内容空洞,不知道在扯什么东西,很少见到真正讨论技术细节的。以为自己留了个长头发,把自己打扮得异类一点,就多牛B了一样。程序员不是玩摇滚的,务实、务实啊!

    玩摇滚的没站在务实的对面;这个事和留长发也没几毛钱关系。吼吼。

  17. 最近看了不少敏捷的讲座,一开始情绪激动,觉得确实是团队合作项目的良方,但是仔细思考后却无从下手。陈皓的文章真是及时雨,读后让人豁然开朗。 嘿嘿,万分感谢!

  18. 很有想法。说的也很客观。我很理解你。谢谢,听到你的这些讲话。
    这就像,当时百家讲坛的讲师红起来一样,说了一些所谓大师说不出来的话,做了一些他们不敢做的事,却受到大师们的批评和质疑。很正常。

  19. 因为有了敏捷,才有了敏捷咨询师;因为有了敏捷咨询师,才有了敏捷咨询师的批判者。任何一个角色的出现都有其出现的必然,我们不能说反感谁批判谁。敏捷给了我们一个方法,敏捷咨询师成为了敏捷方法的推广者,正因为有了他们,我们才能更了解敏捷,有了在这儿大谈特谈的机会。而批判者的存在让我们认识到,咨询师并不伟大。

  20. 刚搜了下说的那个咨询师,大学肄业,自述是失败者的身份,应该不是辍学创业。然后去某技术网站当编辑,再后来去做项目开发,看另一个博客上写的,做项目应该不超过两年的样子,然后回某技术网站在做技术主管之类的。出名估计就是靠翻译书出名的。再后来应该就是去当咨询师了。另外的一个博客上面写的更激烈,质询学历,连英语水平都开始质疑了。

    鉴定:此大学肄业咨询师属于技术编辑出身类型,类似那种整天拿着讲话稿到处讲话的领导,审查秘书的讲话稿很厉害,但是让他自己写讲话稿,保准一段都搞不定。

  21. 再有就是看infoq的东西总感觉空洞无物,好比让刚毕业的学生去听院士讲座,摸不着头脑。听一堆理论不如贴两行代码来的实在。中间还在想infoq靠什么盈利?这才知道原来是外包

  22. 有幸接触过TW的咨询师,在项目组推行敏捷,刚好我负责这一块。
    好的方面:
     1,组织起了早上五分钟站会,还是有效果的,不管是不是任务直接相关,大家都有些交流了。
     2,强调了持续集成,因为公司开发和测试严格分工的,所以还是很有用的。
    坏的方面:
     1,硬上TDD
       之前我也翻过一些敏捷的书,大概知道TDD在设计阶段很有用处,但是在一个有十多年历史的业务复杂
       的大型通信系统,且面临严格的新版本发布期限的情况下,那哥们真是一声不吭,搞到最后搞不下去
       了,我去求证我们的项目不适合上TDD,那哥们才说了一句“是的,……“。
     2,心术问题
       UT框架上我偏向于用gtest,但他即强烈推荐使用他们同事开发的新东西,该东西的问题:支持平台有
       限,有些产品运营的平台不支持(问之答曰:linux 32位上测一下就可以了);虽然也在google-code
       上开了源,但在linux上编译失败,后来发来一个lib才算编译通过;没有文档(框架不好才需要文档);
       库是GPL的。感觉把偶们当小白鼠了,而且还想拿根绳子把你栓牢了。
       

  23. 看到InfoQ张凯峰的邮件,还真是汗了,如此强势

    “以下是问题,可以把每个问题的答案发回给我。截止时间是两天。”请别人参与讨论,看上去却像是上下级关系…

  24. 呵呵,看来 ThoughtWorks和InfoQ 只是卖一种理念。

    如果这个观念站不住脚了,他们做的所有努力都白费了。

  25. 一切的核心当然是人,那个年代都不乏伟大的项目,关键不是方法,是人。我也觉得真真正正的做项目敲代码才能有真本事,但一定有在这个过程中有很好的思考,善用好的工具和方法。敏捷所提倡的一些工具还是很不错的东西,而且其实很多人都在用了,但单单谈方法就本末倒置了。博主说很多咨询师太年轻,我也觉得是这样啊,积累是非常重要的,这个过程需要时间。

  26. @陈皓
    我本人是目前在做产品方向(不敢称产品经理,自认为还离真正的产品经理远着呢,不够格),之前在互联网开源软件初创团队呆过1年,也经常上InfoQ,也知道TW中国。比较关注敏捷,其实我把所有关于敏捷的文章都统一放到”技术方法论”这个收藏夹内。

    我特别认可您对于”对于敏捷方法论的观点”观点,特别是第2条。

    我认为您这点谈的和之前《让敏捷与“以用户为中心的设计”和谐共生》http://www.infoq.com/cn/news/2010/03/ux-and-agile,一文有异曲同工之妙。

    同时也刚刚购买了《用户故事与敏捷方法》一书,http://book.douban.com/subject/4743056/,还没开始看。

    不过敏捷也确实有适用范围,如同您一再表达的,没有项目经验、没有精深技术能力的人,实践敏捷,还不如老老实实写代码。

    敏捷不是为自身而敏捷,敏捷是经历过传统开发流程的人,精简了一些繁文缛节后的最佳实践。所以,做好敏捷,传统的技能是前提。

    至于InfoQ或者TW鼓吹敏捷,那确实和他们的业务生存相关,所以楼主在所难免受到攻击了。但我认为这也不是坏事,如同”云计算”这个概念一样,短期可能大家都在鼓吹,但长期运作起来,必然还是有真正的公司可以做出最佳实践来的。(有点像道家思想,无为而无不为。解释一下,从短期来看,InfoQ或者TW可以从概念上糊弄大家,大家于是乎唯敏捷马首是瞻,大家真正玩过了敏捷之后,才发现敏捷是怎么一回事,其实,这样从长远来讲,是大家真正实践敏捷、发现敏捷真正价值的一个过程,这个是必然的一个过程,就像现在的团购一样。所以InfoQ、TW、楼主的批判文章,从长远来看,都是非常有里程碑意义的。这也是一种思想的迭代,螺旋上升式发展。当然,希望大家不要被概念、名相所迷惑而沉溺其中,那就成了实践敏捷过程中的炮灰了。)

    楼主的文章,我读着,有点像邓小平的”实践才是检验真理的唯一标准”这一思想理念。

    所以,不断练好内功,才是团队/企业的根本所在。做敏捷的主人,而非敏捷的客人。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注