剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mark Levison译者 李剑 发布于 2008年1月22日 上午1时48分
Target Process 2.7已经发布,在InfoQ上曾经对它的2.0和2.3版本进行过介绍。Target Process是一个敏捷项目管理工具,它可以将敏捷项目相关的很多任务进行自动化处理。它简化了计划、追踪和QA的工作。它提供了实时报表和历史数据,以供高层管理团队同时浏览多个项目的状态。从它的最近一次发布至今,增加的主要特性有:
可视化迭代计划(Visual Iteration Planning)
这个漂亮的特性用一个大矩形框来表示一次迭代的工作量,从中可以看出在本次迭代中还剩多少“空间”可以安排功能(基于前一个迭代的生产率估算)。在矩形框里面的小框是已经安排进当前迭代的功能,它们的大小表示了预估的规模。
除此以外,bugs都用红色边框和一个小图标加以标注。这样的计划方式看上去还挺迷人的。
程序级发布计划(Program Level Release Planning)
你的庞大产品用了多个团队来共同完成么?这个新特性可以帮助你在一个程序中追踪多个项目的状态。它也可以让人看到某个发布是由哪些功能组成的。
在Target Process的网站上有快速上手向导,还有一个30天试用版下载。Target Process可以作为托管服务,也可以作为一个应用程序安装在你自己的Web服务器上。
很多敏捷教练都建议说,本地团队应该从使用索引卡和任务板开始工作,因为他们相信在任务板前面做每日的Scrum会议可以更好的促进团队沟通交流。只有当团队处在分布式环境中时才需要使用电子工具。
Target Process在2.5版中加入了个人生产率报表(Individual Velocity Report )。在使用这个特性时需要注意一些事情。从前有些公司已经用过类似的功能来追踪生产率,并据此对个人进行奖励;结果却对团队造成了损害。敏捷方法是建立在团队创造的价值大于个体价值相加之和的依据之上的。如果我们把注意力集中在个体的绩效和奖励上,那么团队成员就会在外因的激励下更多的考虑他们自身,而非整个团队。这可能就会表现为有些人拒绝去培训别人,或者逃避承担项目中的某些任务,因为这些可能会让他们的生产率看上去不怎么样。
查看英文原文:Target Process 2.7: Agile Project Management tool for Distributed Teams
本文主要讲述了如何用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的未来规划。
没有回复
回复