剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Chris Sims译者 秦时月 发布于 2008年8月30日 下午11时41分
在Agile2008上,Charles Suscheck演示了怎样用修改后的Rummy玩法,教给大家项目中沟通、计划和协作的重要性。这个游戏对团队的各种分布情况,以及在项目进行中增删人手所带来的影响进行了探索。在Charles的话题上,参与者分成了三组,每组有5、6个人。
每组都有一个人充当“用户”。游戏开始以后,所有用户都会得到完整的游戏规则,其中包括每一轮游戏中的规则变化。除了“用户”以外,其他人将会得到另一套不完整的规则。
在Charles的游戏设计中,会同时出现6种不同的团队:
团队1: 只通过email交流,没有用户参与
代表分布于不同时区的团队团队2: 只通过email交流,有用户参与
代表分布于不同时区的团队团队3: 只通过电话交流,没有用户参与
代表没有文档的团队团队4: 只通过电话交流,有用户参与
代表没有文档的团队团队5: 开放交流,在最后5分钟的时候有用户参与
团队6: 开放交流,在最后5分钟的时候用户退出
代表难以为继的团队,最后有专家参与提供帮助
代表运作良好的团队,故而最后专家退出
每个团队都有三分钟自由交流的时间,讨论团队的组织、沟通方式、每个人担任的角色等等。
接下来,规则会被分发到团队中,每个参与者都不得把手中的规则给别人看,或是读给别人听。他们可以把自己对规则的理解通过该组特定的沟通方式描述给别人。 最终目标是看哪一组玩Rummy(被Charles修改后的版本)的回合数最多。团队中得分最高的那个人也会成为团队中的“赢家”。
游戏进行了20分钟,Rummy的版本在不断变化,团队中出现分歧,新规则需要理解,团队要进行调整采取新的策略。
20分钟过后,开放式交流的团队玩了11轮,而且还额外搞定了一个文档。这个团队很快作出决定,既然游戏的目的是尽可能的多玩几轮,那他们就要齐心协力,帮助第一个人尽快“出局”,不去管个人“成绩”。
“电话团队”的策略是使用电话会议模型来满足尽可能多的人参与沟通。不过,直到他们玩完一轮以后,才达成一致要帮助一个人“出局”。他们最后玩了两轮。
“邮件团队”一直没能进行协作,有一两个人在很强势的玩牌,争该组中的“赢家”。20分钟内只玩了一轮。
游戏结束以后,Charles组 织了一场总结会议,大家互相分享了自己的心得体会,并且跟各自的实际项目经验进行了对照。很多人都认为,在他们的实际工作中,火爆的内部竞争一直都是达成 协作的绊脚石。即使所有团队在一开始都有计划的时间,但还是没能做到保证沟通渠道畅通,从而在实际实施过程中调整计划。这方面的沟通限制对结果的影响要比 对游戏速度的直接影响尤为突出。
查看英文原文:Card Game Teaches Distributed Project Communication Lessons本文主要讲述了如何用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的未来规划。
没有回复
回复