您的位置:软件测试 > 软件项目管理 > 进度管理 >
依据项目进度的人员组织实践
作者:网络转载 发布时间:[ 2013/7/15 14:30:16 ] 推荐标签:

2.3团队组织关系

一个项目中的两种角色安排的三种可能的关系,他们是:

1 产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中,可能是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个:第一,同时具有管理技能和技术技能的人很难找到。思考者很少,实干家更少,思考者-实干家太少了。第二,大型项目中,每个角色都必须全职工作,甚至还要加班。对负责人来说,很难在承担全部管理责任的同时,还能抽出时间进行技术工作。对技术主管来说,很难在保证设计的概念完整性,没有任何妥协的前提下,担任管理工作。

2 产品负责人作为总指挥,技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时,建立在技术决策上的权威。显然,产品负责人必须预先声明技术主管的技术权威,在即将出现的绝大部分测试用例中,他必须支持后者的技术决定。要达到这一点,产品责任人和技术主管必须在基本的技术理论上具有相似观点;他们必须在主要的技术问题出现之前,私下讨论它们;产品责任人必须对技术主管的技术才能表现出尊重。

3 技术主管作为总指挥,产品负责人充当其左右手。这种组合可以使工作很有效。不幸的是它很少被应用。不过,它至少有一个好处,即项目经理可以使用并不很擅长管理的技术天才来完成工作。

2.4团队组成

在一个大型项目中,软件项目经理必须为成员良好的分工,组成有层次的结构。

系统结构师,从上至下地进行所有的设计。要使工作易于管理,必须清晰地划分体系结构设计和实现之间的界线,系统结构师必须一丝不苟地专注于体系结构。

首席程序员。他亲自定义功能和性能技术说明书,设计程序,编制源代码,测试以及书写技术文档。

程序职员。他负责维护编程产品库中所有团队的技术记录。

编辑、秘书。首席程序员负责产生文档。而编辑进行分析和重新组织,提供各种参考信息和书目,对文档多个版本进行维护以及监督文档生成的机制。

工具维护人员。测试人员。

3. 团队交流

3.1手册、或者书面规格说明

手册是产品的外部规格说明,它描述和规定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。

随着用户和实现人员反馈的增加,规格说明中难以使用和难以构建实现的地方不断被指出,规格说明也不断地被重复准备和修改。然而对实现人员而言,修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。

手册不但要描述包括所有界面在内的用户可见的一切,它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴,而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实现过程。

规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。

3.2周例会

周例会由所有的结构师,加上硬件和软件实现人员代表和市场计划人员参与,由首席系统结构师主持。

会议中,任何人可以提出问题和修改意见,但是建议书通常是以书面形式,在会议之前分发。新问题通常会被讨论一些时间。重点是创新,而不仅仅是结论。该小组试图发现解决问题的新方法,然后少数解决方案会被传递给一个和几个结构师,详细地记录到书面的变更建议说明书中。

接着会对详细的变更建议做出决策。这会经历几个反复过程,实现人员和用户会仔细地进行考虑,正面和负面的意见都会被很好地描述。如果达成了共识,非常好;如果没有,则由首席结构师来决定。这需要花费时间,终所发布的结论是正式和果断的。

这种会议的卓有成效是由于:
 1.每周交流一次。因此,大家对项目相关的内容比较了解,不需要额外培训。
 2.上述小组十分睿智和敏锐,深刻理解所面对的问题,每个人都要承担义务。
 3.当问题出现时,在界线的内部和外部同时寻求解决方案。
 4.正式的书面建议强制了决策的制订,避免了会议草稿纪要方式的不一致。
 5.清晰地授予首席结构师决策的权力,避免了妥协和拖延。

3.3电话日志(交流日志,BBS等记录)

随着实现的推进,无论规格说明已经多么精确,还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释,还有一些仅仅是因为理解不当。讨论和解决,在BBS上做出记录。问题的答案(对问题的认识或者想法记录下来)必须是可以告知每个人的权威性结论。

3.4质量会议

项目经理好的朋友是他每天要面对的敌人——独立的产品测试机构/小组。该小组根据规格说明检查机器和程序,充当麻烦的代言人,查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门,来保证其公正性。

4. 为变化组织架构

每个人被分派的工作必须是多样的、富有拓展性的工作,从技术角度而言,整个团队可以灵活地安排。

当系统发生变化时,管理结构也需要进行调整。管理人员和技术人才的能力给予培养,使管理人员和技术人才具有互换性。

管理人员需要参与技术课程,高级技术人才需要进行管理培训。项目目标、进展、管理问题必须在人员整体中得到共享。

上一页12下一页
软件测试工具 | 联系我们 | 投诉建议 | 诚聘英才 | 申请使用列表 | 网站地图
沪ICP备07036474 2003-2017 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd