剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mark Levison译者 徐毅 发布于 2008年3月27日 上午2时38分
在AgileJournal上最近的一篇文章中,Doug Shimp和Samall Hazziez(3Back的合伙人,Preferred Professionals Business Group的高级合伙人)一道,讲述了是什么使高效的“优秀团队”茁壮成长。
作者观察到许多能产生优秀团队的特性:
随时可见——作为最明显的规则中的一员,它却很少被认真遵守。
这点很重要
对这一点有所疑惑,虽然能够在一个地点当然很好,这样可以保证随叫随到,可是团队的目的不是这个,而是为了有更高的生产率。如果说这个人不和团队在一起工作效率更高,那么是不是不在同一个地点也是可以的呢?另外现在越来越盛行的外包,不就是典型的地点不在一处的分布式团队吗?
可以将这个团队归结为“自组织团队”,但是不要忘了自组织团队有个不成文的前提是其团队成员有着统一的价值观,有着强悍的自律性等。最后还是回到人的问题上,没有优秀的员工,或者没有培养出优秀员工的制度,要达到一个优秀的团队比较困难。
如果说这个人不和团队在一起工作效率更高,那么是不是不在同一个地点也是可以的呢?另外现在越来越盛行的外包,不就是典型的地点不在一处的分布式团队吗?
首先,这个说法的前提是不能保证的。也许这个人单独工作的效率高了,但是整体的效率势必会降低的。盛行外包的原因,也不是因为外包可以提高工作效率啊,从收益的角度考虑,更关注的是大大减少成本,效率降低所占的比重就小多了。
为什么个人单独工作的效率高了,整体的效率势必会降低呢?不时特别理解。个人工作效率高了,交代的任务完成了,不就促成了整体的效率了吗?写到这儿想起一个例子,现在大部分的开源软件的贡献者不都是分布在全球各地的吗?在协调好的前提下,他们的工作效率也不低吧?
对于外包,我的理解是将非核心的工作发包出去,从而提高本团队在核心业务上的工作效率。严格意义上来说,外包团队和发包方是一个整体。所以说我的观点就是“在一起”不是工作效率高的必要因素,有时还可能是障碍。
汗,我并没有说“个人单独工作的效率提高”和“整体的效率降低”是因果关系,我是说这种把team分散的做法,也许会带来个人效率提高,但是作为team整体而言,沟通和写作效率必然会受到影响。
关于外包,楼上还是没有亲身体验啊……你可以找人问一下吧……
对于“随时可见”,最大的好处就是所有的团队成员就可以随时了解到项目的进展和面临的风险,这一点是控制好质量和项目进度的关键!
本文主要讲述了如何用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的未来规划。
7 条回复
回复