授课视频在线视频

嗨，大家好

今天我们开始讨论SQA的组织结构和岗位职责

大家都知道，SQA的核心就是通过保障软件开发
过程

当中满足指定的开发规范来保证产品质量

开发规范的制定和遵守必须动用

整个组织的力量才能做好

同时，企业中的SQA组织不仅决定了SQA人员的
职责

还决定了相关资源的配置方式

一般的，软件开发企业中的SQA组织结构

可以分为职能结构，矩阵结构，以及混合了

这两种结构优点的混杂结构，也叫柔性结构

首先我们来看职能结构的SQA组织

在职能结构中，各个职能部门都设有自己的QA岗
位

它位于高级经理之下，独立于项目组

QA直接对高级经理负责

但业务上他需要向项目经理汇报，属于项目成员

职能结构的优点是QA和项目组成员在一起工作

比较容易融入项目组，容易发现实质性的开发问
题

解决问题也很便捷

职能结构的缺点是各个职能部门相对独立

部门与部门之间缺乏经验的交流和共享

还可能会出现对过程、方法和工具的重复性投资

在这种组织结构下

由于高级经理专注于业务的发展

往往会忽略QA的发展

所以呢，QA的职业发展可能会受到忽视

不容易得到应有的培训和提升

下面我们来看矩阵结构的SQA组织

这种结构设立了专门的QA部门

与各个业务职能部门平级

QA隶属于QA部门，行政上向QA经理负责

业务上向业务部门的高级经理和项目经理汇报

在矩阵结构中，由QA部门经理对QA进行考评和
授权

这有利于保证QA的独立性和评价的客观性

也有利于确保组织的长期利益

与项目或个人的短期利益之间的平衡

在矩阵结构中，QA资源为所有的项目所共享

可以按照项目的优先级进行动态的调配

因此QA资源的利用更加充分

但也可能会出现竞争的情况

QA部门负责对QA流程进行改进，QA知识进行管
理

QA的人员进行负责

并且可以集中资源进行QA的平台建设

以防止重复性的投资

矩阵结构的不足之处在于，QA属于空降兵

平时不和项目组成员在一起摸爬滚打

很难融入项目组，不容易发现开发中的流程问题

而且发现的问题也不容易得到及时有效的解决

混杂结构，也叫柔性结构

是职能结构和矩阵结构的混合形态

它在职能结构的基础上组建了一个QA工作组

需要注意的是，QA工作组是一个专业小组

它不是一个行政机构

QA工作组的组长可以由质量管理部门委派人员担
任

也可以由某个业务部门的QA来兼任

与职能机构一样，QA直接对高级经理负责

但在业务上向项目经理和QA工作组组长汇报

柔性结构吸收了职能结构和矩阵结构的许多优点

既便于QA融入项目组，又便于部门之间经验共享

还有利于QA能力的提高

QA工作组组长可以从各个职能部门QA的工作汇
报当中

提取出那些各个项目共有的共性问题

用于组织级过程的改进

企业还可以通过授予QA工作组组长不同的权利

比如按照八二原则与高级经理分配QA的管理权限

来促进QA人员专业研究与应用的结合

在软件过程成熟度模型CMM中

分配给QA的主要工作是过程评审和产品审计

但是从实践经验来看

QA如果只完成这两项工作，很难体现出他的价值

为了让QA组织的产出大于组织的投入，实现增值

我们一般会根据企业的需要适当的增加QA的职责

比如过程指导、过程度量和过程改进等等

具体来说，就是要求QA在项目前期帮助项目经理

制定项目计划，包括定义和修改项目的过程

和过程模型、计算项目估计、建立项目的验收准
则

设置质量目标等等

还有就是对项目成员进行过程和规范的培训

以及在过程中进行指导

过程度量和产品度量在CMM中已经成为一个单独
的过程域

是对所有过程的一个共性要求

成熟度越高，对度量的要求也越高，难度也越大

这时候QA的主要职责就要包括收集、统计

分析度量数据，以支持管理信息的需求

在CMM中，过程改进主要是工程过程组EPG的职
责

但事实上，QA更接近于工程过程的实施环境

更了解过程运行的情况

也就更容易发现“木桶中最短的那块”

因此QA也是过程实施的重要推进力量

在确定QA职责的时候我们还要考虑企业自身的需
要和环境

主要包括业务需求、过程成熟度水平以及企业文
化

业务需求主要是确定了QA需要完成的工作

比如在执行同行评审的过程中

QA可以协助评审和组织会议

在存在着外包的情况下

可能需要QA在监控外包方面发挥作用

过程成熟度是影响QA职责分配很重要的因素

不同的成熟度等级所要求的QA工作的分布是不同
的

一般来说，成熟度越高，开发人员素质越高

QA的工作就会从简单的过程指导

转移到更复杂的过程优化上

企业文化对QA来说就像空气一样

看不见，但却深深地被它影响

在一个氛围活跃、技术高新、创新能力强的企业

QA应该倾向于服务的职责

而在一个强纪律、低技术、规章制度成熟的企业

QA就应该倾向于监督的职责

下面我们来具体看一下过程能力成熟度

对QA岗位职责的影响

在这个图中，X轴是企业的软件开发过程成熟度等
级

等级越高，我们可以简单的理解为企业的开发水
平越高

产品质量也能得到保障

Y轴是QA的工作职责构成百分比

在低成熟度等级下

QA需要花费大量的时间和精力

来抽取各个项目的最佳实践来定义过程

并指导过程的实施

随着过程的完善和制度化

QA的工作重点逐渐转向了过程评审和产品审计

当企业的过程成熟度达到4级或5级的时候

对过程的遵守已经成为了员工的一种习惯

这时候过程的评审和产品的审计需求变少

而度量和过程能力的优化又成了QA的主要工作重
点

QA的工作比较特殊，QA的岗位设置

也与公司的团队规模，项目大小等等因素有关

一般的我们可以考虑设置专职的QA岗位或兼职的
QA岗位

同时还要考虑知识、技能和素质是不是符合

岗位和组织的规定与要求

这些要求是根据企业文化和成熟度的不同而有所
侧重

同时呢要小心地与组织制度相结合

比如奖惩制度、成本制度等

否则很容易引起利益的冲突

相对而言，QA是一个旁观者和指导者的身份

我们应该把这种身份的优势充分的利用起来

比如在实际工作中

我们可以采取QA和项目经理岗位轮换的方式

也就是让项目经理在QA岗位和项目管理岗位上进
行轮换

我们把一定时间的QA工作经历当作项目经理

上岗的必备条件

这样不但可以让项目经理在QA的岗位上

充分发挥自己的实践工作经验

当好一个过程指导者

而且QA的工作经历还可以让项目经理

以旁观者的角度来审视自己的管理工作

有利于项目经理的自我提升

我们知道，在软件开发活动中

确保开发人员遵守开发规范是QA的一项主要任务

那么这些规范是怎么来的呢？

要想获得这些规范并不难

很多技术资料中都给出了很多很好的建议

按照从简单到复杂的顺序

过程规范的开发一般流程是这样的

查阅资料，制定规范，理解规范，接收反馈

然后修改规范

过程规范的定义是非常具体的

类似于作业流程，抽象的规范是没有意义的

我们制定规范的时候，还要考虑到规范的可操作
性

与抽象性之间的权衡，避免规范过于僵化

限制了软件开发活动的创造性和灵活性

有了规范是一回事

能不能把规范运用起来则取决于开发人员的实际
技能

举个例子来说

如果大部分的程序员没有足够的

异常处理方面的技能

那么有关异常管理方面的规范

也就很不容易得到有效的执行和遵守

学会使用异常并不困难

困难的是如何让程序员正确的使用异常

什么时候使用系统定义的异常

什么时候使用自定义的异常

自定义异常又该如何设计等等

这些都是程序员的技能问题

培训和训练是提高开发技能的有效方法

因此，一方面我们要积极开发科学合理的过程规
范

另一方面我们要加强对开发人员技能的培训

只有这样，才能有效的提高过程质量和产品质量

好，今天就讨论到这里，谢谢大家