模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Geoffrey Wiseman 译者 李剑 发布于 2007年9月6日 上午3时30分
虽然众多敏捷专家都在帮助敏捷项目走向成功这方面投入了很多精力,但是我们也应当过一段时间就停下来思考一下,为什么有些敏捷项目或是对敏捷的实施会失败呢?了解了这些以后,或许我们就能在日后的实践过程中躲开前行路上的种种陷阱。
Jean Tabaka列出了导致敏捷实施失败的11点因素:
敏捷方法已经遭到了种种质疑,因为有的时候它们并没有为采用它们的组织带来所预期的收益。但是在我担任敏捷教练的期间,我发现实际上敏捷实践并没有失败,而是由于种种因素导致了敏捷实施过程的失败。下面是我所列出的最重要的前十一种原因。看看有没有哪一条给你带来过同样的痛苦。
她所列出的11点因素如下所示:
- 没有真正有效地实施定期的回顾(retrospective)
- 没能让每个人都参加计划会议
- 没有注意实施敏捷所需的基本结构
- 为项目带来反面作用的ScrumMasters
- 要么是产品负责人(Product Owner)一直没有加入项目中,要么是项目中有太多的负责人,而他们的意见又不一致
- 因为遇到困难而放弃敏捷,回退到从前的开发流程
- 组织的执行高层只给予口头承诺
- 团队中缺少决策者和负责组织管理开发过程的人
- 远程团队中没有“布道者”,协助调整团队状态,保证敏捷实践的顺利实施
- 缺少支持自我学习提高的团队或是组织文化
- 讳疾忌医,宁愿逃避也不愿面对现实
以上种种,在你的敏捷软件开发中是否也碰到过一些(或是全部)呢?或者你还有什么可以添加到这个列表中来么?
Tom Hume描述了他们组织的一个名为《为什么敏捷会失败》的活动,他们总结出的一条结论就是:“如果敏捷没有起到作用,那么要么是你没有正确的实施,要么就是团队成员不是作敏捷的那块料”。《QA Strategies》列举了一些实施敏捷时遇到的挑战,从对细化管理的担心到过于热心的团队,这些都是实施敏捷的不利因素。Kevin Brady认为敏捷方法没有考虑到人类心理学的因素:
- 人们常常都会把自己的兴趣放到团队的兴趣之上。
- 人们都更为关注自己的事情。
- 商业产品的决策是基于理性的期望的。
- Karl Popper的“协作活动第一定律”:你永远不可能找到超过五个人对任何事物的意见都会保持一致。
Eric D. Brown也认为这和人们自身有关,但是他是从另外一个角度来分析的:“这不在于使用的过程或是方法学……帮助项目成功取得成功的是参与项目开发的人。当然,过程在这方面也会起作用,但是如果没有比较好的团队成员,或者没有帮助这些人取得成功的组织,那么就算是再好的项目管理方法也会失败”。
您可以听一下对Jean Tabaka进行的采访播客以获得更多信息,或者你还可以在InfoQ敏捷社区中留言,告诉我们你认为导致实施敏捷失败的因素有哪些,而你又是怎样处理这些问题的。
查看英文原文:Why do Agile Adoptions Fail?
本采访是在伦敦举行的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谈论了跟他的新作。
没有回复
关注此讨论 回复