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