读后感 (I) 驱动和责任

我觉得您好象没有明白我的意思。
我说的“即插即用”，指的并非在标准化方法下实现的“即插即用”，而是在冗余的方式来实现即插即用，也就是说，团队当中的个人可以随时离开，但是这个个人的离开并不会改变团队的知识结构，也就是说离开的这个人所掌握的能力被冗余到了其他人身上，这当然也可以包括打交道甚至是“潜规则”。这是另一种增加团队鲁棒性的办法。

很多很有意思的观点，先谈一个：

>其实我更喜欢主刀的医生是一个“即插即用”的

我敢拿你的生命来打赌，你不会更喜欢的。
我们假设你要做一个小手术，在医院住了两天，和主刀医生已经打过几次交道，双方并且可能还“潜规则”了对方...
然后你躺在手术台上，麻醉剂开始起作用，恍惚中，你注意到上台的是一个陌生的医生， 他一边听护士对你病情的剪报，一边对你说 - bigboss，别担心，我是即插即用的。
这时候你会怎么想呢?

最喜欢“即插即用”的，是在"红海"中的企业，他们竞争的主要方式是价格。 一个卖快餐的全球企业公开说，他们希望他们的员工不需要任何培训，就可以即插即用地开始工作。

其实我更喜欢主刀的医生是一个“即插即用”的，这样问题到解决了，任何人都是不重要的，同样任何人也都是重要的。我大胆的预测一下，您似乎对现有的软件工程中的开发方法比较欣赏啊，呵呵。

其实软件开发最早的模式应该是“自己自足”模式，所谓“主治医师/手术台”模式只是“自己自足”模式的变种而已。“自己自足”的模式的优点是，自己需要什么自己都知道，而且自己有非常擅长利用各种技术来实现自己所需要的东西。但是“自己自足”的模式无法回避一个问题：如果我需要一个我不擅长的技术怎么办？主治医师/手术台”模式中，假设的是主治医师什么都懂，经过了长期的检查，细致的准备和规划。这个假设是不是有点苛刻了？如果主治医师对全局缺乏足够强大的掌控力，那怎么办？

模型很多时候都是理想的，是对现实的简化，而现实往往要残酷很多。往往理想模式给出一个苛刻的条件，然后在给出一种方法，在满足苛刻的条件下，按照方法就可以达到目的。现实往往是，我们没有达到苛刻条件的能力，我们也要达到相同的目的，怎么办？
现代的软件开发规模越来越大，各种工作分类越来越具体化，这使得很难在好到一个理想的对全局有足够掌握力的人。这就好象在几十年之前，人们认为瀑布模型是他们的救星，结果实现证明了，不可能有人在最开始把一切都能规划好，瀑布模型甚至连最开始的需求获取部分都很难做好，所以才出现了后来的原型法，迭代模型等。最开始，大家都不喜欢变化；而到今天，是行业的发展使得所有人不得不去拥抱变化，甚至不得不去期望在早期变化来得越多越好。

温伯格在90年代之前做的统计结果，软件开发的成功率大约是30+%；就前几年，又有人去做了统计，发现还是30+%。要知道，这么多年，我们经历了CMMI，UML，UP，XP，敏捷，结果没有明显的效果。这仅仅是责任的问题？那么这又如何解释那么多成功的开源项目？我想这只能解释为我们沿用的开发方法存在根本上的问题，也就是瀑布模型存在的问题一直被继承到今天也没有被解决。

另：标准化是否要执行，看的是标准化所需要达到的目的。如果标准化模块不是增加团队鲁棒性的唯一办法，甚至存在新的办法在其他方面有更好的效果，标准化模块很可能就被淘汰掉或者没有向现在这样那么的被重视了。比如，如果每一个人都在项目开发过程中逐渐变成了多面手，那么标准化真的就那么的重要吗？
其实很多时候，多去了解一下敏捷方法背后的含义和作用，还是蛮好玩的。

我对于奥匈帝国不了解。

你的观点给我一些启发，先草草写几条：
1) 没有唯一成功的模式，软件团队很早以前就有“主治医师/手术台”模式，主刀医生对问题的关键非常了解，非他动手不可，其他的人员（麻醉，护士）也确一不可，但是他们的目的就是让主刀医生专注于解决问题。 如果你是一个病人，你希望上台主刀的医生是一个“即插即用”的么？

2) 3人一组 - 很像 Jazz 的小乐队。 如果我们比较交响乐团/民乐团的演出， 和 Jazz 乐队的演出， 我们会发现有很多不同。
你的项目，是交响乐，还是Jazz?

3) 技术可以分两种 sustaining technology, disruptive technology. (参见 innovator's Dilemma)

如果技术处于 sustaining 阶段，这时的竞争从 features, reliability, convenience, 转移到 price. 这时候，标准化很重要。 如果你的项目是写一个内容网站，千万人都已经做过的事，你考虑的重点是。。。

如果是disruptive technology, 例如全新的人机界面，多点触摸的手机， 你考虑的重点也不同。

就先写这么多。

我知道您说的这个问题,这个是从奥匈帝国横扫欧洲起就被开始奉行的模式,现在也有很多人还很崇拜这个思想.但是现在也确实存在一些思潮在反思这个问题.

1.在敏捷运动中,很多地方在打破这个思,团队的中心化现象会越来越严重,新人加进去的话会需要更多的努力.结对编程增加了团队队员的可替代性,但是这是通过冗余的方式来增加的安全,以及辅之以一套对内开放的学习环境,而非传统的那种新人可以随意替代旧人的方式.

2.http://yeka.blogbus.com/logs/36765121.html
这篇任正非的讲话,在一定程度上也对传统的那种组织结构进行了否定."前线3人一组，包括一名信息情报专家，一名火力炸弹专家，一名战斗专家。他们互相了解一点对方的领域，紧急救援、包扎等都经过训练。"达到这种级别,新人真的很容易接手吗?

3.在<设计心理学>里面,提到了,万不得已,不要使用标准化.


PS:谢谢您的 读后感 (II) ,那篇关于交流的内容给了我很多的灵感,提示了我以前一个我一直 没有考虑到的地方.

>将人向插件一样直接插进来就用，这是否不够人性化？

老板希望员工都是可以替代的，标准化的模块，代码风格，文档，都为了后面的人可以很快接上手。

“先进软件开发模式”是个很模糊的概念，因为CMMI本身也承认，就算达到了5级，也不能保证就能开发出好的软件，1级也不是说就不能开发出好的软件。当然还有更激进的，温伯格自己定义了一个0级，这个0级到貌似是最好的。
　　
关于后面两个，说一下我个人的观点
　　
驱动是否是不可替代的？或者说，相对于FREE来说，利益驱动是否就是唯一不可替代的？学习敏捷，利用小迭代来增加成就感的次数，是否同样的也有效果呢？我一直在考虑这个问题，在敏捷方法中，究竟是因为小迭代缩短了每次开发的时间，减少了躲猫猫的时间；还是说因为小的迭代增加了开发人员的成就感次数；又或者两者都有呢？
进而，我也一直在怀疑，是否传统的软件开发方法，忽视了对人的重视，而过多的考虑了去建立一套结构和制度，妄图将人向插件一样直接插进来就用，这是否不够人性化？