再谈敏捷和THOUGHTWORKS中国咨询师

228 阅读14分钟

前言说明

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

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

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

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

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

基本观点

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

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

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

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

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

插播福利

1.近期整理了20G资源,包含产品/运营/测试/程序员/市场等,互联网从业者【工作必备干货技巧、行业专业书籍、面试真题宝典等】,获取方式:

  • 微信扫码关注公众号“非典型互联网”,转发文章到朋友圈,截图发至公众号后台,即可获取干货资源链接;

2.互联网人交流群:

  • 关注公众号“非典型互联网”,在公众号后台回复“入群”,人脉共享,一起交流;


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

对于敏捷方法论的观点

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

二、软件开发的中心是人和项目,而不是方法。千万不要把方法放在中心,改变项目的性质和人的习惯去适应这个方法。正确的方法是,以人和项目为中心,了解项目中所有人的想法和做事的风格,以及项目的性质,从而决定采用什么样的方法。大家可以看看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: xxxxx@infoq.com
Date: Tue, 15 Feb 2011 20:24:27 +0800
Subject: 邀请参加TDD虚拟座谈会的讨论
To: haoel@hotmail.com

陈皓你好,

我是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: haoel@hotmail.com
To: xxxxx@infoq.com
Subject: RE: 邀请参加TDD虚拟座谈会的讨论
Date: Tue, 15 Feb 2011 21:45:51 +0800

张凯峰主编,您好!

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

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

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

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

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

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

作者:陈皓,博客地址:https://coolshell.cn/articles/18190.html