再谈敏捷和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 ,请勿用于任何商业用途)
《再谈敏捷和ThoughtWorks中国咨询师》的相关评论
“不卑不亢,不多不少”
支持!
有的咨询师耍嘴皮子很厉害,他们会拖你下水论战,然后用丰富的经验打败你。
这篇相对于前面几篇说的真就太直白了,看来皓哥也是有点毛了,但是真的很爽.触动了不少技术人的敏感神经,貌似还碰触到了某些团体的”根本”利益.
连探讨,表达相反的观点都不行,是不是有点太霸道了?希望皓哥能够坚持下去.那些家伙想用政治的那一套来搞技术,真是可笑透顶.
工作经历中遇到不少和ThoughtWorks一个德行的人,整天把敏捷挂在嘴边,好像只要用了敏捷项目就能一帆风顺了一样。还有那个熊节,真的挺不喜欢他的,看过他在javaeye和csdn的博客,内容空洞,不知道在扯什么东西,很少见到真正讨论技术细节的。以为自己留了个长头发,把自己打扮得异类一点,就多牛B了一样。程序员不是玩摇滚的,务实、务实啊!
狂顶,我曾经也是敏捷的狂热分子,喜欢方法学,喜欢最佳实践。到现在,我感觉确实技术更重要,方法学只能锦上添花。对一个刚刚工作几年的同学,我想最好的锻炼就是天天做项目,写代码。等有了足够的软件开发经验,对软件开发的各个过程有了直观的体验和认识,可以实验一些方法学,这会让你和你的团队变的更好。人最难得的就是一直保持思考,包括反思。敏捷实践最好是PM去掌握,包括如何去ruan一个团队,scurm的实践足够简单,有效。对于做技术的,多写一点代码,少谈一些方法。谈的都是方法,从不写代码,从不做项目,你这人就毁了,可能毁的还不是你一个人。
恩,不知道言必称老师是谁带起的,听上去很恶心!
浩哥你太强了,估计他们要疯了!
你的回信真的很直白啊。我也看了那个虚拟论坛,虽然不了解TDD,但是看了那个熊X,的确很敏感
别在意,很多程序员和咨询师只是停留在混口饭吃的境地上。想到这里,就都想开了。
张凯峰主编怎么就这样的沟通能力,害得我眼镜都掉地上了
公示私人信件不太好哦,虽然那啥主编小学没毕业,也不能歧视人家
主编的信写的太NB了,赤果果的质问呐。 “我给你个机会,快把你的想法相我汇报!”
@匿名诺夫 是的,我在写这个文章时一再犹豫是否公示信件,后来,后来觉得没有什么隐私,就公示了。大家就围观一样看看娱乐一下吧。由此引发的后果,我负全责就好了。
工作第5个年头了,我觉得无论从技术,还是为人的角度,我都觉得作者本身讲的有道理的。在技术上,经常思考技术的负面其实更有意你更好的实践这个技术;而且确实很多技术在一些时间的考验面前变得不那么吸引力。如果我们可以多反思反思C++,XML,也许今天这些技术会更好。而为人处事上,作者只是表达自己的观点,所有的批评都是有理有据,对事不对人,我觉得写得很好。
哈哈,这事情火起来了~
TW那边肯定会很重视
然后做咨询的人说话方式就是要虽然很心虚,但是表面上还是要强势得压倒你~
而且,去咨询各种事情的人,可能本身对做的事情没什么坚定的看法,所以他们才需要去咨询。咨询师要非常坚定得告诉他们如何如何有效,这样这帮人才能坚定得去干活……
但是,您这文章,把TW打死了,TW的方法不是一定有效的,追随他们的人没办法坚定得去干活……那么……
哈哈哈哈哈
TDD sucks.
TDD sucks,留长发的恶心死人
真够闹腾的,要不俺也bla bla 两句?
任何方法,特别是需要策略支持的方法都是有成本的,记得当年初闻xp的时候感触最深的是台湾人的一篇文章,说程序开发就像做极限运动攀岩,你不得不依靠你的绳索和滑轮。
是的,说的没错,但不是所有的程序开发都能类比成攀岩吧。写写垃圾程序随便人肉测测就行了。
所以我的观点是从成本角度出发,尽量少的用脚手架,但关键部分必须要用。好钢用在刀刃上。
没细看楼主的文章,不知道跑没跑题,不管跑没跑题,贴已经在那里,不悲不喜。 bla bla bla …
看了熊节先生的言论,真的比较失望。他翻译的《重构》对我影响很大,但他本人言论那么像个太空人。
哈哈,赶快向办法应对黑客。
希望这是一场有实际内容的争论
珍爱敏捷,远离咨询师
俺理解的敏捷法是小成本小颗粒方法,至于要用咨询师吗? 搞那么复杂用个p。
好东西一用便会,一使便喜欢,何必整天吆喝个没完,让人感觉有点blah
有多少人是真正热爱这个事业的
顶兰州,说得好
TW問問題真不禮貌, 被批活該!
其实很讨厌那些永远都是对的家伙。
耍嘴皮子 加上有欺骗的感觉
誓死捍卫讲话的自由
@lin
应该是说把自己当神的人, 可悲
我一直很怀疑tw这家公司很是怀疑。终于看到有人持相同观点了
学术自由,百花齐放。另外,国外做咨询的,都是五、六十岁以上的人,因为他们有几十年的从业经验。国内的咨询业做得有点烂
@AnkyHe
这位兄台说的在理。
希望能听到有内容的评论,而不是上来就骂人。虽然我挺反感敏感词过滤,但是对于技术讨论来说,那些糙话还是不用为好。支持或者反对的,都说说自己的理由和依据。建议陈皓也少用什么传销和电视购物等字眼,既然你推崇捍卫别人说话的权利,那么希望大家都少用偏激的字眼,尊重别人也是尊重自己。
皓哥威武,“中国ThoughtWorks某些咨询师们,喜欢翻译国外的书,但从不自己写书,他们喜欢blog,他们的blog里都里大量的Agile的方法,而很少有对技术的见解,以及技术细节知识性的文章,在他们的blog中,你很难看见代码。”,这个太nb了
我一直认为我们需要把敏捷方法和TW中国分清楚,敏捷不能代表TW中国,TW中国更不能代表敏捷。我与很多敏捷咨询师工作过很长时间,他们对于敏捷和技术本身都是非常热爱,也是非常专业的。有的也只有24、5岁,但是却比许多资深的工程师技术更强,效率更高,并且他们的沟通能力也是超出普通的开发人员的,他们喜欢相互交流心得体会,定期每周举办读书交流会。其中也不乏比较激烈的争论,但都是针对技术和项目,对事不对人,更没有人身攻击。我觉得中国的技术人员应该学习并掌握好的沟通技巧,个人认为这比技术更为重要。
IT没有银弹,对任何方法论的狂热都已经偏离了事情的本质。 另外老有人说什么沟通比技术更重要… 沟通最多在某些情况下跟技术一样重要,而不是更重要。 没有技术实践的沟通就是在浪费时间。 跟霍金沟通很不方便,但没人觉得麻烦。
@jnj 我觉得这篇文章没有在讨论技术或是学术,这篇文章我发布的就是我的观点,这篇文章更像是blog,就是写写自己的想法。就像你的回复也是在说一些非技术的东西一样。
在我的文章中,我已经把敏捷和中国TW咨询师的评论分开了。不过,事实上,TW的中国咨询师和敏捷这两者是分不开的。这点大家都明白。
我使用了传销和电视购物的字眼,我不觉得极端,因为他们都有两个共同的特性,1)不停不停的鼓吹自己的好,2)狂热主义。而且。另外,在互联网上使用这样方式的评论文章很多,比我的有过之而无不及,互联网在中国都那么多年了,这就是网络文化,你要学会适应。
如果想讨论实质学术的话,可以去InfoQ那边看看,只不过,在那里我看到的更多的只是空洞和党同伐异。
这位仁兄的评论很实在啊~之前和熊节在一个园区工作的人飘过~
在这里谢谢大家 的评论和回复,也感谢给我发来邮件的一些朋友,你们和我分享的你们和TW,和敏捷,和TDD,和熊节,和InfoQ的经历都太正点了。感谢你们的分享,感谢大家看得起我!
@jaunty
同感,特别讨厌他。
@陈皓
因为你的这几篇文章的文章分类和tag都是技术相关的,所以我无法把它们理解为非技术文章,也没有提高到所谓的学术高度。
看起来大家都比较反感光说不练的咨询师及其鼓吹的理论,也许再讨论下去“咨询师”这个头衔也要变成象“白领”那样的贬义词了。大家最关心的还是自己的问题能不能够得到解决,如果敏捷方法不能够解决你的问题的话,大可以一笑置之,然后寻找更适合的方法。对那些电视购物般的鼓吹,睿智成熟的我们应该不会轻易上当。奋起反击,也说明博主对此等现象无法适应和忍受,如同我无法适应骂街似的评论一样。
我选择了几篇文章,作者是一位曾经和我工作过的程序员,我比较推崇他的交流方式,一切理论从实践中来,又应用到实践中去,比那种云山雾罩的讨论方式更直接,更有用。也许文章并不适合大家的口味,也不能解决大家的实际问题,只是希望国内也多一些这样的经验分享,而不是文革似的大呼口号,动不动就打倒谁。
BDD with scenario code DSL, sometimes you dont need atool
TTDD tautological test driven developmen anti pattern
build dashboard radiator your build light 2
technical debt retrospective
不妨把TDD与咨询公司分开,大家讨论一下如何根据自己的实际情况来改进TDD
@jnj 哦,文革口号,打倒?没有你说的那么严重,这就是一般的批评罢了。你过于敏感了。(另,读文章不应该读文章的分类和Tag)
我的观点就是我的观点,无论你同不同意,喜不喜欢,都是我的观点,他就在那里,不卑不亢,不多不少
看到这句话我知道了,LZ反正也没打算讨论啥,也没有讨论的心情和讨论的态度。所以楼上的jnj,你举毛例子讨论哦,没有必要~~~
反正我的观点就是我的观点,Whatever,
楼主,您说对不?
(我删了一条骂人的评论)
jnj还真不是TW的,他是我的大学同学,我也不知道他怎么这么敏感。他现在在国外,国外的TW我不清楚,不过我这里说的是中国的TW。(jnj同学如果想了解一下中国的TW是怎么运作的,怎么管理的,他们内部的自大的明星员工的圈子,他们的模糊的定位,他们员工的职业生涯,他们最近走了一些不错的人的原因,为什么他们的员工都比较high,为什么他们爱翻译爱写blog,但从来不谈编程技术,等等,等等。我都可以和你电话谈谈)
我发现,热爱敏捷的人很像民族主义——我个人怎么样无所谓,但你不能容忍你批评我的国家。你要说你是TW的咨询师,这可能会影响你的职业生涯,还可以理解,但是作为fans来说,实在难以理解。
难道你们信仰敏捷真的已经到了一种宗教的地步了吗?
兄弟,你不用再了,ThoughtWorks是一群孙子,任何伟大的产品基本不会从这帮孙子中间诞生。如果ThoughtWorks的人基本上是靠概念、词汇骗钱的的一群家伙,包括我以前所尊敬的Matin fowler,Matin Fowler写了一堆关于面向对象、设计模式、企业模式的东西,但这逼从来没有用简单的语言指明企业系统的真谛:数据!
@陈皓
刚才看到那个帖子了,没想到还真招来骂街的,本来想置之不理,还是谢谢陈皓。
首先声明我和TW没关系,和TW中国更是一点关系也没。我自觉也没有把敏捷当宗教来信仰,陈皓也知道我和大多数中国人一样,没有什么信仰,呵呵。
我很喜欢这样的讨论,也看到了有很多有想法、有内容的回复,希望酷壳多一些这样的评论,少一些骂街或者偏激的字眼(我在前面的回复里也用到了“文革”这样的字眼,有点过激了),我还在考虑是否可以把关于这个主题的一些有内容的回复收集起来专门编成一篇文章,不知道陈皓觉得妥否。
我收到几封网友们的来信,都是和我分享了他们的和TW的经历。因为他们和TW相处很深,有一个居然和TW有十年的交情了,因为有一些事,TW的一看就知道是谁了,所以他们就私下发给我了。这些邮件,基本上都是和我分享他们对TW和里面的明星员工的看法的。看过这些邮件,我发现我对TW及其咨询师,我真的没有理解错。
我摘一句网友发给我邮件中的话——“敏捷宣言的敏捷,和咨询师嘴里的敏捷,以及大家实践中的敏捷,是很不一样的。”,我对这句话的理解是——理论和实践的差别!
最后,jnj,你做你想做的事就好了。
支持coolshell. 如果不用考虑开发成本,TDD的确不错。但实际中,又有多少项目有充足的时间和资金呢?
@cj
沟通的重要性,我是很赞同的。如果一定要加个前提,则就是“绝大多数情况下”
团队的内部沟通、公司的跨部门沟通,往往都是把技术能搞定的事情都给拖死了
我等阿猫阿狗内牛满面