家传秘方

最后说说FDD、XP这些方法的问题。
首先我想一个成熟的企业没有自己的方法系统，而要去依靠一个什么外在的方法，是绝对不会发生的情况。M$有MSF，IBM有CRM/水晶，包括FDD和XP都和IBM有千丝万缕的联系，而CMM更可以说是基于70年代的IBM软件工程做的延续。
而面对国内的这些企业，我想还没有几个可以做到可以产生一个成熟的方法的地步。而从我最近一年多来面对的那些CMM的企业的丑行让我实在不能对CMM保有一丝的善意，说句不客气的化，你们到那些CMM企业中去看看，如果10个中有九个不可以满足最基本的SCM要求，你就不会在有去研究实施CMM心情了。
而面对XP和FDD这些方法，我想SCM都不会是问题，因为这些方法都内在的强制你必须建立一个良好的SCM系统，并且离开这个系统你将完全无法运行你的业务。而更重要的是FDD和XP还提供了那么多技术的手段，这些手段绝对不是CMM那些所谓的KPA所能相提并论的，都是具体了有具体的实实在在的手段。比如FDD中的领域分析和FEATURE列表，项目进度控制，人员调配，XP中的持续集成、重构、结对编程，这些都是再也无法更具体的技术手段了。而且这些方法实施的成本机会为0,同时又可以使程序员尽快的成长。那么我们为什么会认为实施这些方法会没有用处呢？

当然现在软件行业面对的问题绝对不是一个敏捷方法可以解决的，而是需要多侧面系统的解决。找到主要矛盾和矛盾的主要方面使正确的，但是并不能说只去关注主要方面，只去解决主要矛盾，就可以解决问题。头疼医脚，脚疼医头，自然不对；但是头疼医头，脚疼医脚，也不解决问题。还是需要整体的解决，系统的解决。而作为程序员来说，解决他们面对的问题，选择一种适应自己而且代价小的方法，就是他们为解决软件行业整体问题做的贡献。我们需要不同的角色的人，都去解决面对的问题，销售员要解决他们问题，客服也要解决他们的问题，程序员自己也要解决他们的问题，老板当然也会解决他们的问题。不合理就是要研究解决，而不能用种种接口去推托。

市场允许他能够生存，那就是合理的。关系，销售仅仅是这个国内这个市场运作方式的一部分。
有兴趣的话可以看看下面的文章:
http://www.vankeweekly.com/asp/authornews/showfile.asp?id=4293
软件市场的评价标准是怎么样的，就会孕育出什么样的管理方式。这是一个
质高价高者胜出，还是质次价低者胜出的问题。这个市场上有吃鱼翅的，也有吃粉丝的。国内的市场，大抵还是属于吃粉丝的那类。我见过的老板也不少了，自己也当过老板。其实作为老板的认为软件过程毫无必要，因为苟且也能过活。最多就是你多加班，你不愿加班外面等着求饭碗的人多的是。
我参过许多非常糟糕的项目，可是他们最终也能卖出去只要你卖出去了别人也不
管你的内部是怎么实现的，项目怎么控制的。再说软件的对国内企业又有多少价值？有软件可以做，没有软件也可以做。我成立的第一个公司做电信语音产品，我们的销售去114查询台了解客户意向，他们的老总想了想说你们这个东西好是好，可是削减了这些人力他们就要成为我的下岗工人每年有下岗指标超过指标我就要挨批。我服务的第三个公司，给他们上一套office系统我们移交系统的时候他们那个网关竟然是一个只会打字的40岁的中年老头。他们的客户代表说:没有办法公司里要们从二线(也就是待岗)人员中招聘网管.
在我们的角度看来不合理的软件开发过程，在国内这个市场上有其合理性。
便宜的人力资本，小规模的项目,低廉的寻租成本，乃至软件本身对于客户的价值
决定了不采用软件过程是合理的。

市场允许生存就是合理的吗？
你需要不需要考虑软件开发的效率和成本的问题呢？难道你不需要吗？
老板觉得软件工程没有用，软件工程就真的没有用吗？
客户不在乎的软件究竟是怎么开发的，难道就说明你可以不在乎吗？你控制不了进度，对于客户对你来说难道是无所谓的？那你干吗还要加班？
卖出去就可以吗？卖出去还要赚到钱才可以。赚到钱就可以吗？赚钱还有多少的区别。赚的多就可以吗？赚的多还要考虑失败的风险。这样大概就可以了吧？还要考虑这个事情你究竟有没有能力做。卖出去不是那么简单，就不要说还要卖出学问。
不说别人我们就说说你的那两个例子。114的问题很显然是你对于需求工程做的不到位，你只是了解了企业的需要，而没有了解政策的需要，也就是你只研究了具体的需求，没有去研究行业。而40岁的网管正好可以说明你对于需求工程了解的不总已经让你的思考问题的思路变得非常狭窄。我讲过很多的单位还没有网管，这就要求我们必须对软件的易用性和宜维护性有更高的要求。
人力资本便宜吗？我怎么就觉得现在人力资本贵呢？那些所谓的便宜的程序员有几个不是让人付出更昂贵的代价的。为什么前些年软件蓝领的这样明显错误的论调还有市场，难道这可以说明软件开发的人力成本已经很低了？
小规模的项目,低廉的寻租成本难道就不正好说明，你应该更加注重成本和效率。难道这可以说明，软件开发随便乱来，随便开发，随便测试。
软件本身对于客户的价值这个可以看作一个原则的问题，就如同我们讨论CMM究竟是不是好的问题是一样关系道德水准的问题。如果你就是喜欢开发对客户无实际意义的软件，只把关注点放在赚钱上，我想你根本就不应该做软件这个行业，有很多别的行业赚钱更加简单。而且你也不应该来这里讨论软件问题，因为这对于你赚钱来说没有任何用处。

每家都有每家的“秘方”，所以讨论起来，想要达成共识似乎是不可能的（实际也是这样的吗?）CMM是不是放置四海皆准呢，软件工程里到底有没有可以通用的在里面呢？或多或少，我都会说，“无用有用处，无意有意思”。。。

刚看完《最后期限》，感触最深的就是向故事主人公那么有项目管理经验的人，同样会犯很多错误，为什么，因为它遇到的是随时变化的状态，最直接的就是项目最后期限的制订，一旦有了最后期限，软件工程是不是就不那么“重要”了？


别批我太狠就行。

本人完全同意 o6z 的意见。以粗放经营的思路来办软件公司想要赚到大钱是很困难的。项目管理毕竟不等于赶羊+无休止的加班。那位 Trustno1 老兄，你确实是需要静下心来好好读几本书了。

粗放不粗放，我说了不算，书也说了不算，市场说了算。

如果要继续，讨论一个更实际的话题吧：
假设CMM依然存在价值，那么什么样的公司适合实施CMM？
－作为一个实施cmm失败的公司的员工倾听各位的发言。

jaqwolf
这个答案很简单，那就是外包，这个原始的目标。如果你们要开发自己的产品，那么CMM的风险控制机制就太弱了，而对于过程的控制又太强了。而如果这些拿来做不动脑筋的只要求尽量减少编码错误的外包，则刚好合适。但是现在这样的事情越来越少见，所以CMM的市场范围越来越小。

我是一个从CMM2级的公司里面走出来的。公司在开发一个新市场的同时开始实施了CMM2，等我们在按照CMM2的过程做完一个原型后（开始定不是原型而是一个产品，后来开发出来后变成了原型），客户已经等的不耐烦了，而选择了另外公司的产品。
确实，如 ozzzzzz老大所说，风险控制很形式化，而过程中，形形式式的文档非常繁琐（加班写文档），频繁的评审也是走过场。
不知以后会苦尽甘来，还是会陷入泥潭。。。。。。
软件过程改进是好事，但为什么搞得这么痛苦呢。。。。。

转眼脱离CMM已经一年多了，我去了一间开发人员20来人的公司，今天老总宣布一个震惊的消息，正式启动CMM3。。。。。。
我有一种想哭的感觉，呵呵。