活动:
|
目的
|
|
角色:项目经理 | |
频率:按照要求,一般是每个阶段至少一次,然后在需要时重新访问。 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: |
工作流程明细: |
项目经理将在活动:定义项目组织和人员配备中已经确定迭代的人员配备需要,并将关注组织的人力资源功能,以提供具有所需领域、技能和经验背景的人员。大多数组织不会奢侈到为项目预备大量工作人员,而且项目的开始并不总是正好与先前项目的结束同步。所以,除了少数几个人员能一开始就参与项目外,许多人员经常需要在以后招聘。这可能是个长期的过程,所以精明的项目经理往往会未雨绸缪,在为当前迭代招聘人员的同时就开始准备将来迭代的人员了。加班加点地工作,或者使用承包人员而不使用长期员工,这两种方法也许可以弥补不足。但这两种解决方法也有缺点;人员层面上任何系统性的、持久的不足对于日程安排都是一个重大风险。
角色用于定义个人或一起工作的一组人在企业中的行为和职责。每个角色的行为都定义为一组活动。每个角色的职责通常是就某些工件(如文档)进行定义的。举例来说,角色有设计人员、软件设计人员和复审人员。由于要完成一组关联的活动,角色还潜在地规定了应具备的能力。
请注意,角色不是指个人,而是说明个人在企业中应该有怎样的行为以及这些个人承担什么职责。
项目一般可自行支配一定数目的资源,即具备特定能力的个人。例如,Joe、Marie、Paul 和 Sylvia 是几个具备不同能力(尽管部分能力有所重叠)的个人。根据流程中定义的角色,为个人扮演的角色安排在项目中可用的资源。
将个人与角色关联是随时间动态变化的,影响因素有阶段在项目生命周期所处的位置以及要执行的工作。
尝试要使职责的分配能让工件尽可能少地从一个资源传递到另一个资源:让同一个人或同一个团队设计并实现子系统,使他们不必重新了解已经由他人所做的工作。
当由同一个团队设计并实施时,从设计到实施的过渡就会很顺利。此外,它还使设计人员能更出色地工作:通过了解什么可行、什么不可行,他们就能更好地明白什么是好的设计,并将其用到未来的工作中。就像雕塑家一样,好的设计师必须了解用于表达的材料,而对于软件来讲,这种材料就是实施环境。
项目组织的形态和迭代所要求的人员配备级别已经由项目经理在活动:定义项目组织和人员配备中确定了。有了对实际资源可用性的了解,进一步要做的工作就是对结构进行微调并为该结构配备人员。项目经理应该重新检查所有七人以上的团队,看看是否有在结构上比较明显的方法来分解团队,即沿子系统线分解。
团队的组成应该最少两人,最多约七人;七人以上的团队往往会自然而然地自己分成小团队,所以最好替他们分开,免得出现其它麻烦。
将人员分成各个团队时,项目经理应该对团队的整体经验和熟悉程度很敏感,并且应该尝试让团队既有“新鲜血液”又有在项目中已经做了一段时间的人员。在项目开始时,项目经理必须依赖于将有经验的人员与较新的人员相混合。
在很多情况下,一份项目可用资源的能力的清单将在为角色分配团队成员时,显示出存在的差距(假设已经尝试了正常的、招募更多团队成员或聘请外部承包人员的方法)。在这种情况下就需要培养技能了。对这些人员必须进行适当的培训和指导,时间是就在他们需要这些技能前。不立即投入实践的培训会很快失去作用。通常情况下,正常的培训后如果能由导师带领开展一个研讨会来“启动”活动,这对于实践新技能将特别有用。
Rational Unified Process
|