再谈敏捷和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 ,请勿用于任何商业用途)

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

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

  1. 本来就不信牛鬼蛇神的我又怎么会随便相信不知道做过项目没有的咨询师呢?

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

    @吗啡
    1. 组织个standup meeting不需要请咨询公司吧
    2. 相比TDD,我更喜欢说Test First, 即在写代码时优先考虑要怎么测试,考虑设计的可测试性。
    并不是说一定要用test case来作设计.
    敏捷的核心应该是量体裁衣,充分发挥现有人员的能力和潜力,而不是随便拿个方法论来套。

  3. @tangxinfa

    2,心术问题

    It is really something I don’t like either.
    For their own sake, some consultants love to introduce immature and unproven frameworks and technologies. It is bad and needs to be controlled by the employer (yourself).

  4. 关于敏捷,我个人认为中间是有很多可取之处的。我们不能神话他,也不用妖魔化他。在我看来,这就像一双鞋子,合不合脚只有自己知道。敏捷也好,瀑布也好,能解决问题的就是好的。没有必要削足适履。

    我自己也是内部咨询师,最佩服的咨询师就是大前研一,在他的《专业主义》一书中提到,作为一个合格的咨询师,一定要发誓把客户的生意放到自己的生意之上,如果他们觉得客户的条件不具备,他们宁愿不接这个单子。我不知道国内的咨询师有几个能够做到这一条?

    我接触过许多的咨询师,有国内的,也有国外的,感觉国外的咨询师大部分都很低调。而且确实能帮我解决问题。他们回答完我的问题以后一定会问我一句“你是否觉得有帮助?是否解决了你的问题?”而且他们大部分都有很强的代码能力,能够帮助我的员工做hand on coach。

  5. kknd :

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

    @吗啡 1. 组织个standup meeting不需要请咨询公司吧2. 相比TDD,我更喜欢说Test First, 即在写代码时优先考虑要怎么测试,考虑设计的可测试性。并不是说一定要用test case来作设计.敏捷的核心应该是量体裁衣,充分发挥现有人员的能力和潜力,而不是随便拿个方法论来套。

    单元测试框架自己人定不了吗?这是经验教训呀!

  6. 不知道到底是文化,信仰抑或教育制度的原因,国人常常不是在pursue excellence,而且做人做事往往不professional。有些人大谈Agile和TDD之时,从没想过,这些西方学术文化下的理论,其实以很多西方的common sense为前提:pursue excellence, be professional, trust, respect。

    最后说件,可喜抑或可悲的事,本人所在公司正在某些资深coach的指导下,全面转向Scrum。近日,喜报公司内的某scrum team,be awarded “Best Agile Practices”by China Agile Conference。而这个team,现在才刚执行了第三个sprint,我都不敢想他们的coach帮提交的材料属于第几个sprint。资深agile coach嘛,当然是很神的人,什么奇迹不可能发生呢?至于你信不信,反正China Agile Conference信了。

  7. “中国ThoughtWorks某些咨询师们大多都比较敏感,都是坚定不移的敏捷信徒。你别说有不同观点了,你就问个有点疑问的问题,他们就敏感了,就要反驳或是教育你了。“—–深有同感。殊不知我是实际工作中总结出的方法,他是书本的教条主义,我对他笑笑,也就没说啥。

  8. TW的某些人,从来不懂得好好说话,只要一张嘴就先把自己摆在敏捷权威的位置上,从气势上取胜。然后就说一些模棱两可、貌似高屋建瓴的话。你说不对吧宏观上有没啥问题;你说对吧又空洞乏味等于白说。要么就是搬那几本书里的教条出来吓人。
    另外,动不动就是这个老师,那个老师,入行2,3年也敢出来咨询,也敢称老师,软文满天飞,让我这在开发一线干了11年的人情何以堪。
    敏捷方式是个好东西,但被一帮没脑子的、或为了商业利益而过度包装的人搞的臭大街了。

  9. 索林那瑞 :
    @陈皓
    我本人是目前在做产品方向(不敢称产品经理,自认为还离真正的产品经理远着呢,不够格),之前在互联网开源软件初创团队呆过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、楼主的批判文章,从长远来看,都是非常有里程碑意义的。这也是一种思想的迭代,螺旋上升式发展。当然,希望大家不要被概念、名相所迷惑而沉溺其中,那就成了实践敏捷过程中的炮灰了。)
    楼主的文章,我读着,有点像邓小平的”实践才是检验真理的唯一标准”这一思想理念。
    所以,不断练好内功,才是团队/企业的根本所在。做敏捷的主人,而非敏捷的客人。

    这个哥们说的在理,控制情绪,多做事情;不偏激,不盲从。。。好的东西也要经得起考验和不断成长

  10. 主要是TW这段,但凡在有实战经验,有成熟产品,知道自身总结演化的IT企业呆过的
    人,都知道TW中国是怎么一回事. 就像皇帝身边的仪仗兵永远不知道满身血污的的
    边疆军团是怎么穿着残破的装甲,拿着带缺的武器,却能像割麦子一样将敌人砍倒,
    不否定敏捷,也不否认TW里的有威望,有成绩的人,但是那满天飞舞的刚毕业的各种
    高级资深训练师咨询师,和张口闭口的敏捷,敏捷,就让人汗毛倒竖,呕吐不止.

  11. 不知陈皓博主是否严肃实践过TDD。我觉得对TDD的批评有些偏激了。毕竟提出这些概念的人都是从不敏捷的时代走过来的,对传统方法论和敏捷都有所认识。 虽然本人没用过TDD和其他任何敏捷实践,但是不排斥,并且很想尝试。

    看遗留代码的痛苦想必大家都经历过,有了比较完善的单元测试,能帮多大的忙啊! TTD至少可以解决个人英雄主义开发人员不写测试不写文档的问题。
    项目主要人员突然离职也很痛苦,特别是接手他工作的人。结对编程能解决这个问题。
    企业有太多的时间在打酱油,却怕实行结对编程浪费一倍的人力。。。

    敏捷至少我看来是开发人员友好型的方法论,而楼主所强调的个人英雄主义,恰恰是一个既得利益角度的言论。

  12. 楼主的观点我不大赞同。

    TDD我理解应该是分层次的,需求、设计、编码的人都可以以TDD的方式工作和协作,各个层次的人通过不同层次的测试用例表达了自己想要的是什么。因此,TDD不是一个人写了一堆测试代码然后以此驱动所有人干活。

    最早写出来的测试代码应该直接针对业务功能的,需求人员即使不能写也可以读一下这些测试代码,确认一下这些测试代码是不是代表了他们想要的业务功能特性。这些测试代码对应的是需求。

    为了实现这些功能,做设计的人会设计一些模块或者方法,这些模块和方法可能是他自己写也可能要求别人写,于是他又写了一些测试代码,用来表明他要求实现的方法是什么样的。这些测试代码对应的是概要设计。

    被要求实现这些方法的人,为此可能要再做一些更细致的设计(编码本来就是设计),如果继续用TDD的方法,那么他们也会写一些测试用例来检验自己的代码。这些测试代码对应的是一些私有方法和实现代码了,可以认为是单元测试或者白盒测试代码。

    另外说到方法和流程的问题,无疑项目是依靠人的,如果有足够的几个相互熟悉的牛人来,也许什么方法都不需要的。但现实情况下,每个项目你都得不到足够的牛人,你面对的就是一群资质很一般、经验很一般的普通人。即使你在google这类地方,我相信也是有少数人(通常这些少数人就是项目领头人什么的)认为其他大部分人相对他们面临的任务是笨蛋。搞出这些“方法”来,无非就是让一群普通人不至于弄出什么不好收拾的纰漏来,平安地把项目做完。

    东方文明与西方文明的差距越来越大,我认为根本原因之一是在于东方文明太不注意理论和方法的积累,感性、人治的成分为主。依靠明君能臣而不是依靠制度总不是很靠谱的事情。

  13. 有实践才有发言权,实证高于一切,拒绝极端和炒作,计算机科学和C & Unix哲学体系浩瀚如烟,本田宗一郎说现场有神灵。支持博主观点。 就像习武,要跟李小龙、叶问,不跟金庸。 :)

  14. @jackhuang
    应该说的是一个平衡的方法吧。
    当然有的要因势利导,有的原则还是要坚持的。
    楼主主要针对的是把教条当原则。

  15. 确实,没有万能的方法,在实践中积累出自己的一套才是真家伙。在经验不足的时候,就不要怕走弯路,花大量时间去干,想,再干。片面追求方法就是急功近利。

  16. 写得很好。软件=数据结构+算法,没有人说是软件=测试吧,测试用来控制质量的,跟设计有毛关系啊,没有设计,测个毛啊;TDD是test driven development,不是test driven design,TDD无非是把test和开发过程结合更紧密,保证各阶段的质量 – 设计的质量,你和你同事代码的质量,软件的质量。

  17. 一个【你好】和【您好】就立判高下。
    我是来挖坟的;-)从StartupNews看到一篇关于TW的文章然后经过Google就到这里来了

  18. 大赞:

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

    无论是敏捷还是传统的软件工程模型,都完全避而不谈/或者很少提及适应的场景/对人员的要求。这都是典型的以方法论为中心的论调。

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

    TDD是为了理清和用户/其他开发人员的接口,即整体的设计目标,可以尽量避免因为早期的沟通不足导致的问题(很多程序员都有拿到需求也不问是否合适甩开膀子就干,最后发现和其他人的工作根本衔接不起来的问题)。

    这是一种自顶向下的设计/开发理念,好处是可以尽快的让使用者看到一个产品的雏形,也就是可以帮助用户发现/挖掘他们真实需求的一种方式。

  20. 张凯峰好搞笑,他说自己是“InfoQ中文站的主编”。他组织这个虚拟讨论会后一个月就去thoughtworks当咨询师了。哈哈。

  21. 哈哈哈。耗子哥真是性情中人。说得好。
    从我个人实施Scrum的经验来看。个人感觉Scrum实施的是否好在于是否有一个好的Scrum Master。
    我们使用敏捷实施了3个项目。
    第一个失败了,原因是项目经理认为自己可以兼Scrum Master的职位,而且并不理解Scrum。结果是做成了一个四不像,大家觉得Scrum没啥用,所以后来又成了习惯的瀑布式。
    第二个执行的不错,原因是有一个严格的并且理解Scrum的Scrum Master。他会不断的指出项目组的错误之处,也会经常跟项目经理对着干(项目经理跟Scrum Master不能是同一个人,否则就没有反对意见了)。同时,Scrum Master对Scrum的理解也在不断的加深,他自己也随着项目组一起成长。我认为这是一次好的实践。我们在Scrum的实施中得到了确实的好处,也得到了很多欢乐,比如用打牌来确定Story Point。
    第三次又失败了。我们换了一个Scrum Master。他也不是很懂Scrum。所以项目管理也越来越水,导致大家觉得有没有Scrum跟瀑布没啥区别。在这个项目中,我只能在看到Sprint会议,Story Point的时候会让我想起Scrum。其他部分跟瀑布没区别。

发表回复

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