模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Vikas Hazrati 译者 金明 发布于 2009年4月17日 下午8时9分
多大的团队规模才是最佳,从而使生产率最大化?关于这点已经有很多的讨论和争论。虽然大多数敏捷实践者赞同团队规模越小,团队的实用性更强、生产率也越高,但定义最佳的团队规模大小,依然是一个挑战。
Jeff Sutherland 分享了一些有利于小规模团队的统计:7人团队开发每个功能点的成本是$566美元,而14人团队则高达$2970美元。在对InfoQ新闻“
关于团队规模增长和生产率”的回复里面,Mishkin Berteig同样写到
假象一下你被任命为由100名开发人员组成的软件开发团队的头,现在需要开发一个非常重要的项目。下面哪种结构更可取:
a)把所有的100个人都安排上项目(提供良好的项目管理、领导力等),或者...
b)找出团队里面想加入项目的最强的7个人(换句话说,这7个最强的人对该项目真正感兴趣),让他们上这个项目。解雇其他所有人,把省下的钱用来给这7个人配置他们想要的最好的工具和环境,剩下的钱用来提高这些人的满意度和愉悦度。
就个人而言,尽管方案b过于严酷,我依然会选择它,而不会选择方案a。
Jurgen Apello 建议最佳的团队规模应该是5个人。在很多对沟通和团队结构的研究里面,5是常见的团队规模大小。
在对帕金森定律的回复中,PMHut提出了另一项5人团队的论据支持,他指出
团队成员越多,沟通方式就越多,而且该数量是呈指数上涨的。比如团队有3个成员,你可能会有4种沟通方式,但一旦成员数为4,就会有9种。我猜想对应的方程式是(m-1)2。
在我看来,4到5人的小团队是最理想的。
因此,上面的事实和研究表明,从Scrum推荐的团队规模、帕金森定律、短期记忆的自然极限到有利的沟通方式,5人的团队规模满足了所有的条件。
然而,虽然种种迹象表明5人团队是最佳的规模大小,Jurgen 也警告与其照搬推荐的团队规模,不如由团队先尝试自组织,然后动态达到最佳的团队规模。根据他的观点,
当你需要组建一只庞大的项目团队,不要照搬任何书里面写的“更佳”的团队规模。尝试团队自组织,由团队成员(在真实的环境下)得出最佳的团队规模。他们愿意把7人团队分割成两个,一个3人,一个4人?当然,为什么不?他们想把两个团队合并成一个15人团队?没问题,让他们看是否有效。
查看英文原文:Is Five the Optimal Team Size?
本采访是在伦敦举行的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 条回复
关注此讨论 回复