活动:
|
目的
|
|
角色: 项目经理 | |
频率:每个迭代一次 | |
步骤 | |
输入工件: | 结果工件: |
工具向导: |
工作流程明细: |
目的 | 按职位、团队、职责和等级定义项目的组织结构。 |
项目组织结构的选择取决于项目的特征以及外部约束,例如现有组织策略。所以,很难规定这样的结构,因为哪种结构有效(或者甚至只是可行)将在很大程度上取决于环境。项目组织的形式和规模随阶段的不同而不同,将对软件开发计划(它是一份活动文档)进行更新以反映这些变化。
目的 | 定义项目所需人员的人数、类型(技能、领域)、经验和才能 |
根据项目的工作量估计、期望的进度安排、选择的组织结构和角色的映射,项目经理确定项目需要的人员配备概要情况(随时间推移的人员数量和技能集)。项目的工作量估计当然与团队规模、经验、技能和才干有关 - 当估计工作量时,项目经理很可能将对人员能力等作一些假设。在 COCOMO 估算模型中(请参阅活动:计划阶段和迭代),人员能力和经验是主要的工作驱动因素。所以,选择可接受的总工作量(通过调整各个不同的 COCOMO 工作驱动因素)和一个可行的进度安排将确定人员概要情况。
在一些情况下,项目经理可能提前知道可用的人员人数和技能。在这些情况下,假设项目范围保持恒定,则人员规模和技能集也恒定,只有进度安排可变。
项目经理还必须了解可能由于人员级别上升过快而造成的中断,以及尝试通过大幅度增加人员人数来过激地缩短进度安排,从而对生产率造成的潜在灾难性影响。
在先启期间,着重定义范围并确定范围边界,并为项目开发业务案例。因此,团队规模非常小:一名项目经理、一名软件设计人员、可能还有一到两名开发人员,尤其是需要原型的概念证明来阐明需求或为产品构造支持时。
在精化期间,重点主要放在体系结构和体系结构原型。因此,早期精化阶段的设计活动着重于体系结构方面的问题;对类和类属性的详细信息关注很少, 这些尽管已经识别的类和类属性在体系结构上不重要。在这些迭代期间,大多数工作源自您的体系结构团队和指定的原型团队。原型团队通常由较有经验的程序员组成。此时您有一个很小的设计团队,该团队将着重于一般机制和技术。测试团队将着重于构造测试环境和测试早期用例。
必须仔细挑选体系结构团队的成员:他们不仅应具备出众的分析和设计技能,而且应具备领导能力。为了在构造阶段将体系结构传达给较大的团队,好的做法是将体系结构团队的成员分配到构造团队中。体系结构团队的成员还需要具备广泛的软件工程经验:软件设计和实施、性能调整、数据库管理、网络管理和配置管理,包括在体系结构团队中必须具有的主要技能集。
构造阶段着重于在将不断增长的功能构造到系统中的同时,保持系统的体系结构完整性。这要求进行体系结构改进(这样在精化阶段之后,是体系结构的“设置基线”而不是“冻结”),还要求 体系结构团队关注设计员及其设计。
体系结构团队倾向于将他们自己分配到开发团队中,担当技术领导,并与其他技术领导协调组间事宜。构造团队本身必须是跨功能小组,同时具备设计和开发专长,因为他们同时负责分配给他们的功能的设计和实施。通常,构造团队负责一个或多个带有定义良好的接口的子系统;更改这些接口或者 添加新的子系统会导致体系结构更改,需要慎重考虑。在子系统内,团队可以相对自由地设计和实施它认为合适的内容,但需要跨团队的通信来确保团队没有在同时构造相同的实施机制。
通常,构造团队是沿着分层线水平组织的。一个团队可以负责数据库接口或者通信基础结构,而其它团队则着重于应用程序功能本身。因此“上”层团队需要问题领域中的更多专长,以及更多关于用户接口设计或与外部系统对接方面的专长。“下”层团队则与实施技术关系更紧密。这些团队的组成必须反映这些不同的技能需要。
测试中的第一个问题是需要进行多少正式测试? 然后,您能负担多少工作量以满足质量目标,而且该工作量在成本和进度安排方面还要处于合理的限制范围内。项目的预算很少能执行所有种类的测试。通常,项目必须选择一个它们能承受的测试级别。记住,必须检查和维持每个测试规范。如果有计划要创建许多测试规范,但由于时间不够而无法实施这些计划,那么会对项目团队的士气产生非常不好的影响。
创建特定的测试团队。测试团队中至少必须有一个人来自需求捕获团队。测试团队负责:
记住测试不仅仅是运行测试 - 它还要准备测试环境,撰写和检查测试规范。
应由独立小组来测试用例和整个系统。他们还应执行测试并撰写测试报告。应对测试用例的工作进行组织,以便每一个 用例都有一个专人负责测试。
如果不可能由独立小组来测试用例(例如小项目),您至少应确保负责用例设计的人员不测试该用例。
应对中型和大型项目使用自动回归测试。测试团队将需要一些程序员支持此能力。在迭代开发中这甚至更重要,因为您不想花费大量的工作来一遍遍地重新运行相同的测试套件。
在移交阶段,完成开发工作。进行 Beta 测试,准备最终发行版。如果构造阶段的工作完成得不错,项目团队可以开始规模缩放,以减少开发人员和测试员的数量。团队的混合将转换为偏重培训师和基础结构物流专家,这些人负责将产品部署到用户团体中。
软件设计人员或体系结构团队以“穷追方式”工作:他们帮助挑选出问题报告,划分变更建议的优先级,以及更改顺序,以确保不会为了图一时的方便就用会损坏体系结构的方式来纠正这些问题。设计活动在移交阶段会退后,并只限于纠正问题,或引入最新增强。
Rational Unified Process
|