Web服务项目角色
2008-7-18 8:17:12 作者:Olaf Zimmermann, Frank Mueller |
|
人员到角色的分派 每个角色都负责整个项目的一个不同方面。前面我们说过,一个人通常可以戴几顶帽子,换句话说,担当多个角色。如果各种具备渊博知识和多方面技能的人在一起工作,就会减少项目的风险。在有些情况下,只有这样的各种人开展有目的的合作才会揭示项目至关紧要的问题并且提出合理的解决方案。在另一方面,通信开销会随着每个新组员的加入而增加。没有单一且简单的答案来解决角色到人员映射的难题。关于应该如何着手处理这个问题存在许多不同的意见和争论(甚至本文的两位作者也没有达成一致的意见!)。 我们不继续这些争论,现在让我们来看一个小例子。考虑下面的场景:我们虚构一家来自保险业的公司,这家公司决定构建一组新的Mid-Office业务应用程序来用于风险和策略管理,这不可避免地涉及两种不同的后端系统。两种后端系统都已经作为J2EE应用程序构建好了—一个使用EJB,另一个只使用Servlet、JSP和JDBC来连接到它的客户和契约数据库。 在已启动的开发项目的初始阶段,会将上面定义的角色分派到组员。除了Web服务的特定活动之外,还要确定和分派标准的项目任务和角色。表二列出的是这项工作分解训练的结果。 您可以看到,除了项目管理员和商业分析员以外,所有其他的组员都戴了多顶帽子。而且根本没有分派属于额外角色的流程流建模人员,因为在这个场景中它是不需要的。 同时需要注意的是,这个例子是相当简单的;在实际项目中,需要有更大的项目组。根据我们成功的经验,在核心组的大小最好为7到10个的范围内。这完全取决于您所处的场景;为了避免您的工作分解结构由于过于复杂而变得难以处理,您可以将项目分解成几个阶段。换句话说,要确保项目按计划循序渐进地进行。这可以让项目组成员有机会学习这项工作并减少项目风险。在灵活的开发领域,这种原则称为连续集成(Continuous Integration)。 我们不再进一步在这里详述这个虚构的保险例子了。其实,它来自 Perspectives on Web Services 这本书(请参见http://www.ibm.com/developerWorks/cn/webservices/ws-roles/#6),在书中它是作为一个端到端案例研究以及未来引用实现的场景来描述的。如果您愿意,可以把本文看作是该书的一个小小的学习指南—其实践观点(Engag-ement Perspective)的延伸。 结束语
此文章共有5页 上一页 1 2 3 4 5 下一页
文章来源:互联网
软件开发项目管理培训课程方案
|
|
| 【发表评论】
【大 中 小】
【推荐】 【打印】
|
|
|
|
 |
图片广告 |
|
 |
热点文章 |
|
|
|
|