敏捷-意淫者的天堂

看了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人必须要做的，却又最容易迷失的本质。

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

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

评论

50 楼 dualface 2007-12-10  

gigix 写道

dualface 写道

前不久客户拿了一个印度团队做了一年的项目给我们，希望我们优化性能。
我们简单看了一下，发现性能瓶颈都是在一些很细节的地方。比如每次显示页面，都用 gd 来获得图片大小然后输出给 <img> 标签；或者模板每次都从数据库读取之类的。再细看代码，也是很凌乱的。并不是吹的那样如何如何好。

我始终认为，软件开发仍然是手工活。虽然可以用过程来规范整个流程，但是具体到实现上，开发人员的个人素质才是最主要因素。开发人员的素质不高，再好的管理也做不出好的软件，只是降低了失败的机率。
不过问题就是合格开发人员根本不够。大部分都是为了混口饭吃，只知道 copy & paste 的人。这些开发人员不会去想怎么把细节实现得更好，只知道把已有的东西修修改改完成任务就 OK。

曾经尝试过把一些常见问题的解决方案整理成文档，让开发人员来照着做。这一步确实很有效，问题是大部分人不会举一反三，只会问：这个问题没说过，怎么做呢？

所以代码工厂的模式拿到中国来，一样没法产生高质量的软件。

关于过程和方法，有一点特别常见的误解
很多人以为，只要有一个好的过程，那么不管什么样的人只要稍微培训一下塞进来就可以做出好的软件了
过程不能解决问题
好的过程让问题比较快暴露出来，坏的过程把问题掩盖起来很久之后才发现
但问题仍然是问题
想靠过程解决问题，在建筑工地也许可以（也未必，毕竟我不了解这个行业），在软件业是不可能的

过程不能解决问题
可惜现实就是很多人都是这样认为的。不但过程被当作了万灵药，就连一项技术、一个框架也被期望能够拯救一切。

我认为软件工程和建筑工程最大的区别就是建筑工程的所有建筑材料都是工业化生产的，可以按照一个标准来规范。
而软件的每一个组成部分都是手工打造，同一个问题在10个人手里就有10种解决方法。
虽然从很小的一个组成部分看，也许这种差异并不大。但足够多的差异累计起来，就让不同团队开发出来的软件有巨大差距了。

49 楼 hyhongyong 2007-12-10  

ozzzzzz 写道

敏捷宣言里面说，个体与交互胜过过程和工具。如果敏捷也是一个过程，那么就是说个体与交互胜过敏捷和敏捷工具。

应该如此吧，说明软件开发更多的是要依靠人的主观能动性，而不是工具。

48 楼 ozzzzzz 2007-12-09  

敏捷宣言里面说，个体与交互胜过过程和工具。如果敏捷也是一个过程，那么就是说个体与交互胜过敏捷和敏捷工具。

47 楼 gigix 2007-12-09  

yeshucheng 写道

最终预期或者说期望的结果，无论是客户还是开发商，大家想法都是都是一致的。但是敏捷难道不是一个过程的手段吗？

期望肯定是有很大的空间的，不然也不会一直强调客户期望管理。我随便举个例子，不止一家公司打电话跟我们说，他们下一个项目时间紧任务重所以希望用敏捷方法来确保按时按量交付，问我行不行。你说我怎么答？我就只有设法调整他的期望，让他明白项目的难度在哪里，使用敏捷的风险和收益是什么。这经常是个很费劲的说服过程，但如果让他抱着这样的期望去开始项目，他最后有非常大的可能会非常失望，对ThoughtWorks的服务和对敏捷方法。而那些宣称敏捷无所不能、任何问题都可以在敏捷里找到解决办法的人，无疑是在给我的说服工作添乱，让我需要费更多的劲来调整（潜在）客户的期望，所以我很敬畏这些看着像教主、大神的人物。

46 楼 yeshucheng 2007-12-09  

最终预期或者说期望的结果，无论是客户还是开发商，大家想法都是都是一致的。但是敏捷难道不是一个过程的手段吗？

45 楼 gigix 2007-12-09  

Godlikeme 写道

gigix 写道

Godlikeme 写道

很好奇的问一句，
谁说过 过程能够解决所有问题？

凡是认为“因为我有CMM x级认证所以我做的软件一定好”的人

不是很明白为什么会有人这么想，
过程不是CMM X特有的，，敏捷也强调过程，
从没有见过哪个官方提到过 过程能够解决所有问题。

因为我们敏捷 所以我们能够把软件做好？
这样说可以么？

我最怕的就是（潜在）客户有这种想法
这是一个过高的期望
而我就不得不花大量的时间和精力去打消他这个想法
不然我就会把自己放在一个危险的被过高期望的位置上
但确实有很多人当面或者在电话里跟我表达这样的想法
过去的一些从来没有被兑现的承诺把大家的胃口给吊了起来
没办法的事

44 楼 Godlikeme 2007-12-09  

gigix 写道

Godlikeme 写道

很好奇的问一句，
谁说过 过程能够解决所有问题？

凡是认为“因为我有CMM x级认证所以我做的软件一定好”的人

不是很明白为什么会有人这么想，
过程不是CMM X特有的，，敏捷也强调过程，
从没有见过哪个官方提到过 过程能够解决所有问题。

因为我们敏捷 所以我们能够把软件做好？
这样说可以么？

43 楼 gigix 2007-12-09  

ozzzzzz 写道

张敏捷在跟新他的文章。新的内容已经明确的说了，他的《敏捷》是查字典而不是来自《敏捷宣言》。这个问题，看看已经不需要太讨论。
而且他还进一步说，敏捷就意味着成熟，是在成熟基础上的。这个论断我不知道他是怎么证明的，而且在我看来敏捷就是在成熟和不成熟间进行不断的权衡调整，以便于从成熟走向不成熟，从不成熟走向成熟，这样一个循环过程。而进一步说，我认为一个组织的过程能力并不是在于其过程具有多大的成熟性，而在于其对于过程的变更具有更多的能力——过程能力强的组织必然更能不断的调整其流程，而不是等待过程的成熟。

这个，我随便引用一句话

引用

我们经常看到一些号称 Agile 的国内项目，按照菜谱、操作指南和教父语录的提示，采用了许多花哨的技巧和实践（做法），是啊，表面上确实 Agile 了，那么结果呢？项目还是不能按时完成，甚至严重超支和超时，这能叫“敏捷”吗？

这个我就不想多评论了。

42 楼 gigix 2007-12-09  

Godlikeme 写道

很好奇的问一句，
谁说过 过程能够解决所有问题？

凡是认为“因为我有CMM x级认证所以我做的软件一定好”的人

41 楼 ozzzzzz 2007-12-09  

张敏捷在跟新他的文章。新的内容已经明确的说了，他的《敏捷》是查字典而不是来自《敏捷宣言》。这个问题，看看已经不需要太讨论。
而且他还进一步说，敏捷就意味着成熟，是在成熟基础上的。这个论断我不知道他是怎么证明的，而且在我看来敏捷就是在成熟和不成熟间进行不断的权衡调整，以便于从成熟走向不成熟，从不成熟走向成熟，这样一个循环过程。而进一步说，我认为一个组织的过程能力并不是在于其过程具有多大的成熟性，而在于其对于过程的变更具有更多的能力——过程能力强的组织必然更能不断的调整其流程，而不是等待过程的成熟。

40 楼 Godlikeme 2007-12-09  

很好奇的问一句，
谁说过 过程能够解决所有问题？

39 楼 gigix 2007-12-09  

dualface 写道

前不久客户拿了一个印度团队做了一年的项目给我们，希望我们优化性能。
我们简单看了一下，发现性能瓶颈都是在一些很细节的地方。比如每次显示页面，都用 gd 来获得图片大小然后输出给 <img> 标签；或者模板每次都从数据库读取之类的。再细看代码，也是很凌乱的。并不是吹的那样如何如何好。

我始终认为，软件开发仍然是手工活。虽然可以用过程来规范整个流程，但是具体到实现上，开发人员的个人素质才是最主要因素。开发人员的素质不高，再好的管理也做不出好的软件，只是降低了失败的机率。
不过问题就是合格开发人员根本不够。大部分都是为了混口饭吃，只知道 copy & paste 的人。这些开发人员不会去想怎么把细节实现得更好，只知道把已有的东西修修改改完成任务就 OK。

曾经尝试过把一些常见问题的解决方案整理成文档，让开发人员来照着做。这一步确实很有效，问题是大部分人不会举一反三，只会问：这个问题没说过，怎么做呢？

所以代码工厂的模式拿到中国来，一样没法产生高质量的软件。

关于过程和方法，有一点特别常见的误解
很多人以为，只要有一个好的过程，那么不管什么样的人只要稍微培训一下塞进来就可以做出好的软件了
过程不能解决问题
好的过程让问题比较快暴露出来，坏的过程把问题掩盖起来很久之后才发现
但问题仍然是问题
想靠过程解决问题，在建筑工地也许可以（也未必，毕竟我不了解这个行业），在软件业是不可能的

38 楼 dualface 2007-12-09  

OneEyeWolf 写道

stevenwang 写道

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

印度人成本低，是因为人力成本低，都找些高中手，能不低吗，而不是生产效率和生产力，不过这几年也在上升当中，反倒中国的开发成本是越来越低了。这几年外包业发展很快，很多公司都酝酿着上屎，文思创新不是已经上屎了吗。

中国人创新不行，复制能力世界一流，大连外包软件园，现在天津滨海也成立一个以外包基地的软件园，你现在找工作试试，有没有感觉到到处都是外包公司。

别再拿印度当神了，都是一个球样。我在论坛当中看到，只要是外包员工，很少有人觉得爽的时候。

印度人写的代码，不过也是jsp, servlet满天飞，软件都是一行一行代码写出来，还经常自己造轮子，那球有什么代码工厂之类的。

改善我们开发、解决项目管理中的问题，就像调优一样，你得先找到瓶颈点，也就是问题的根源在那里，不是否定一切，从一个极端走向另一个极端。
在雷区当中，你怎么走，向那个方面走，都要踩地雷，敏捷在于实践，不在于忽悠。

前不久客户拿了一个印度团队做了一年的项目给我们，希望我们优化性能。
我们简单看了一下，发现性能瓶颈都是在一些很细节的地方。比如每次显示页面，都用 gd 来获得图片大小然后输出给 <img> 标签；或者模板每次都从数据库读取之类的。再细看代码，也是很凌乱的。并不是吹的那样如何如何好。

我始终认为，软件开发仍然是手工活。虽然可以用过程来规范整个流程，但是具体到实现上，开发人员的个人素质才是最主要因素。开发人员的素质不高，再好的管理也做不出好的软件，只是降低了失败的机率。
不过问题就是合格开发人员根本不够。大部分都是为了混口饭吃，只知道 copy & paste 的人。这些开发人员不会去想怎么把细节实现得更好，只知道把已有的东西修修改改完成任务就 OK。

曾经尝试过把一些常见问题的解决方案整理成文档，让开发人员来照着做。这一步确实很有效，问题是大部分人不会举一反三，只会问：这个问题没说过，怎么做呢？

所以代码工厂的模式拿到中国来，一样没法产生高质量的软件。

37 楼 dualface 2007-12-09  

gigix 写道

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

深有体会啊！
免费提供点意见，当你是绕着弯子骗钱！
给了钱再说，就当成金玉良言了！

36 楼 whale 2007-12-09  

引用

1.过于激进的进度计划，对于资源的规划，分配，都头脑发热，过于简单。

正身受其害...，觉得适量的任务对程序员最好～

35 楼 Godlikeme 2007-12-09  

说来说去还是 少谈些主义，多解决问题。
InfoQ上看到 敏捷的核心：消除浪费，走向精益
用四个字概括：提高效率。套用一些管理学的原理，算是一席空文吧。

34 楼 tcmak 2007-12-07  

stevenwang 写道

所以，一句话，代码工厂模式是最优秀的。

這一句話本身已經有問題, 至少我不相信有一個模式在任何情況環境下都適用.

BTW, "代码工厂" 是 "Software Factory" 嘛? 小弟中文不好, 請多多包涵.

如果是 "Software Factory" 的話, 那也可以做得很敏捷的, 所以也不用說它已經是 "最優秀" 而去排斥其他方法和思想.

其實我們聽很多什麼 A模式 B模式 C模式... 感覺都是從其他東西上拿比方, 其實製造業的最為多, 這我想起 software craftmanship  當中提到軟件開發像什麼的. 到目前我都是比較覺得軟件開發像吹玻璃多於玩具工廠.

33 楼 OneEyeWolf 2007-12-07  

stevenwang 写道

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

印度人成本低，是因为人力成本低，都找些高中手，能不低吗，而不是生产效率和生产力，不过这几年也在上升当中，反倒中国的开发成本是越来越低了。这几年外包业发展很快，很多公司都酝酿着上屎，文思创新不是已经上屎了吗。

中国人创新不行，复制能力世界一流，大连外包软件园，现在天津滨海也成立一个以外包基地的软件园，你现在找工作试试，有没有感觉到到处都是外包公司。

别再拿印度当神了，都是一个球样。我在论坛当中看到，只要是外包员工，很少有人觉得爽的时候。

印度人写的代码，不过也是jsp, servlet满天飞，软件都是一行一行代码写出来，还经常自己造轮子，那球有什么代码工厂之类的。

改善我们开发、解决项目管理中的问题，就像调优一样，你得先找到瓶颈点，也就是问题的根源在那里，不是否定一切，从一个极端走向另一个极端。
在雷区当中，你怎么走，向那个方面走，都要踩地雷，敏捷在于实践，不在于忽悠。

32 楼 daquan198163 2007-12-07  

gigix 写道

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

想点收藏，不小心点了引用

31 楼 gigix 2007-12-07  

tcmak 写道

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

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

我前一阵接受CSDN和InfoQ采访的时候就说过
敏捷的核心是消除浪费
所以如果你说现有的敏捷实践不适合你，那么你遇到的浪费跟别人不一样，你需要别的实践
但如果你说这种敏捷“文化”不适合你，那么就意味着
（1）消除浪费不适合你
或者
（2）你篡改了敏捷“文化”