本文主要是介绍梅花香自苦寒来 ----议张恂《笑看JavaEye软工坛之叽叽喳喳》，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
梅花香自苦寒来----议张恂《笑看JavaEye软工坛之叽叽喳喳》
序
从J2EE阵营走出来已经半年了，这时间一直在中国一家一流电信设备商从事C++程序开发工作。如果你没有这样的经历，你是不会知道刚来时有多么的压抑？要知道转方向对于我们从事IT业的人来说是多么的困难，更何况是从应用软件走到系统软件，现在的很多开发人员不也是被牵着鼻子走么？
那时不仅对自己的决定产生了怀疑，虽然部门过了CMM4，但对企业内部只重视管理和过程而忽略技术和人愤青了多次。后来，老教授们找我谈心，这些人曾参与过我们国家的两弹一星工程，是他们不厌其烦的教导，让我沉下心来，并慢慢看到了自己的无知。
今天本来是想继续学习项目管理的，但突然怀旧起来，梦游至JavaEye。看到昔日曾经一起奋斗学习的朋友们，都出了书，并成为了独立咨询顾问，为他们高兴的同时，也无形的激励着我。然而，各位的有些讨论确让我无法赞同。每个人有每个人的选择，每个人也有每个人擅长之处，这是无可厚非的。但，对于这样大的论坛，这样的讨论是否能让后来者有更多的受益呢？论坛是针对大家的，是应该具有指导性和广泛性的。
今天我也试着来谈谈大家认识上有严重分歧的内容。
用例和用户故事
这两者的本意都是捕获涉众的需求。需求理解本身就存在歧义性。比如温伯格说的玛丽有一只小羊。那么真正所要表达的意思是只有一只羊而不是两只，还是强调的是玛丽而不是爱丽丝，这只有涉众自身知道。
用户故事就好比我们小学学习的比喻，通过另一个故事来把这个需求更好的表述出来。比如，一个人应该只能照顾一只小羊，这样才能使小羊更加健康地成长。当这样描述时，我们知道强调的是一个人对应一只羊。这需要很强的想象力，而想象力又是做分析的基础。所以说用户故事可以很好的用于需求分析，但不是需求捕获。Partech所举的例子就是描述的功能点，也是特征，也是规格，这已经包含了分析人员的主观性，而不是涉众想表达的。比如自动停止欠费客户的所有服务，这怎么可能是用户所希望的呢？这明明是系统所提供的功能。
《编写有效用例》开篇第一页就写着：用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。这里的用例是不会有过份的交互设计的，因为这时表达愿景。没有目标的努力除了徒劳无功还能说什么。这就像周末起来，你和你夫人商量许久，最终决定去爬山，可从南坡爬还是北坡爬，是一气爬上去还是到中间的亭子欣赏风景，在这个契约达成的时候是没有体现的。这就是所谓的云朵级用例，现实中我们可以通过业务建模来完成。它所捕获的需求是客户需求。这一级的分析有时是不需要的，比如，我们项目中依赖的开源软件需要升级，这也是一个需求，可这时的涉众是我们自身，同时需求也很明确。这种情况就是我们通常所说的实现方案导出的需求。
爬上的意愿定下来了，可我们不熟悉路，我们必须找一些人带领我们去，我们就要和他们协调，可能他们有别的安排，没有关系，我告诉他如果他帮我，我请他吃饭，事情可能就这样很好的解决了。这个过程其实就是要找到实现愿景所需要做的事情（熟悉路），以及解决对这些事情的限制（通过请他吃饭让他带路）。这也就是我们通常所说的功能与非功能需求。但这时我们并没有涉及到爬山时的具体细节，比如在哪里休息，在哪里欣赏风景，如果没到中间亭子时下雨该如何办。我们关注的是整体，所以它叫做产品需求，是海平面级用例。这对应着系统建模，注意并没有开始系统用例的编写。
最后就是商量爬山时的细节，同时要考虑一些意外的情况，比如下雨了该如何处理。这时是海平面以下级用例，是系统需求。这里才涉及到了交互的细节。Partech举的下面这个例子恰好说明了这时用例所要达到的细致程度，它采用“用户…….系统……”来描述，其实就是接口文档，这里才和用户故事很相似。
User Intention System Responsibility
identify self
verify identity
offer choices
choose
dispanse cash
take cash
Partech的例子
那么我们如何知道我们做的这个需求是满足客户需要的呢？我们必须制定系统测试计划，以便在系统完成的时候进行测试，来验证系统的质量。但，只用用户故事，我们只能进行功能测试，而逻辑测试、压力测试、边界测试等这些非功能性需求是无法进行验证的。所以我们要把非功能性需求和我们编写的用例搭配起来。而XP的非功能性需求也是通过用户故事来描述的。
至此，我们对用户故事和用例有一些了解。相比较而言，用例比用户故事更规范一些。我们都知道灵活性和复杂性是相对的。那么对于项目来说如果预防风险比起可扩展性来说更重要的话，那么我们当然应该选择规范的方法来避免复杂性。
其实，这里也不仅这两种技术。当我们无法确认客户的需求时，我们还可以采用鱼骨图的方式来发现隐藏在问题背后的问题。比如：导致产量减少、人员离职和效率低下，是因为质量有问题。而导致质量低下和机床维修次数增加的原因是机床掉了一颗螺丝。那么问题的实质就找到了。
还有很多好的方法，重要的是把握它的优缺点，做正确的事。
CMM和XP
首先你们不能像对smallfox一样对我，因为我对XP的了解应该比你早，chinaxp不知道为什么上不去了，如果可以的话，你可以去找我发的帖子。其次，你们如果没有在CMM4级以上的公司参与过至少一个项目的工作，你无权对CMM发难。没有实践就没有发言权。
CMM和XP其实是不应该做类比的，一个是模型，一个是方法。他们更好的关系是融合。就像张恂写的《用敏捷方法实施机遇CMM的软件过程改进》。
另一种争论的焦点是重量级和轻量级。认为CMM代表重量级，其实这也是不了解的人的主观臆断。就像RUP可以进行裁减适应不同项目一样，CMM也如此。而裁减是可以进行的，比如《Rational统一过程实践者指南》就有这样裁减的参考。而XP这种轻量级的方法学要完成重量级的效果是需要进行扩充的，这也就是敏捷所要进行的融合。个人的观点：我更愿意学习一个而不是多个，过程之间的沟通就像人之间沟通一样，特征驱动开发第一大章就说了沟通的重要性。在没有捷径的情况下，矩阵式（就是一对一的沟通）是最笨但也是最好的方式，沟通的成本可想而知。
IT行业正像制造业一样，从智力密集型向劳动密集型转变。没有规模化、产业化是不可能有本质的改变。软件开发关心三个问题：质量、进度和成本，如何协调三者一直是我们研究的重点，所以我们要提倡质量和生产率。而二者的提高依赖于三个因素：过程、人和技术。这也是通常我们所说的质量三角。片面的强调过程，或者片面的强调人或技术都是不正确的。实施CMM的企业关注过程，目的是在稳定的过程下，发现人或技术上的不足，从而逐步改进。而敏捷是在强调了人和技术的重要性后，现在开始关注过程的融合。dlee的话“无论侧重于技术还是侧重于管理，做到极至可以殊途同归”是对的。但能达到规模化、产业化只能依赖于前者。这就像现在中国的服装业和意大利的服装业。前者关注规模，后者关注品质。我们也想做精品，可这条路走不通时，我们只能走规模化的道路，就像联想。在中国只走精品之路是走不通的。而先走规模再走精品却有很多的例子，比如华为当年采用农村包围城市的战略，卖的是低端产品，可如今却做到了多项世界第一。
细节上，过程是可以量化的。比如公司遵照某种过程，完成一个项目时得到以下故障数据：
需求评审 设计评审 代码评审 单元测试 系统测试 验收测试
需求 0 0 0 1 1 0
设计 14 3 1 0 0
编码 21 48 17 6
从上图我们可以看出设计阶段评审很有效果，发现了14个缺陷，结果是以后的测试阶段仅发现1个故障数，成本很低；而单元测试发现了48个缺陷，系统测试发现17个，就连验收测试还发现了6个，这说明编码和代码评审不彻底，这两个阶段需要改进。从而分析到底是程序人员技术水平有限，还是编码阶段的时间过短。这对组织级来说是很有意义的。
而人和技术是无法量化的。在J2EE项目中，一个精通JAVA的人，有效代码行数可能为40行/天，那么精通Struts的应该加多少行呢？懂Hibernate的又要加多少行呢？在这里，一个人比另一个优秀，你是如何得来，是主观臆断还是客观的定量比较呢？
还有一种争论是认为实施CMM的企业里过份强调遵循相应级别的关键过程域以及目标，比如二级应该采用SSM（软件子合同管理）。其实这是受国内的书籍所影响。国内关于CMM/CMMI的书籍编写者都是从理解规范和进行评估的角度来编写的，而不是从如何实践CMM/CMMI讲起。但也有重视实践的，比如讲解印度InfoSys公司的《CMM实践应用》和《软件项目管理实践》，漫索公司的《面向企业的软件研发管理解决方案》，以及刚出版的关于微软公司的《软件开发项目管理》。
事实上，所有人想表达的意思是：我们不应该用标准来约束我们，而是要参考标准。比如，进行同行评审是三级的一个关键过程域，其中一个目标就是把同行评审纳入计划。而我们采用XP的企业进行过同行评审么？这种尽早发现缺陷的方法难道不值得提倡么？当我们把一些该改进的进行了改进，我们就达到了相应的级别。而不是为了达到某个级别，而去进行相应的改进。
国内实施CMM的企业有时一味的为了过级，那时因为参与项目招标的资格上写明了要达到CMM几级，我们要参与国际竞争，就必须走这条路。当我们走过了，我们马上就回来思考如何去改进，这其实就是多走了一些路而已，但目的同样可以达到的。不知道各位有没有勇气扔掉自身的技术到这样的企业来体会呢？
我们都知道一个人的力量是有限的，组织的力量才是无限的。如果把一个技术很强的人扔到实施CMM的企业里，他就会一种四处软绵绵的感觉，因为企业强调的是整体而不是部分，一个人的才能是凸现不出来的。如果他能静下心来适应，他就会发现他的才能可以更好的发挥出来，因为这里舞台更大。这是一种以退为进的方式。否则，他就会选择退出，然后声称企业毫无创新，没有前途，然后进入一家小型公司（和那些过了CMM的大企业相比较而言）。下面文字摘自搜狐：
2004年，计算机硬件设别的销售额仍然占据71.5%的市场份额，但比2003年的73%有所下降；而软件和IT服务的市场份额则有所扩大，其中IT服务的份额增长较快，由2003年的15.6%增长至2004年的16.8%。
看着这样的比例你有没有些想法呢？不要以为计算机硬件设备就是卖电脑、卖交换机，其实卖的更多的是附加值的软件。服务业的确是目前的一种趋势，因为那有高利润的空间。但如果行业要发展，是不是还要依靠那71.5%呢？基础不打好，怎么建高楼啊？而这些需要很多其它的知识，比如项目管理和系统工程，那么当我们已经觉得软件工程学的很好时，是不是可以跳出来看看这些知识体系呢？
后记
当年楚霸王自刎乌江，他是因为打不过才自杀的么？不是，是因为无颜见江东父老。如果你也是很好的领导，那么你在乎的是自己的技能有多强，还是整个团队有多强呢？
你们知道Martin Fowler、Craig Larman，我也知道。可你们知道Crosbv、Deming么？我们还年轻，年轻是资本，这种资本可以让我们承担失败，固步自封只会错过机会。有一天，如果我能完成中国所有银行IT系统的改造工作，谁还会关注是采用的瀑布还是迭代呢？
戴习为老师说的好，“中国软件人最需要的是一张宁静的书桌”，这真的是很有道理。
Perfection团队
2005-11-05于深圳
这篇关于梅花香自苦寒来 ----议张恂《笑看JavaEye软工坛之叽叽喳喳》的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
