敏捷-意淫者的天堂

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

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

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

评论

70 楼 sslaowan 2007-12-18  

<p>

抛出异常的爱 写道

。。。。误会了。。。

</p>
<p>    呵呵，我是在实践中发现让本身不喜欢编程的人写单元测试真是痛苦，虽然我自从用上了TDD就再也不愿意回到过去了</p>
<p>   等等事情多了，所以看到您的观点大有同感</p>

69 楼 抛出异常的爱 2007-12-18  

。。。。误会了。。。

68 楼 sslaowan 2007-12-18  

<p>

抛出异常的爱 写道

你的观点是什么？

</p>
<p>  其实我引用你的观点就是因为赞同你的观点，你最初不是说“这些实践需要动力”吗？我理解的动力就是说我们对于编程的热爱，对于事业的责任心，解决问题的热情，所以我后来才说，没有这种动力，再好的实践也不确保成功，这和gigix所抱怨的客户总问他是不是使用敏捷就一定成功？的说法也是一致的，成不成功还主要依赖于人的态度。</p>
<p>   人们说瀑布模型不好，但瀑布模型有没有成功的应用，肯定有；说XP好，失败的例子也一堆。</p>
<p>   关键在于人，这不是大家的共识吗？</p>
<p>   看微软的人写的一本书，说软件开发很简单，就是几个热爱编程的高手用他们认为最有效的方法编程。这当然有些片面，不过也从侧面说明了：需要有热情，责任心，敏捷的态度，有问题赶紧解决，别拖。</p>
<p>   不知道为啥您能推导出两个凡是，我只是就着您的观点补充了一些，是我理解错了？</p>
<p>      </p>

67 楼 抛出异常的爱 2007-12-18  

你的观点是什么？

66 楼 sslaowan 2007-12-18  

<p>

抛出异常的爱 写道

引用

我觉得最重要的是敏捷的态度（上次在JavaEye上写过一篇敏捷最重要的是价值观），懒人、或者没有对工作那份热情的人是敏捷不起来的，gigix说的减少浪费是一方面，另外敏捷的主义就是勤快，积极主动，以事实求是的态度去做事情。敏捷实践的作用一方面是告诉聪明的人如何去做，强迫懒人们去做（做总比不做强）。 有三本书让我看了巨震撼，一本是Kent的《解析极限编程：拥抱变化》，一本是讲通用电气前CEO杰克·韦尔奇的《赢之道》，一本是IBM前CEO郭士纳写的《谁说大象不能跳舞》。之所以震撼，是因为我发现三本书中出现的促成成功的活动和态度竟然是相同的，而且用词都一样。比如Kent的书名就是拥抱变化，而《赢之道》中韦尔奇经常跟员工说的话就是市场再变，变化是正常，不变是异常（市场再变，商务再变，支持商务的软件自然要变啊），而且变化非常之快，必须作出快速反应。再举个例子，三本书中都讲到要深入基层，郭士纳说，很难想象如果一个CEO不跑遍IBM所有的子公司，如何发现问题。 说XP很难推广的真正原因在于：太多的不爱软件开发的人混迹在IT行业，Team Leader，开发者都太懒，遇到问题想得不是马上解决，而是得过且过。建筑行业那么悠久的历史，那么严格的有国家标准和力学理论支撑的行业，你去建筑工地看看，想要快速完成任务还不得有人一直盯着，呼喊着，引领着大家干活。 说实在的，在好的方法，一帮得过且过的懒人使用，也做不出好项目，而使用不好的方法，结果就更糟糕而已。

1.凡是成功人仕强调的，都是好东西。 2.凡是好的东西没人用，都是由于用的人差。 我在建筑业干了也不短的时间，想要快速完成任务，所需要的是增加工人，延长工作时间，呼喊着引领大家干活这种事我是不敢亲力而为的。 PS：两个凡是得出一个结论，你没成功的话，都是由于你RP差。

</p>
<p>         当你发现，在很多行业，用了相似的理念或方法都取得了成功，那么是不是该思考一下他们的共性呢？敏捷联盟的出现，不就是因为XP，Scrum之类的方法的领导者发现了他们的方法论之间的共性吗？精益制造不就是不同行业发现的共通成功原则吗？</p>
<p>         我所举的例子，只不过是不同行业成功者的典范而已了，起码我看过大多数案例领导者都是这样的。</p>
<p>        另外我从来没说过你勤快，不偷懒，积极去做，就一定会成功（虽然那些成功的人都这么说自己，最大的优点就是一条道跑到黑），不成功的因素多了去了，比如政治，自然力……但是领导者个人因素当然也占很大比例。</p>
<p>       当然你可能偷懒，不积极去做也可能成功。</p>
<p>      因为这东西不是数学，不是充要条件。</p>
<p>        在建筑行业你不是做工头吧，如果不是工头当然不用你亲力亲为那些事情，我父亲就是建筑工程师，他在现场，但是也不需要整天呆在太阳地儿底下喊工人干活啊。话说回来，建筑行业分工太细致了，软件业根本达不到。现场不控制，从两头挖地下通道结果最终合不上的事情您听说过吧；工程师不在现场看着工人按图纸施工，最后把大门方向弄错的事情您听过吧。（北京测绘局的朋友跟我讲的上面两个例子；第一个例子我父亲也跟我说过类似的）</p>

65 楼 抛出异常的爱 2007-12-18  

引用

       我觉得最重要的是敏捷的态度（上次在JavaEye上写过一篇敏捷最重要的是价值观），懒人、或者没有对工作那份热情的人是敏捷不起来的，gigix说的减少浪费是一方面，另外敏捷的主义就是勤快，积极主动，以事实求是的态度去做事情。敏捷实践的作用一方面是告诉聪明的人如何去做，强迫懒人们去做（做总比不做强）。

       有三本书让我看了巨震撼，一本是Kent的《解析极限编程：拥抱变化》，一本是讲通用电气前CEO杰克·韦尔奇的《赢之道》，一本是IBM前CEO郭士纳写的《谁说大象不能跳舞》。之所以震撼，是因为我发现三本书中出现的促成成功的活动和态度竟然是相同的，而且用词都一样。比如Kent的书名就是拥抱变化，而《赢之道》中韦尔奇经常跟员工说的话就是市场再变，变化是正常，不变是异常（市场再变，商务再变，支持商务的软件自然要变啊），而且变化非常之快，必须作出快速反应。再举个例子，三本书中都讲到要深入基层，郭士纳说，很难想象如果一个CEO不跑遍IBM所有的子公司，如何发现问题。

     说XP很难推广的真正原因在于：太多的不爱软件开发的人混迹在IT行业，Team Leader，开发者都太懒，遇到问题想得不是马上解决，而是得过且过。建筑行业那么悠久的历史，那么严格的有国家标准和力学理论支撑的行业，你去建筑工地看看，想要快速完成任务还不得有人一直盯着，呼喊着，引领着大家干活。

     说实在的，在好的方法，一帮得过且过的懒人使用，也做不出好项目，而使用不好的方法，结果就更糟糕而已。

1.凡是成功人仕强调的，都是好东西。
2.凡是好的东西没人用，都是由于用的人差。

我在建筑业干了也不短的时间，
想要快速完成任务，
所需要的是增加工人，
延长工作时间，
呼喊着引领大家干活这种事我是不敢亲力而为的。

PS：两个凡是得出一个结论，你没成功的话，都是由于你RP差。

64 楼 sslaowan 2007-12-18  

<p>

抛出异常的爱 写道

我作监理时如果用了你的理论。。。。我真不知道13号线能不能运人。。。。 楼上是两个凡是，加上想当然。

</p>
<p>   我的理论？两个凡是？想当然？</p>
<p>   不明白你的意思。</p>
<p>   1、 这也不是我什么独到的观点，我看过所有的敏捷方面的书、资料和访谈，软件行业的，商业的都是这样的。</p>
<p>   2、哪两个凡是？凡是成功的项目都依靠敏捷，凡是敏捷的项目都会成功？不会吧，我是反对这种说法的，成不成功依赖于人，我已经说得很清楚了</p>
<p>   3、大家的经历不同吧，不过从我的经验来讲，做企业级开发就是“不以善小而不为，不以恶小而为之”。我不太觉得自己是想当然，因为我遇到太多次不做好（什么是好依赖于个人判断，总有些人能够作出恰当的决策）计划和控制的（长期的远景目标——是否有效决定于你个人眼光，比如比尔·盖茨的眼光就很好；短期的随时改变的小计划；控制比计划更重要）造成的失败了，拆东墙补西墙。</p>
<p>        这事没啥好说的，做到的人说这样做行，做不到的人说这样做不行。</p>

63 楼 抛出异常的爱 2007-12-18  

我作监理时如果用了你的理论。。。。
我真不知道13号线能不能运人。。。。

楼上是两个凡是，加上想当然。

62 楼 sslaowan 2007-12-18  

<p>[quote="抛出异常的爱有些实践说起来轻松但是这些实践需要的动力也非常的高。 PS：XP现在在中国还太另类，很难推广。</p>
<p> </p>
<p>       我觉得最重要的是敏捷的态度（上次在JavaEye上写过一篇敏捷最重要的是价值观），懒人、或者没有对工作那份热情的人是敏捷不起来的，gigix说的减少浪费是一方面，另外敏捷的主义就是勤快，积极主动，以事实求是的态度去做事情。敏捷实践的作用一方面是告诉聪明的人如何去做，强迫懒人们去做（做总比不做强）。</p>
<p>       有三本书让我看了巨震撼，一本是Kent的《解析极限编程：拥抱变化》，一本是讲通用电气前CEO杰克·韦尔奇的《赢之道》，一本是IBM前CEO郭士纳写的《谁说大象不能跳舞》。之所以震撼，是因为我发现三本书中出现的促成成功的活动和态度竟然是相同的，而且用词都一样。比如Kent的书名就是拥抱变化，而《赢之道》中韦尔奇经常跟员工说的话就是市场再变，变化是正常，不变是异常（市场再变，商务再变，支持商务的软件自然要变啊），而且变化非常之快，必须作出快速反应。再举个例子，三本书中都讲到要深入基层，郭士纳说，很难想象如果一个CEO不跑遍IBM所有的子公司，如何发现问题。</p>
<p>     说XP很难推广的真正原因在于：太多的不爱软件开发的人混迹在IT行业，Team Leader，开发者都太懒，遇到问题想得不是马上解决，而是得过且过。建筑行业那么悠久的历史，那么严格的有国家标准和力学理论支撑的行业，你去建筑工地看看，想要快速完成任务还不得有人一直盯着，呼喊着，引领着大家干活。</p>
<p>     说实在的，在好的方法，一帮得过且过的懒人使用，也做不出好项目，而使用不好的方法，结果就更糟糕而已。</p>

61 楼 tcmak 2007-12-18  

抛出异常的爱 写道

引用

所谓好的方法，就是做到能做到的，知道不能做到的

是啊，有些实践说起来轻松
但是这些实践需要的动力也非常的高。

PS：XP现在在中国还太另类，很难推广。

最好的方法, 從客戶的角度是為他們帶來最大的利益, maximise 他們的 ROI.

實踐動力, 很依靠隊伍和公司對於改善生產力的追求和決心. 敏捷方法的起源都是因為他們經過很多次的失敗經驗中而取得的.

在面對如何從錯誤中學習之前, 首先處理的是面對錯誤及對工作熱誠方面的問題, 有些可能根本不會去檢討項目失誤. 之後才是有沒有決心去改善的問題, 改變慣常工作模式阻力很大, 像我們去客戶引進新的系統一樣, 他們也會有阻力的, 改變隊伍和公司組織也會有阻力. 我可以慚愧地說, 我早幾天參與 Barcamp 活動時發現敏捷原來對很多人還是一個新的東西.

PS: 敏捷本身的概念都是很 "另類" 的....e.g. self-organisation, active stakeholder participation... 等等....

60 楼 抛出异常的爱 2007-12-18  

引用

所谓好的方法，就是做到能做到的，知道不能做到的

是啊，有些实践说起来轻松
但是这些实践需要的动力也非常的高。

PS：XP现在在中国还太另类，很难推广。

59 楼 gigix 2007-12-17  

引用

不喜欢gigix的工作方式，
总把自己的方法吹上天，

我能理解
因为不同的人对所谓“好的方法”理解不同

按照我的理解
所谓好的方法，就是做到能做到的，知道不能做到的
而很多人认为好的方法就是什么都能做到，所以误会就来了

另一方面，我不认为有一种最好的方法
我做事的方法是在不断改进的
所以任何时候我总是认为自己的方法是最好的
因为如果有更好的，那么我就已经改进了
不理解这一点也会造成误会

58 楼 dearwolf 2007-12-17  

抛出异常的爱 写道

敏捷很多的心思都用在了减少风险上面
敏捷所对应的是变更所带来的长时间DEBUG
无论是XP还是FDD

不喜欢gigix的工作方式，
总把自己的方法吹上天，
让人误以为敏捷是一切。

所以有开始的一问。

很奇怪异常怎么会有这样的感觉，透明什么时候这样子宣传过敏捷了？

另外，“敏捷所对应的是变更所带来的长时间DEBUG”——这句话又是由何而来的呢？

57 楼 抛出异常的爱 2007-12-17  

敏捷很多的心思都用在了减少风险上面
敏捷所对应的是变更所带来的长时间DEBUG
无论是XP还是FDD

不喜欢gigix的工作方式，
总把自己的方法吹上天，
让人误以为敏捷是一切。

所以有开始的一问。

56 楼 gigix 2007-12-17  

pythonjyc 写道

敏捷 真有那么敏捷么？
不要自己砸了自己脚，老板认为敏捷估计一天让你项目做完，你说完不了，老板又说了，你不是敏捷么，敏捷不是速度快么

做不到就是做不到，没有什么不好意思承认的
我从来不敢说什么敏捷了就可以做得快，敏捷了就一定保证交付之类的大话
谁跟你说了这些话，你就让他上，看看结果会怎么样好了

展开一点说，承诺就意味着责任，谁承担责任谁就要管理风险
不管作为开发者、项目经理还是咨询师，如果我做这种承诺，我是负不起这个责任的
最后承担责任遭受损失的还是这个老板自己
所以如果他是一个明智的老板，他就不可能来跟我要这种承诺，因为我承诺了也没有用
这就跟敏捷不敏捷没关系，只是一个风险管理的常识

55 楼 pythonjyc 2007-12-17  

敏捷 真有那么敏捷么？
不要自己砸了自己脚，老板认为敏捷估计一天让你项目做完，你说完不了，老板又说了，你不是敏捷么，敏捷不是速度快么

54 楼 gigix 2007-12-17  

yiding_he 写道

我只知道敏捷对人的要求很高的。不论是思维方面还是表达能力，有缺陷的话效率就低了，就敏捷不起来了，最后还是只能回到一大堆文档的书面沟通方式上。所以以为搞技术就可以回避交流能力不好的缺点，这样的看法迟早要吃苦头的。

至于敏捷能不能提高人的素质，这个太……我是想象不出来。

问题1，能力不足的团队或者个人，放在别的方法底下就能效率高吗？
问题2，团队或者个人的缺陷，你希望早发现还是晚发现？

53 楼 yiding_he 2007-12-17  

我只知道敏捷对人的要求很高的。不论是思维方面还是表达能力，有缺陷的话效率就低了，就敏捷不起来了，最后还是只能回到一大堆文档的书面沟通方式上。所以以为搞技术就可以回避交流能力不好的缺点，这样的看法迟早要吃苦头的。

至于敏捷能不能提高人的素质，这个太……我是想象不出来。

52 楼 fourfire 2007-12-14  

务实为主吧

51 楼 jaul 2007-12-11  

偶的意见：

软件开发具有“波粒二象性”，首先是工程的”波性“，其次才是工艺上的“粒性”。
”波性“即管理，整体的管理还是需要一个明确的能上纲上线的过程来管理；
”粒性“即团队个体的素质，局部的工艺需要有素质的人去保证。

可以在这两个特性上加权，得出你的软件成果。
下面给出公式：

软件成果的质量 × X% = 过程管理×Y% + 员工个体水平×Z%

请对号入座，看你怎样填充Y，Z那你就能得到怎样的X。

说白了，不能抽象出适合自己的管理过程，一是管理者的无知无能，二是管理者的懒惰；