模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。

作者 Jim Johnson 译者 罗小平 发布于 2007年9月20日 上午1时57分
有关项目失败率的CHAOS统计数据,经常被敏捷或其他过程改造方法的推崇者引用。因此,这些数据的真实性就非常重要。今年8月,《ACM通讯》(Communications of the ACM,CACM)发表了Robert Glass的一篇文章,影响很大。于是,InfoQ采访了项目失败系列研究报告“CHAOS Chronicles”的创立人Jim Johnson,咱们来听他说说是如何整理出这些数据的。
在采访后的一系列讨论中,有个关键问题仍然没弄明白:对于成本超支率从1994年的189%剧降至1998年的69%,Standish Group是如何解释的?互联网的其他很多地方对这个问题也有提及。Robert Glass文章认为,可能是因为Standish在这几年改变了研究方法,只不过没有在报告中说明。如果真是这样的话,那么比较1994到1998年的CHAOS数据的就毫无意义了。
Standish创始人Jim Johnson对1994到1996年间的研究结果差异也非常重视,甚至1996年的数据从未单独公开。在本文中,他将和大家一起分析CHAOS数据背后隐藏的90年代中期软件开发领域的重大变化。
文章引自CHAOS大学简报2006年11月刊,作者为Standish Group创始人兼现任负责人Jim Johnson。
近来,不少人希望我能解释项目成本超支率从1994年的189%剧降至1998年69%的原因。其实,我们已经在很多场合很多会议上做过说明,比如我最近的文章《CHAOS Chronicles 3.0》和著作《My Life is Failure》。今天再和大家讨论一下,当然,不会有什么新东西。

如果说这种进步是我们的研究报告促使大家努力改进工作而取得的,显然是夸大其词、过于自恋了,我们不会贪天之功。不过,报告首发以后,我们的确发现在我们关注的很多团队和组织中,用户参与度提高、管理层支持加强、大家对业务目标的认识更为清楚,很多公司开始重视其项目经理的PMI认证。所有这些,显然都产生了积极作用,但我们觉得这或许可以让1994年的189%下降到1996年的142%,而说成是上面问题的主要原因,仍然站不住脚。
在本月的调查问卷中,我们要求SURF参与者反映他们对项目时间和成本的评估水平。有不到10%的人认为他们水平已经很高,而几乎三分之二的人仍然认为他们还在起步至中等层次。

项目时间和成本评估能力的高低,对项目的时间和成本超支率有直接影响。1998年春季,我们曾就是否已经改进项目评估问题对很多团队做过调查。结果显示,绝大多数人认为自己到那时为止仍然习惯于先大致评估,然后在考虑不可控因素基础上增加一个误差范围的传统方法。从1998年开始,大多数团队开始修正原来的老办法,以期实现最优评估,这和我们在上图中看到的1994到1998年发展趋势是吻合的。然而我们认为,这仍然不是超支率从189%猛降到69%的主要原因。因此,在你阅读下面段落之前,我希望你能回忆1994到1998年发生过的事情。闭上你的眼睛,遥想在那几年里,我们的IT产业和计算机应用领域究竟发生了什么样的巨大变化。
现在睁开眼睛,你想到了什么?我先提供一个线索!我们1996年的报告显示约有40%的项目失败了。这年的情况是如此混乱,以致于我们没有提供正式的1996年版CHAOS报告。不过,如果找到包含所有年份的CHAOS报告,你将会看到如下结果:

是什么原因导致1996年如此之高的失败率?答案是互联网。我们从传统的C/S转变到互联网开发模式。C/S应用的开发和实施比互联网应用复杂得多,总是莫名其妙出现很多问题,你永远不知道用户的PC上会出现什么样的软件冲突。于是,所有组织迫不及待地将C/S模式像垃圾一样丢掉。互联网应用使项目变得更小、更简单、实施更快、更容易管理。而其中基于浏览器的无客户端模式则是主力军。于是,从1998年开始,我们看到项目失败率稳定下降。仅从这点,我们就能学到很多东西,特别是必须努力让我们的思想进步,学会选择最优的软件开发方法。

本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
3 条回复
关注此讨论 回复