双倍赤裸裸的真理——评《软件工艺》

（1）找到合适的人；（2）给他分配合适的工作；（3）保持他们斗志昂扬；（4）保持团队凝聚。

经典。有人看过＜水煮三国＞这本管理类通俗读物吗，理念是相通的。第一点特别重要。“知人善用”不就是指这个吗？，所以一个团队它的领导者是关键，而这种“知人善用”领导者真可遇而不可求也。

凤舞凰扬
好象你不知道，ISO和6σ在软件工程方面基本上被公认是失败的，所以ISO才转向于SEI合作，MOTO也只是在服务和硬件部门小规模的去玩他们的黑带。
而更加让你不能想象的可能是CMM更加强调个人英雄主义，这就我和你说RUP对ITERATION支持不好一样。CMM这些所谓的传统理论体系下的方法人为，软件开发不能依赖程序员的个人英雄主义，于是他们就搞了一个管理者的个人英雄主义。CMM这些重方法的复杂与难于掌握我想谁也不会出来反对，他们说可以让少部分的人领导开发，让少部分人做设计，那些底层的人只需要去编码。我不知道你是不是人为你可以做到那个做设计的位置，至少我是从来就没有看到过一个人可以完成这个工作。
理论是一回事，做起来是另外一回事。

haha, that's right。ISO在工业制造方面很成功，可是对软件行业简直是风马牛不相及的感觉。

有些悖论了，任何东西都是人创造的，任何东西都离不开人。工程、工艺都是人创造的，自然人更加重要了。 不过这样的说明，有意义么？我们强调的是个人能力，还是合作能力？（工程的存在就是促进这种协作能力）。一个职责分工不明确的团队算是好团队？
   再注意我的说法：项目的成功纯粹是人么？那制度、客户需求的变更这些因素在你们眼中又是什么那？（你们说的人究竟是全部的人还是项目组内部的人啊？）
   做过项目的都应该知道，影响项目成功的往往不是技术的使用，而是对需求的把握和分析（而这不一定是考需求人员就可以把握的，也要靠客户对于需求的把握），而需求的变更管理更加是重要部分，不要有人跟我说不靠一种制度，一种约束，关靠人就可以控制好。
   O6Z，如果说你对软件工程了解，我佩服，但是你对6σ看来并不了解，谁说6σ公认失败了？（通用用它、MOTO用它都是在其他技术方面，软件的管理才刚刚涉入，公认是个怎么样的表达？），它的概念是什么，在座的各位不会有比我清楚的（我最好的朋友就是负责格力电器6σ的实施），它只是一个指标体系而已。
    最后希望大家冷静一些，过度的评价和批驳就会变成一种盲目。

人孰无错？将一个整体的事务依靠在某些个体的身上，这是一种悲哀。
盲目地放大工程是一种悲哀，而放肆地批驳工程更是一种悲哀。

第一，一个non-trivial的软件项目的成败肯定要系于某些个体的身上。我记得《死亡之旅》说有个项目的两个核心开发者出车祸死掉了，你说什么样的软件工程能让这个项目成功？

第二，是不是好团队，只取决于他们是不是成功达成目标，不取决于职责分工是不是明确，我相信任何人都会同意这一论断。软件开发是一个纯粹智力活动，其中最大的成本在于交流，交流的频率与职位数的平方成正比，我相信你也会赞同这一观点。那么，我们可以得出什么结论？

第三，我一直认为，客户（更不用说公司的其他同事了）跟我们是在同一条战壕里的，对面的问题在向我们疯狂开火。我们的任务是要解决那些问题，为客户提供最大化的价值。当客户有需求变化时，我们可以按照教科书上的做法，来个变更管理，走上一星期流程；也可以按照XP的做法，拿出时间/成本估算，让客户自己决定要哪些feature不要哪些。你认为哪种方式比较好？

凤舞凰扬
大概我研究6σ还不是很多，只是草草学习了几年，知道通用在搞，软件方面就只是moto在搞，当初也差点成为黑带，所以可能不是特别了解最近的情况。
6σ需要以可计量为基础，但是我想你也明白软件开发中的计量是一个难题，至少CMM也是在高级阶段才有这个要求。
其实6σ主要还是以品质要求为主的，主要面向的是生产，当然现在也扩展到市场和服务，但是面对开发，至少我是没有看到任何报道。
而其次6σ需要的是实施前后的对比，但是这个对比在软件中会很困难，因为你这次的项目和下一次的项目应该有非常大的不同。当然如果你的几次项目的情况都很类似，我觉得这个时候也不是实施6σ的时候，而是你应该检查你的开发方式，为什么没有把已经很固定的东西形成产品的时候。
我想这三点就够了，如果你愿意，我还可以给你说下去。通用和moto都是用他在服务和重复性的生产，而不是用来规范开发。我想如果你的朋友没有告诉你这些，那么他的水平你还是应该怀疑一下。就开发方面来说，实际上那个ISO9001也只是做做样子，根本就没有一种理论和方法可以规定开发应该是怎么做，就更谈不上标准的。

很确切。

      6σ主要是以品质为主，这个没有错。它的最开始来源，是来自于统计学中的σ概念（有兴趣的朋友可以看看统计学的书），最早推出这个6σ的是通用，它是用于生产阶段，现在绝大多数电器厂家已经引入了。MOTO算是引入的第一个IT厂家，它正是因为以前流程改造的失败才引入的。6西格玛是因为在MOTO的成功而出名，而非失败而出名。
    6西格玛是针对流程改造而言的，它通过改造流程而明确责任，降低每个阶段的品质问题，从而降低整个产品的品质问题。它属于一种质量管理，可以说是QA和QC的一种管理模式。
    它引入软件是否成功，现在刚刚起步，但是有一点，它不适合项目，其实就正像你所说的软件多变。但是首先一点，将软件的生产全部划为项目的开发这本身就是一种极端。最后，所有产品的品质量化，包括软件，都是一样，必须是建立在统计学的基础上（对于广泛的数据进行采样，然后根据某种指标进行分析），没有任何一样东西都可以绝对的比较，这，便是工程所要求的（工程指的不仅仅是技术）。也是工程和工艺的差别。
    如果没有明确的流程、没有明确的责权分配与说明，就无法进行有效的数据收集和统计，也就自然谈不上分析和量化。所以每一次项目都是反复地重新开始，几乎找不到任何可以借鉴的东西，这个时候，就只能期望我们的项目经理、需求分析人员有超高的才能。
    没有经历过工程的人，没有受过专业的工程教育的人（这也是计算机系学生的一些悲哀），是无法去体会工程所带来的东西，要么极其夸大，要么极其贬低。

凤舞凰扬
你说到了一个很关键的概念工程，专业名词应该是工业工程－IE。现代IE已经不是50年代的那些东西了，但是统计学还基础。
对于6σ的观察，从这几年的经验看，我是被悲观的。软件开发有起不可重复性，而且你的开发能力越是高，技术水准越是成熟，管理越是严格，就越是不可重复。这一点是别的工程所不具备的。并且大量的软件开发工作是概念的开发方面的，这个过程具有不可控制，不可再现，不可显示，这些的特点。这是一种类似剧本创造的工作，存在着模式，但是不存在标准；存在风格，不存在模板；存在技巧，但是不存在定义。这是一个非常个人化的活动，6σ这样的东西存在的物质基础在这个领域是非常缺乏的。
我不是贬低6σ和ISO这些东西的价值，我只是认为他们使用在软件开发方面至少从现在的情况看是不合适的。