敏捷-意淫者的天堂

看了infoq中文站的那篇敏捷之文，又顺藤摸瓜，找到了太极掌门人的网站，作为一个旁观者，仿佛看到两个下盲棋的高人，飘在空中，一个说“炮五平六”，一个说“马8进7”，杀的好不激烈，另有一群评棋之人，或指点，或赞同，或反对，好不热闹。

回到JavaEye,却更觉得这是块净地，务实求进，Pragmatic, 是我看到的JavaEye的风格之一。更觉可贵，也更希望保持下去。看到很多追求卓越的人努力的改进自己所在项目的软件过程，虽处在强大的官僚机器之下，力量弱小，却又像一群拓疆之士，在大雪迷漫当中，互相扶拥，奋力前进，自己身处于其中，似乎更加亲切。

软件开发本来就是一种抽象的过程，将现实世界的连续的东东，转化成离散的数字，这不可避免的要运用人的思维意识去做这个复杂的事情。那就不可避免的存在了意识膨胀，意识膨胀是管理者、经营者经常容易犯下的错误，不仅仅是IT，在IT当中，更盛行。人们越来越多的所求实际，人们也在努力的改善，避免出现，如“IT三大忽悠”，“皇帝的新衣”，“灯下黑”之类的错误。


意识膨胀，常常是我们长时间脱离实际，官僚，形式主义，再加上所决策、控制、工作之事物，本来就是抽象的东西，更加容易犯下错误，在决策时，容易产生错觉，以为所有的资源都在我的控制之下，对于资源的生产力，又过度放大，期望过高，对自己本身，又无限完美，是万物之神。

再加上每个人的能力都是有限的，所以要有分工，要有依赖，管理者不熟悉技术就要依赖于技术者，对于不熟悉的事物，思考过于简单，用自己的思维一刀切，来解决自己不熟悉、不了解也不打算去了解的事物、背景, 这种产生了意识膨胀。

一些体现如：
1.过于激进的进度计划，对于资源的规划，分配，都头脑发热，过于简单。
2.自己也做不好的事情，却以为别人能够做好。
3.自己能做好的事情，以为别人也能够做好
4.以为所有的问题，都是软件过程不好所造成的。
5.以为所有的问题，都是由于没有敏捷。
6.自己是锤子，其他人都是钉子，砸你没商量，用自己擅长的东西解决不熟悉的事情，如技术者，喜欢对管理说三倒四，却不愿意首先改善自己，管理者一有问题出现，就认为是沟通的问题，是软件过程出现问题。

7.过度抽象，喜欢用一些八股文之类的语言，或者火星语，去教训别人，去和别人去沟通毫不相关的问题，这是经常从事抽象工作的人（如consultant, architecture designer)所容易做的事情，所谓的架构、分布式、SOA、构架、敏捷、UP、RUP之类的，脱口而去，倒背如流，看了太极掌门人的文章，又长见识了，经常看到这样的形容词：“科学”。实际上人们的日常工作，和这些都八杆子都打不着。


上面的几点，不在于去针对谁，只是对自己的一个警醒。deliver result，result-oriented是老外的企业文化，我在GE公司的墙上，随处可以看到，这也是IT人必须要做的，却又最容易迷失的本质。

我也是在努力的少去这些之类的网站，埋头，多写些软件，少谈些主义，我看的文章多了，我就会产生幻觉，以为自己也可以做到，实事上不是。

有很多的好的东西，失去了它所必须的条件和环境，又没有足够的资源支持，不过是一坨屎而已。成熟的管理者在公司文化政治当中生存，总是避免激进，追求稳妥，作事先看看有没有足够的资源、背景，所谓天时、地利、人和，如果没有，那就闭嘴，而不是去大叫大嚷，搬石头砸自己的脚。

评论

30 楼 tcmak 2007-12-07  

第一眼看到什麼 "西式敏捷", "中西敏捷" 就覺得有問題....那會有 "京式敏捷", "滬式敏捷", "港式敏捷", "台式敏捷", "日式敏捷", 以至..."毛里塔尼亞式敏捷"?

敏捷開發不是文化上的問題, 所以我覺得一開始就說人家的是 "西式敏捷" 已經是一個問題.

RUP 從來都不是敏捷開發方式, 至少當初設計 RUP 的人沒有敏捷方的考慮... 如果以為并行工程就已經敏捷, 亦是很大的錯誤. 對於 RUP, 有人提出 AUP, 加入了敏捷的原素...

http://www.ambysoft.com/unifiedprocess/agileUP.html

文中還提到:

引用

中式敏捷的基本原则

1）反对封建主义，教条主义，官僚主义，形式主义和本本主义。
2）软件开发中，一定要坚持定性分析与定量分析相结合的原则。

反對教條主義的兩條教條.....暈到.

敏捷的來源是老莊... 也很搞笑, 如果說提老庄思想應用到敏捷開發上, 都還有可能說得通, Kent Beck 和 Ron Jefferies 有時候說話都很禪的. 他們都會看那些方面的書, 敏捷開發的確有其哲學性部份, 但認為敏捷的來源是老庄我覺得太過了, 至少我想老莊時候沒有軟件開發的考慮吧.

"中式敏捷" 的確有點不恰當, 如果有一天有人想到把儒家思想應該在軟件開發方面, 是不是不可以叫作 "中式敏捷"了?

XP 最不敏捷, 這點我不同意, 更不敏捷的 FDD 和 DSDM 都還算是敏捷開發的範圍. 所以 XP 最不敏捷我很不認同. 但更根本性的問題在於筆者提出的原因 - 因為最嚴格和規範, 無論什麼敏捷開發也好, 都有其法則, XP 有其法則, Crystal 也有其法則. 他們都很講求紀律. 對紀律的要求, 恐怕比 CMMI 裡提出的更要多. 雖然我不敢說我很了解這個 "中式敏捷", 但我想信原作者不會看到一個不講紀律的隊伍. 有固定的規範, 是使其應用性提高, 否則新手很容易無所適從.

還有, 我相信 Cockburn 不太熟悉道德經, 即使他會詩人, 也不一定就熟道德經, 印象中他說的最抽象, 最接近文中提出的 "中式敏捷" 的東西是 "守, 破, 離" 的概念, 但這是來源至日本的合氣道...

我相信修練 "中式敏捷" 的人可以升仙的機會比付運軟件的機會還大的, 哈.

ozzzzzz 写道

这篇文章很好的反映了一个现实的情况——
http://www.zhangxun.com/showdoc.aspx?sname=WhatIsAgile

这里张敏捷有几个观点很说明些问题。

1、agile是多样化的，而《敏捷宣言》不是敏捷的全部。
这个是自然了，有那么多方法都是敏捷旗下的。而一个短短的4条判断和一个小小的说明，不可能是敏捷的全部。但是这并不是说，你自己搞一套过程，因为敏捷宣言不能覆盖所有的敏捷活动，那么你这个过程就可以被认为是敏捷的了。
敏捷宣言是一个思想性的、纲领性的文件，其代表了敏捷方法的价值观和实施的原则性的指导。任何一种方法只要它想被认为是敏捷方法，就必须体现这个敏捷宣言的思想和原则，如果不能做到全部覆盖，但是至少主体和大部分应该是有这种体现的。这一点没有讲价钱的余地。
2.张敏捷第一次接触敏捷这个词是在1997年，那个时候敏捷方法还没有出现，也就是他所谓“西式敏捷”还没有出现。
其实这话很好的反映了张敏捷的观点，他是老敏捷了。不过我们回过头来看，敏捷方法在命名的时候曾经有过争论，由于一些人不喜欢“轻型”或者“轻量级”这个说法，经过讨论才使用了敏捷做命名。而如果当初轻型或者轻量级被通过了又如何？或者干脆那些人选择了比如“新方法”，“灵活方法”，这样的词汇又如何。难道这个叫“轻型方法”的东西，你说一句我是在1923年就在职业拳击的拳台上知道“轻型”的，就表示你真的很创新了吗？如果这样说，我93年出来的那家公司有点日本背景，不也讲过丰田方法吗？那是不是说我在93年就玩这个了呢？那么我才是老大啊！
我从来也不否认，并且可以说我很早就说软件工程上的敏捷并不是方法学家闭门造车的结果，是整个商业环境敏捷思想大潮的一个有机组成。柔性管理，面向流程管理，丰田方法，等等都是先在传统制造业流行开来的。这些实践无疑都是给软件敏捷提供了良好的背景和经验借鉴。但是软件制作有特殊性，其他方面的经验和方法不可能被直接的拿过来，而需要消化吸收和改造。那些方法无疑会给你一个良好的提示，但是绝对不能说因为我早就知道以至于你实施了那些东西，你就是软件上的敏捷了。
3。“RUP 不正是软件开发的并行工程吗？这不就是敏捷吗？”
RUP可以是并行的，也可以是串行的；它可以是敏捷的，也可以是不敏捷的。这一点难道还有必要再次拿出了讨论吗？而且这里有涉及到2的问题——这里的“敏捷”究竟是普遍意义上的敏捷，还是传统制作业上的敏捷，还是软件开发上的敏捷呢?显然那个时候敏捷方法联盟还没有出现，敏捷宣言还没有出现，敏捷方法这个词也没有出现，那个这个意思是不是说这里的敏捷就不能说是敏捷方法的敏捷呢？
4 当然我们可以看到，敏捷宣言产生前，敏捷的各种方法就已经出现，通过一次会议，大家普遍性的同意，在一个思想纲领下，这些方法是统一的。但是这显然是在这次会议以后才出现的软件敏捷的纲领，你可以使用这个纲领回过头来看你以前的实践。但是你不可能在这个东西没有出现前，就使用这个纲领来判断。
5 张敏捷说中式敏捷的来源是老庄（当然不是庄表为），我是没有看出来，这个说法的依据。

29 楼 gigix 2007-12-07  

stevenwang 写道

aninfeel 写道

终于看到一个头脑清醒有洞察力楼主了。

以目前软件业落后的管理模式来说，任何好东西，先进的东西都是邯郸学步。
日本，印度的模式比较适合我们，
用严格的软件工程的管理模式，限制住大家脱缰的思想冲动。
设计书写的就老老实实照做，比学什么敏捷之类的扯淡理论好多了。
美国的那种精英模式我们学不了，日本和印度也学不好。
我们都没有那种创新的土壤和厚重的科技兴国的技术氛围。
所以，一句话，代码工厂模式是最优秀的。

说真的，我现在听这种话都觉得挺无所谓的
你爱搞代码工厂你就搞去，搞成啥样跟我没关系，反正不花我的钱
等你有了毛病，等你出了钱，咱们再来谈怎么改进的事

我现在算明白过来了
温伯格《咨询的奥秘》那是真理
不给钱就不给意见
免费的意见，不仅没人领情，还总觉得你别有用心

28 楼 ozzzzzz 2007-12-07  

stevenwang 写道

aninfeel 写道

终于看到一个头脑清醒有洞察力楼主了。

以目前软件业落后的管理模式来说，任何好东西，先进的东西都是邯郸学步。
日本，印度的模式比较适合我们，
用严格的软件工程的管理模式，限制住大家脱缰的思想冲动。
设计书写的就老老实实照做，比学什么敏捷之类的扯淡理论好多了。
美国的那种精英模式我们学不了，日本和印度也学不好。
我们都没有那种创新的土壤和厚重的科技兴国的技术氛围。
所以，一句话，代码工厂模式是最优秀的。

扯淡的最佳模板。
我是想去做代码工厂，别人给我一堆东西，我照做就行。
问题是我的智商低于76的脑袋都想知道，谁能给我这些东西。从日本人哪里？日本人的程序员大量都是新手，老人都将近退休，他们能提供？从印度人哪里？印度人自己的成本比我们还低，为啥给我们？从美国人？美国人为啥不去印度，难道他们觉得中文好听？
俺智商太低，想不明白这么复杂的问题。

27 楼 stevenwang 2007-12-07  

aninfeel 写道

终于看到一个头脑清醒有洞察力楼主了。

以目前软件业落后的管理模式来说，任何好东西，先进的东西都是邯郸学步。
日本，印度的模式比较适合我们，
用严格的软件工程的管理模式，限制住大家脱缰的思想冲动。
设计书写的就老老实实照做，比学什么敏捷之类的扯淡理论好多了。
美国的那种精英模式我们学不了，日本和印度也学不好。
我们都没有那种创新的土壤和厚重的科技兴国的技术氛围。
所以，一句话，代码工厂模式是最优秀的。

26 楼 aninfeel 2007-12-07  

终于看到一个头脑清醒有洞察力楼主了。

25 楼 dearwolf 2007-12-06  

gigix 写道

引用

作为技术人员，说出这样话，或者那么想实际上处于无奈！

为什么？难道懂技术就一定要不懂人情世故？

是不是有些开发人员确实有这样的思想误区，一方面本身怯于或是不善于沟通交流，而又觉得做了这个行业以后，便可以一心搞技术、钻研，免去与人交往之苦了呢？

24 楼 gigix 2007-12-06  

引用

作为技术人员，说出这样话，或者那么想实际上处于无奈！

为什么？难道懂技术就一定要不懂人情世故？

23 楼 jelly 2007-12-06  

“敏捷”应该是我们的目的。
不一定要用“敏捷方法”才能敏捷。

你们知道我在说什么吗？我在说什么?

22 楼 roger51 2007-12-06  

不要抓狂，

不抛弃，不放弃，

21 楼 bookong 2007-12-06  

这个“张敏捷”和那个自称“哲学乌鸦”和黎鸣有点儿像哦，都是“做梦都想当宗师”的主儿

20 楼 stupitguy 2007-12-05  

一个字，好...观点比较全面...

19 楼 Protoss 2007-12-05  

不懂得人都比较喜欢跟风。估计以后手纸上都得印上敏捷。

18 楼 stevendu 2007-12-05  

为了敏捷而敏捷要不得，合适为好。

17 楼 bubble 2007-12-05  

OneEyeWolf 写道

一些体现如：
1.过于激进的进度计划，对于资源的规划，分配，都头脑发热，过于简单。
2.自己也做不好的事情，却以为别人能够做好。
3.自己能做好的事情，以为别人也能够做好
4.以为所有的问题，都是软件过程不好所造成的。
5.以为所有的问题，都是由于没有敏捷。
6.自己是锤子，其他人都是钉子，砸你没商量，用自己擅长的东西解决不熟悉的事情，如技术者，喜欢对管理说三倒四，却不愿意首先改善自己，管理者一有问题出现，就认为是沟通的问题，是软件过程出现问题。

7.过度抽象，喜欢用一些八股文之类的语言，或者火星语，去教训别人，去和别人去沟通毫不相关的问题，这是经常从事抽象工作的人（如consultant, architecture designer)所容易做的事情，所谓的架构、分布式、SOA、构架、敏捷、UP、RUP之类的，脱口而去，倒背如流，看了太极掌门人的文章，又长见识了，经常看到这样的形容词：“科学”。实际上人们的日常工作，和这些都八杆子都打不着。

先汗一下，7个体现至少有4个站不住脚啊

16 楼 gigix 2007-12-05  

引用

在中国搞好人际关系胜于一切

即便这句话是对的，那也不能忽视一个基本的事实即你不可能让所有人都爱你。如果你希望与一部分人搞好人际关系那么你就通常必须与另一部分人交恶，或者你就只能与所有人建立泛泛之交。
另：“搞好人际关系”不是和稀泥的万灵药，人际关系同样是有技术有策略的。

15 楼 ozzzzzz 2007-12-05  

gigix 写道

o6z很没劲
所谓逻辑推理是这样的一种东西：承认逻辑推理方法（譬如三段论之类）的人必定能从同样的前提推出同样的结论，不承认逻辑推理方法的人你必定无法说服他。
而张恂，难道你还认为他承认（或者具备）逻辑推理方法？

哈哈，我写这个本就不是针对某个人的。之所以拿张敏捷做靶子，仅仅是他位置比较好，或者说做法比较典型。我这套分析，其实是针对现在发生的一些事情的普遍总结梳理。只不过是借力打力，对一些人做法的不定名评论。
张敏捷究竟是不是敏捷，大家自然会有认识。我也没有兴趣搞张敏捷现象研究。我只不过希望推迟一点：“你敏捷，你一家都敏捷。”的出现罢了。

14 楼 gigix 2007-12-05  

o6z很没劲
所谓逻辑推理是这样的一种东西：承认逻辑推理方法（譬如三段论之类）的人必定能从同样的前提推出同样的结论，不承认逻辑推理方法的人你必定无法说服他。
而张恂，难道你还认为他承认（或者具备）逻辑推理方法？

13 楼 ozzzzzz 2007-12-05  

6

引用

按照中式敏捷理论的推断，XP 大概是所有西式敏捷方法中最不敏捷的一种，因为它具有最好的可操作性，定义得很具体、很细，在规范性、严格性方面恐怕不亚于 CMM 系统中的 PSP/TSP。XP1 中许多做法（practices）的设计是环环相扣、互为支援的，某个环节做不到就可能导致失败，或者给项目带来严重的风险。一个软件开发过程工艺模型刚性很强，必然会失去一定的灵活性和适应性。

这个很有意思，我记得当初我曾经说XP的纪律性很强，严格性也很强，是我见到的最严格的方法。当时gigix还为这个事情和张敏捷发生了口角。但是今天我们看，张敏捷至少承认XP，的规范性、严格性不亚于CMM系统下的PSP和TSP了。
而确实一个方法如果具有的针对性越强，是使用的范围就越是固定，也越是狭窄。这个是缺点还是优点呢？我看大多数情况下是优点，因为范围的固定，可以让你很简单的知道啥时候是可以，啥时候是不行的。而如果是一个适用于一切场景下的方法，那你要它又有什么用呢？仅仅是解决一下宗教信仰的问题罢了。
而一个方法的环节很紧密，大多数情况下也是好事情。因为如果这些环节都各自独立，那么还有什么必要把它们放在一起。而进一步说，如果一个环节的失败会导致整体的失败，那么就应该去找把各个环节分开，从而保证即使一个环节失败，那么整体也会成功，这样的时候这个可以失败的环节究竟还有必要存在于这个方法中吗？它是不是更应该是一个独立的实践，而不应该是这个方法的核心构成呢？而如果把所有的环节都可以替代，那是不是说这又是一个RUP式的方法框架，而不是一个方法呢？是不是说这个方法根本就没有核心构成也可以存在呢？
而又如何理解“XP 大概是所有西式敏捷方法中最不敏捷的一种”这个敏捷的意义呢？是说他不距离敏捷宣言要求的东西最远；还是说他灵活性最差，从而导致其在普遍意义上的敏捷方面最不好？我看答案是后者。不过作为一个专业人士，在这么关键的地方做调侃，玩文字游戏，而不加以说明，其治学态度和专业精神究竟是如何很值得我们去思考。
8 张敏捷其实自己已经很明白的告诉我们他的敏捷和敏捷方法的关系了。他一再用“中式敏捷”和“西式敏捷”强调他的方法同西方来的敏捷方法的差别，其实就是说他的敏捷并不是“西式敏捷”，也就是我们平时经常认为的敏捷方法的敏捷。可以他不断的说张敏捷的中式敏捷，和敏捷方法没有啥关系。这一点他还是足够的诚实。

至于后面他说的，啥中式敏捷的原则和基本理论，由于没有具体的内容作支撑，我觉得研究的价值很小。
不过他搞了一本书，在他的网站上可以看到草稿。我看了一下，内容很好地反映了他的认识，也就是中式敏捷只是西方敏捷方法和他把以前的CMM、RUP之类的嫁接，是一个混杂体，根本就既不是敏捷，也不是CMM，也不是RUP。这无疑让我想起国内做论文的，综述性文体。
最后给中式方法一个评价——很好，很强大。

12 楼 ozzzzzz 2007-12-05  

这篇文章很好的反映了一个现实的情况——
http://www.zhangxun.com/showdoc.aspx?sname=WhatIsAgile

这里张敏捷有几个观点很说明些问题。

1、agile是多样化的，而《敏捷宣言》不是敏捷的全部。
这个是自然了，有那么多方法都是敏捷旗下的。而一个短短的4条判断和一个小小的说明，不可能是敏捷的全部。但是这并不是说，你自己搞一套过程，因为敏捷宣言不能覆盖所有的敏捷活动，那么你这个过程就可以被认为是敏捷的了。
敏捷宣言是一个思想性的、纲领性的文件，其代表了敏捷方法的价值观和实施的原则性的指导。任何一种方法只要它想被认为是敏捷方法，就必须体现这个敏捷宣言的思想和原则，如果不能做到全部覆盖，但是至少主体和大部分应该是有这种体现的。这一点没有讲价钱的余地。
2.张敏捷第一次接触敏捷这个词是在1997年，那个时候敏捷方法还没有出现，也就是他所谓“西式敏捷”还没有出现。
其实这话很好的反映了张敏捷的观点，他是老敏捷了。不过我们回过头来看，敏捷方法在命名的时候曾经有过争论，由于一些人不喜欢“轻型”或者“轻量级”这个说法，经过讨论才使用了敏捷做命名。而如果当初轻型或者轻量级被通过了又如何？或者干脆那些人选择了比如“新方法”，“灵活方法”，这样的词汇又如何。难道这个叫“轻型方法”的东西，你说一句我是在1923年就在职业拳击的拳台上知道“轻型”的，就表示你真的很创新了吗？如果这样说，我93年出来的那家公司有点日本背景，不也讲过丰田方法吗？那是不是说我在93年就玩这个了呢？那么我才是老大啊！
我从来也不否认，并且可以说我很早就说软件工程上的敏捷并不是方法学家闭门造车的结果，是整个商业环境敏捷思想大潮的一个有机组成。柔性管理，面向流程管理，丰田方法，等等都是先在传统制造业流行开来的。这些实践无疑都是给软件敏捷提供了良好的背景和经验借鉴。但是软件制作有特殊性，其他方面的经验和方法不可能被直接的拿过来，而需要消化吸收和改造。那些方法无疑会给你一个良好的提示，但是绝对不能说因为我早就知道以至于你实施了那些东西，你就是软件上的敏捷了。
3。“RUP 不正是软件开发的并行工程吗？这不就是敏捷吗？”
RUP可以是并行的，也可以是串行的；它可以是敏捷的，也可以是不敏捷的。这一点难道还有必要再次拿出了讨论吗？而且这里有涉及到2的问题——这里的“敏捷”究竟是普遍意义上的敏捷，还是传统制作业上的敏捷，还是软件开发上的敏捷呢?显然那个时候敏捷方法联盟还没有出现，敏捷宣言还没有出现，敏捷方法这个词也没有出现，那个这个意思是不是说这里的敏捷就不能说是敏捷方法的敏捷呢？
4 当然我们可以看到，敏捷宣言产生前，敏捷的各种方法就已经出现，通过一次会议，大家普遍性的同意，在一个思想纲领下，这些方法是统一的。但是这显然是在这次会议以后才出现的软件敏捷的纲领，你可以使用这个纲领回过头来看你以前的实践。但是你不可能在这个东西没有出现前，就使用这个纲领来判断。
5 张敏捷说中式敏捷的来源是老庄（当然不是庄表为），我是没有看出来，这个说法的依据。

11 楼 mingo 2007-12-04  

OneEyeWolf 写道

多写些软件，少谈些主义

赞呀


一个企业如果摸索出很适合它自身的一套方案，可能不如正统的敏捷那样高效，也没有种种的“敏捷实践”，但确实很协调，很灵活，也相当的有效率，那么可以从某种程度上来说，也是满“敏捷”的