剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 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
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
没有回复
回复