模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Mark Levison 译者 郑柯 发布于 2008年6月6日 上午2时40分
近来发表的关于敏捷回顾的众多文章,重点都放在诸如如何引导以及采取何种形式等这些基础知识之上。而Patrick Kau则从相反的角度出发,他提出了敏捷回顾可能被错误执行的一些方式,并就如何避免这些问题给出了自己的建议。
他指出了目前发现的一些问题:
那我们该如何解决这些问题呢?Patrick提供了一些建议。说到“控制谈话”和“利害冲突”,他推荐这样的做法:
……重点要放在流程,而不是内容之上。你的目标是保证每个人都有机会发言,说出自己的想法,形成共识,并为最终决议的形成贡献自己的力量。不要去强制推行你认为的最佳方案,……要让大家知道,当你发言时,你所表达的只是个人观点。要让团队有这样的权力:通过一种机制,当他们觉得对话被你所控制的时候,能够反馈给你他们的感觉。
为了让回顾的形式更加丰富多彩,《Agile Retrospectives:Making Good Teams Great》这本书中提出了一些建议,并获得很多方面的认可。此外,Nathan Henkel还建议:
……要从细节入手。问类似这样的问题:“我记得你当时打算用表格查找技术来提升性能,效果怎么样?”类似“咱们这次哪些做得不错?”这样的问题会让大家摸不着头脑。
关于如何产生可以完成的后续行动,Sumeet Moghe有些想法:
- 用SMART原则来指导后续行动(Specific——明确的,Measurable——可测量的,Achievable——可完成的,Relevant——相关的,Time Boxed——有时间限制的)。
- 不要自己承担推进后续行动的义务。
- 当复查后续行动时,要让所有者给出更新的想法,再看看团队是否满意……
- 要提醒团队:改进是大家的共同目标,彼此都要负责。
最后,Bas Vodde提出:将大型长期任务拆分为小的、可控制的目标的方式,可供借鉴:
我让团队将所有的后续行动都按照特定的格式来整理,包含两项:长期的目标,可以在验收测试层面实现测试的自动化;眼下的行动,Pete会用Fit来自动化一个测试。
这种形式可以让团队为每个后续行动都考虑其长期目标。这样还可以帮助他们创建具体的行动,来让团队朝着长期目标更近一步。眼下的行动必须是在下一个sprint中就可以实施的,而且必须是团队自己就可以完成的工作。
查看英文原文: Retrospective Failures and How to Avoid Them
本采访是在伦敦举行的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谈论了跟他的新作。
没有回复
关注此讨论 回复