关于 60 分和 100 分

以前在 jlinux 的 blog 上说过关于 60 分和 100 分的问题。
gigix 和 o6z 等一些朋友都在从事一些咨询工作。我对他们的期望是什么呢？就是尽量把一个产品或者项目的开发当作一个整体来考虑，把握好最高层次的业务目标。这个整体可能是非常复杂的，必须把它分而治之，分解为很多较低层次的目标。较低层次的目标又可以分解为更低层次的目标。按照《编写有效用例》的说法，有些目标是高入云端的，有些则是深入海底的。要在这些目标中进行很好的权衡，这需要非常多的实践经验。
写好用例是一个整理思路的过程，最难的就是确定哪些目标是最重要的目标，哪些是相对次要的目标，划分出这些目标的优先级。哪些目标一定要做到 90 分以上，甚至 100 分，哪些目标则可以捣捣糨糊，混个 60 分就足够了。切忌什么都要追求尽善尽美，任何做过很多项目的人都知道这是个 mission impossible，因为任何时候资源都是有限的，这个资源包括时间、资金、开发人员的技能等等。整体上能达到 80 分就已经很不错了。国内的某些“软件工程专家”总是鼓励你在某些细枝末节的问题上追求 100 分，似乎你可用的资源永远都是无限的一样。比如那些 CMM 实施顾问总是想让你认为软件开发的终极目标就是追求更高的 CMM 评级。TDM 说了一个笑话，以 CMM 的高质量和高效率毫无风险地生产出了一个让世界打瞌睡的产品。
比如现在 gigix 为别人实施 XP 提供咨询，XP 的最佳实践很多，是不是都要在第一时间一股脑全部用起来？如果不是，比较自然的采用顺序是怎样的？TDD 在有些场合会造成开发成本的上升。如果资源极度受限，是否还一定要强调 TDD？开展 XP 比较适合的是至少 6 个人以上的团队，可是我们的团队如果连 6 个人都没有，如何实施 XP（你不会只是骂骂，这个穷鬼，连 6 个人都不愿意雇）？对于以前那个认为我不用 Maven 就是不重视文档，不重视软件工程的朋友，我就只有苦笑了。不用 Maven，难道我会死吗？就算把 Maven 用好了，就能保证我的项目顺利完成吗？

咨询，看起来很光鲜，但是其实是充满荆棘的一条路。Kent Beck、Martin Fowler 都是些什么人，他们做过多少年项目开发实践了？不过还是希望朋友们能够获得一个很好的发展，因为他们都是一些我值得尊敬的朋友。

dlee喜欢李熬，于是今天特意在blog来了一个李熬风格的文章，来撰述一下那些人经常推崇的RUP的老爹关于文档驱动和需求驱动开发方式的观点。很多时候杂技派总是利用国内信息的封闭，搞他们的种种文章。好在现在出版发达，网络也通畅。最近可惜没有时间去研究CMM，要是又时间我到底要看看CMM是不是那些顾问嘴里面的CMM。
杂技派一个一个像都是大师的关门唯一弟子，只有他们能理解大师的话。可是我见到就是这些人在搞CMM认证（他们以为自己是SEI），搞CMM三级跳，搞评审突击。所以现在我们反对CMM还说不好到底是不是在反对CMM，更多的还是在反对这些玩CMM的杂技派。好在CMM从来就没有成为主流，DoD也不是美国商务部，他们才没有兴趣为所有的软件开发组织提供一个放之四海的标准。

做项目不是为了工整地实施某种软件过程，最重要的是项目始终在往前推进，而不是停滞不前。我把这种只能得到 60 分、70 分的状态叫做“曳尾于涂中”。遇见 o6z 时候他常会问我，有没有学习 Python，有没有学习 Zope，有没有学习 Color UML，我只能很惭愧地说还没有，好象一个只能得 60 分的学生。不过现在我的时间确实很不自由，我花上哪怕 3 天时间去看 Python，就不知道 ly 该说出什么不好听的话了。不过 ly  确实在很多的方面对我都有很大帮助，我现在的目标比前两年明确多了。

一针见血啊～～～～～～～～～
   如今的公司就喜欢盲目地搞过程，搞RUP，搞CMM，一个项目组才几个人（有六个人还算可以了），能用什么RUP过程？
   mikeho所在的公司更夸张，几十个人，都没有正规的过程和稳定的团队，老总就放言今年要过CMM3（还是名校办的公司啊），真是搞笑～～～
   合适的才是最好的，希望每一位做咨询的好，做过程的好，做管理的好，还是做开发的人员也好，永远记住这点～～～～

我这都过了五级，不过没任何感觉

这个dlee自己不学习总是找借口。别的不说就color uml。我相信10页的英文你不到2个小时就可以解决，这根本不是有没有时间和精力的问题，而是你愿意不愿意的问题。很多事情我们过于追求一个完美的结局，而往往会希望越高失望越大。软件开发不是考试，分数越高越好，而是要在合理的成本范围内，开发出质量合乎需要的软件。而这一点往往为某些所谓的软件工程学者所忽略，总是希望设立一个从低到搞的进步阶梯。为什么DoD的项目要求是CMM3，而不是SEI多年要求提高到的4，原因就在与此。而即使是CMM5被认为是最好的，但是当你的组织发生了变化，你一样应该去实现最迫切需要实现的KPA，而不是高一个级别的KPA。

很可怜, 现在为了推销我的产品, 也需要做一些"咨询"的工作. 60分与100分是我在"咨询"过程中的一些体会. 在给客户做咨询的时候, 并不盲目的推广cmm和rup等, 一直强调的是实用主义. 也就是在项目管理中至少要做到60分, 但绝对不能做100分(当然也有例外的情况, 后面我们会说到).
其实60分和100分要看在什么样的情况之下, 在前面提到的软件项目管理中, 超过60分就好, 能达到70,80分最好. 而要从项目中获取到的利润, 应该以100分为目标. 以取得最大利润为目标来决定软件项目管理应该达到多少分(当然至少是60分), 给客户的服务需要达到多少分.

这就是一个三角关系, 软件项目管理你要追求100分, 要求文档中的每一个标点符号都不能错, 你也许可以达到你的目标, 但是你获取的利润就不能达到高分, 或者甚至是负分, 另外你在软件项目管理中得到了这么高的分数, 你给客户带来了什么好处, 一个100分的软件??? 那几乎是不可能的.  
所以一个项目中各个方面的分数是需要以获取最大的商业利益(这里所说的商业利益不一定是金钱, 在一些情况下也可能是名声等等)为目标去平衡的,

我这篇帖子的意思就是说，不完美是人生的常态，完美不是人生的常态。不完美的人才是有生命力的人，完美的人往往都是些很孱弱的思想型的人。
为了完成更大的目标，忽略一些次要的目标是可行的。就是以前某位网友说的“为了更好地做一些事而不去做一些事”。
很多问题确实是问题，但是是不是必须马上去解决？如果当前还有更重要更紧迫的工作，那么把这些事情放一放又有何妨？
不过关键就是你要认清楚哪些是最重要的目标（这些目标可能不光是技术，项目开发所涉及的问题可不仅仅是技术，甚至包括打点各方面的关系），这个就要依靠个人的经验积累了。

余世维 的一个管理讲座讲的一个观点很有用，也和各位老大的讲法很一致：
要将工作划按照 重要和紧急的程度进行划分：只要最重要，和最紧急的事情做好了就行，不重要和不紧急的事情，就让他躺在那里好了

因为事情是永远做不完的 ：）