质量保证：是否应该保持一个独立的组织

 

质量保证：是否应该保持一个独立的组织
 

陈能技

2007-9-10

 

原文：Software Quality Assurance Should It Remain a Separate Organization- Johanna Rothman

 

产品开发组是为了组织起来制造人们会买的一个产品。组织产品开发组的第二个目的是拥有不断地制造产品的能力。为了达到这些目的，产品开发组一般组织成功能型的团队或项目型的团队。特别是在软件工程中，很多时候很难在产品开发组和SQA之间划分界限。

 

背景：什么是软件工程?

为了方便讨论开发组和SQA组之间是合并在一起，还是划分开来，让我们先来看一下软件工程涉及的任务：定义需求、设计和实现产品并进行测试、产品验证、发布。软件工程的目的是：通过制造人们会购买的产品来为公司赚钱。

 

软件工程人员必须判断对于顾客来说什么是质量，定义如何制造产品（产品开发流程），设计、实现、测试和发布产品。另外，软件工程师必须能够从前一个项目中犯的错误学习。

 

很多组织对质量的定义只是对缺陷的度量。然而，这是很有限的定义。为了真正地定义质量，我们还需要考虑功能、可用性、可靠性、性能和配套支持。把项目的质量定义好了，才能更加精确地制定流程和权衡项目。

 

软件工程角色

我们来看看软件开发和软件质量保证人员的角色。软件开发人员定义需求、设计和实现产品，并最低限度地验证产品是否满足需求。开发人员经常使用功能规格、设计文档和原型来帮助定义需求。当开发人员设计和实现代码时，他们编写详细的设计文档、编写代码，编译并进行单元测试。开发人员也会通过集成测试来验证产品。

 

软件质量保证人员，产品的验证者，定义产品的测试需求、设计、实现和验证测试，验证产品符合需求。SQA工程师使用测试规格和测试场景设计来帮助定义测试和产品需求。当SQA工程师设计、实现和验证测试时，他们会编写详细的测试场景、编写测试脚本代码或测试用例、编译并验证测试代码。他们通过系统测试来验证产品满足需求-系统地测试产品的所有功能。

 

在这两个过程中有明显的相似之处：都定义需求，设计和实现产品或测试代码并验证他们的开发活动。产品开发人员的输出专注于可交付的产品-发布的代码。产品验证者的输出专注于不交付的产品-保留的（测试）代码。

 

但是也有很多不同之处：开发人员倾向于专门的领域-他们理解和开发产品的一个相对窄的领域。SQA工程师倾向于拥有更全面的视角-他们理解产品的整体并收集数据以理解产品的状态。因此，即使过程很类似，工作的专注点有较大的区别。

 

专注点的不同往往导致技术技能的不同，特别是在测试区域。单元测试开发需要产品代码的知识，对代码覆盖的理解并指导怎样衡量。集成测试需要明白配置管理系统并知道如何正确地集成产品。另外，集成测试需要有系统的架构知识，从而恰当地整合这些基本的测试。系统测试除了需要不同的技术外，系统测试开发还需要产品和代码的知识，用于发现和测试错误集中的区域。

 

既然软件产品开发的目的不仅仅是制造一个产品，而是重复成功地制造更多的产品。我们能否利用这些开发和验证之间的相似过程来组织软件产品开发呢？

 

功能型产品开发组织

如果产品开发是以功能型来组织的，开发人员、SQA、文档人员、工具、发布工程师都是独立的小组。一般会有比较多的开发人员或开发小组，所以开发组就默认地拥有了产品开发方法论。开发人员定义他们做什么，其他小组的职责是什么，开发人员是产品开发的驱动力量。一般SQA组拥有的是验证和发布过程。SQA定义测试什么和什么时候测试，发布的标准是什么。

 

这种功能型的组织的好处是：

1、 产品的创作者和测试者至少在技术贡献方面是独立的。

2、 经理知道如何培养这个组织

 

问题是：

1、 SQA很迟才参与到项目周期中

2、 即使选中的是一个全面的项目领导，也很难有动力去改进产品开发过程

3、 缺乏跨组织功能的指导和增长

 

功能型经理，授权的团队

在这个模型下，还是会划分功能区域：开发经理、SQA经理和他们的职员。管理层拥有方法论、工具、过程问题。团队拥有产品开发、文档和验证过程。目的是在一个大的项目组中创建一个小的项目组，然后允许技术贡献者选择最合适自己的角色。

 

这跟传统的矩阵型管理类似，但是传统的矩阵型管理由经理为项目组指定角色。授权型的项目组为每一个项目组成员选择合适的角色。

 

项目组成员定义他们自己的角色，怎样工作。经理在有问题时进行指导。也会有集中的组，如果他们为不同的组工作的话，例如工具开发组。

 

这种组织的好处是：

1、 项目组把问题系统地考虑、系统地解决。

2、 经理能更容易保持项目历史记录

3、 这使得人们更容易进行职业培训。能者多劳，不能者少做点。

4、 项目组成员可以在整体的产品开发流程中正确地定义工作-他们能用适合他们自己的要求的方式定义如何使用流程

 

问题是：

1、 不够稳定，因为不能满足很多经理的控制要求

2、 经理可能会偷懒不去记录全体的历史

3、 如果管理层对角色定义有太多的输入，技术贡献者可能会被归类成一种角色

4、 这对于小团队不实用（30人以下）

 

自我组织的产品组

自我组织的产品组由经理作为项目领导。管理层的作用是职业培训、为项目组争取好的项目。

关键点是项目领导不掌握所有信息-项目知识被项目组成员共享。

 

项目组成员之间必须互相信任，共享知识并拥有足够的能力来完成工作。项目组成员之间可以交换角色，或使用结对制。

 

交换角色的例子如下：

Module	Product Code	Documentation	Test Code	Tool Code
A	Jo	Jim	Jack	Jill
B	Jill	Jo	Jim	Jack
C	Jack	Jill	Jo	Jim
D	Jill	Jo	Jim	Jack

在这个例子里，所有人都会在所有角色之间交换。这不常见，不同的人有不同的才能和角色，他们会希望做相对固定的工作。那么结对制(buddy system)就比较高效率了。例如：

Module	Product Code	Documentation	Test Code	Tool Code
A	Sally	Sue	Sam	Stone
B	Sue	Sally	Stone	Sam
C	Sally	Sam	Sue	Stone
D	Sam	Sally	Stone	Sue

在这里，两个人工作在一起，为某个任务集合服务，例如产品代码或文档、测试代码或工具代码。取决于模块，有些人也会转换角色，但是仍然与同伴一起在同一个模块工作。

 

这种组织的好处是：

1、 除了用系统的方法解决问题外，项目组还能学习流程和产品。个人还可以选择学习哪个区域。

2、 项目组有能力进入一个高效的产品开发状态

3、 项目组能快速地开发它的工具和方法论

4、 项目组能以适合自己的方式定义怎样使用流程

5、 项目组完全是自我授权的。

 

问题是：

1、 组织是不稳定的，因为不能满足很多经理的控制需求

2、 即使经理保持了项目组的整体历史记录，项目组还使必须找到方法传递它的知识。对于如何把成功的项目组经验传递给其他组没有清晰的答案。如果这个项目组分解了，项目组成员的知识如何传递？

3、 如果项目组缺乏能力，或者知识有限，项目组会失败

4、 如果管理层对角色定义有太多的输入，技术贡献者可能会被归类成一种角色

5、 这种方式可能不适用于大的组织（70人以上）

 

结论

产品开发组织专注在开发高质量的产品，以便满足用户购买的需要。需要考虑最佳的组织结构。不是为了组织需要而把任务和人分割到功能型的小组。产品可能需要一个专注于项目的小组，专注于产品，而不是组织结构。

 

当产品开发组考虑他们的组织需要时，他们需要考虑员工、质量需求、过程需求和项目的类型。在很多情况下，把产品开发人员和产品验证人员整合到项目组会有很多积极的作用，例如对于项目进度、产品质量、项目团队知识的增长都有积极的作用。随着团队的知识的增长，管理层可以信任团队是可以满足进度和产品发布要求的。

 

尤其是作为从开始阶段转入成熟阶段的公司产品，管理层必须有灵活的方法管理团队组织。即使管理达到某种程度的成功，但是能否保持每次都成功才是管理的关键所在。