运用Ruby纤程进行异步I/O:NeverBlock和Revactor
Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。
作者 Geoffrey Wiseman译者 郑柯 发布于 2007年12月7日 上午3时48分
对于一个组织来说,同一组开发人员来完成多个项目,这是常有的事儿。在这种状况下,应该如何组织团队呢?他们的工作又该如何计划和分配呢?
如果可分配的资源较多(比如说,可以为每个项目分配6至10个开发人员),而且已经知道这些项目的大小和相对优先级,一般来说,将开发人员划分为两个或多个团队就可以了。
反过来说,如果每个项目能够分配到的人员很少(每个项目只能有1到3个开发人员),而且项目的大小和相对优先级不明确或者易于变化的状况下,就很难以一种有效的方式来划分团队了。
针对如何组建一个项目和团队,Gilad Gruber正在寻求答案:
我想知道最好的方式是什么,Scrum是如何处理这种情况的。我觉得最好的方式是所有的团队共同拥有一个product backlog(尽管这意味着在一个sprint中,团队会处理分属不同项目的问题)。我认为那些拥有纯粹主义观点的人会推荐切分团队并建立多个backlog。
Wolfgang Shulze Zachau分享了他的经验:
我们只有一个团队和一个覆盖多个项目的product backlog,而且只有一个产品所有者(Product Owner,简称PO)。他在对客户和其他利益相关者进行仔细交流后,对优先级有最终决定权。只要让PO能自己做决定就行。
他又说道:“当然,其前提是你要有个合格的PO。”
Xu Yi-Kaveri表达了不同意见:
我反对多个团队共有一份product backlog。因为PO是决定product backlog的人,而我认为,基本上同一个人不可能同时是多个项目的PO。
他所担心的是:如何排定项目间的优先级,以及这样做可能会影响产生特性的优先级和项目的优先级的排定。因此,他建议:
你应该评估你的团队的工作能力,然后可能要和项目经理讨论一下多个项目间的能力差异。接下来,根据团队的具体工作能力,为不同的项目选择各自的product backlog条目。
Roy Morien建议依据常识在两者中做出选择:
无论如何,常识必须被认可。如果可以方便高效地切分多个团队,而且每个都拥有自己的product backlog,那就这么做好了,每个PB都可以独立划分优先级。假如多个团队共享同一个backlog,这就暗示着多个团队(每个团队的适当人数是7~9人)共享相同的PB,处理PB的优先级时就会出现问题,而且“有条理地选择条目并把其放入Sprint backlog”也将成为麻烦事。
最后,George Dinwiddie现身并(通过邮件列表和博客)分享了他使用多个product backlog时遇到过的一些问题:
估算就是估算。开发人员很可能处在这样一个境地:工作量配额已经用完了,要么继续开发一个未完成的用户故事,要么切换到别的工作。此时,或许开发人员要被迫加班,因为PO可能责怪开发人员未完成任务。在这种状况下,可能发生很多事情,但几乎没有哪件事情是符合敏捷原则的。查看英文原文:Multiple Projects, One Agile Team我跟你说,这一点儿都不好玩,而且对于业务也没有任何好处。
一个团队里面有多个任务,从本质上来说,还是人力溃乏. 高层们总是想用一个团队做多件事情,从实质上来说,最终带来的就是项目管理的失控. 用一个团队做多个项目,最终的结果就是代码开发工作好不容易完成,然后一些基本的测试都没有开始做,又进入另一个项目.而后,提交客户,换来抱怨,最后高层再说你们团队的技术如何如何的.最后带来的恶果就是项目的失败或者是半失败. 想用一块钱去买二块钱的东西,只能是表面上的,基本的工时得不到保障,量多有何意义. PM的恶梦.也是中国现在的中小公司的现状.
要看你选择的什么技术、怎么架构以及怎么的项目模式,用一种模式可能会一堆人围着一个项目都显得凌乱和整天加班; 而采取另外一种模式,可能使得您(一个人)或者一个小的团队就可以同时跑几个项目。
Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。
InfoQ中文站有幸与Google中国的产品经理杨巍先生在一起探讨了OpenSocial的相关话题,包括OpenSocial的初衷、构成要素、实现方式、以及要实现它的技术储备等等。
Ryan Cooper对Amr Elssamadisy的新书发表了评价,并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法,而是为读者提供一些模式和工具,用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
本视频主要对OpenSocial进行了分析,并对实现的方式进行了介绍。其中包括:OpenSocial的开发经验、Container Provider的技术准备、平台的构成要素、具体的规范、以及对未来的展望。
Memcached在大型网站被应用得越来越广泛,但是Java客户端并不多,本文作者基于现有的开源客户端进行了封装优化,并翔实记录了这一过程。
在他们文章的第二部分,作者探讨了动态业务应用的架构并介绍了资源容器的概念。他们示范了如何在JEE之上构建这个架构,以及它如何影响实现生产力。
ClickOnce让WinForms应用程序的部署轻而易举。David Cooksey演示了如何在ASP.NET中编写一个HttpHandler来实现对ClickOnce部署的版本细分。
2 条回复
回复