哈哈，张恂找到了最新的银弹证据！

这种论战在看起来当然是花团锦簇，落英缤纷，眼花缭乱，各式各样的武功都用上了，让人觉得很过瘾，但是没有实际意义啊，做事情还是要踏踏实实的。看了那么多文字堆砌有什么用？把风气都带坏了。我看啊，也不要斗嘴了，划下一个道道，双方写代码比高下吧。

可是有一些想法无法用写代码这种方法来一较高下哦

以前听过一句话：软件工程就像在一个黑屋子里找一只并不存在的猫，有人宣称：找到了！
今天你找猫了吗？

软件工程这类话题稍微一点开发经验的人都能扯上几句，然后欣欣然，以为莫己若了。其实意淫而已
多关注一些实在的东西，比如怎么把文档整理得更清晰，怎么更好的进行单元测试，怎么写出更快、更好的代码，怎样挣到更多的money

管他什么敏捷还是RUP，管他银弹还是金蛋，更好的完成项目才是最终目的

多谈问题，少谈主义

其实单纯就银弹问题，我觉得还是很有必要进行细致的研究，毕竟我们都是在做软件，需要知道什么是可以成功，什么是不可以成功。用了两个晚上，把那两篇文稿从新读了。确实有了许多新的发现。首先银弹是指软件工程方面的手段，但是他给出了一个非软件工程方面的解决方法，那就是不开发而只是使用产品软件。其次他在没有银弹中是愿意相信，组合的多种方法可以成为银弹，但是后来就又认为即使组合也不可能，这也就是说一种集合了多种手段的方法论，也不可能成为银弹。其次作者认为小粒度的复用不解决问题，粒度越大效果越大，最好是软件复用，也就是直接购买软件成品。
而结合SEI等最近的一些说法，也就是尽量少编程,自然就会少人数，也自然就会小团队，也就是那种一个人做决策，几个人设计，一大堆人实现的所谓软件工厂模式，已经被SEI很不直接但是很确定的否定了。这也无形中从另外一个方面承认了最近几年敏捷的成功。
这些问题似乎很主义，其实分析起来却非常的问题，非常的有指导性。其核心意义就在于指出软件开发应该以构架为核心，也就是承认来从UP开始的面向对象社区的实践已经是最重要的方法，从而代替了CMM的核心地位。这种认识也等于认为，软件开发的成功与否，最重要的还是软件的核心构架。构架的研究对学院派和工程派来说，没有太大的区别，也就是一个理论多些一个实践多些，只是量的不同，而非质的差异。这也证明，只要按照求是求实的做法，学院派和工程派最后都还是要走到一起来的。这其实也是别的工程领域的已经发生过的事情。也就是那些喜欢不研究不实践的人的可活动空间会越来越小。

dlee似乎你从来都不用心看我的blog。

不是我没有仔细看你的 blog，还是我说的 100 分和 60 分的关系。
软件工程要实施好是建立在足够的角色划分的基础之上的（即使 XP 也要有角色划分），问题是我们每个项目没有足够的人来担任这些角色，更不用说他们没有足够的经验和技能来担任这个角色。而根据我的经验，一个人如果同时担任两个以上的角色，他就不可能做好工作。如果他们能做一个好的程序员，我所交给他们的编程任务他们都能完成，我就谢天谢地了。
比如我们现在平均每个项目包括所谓的 PM 在内只有 3、4 个人，PM 需求、设计、编程都要上阵，一个项目从需求调研到试运行 3 个月就要完成。在如此苛刻的资源限制下，不光张恂无法回答我如何做好软件工程，连你也同样无法回答我。我不仅不能照搬 CMM 的做法，同样也不能照搬 XP 的做法，我根本就没有足够的时间来做好  TDD。那么我是不是直接就撂挑子撤了？ No，弟兄们，丢掉幻想，准备战斗！

最后一段感同身受啊，我们项目组就是这样，而且头儿根本不管过程，就是给你一个时间限制，到时候交东西，能够通过测试就OK，管你什么方法，时间多的话，可能还会照搬着一些严格的流程，时间紧的话，一切都是空谈，当然这也有可能是我们水平低，所以我一直很想知道别人在同样时间的工作量的压力之下，会怎么做。有一次和一个人作一个小项目，时间比较紧，头儿天天逼着，先做一下比较基本的的设计和分析，接着实现一个轮廓模型，然后各个功能块慢慢细化，在细化的过程中不断的调整代码结构（类似于所谓的重构，不过这个没有单元测试代码做保证，因为根本就来不及写，主要也是还没有真正会用这个东西）。
说到压力，不知道别人是什么感受，只知道，当头儿每天都跑来问进展如何的时候，我恨不得多长几颗脑袋和几双手。
那时候减少一些bug的方法就是每天下班前都进行集成测试（那段时间Martin Fowler的《持续集成》的确给了我很多启示），因为系统不大，所以两个人相互测试，差不多都很熟悉彼此的工作，查出bug随时都可以给对方改掉，当然，每天我们可能会花至少半个小时进行交谈，说出彼此的想法和实现之类的。那时候什么狗屁理论都不在考虑的范围之内，所有的想法都是如何提高效率，什么方法能够提高效率，我们就在当时情况允许的条件试着用。一个月满负荷的工作，终于可以说是提前完成了，那是我第一次带着别人单独的做一个项目，此前，只不过做了一个系统的几个模块而已，但是从那以后，我就感到身心都很疲惫，学习和编码的积极性似乎没有以前那么高涨了。
总来的来，那是个很失败的经历，留下了无法治愈的后遗症，让我变懒得越来越懒了。

我希望看到大家交流，就是想知道，别人是否有更切实有效得方法来提高效率。比如，你天天说敏捷，天天说银弹，给出一堆统计数字，这些对我而言，没有用，我想我更愿意听一些建立在实践基础上的，比如我看potian写的关于单元测试的那篇，就觉得很亲切，也更容易接受，因为他写的那些感受，我也曾经有过，那些迷惘我也有过，所以我可以很快的接受和认同他的看法。

我来给我上面说到的那个国内软件公司项目开发的典型场景撒上一点盐——数据。只不过这里是国外的数据。
《编写有效用例》第17章“用例在整个过程中的作用” 17.6.2节“用例需要的平均时间”中说到：

至少我们目前是没有办法完全按照 Cockburn 介绍的做法把用例这一环节做到 100 分的。但是我们还是认为用例是必须要做好的一个环节，因此会下大力气来编写用例。
最为恶劣的是国内最不缺的就是人，掌握初级软件开发知识的“软件蓝领”将来也会越来越多。如果只做一些技术含量不高的项目，没有自己的核心技术，无法有效地降级开发成本、提高开发效率，是根本无法构成核心竞争力的。国内的企业根本没有看到软件的价值，不管你如何报价，他都能给你拦腰砍上一刀，糟糕的是再低的价格也有公司愿意帮他做。我不知道张恂有没有研究过国内大部分软件项目的成本构成，如果完全按照他所提倡的那种软件工程来做开发，是根本赚不到钱的。他的眼睛只知道盯着国外、盯着书本，盯着 Rational 三友等少数几位大师，而不去研究身边发生的事情，在我看来完全是闭着眼睛做学问。可叹国内的某些软件公司居然把他当作专家，真是问道于盲！我不知道他何时可以走下神坛和我们一起唱“南无阿弥陀佛”，也许永远没有这一天。如果在同一家公司我有这样的同事，我就只能“敬鬼神而远之”了。说不过你我还躲不过你了？
我来举个例子，以前我是做企业级邮件服务器的，我们的开发成本比较高，但是我们的产品是经过了严格的压力测试的，支持上百万用户量，而且比较稳定，功能也很丰富。但是邮件服务器这个市场门槛太低，基于 Qmail/Postfix 二次开发添加 Web 界面后就可以推出一套具有基本功能的邮件服务器系统，至少支持几千用户没什么大问题，而对于大部分企业这就足够了。我们的系统一套至少要卖 5、6 万，而有些夫妻店生产出的产品只卖 1、2 万，于是在残酷的竞争下我们终于垮掉了。我印象深刻的是最后一天去公司上班，因为公司拖欠我们两个月工资，因此我们要做的事情就是“分家产”（按照 xel 的话说就是“分田分地真忙”，或者按照大史记2 “分家在十月”中的话：“卫生纸也要，一次性纸杯也要，我靠！”）。开发人员可以把他开发用的机器带回家，我于是得到了一台旧的华硕笔记本电脑。我举这个例子只是为了说明成本究竟对一个软件公司意味着什么。这样的教训不可谓不深刻了。

为什么usecase会流行，敏捷会流行？原因其实非常简单－－成本。
一般一个项目大约会包括6－10个核心用例，而写作这些用例大约也就会花费2天（项目组大约6人），而一迭代大约也就是完成1/2个用例。而详细的用例说明是在开发过程中不断的进行细化的。其实编写有效用例已经类似的书，都没有把迭代的问题加以说明，所以感觉这些工作会耗费很多的资源，其实完全不是这样。
而看书如果不考虑上下文和实际的情况，就往往会对这样的情况发生误解，以至于认为这些事情都是可行性不佳的。

《编写有效用例》其实已经是一本可行性非常好的书了，如果感觉没有可行性我就不会去读它了。我们这里的 PM 都读过这本书。我们要写好用例还有一个原因是可以更加客观地估算工作量，和客户谈价钱时心里也比较有底。我的意思只是说从 60 分到 100 分是需要一个过程的，不要那么急于把什么都做到 100 分，那样你是无法完成工作的。
我感觉软件开发工艺的成分大约占 70%，工程的成分大约占 30%。上次你说软件工程可实践不可......（忘记后面怎么说了），我现在可以这样说，没有实践就没有软件工程。而我把可实践的软件工程也看作类似于工艺一类的东西，例如 TDD。对软件工程理解最深的往往是那些技术最好的大师。而不亲自去实践（不能完全依靠别人的实践和经验，一定要自己去实践），只从书本、文档中研究软件工程肯定是一条死胡同。
我现在有个想法，我们中国人可能需要走自己的路，创造出属于自己的软件工程。这类中国的软件工程专家我并不认为会从张恂这样的人中间产生，而极有可能出现在 potian、gigix、robbin、庄表伟、你、我这样的人中间。