关于“SQA职责”的讨论

关于“SQA职责”的讨论

发布时间：2008-05-08 17:00:38  来源：  作者：  点击：460

hjhza
在谈QA的职责的时候，首先要了解质量问题会出现在那些方面，因为这是质量保证的重点。我们经常说，质量是制造出来的，是设计出来的，所以QA对整个过程都应该跟踪。但是如果是整个过程跟踪，就出现了缺少重点的问题，没有重点那就难以监控了。所以必须要了解整个开发过程中那些是必须被监控的，那些是可以放松力度的，那些是不必要去监控的（这些根据公司对QA的定义而要求不同）。在确定了这些事情后，就要对必须被监控的东西进行分类，进行排序。这样可以让QA的主要经历放在关键地方（一般来说，中国的软件企业不会要求到一点问题都没有，所以有的地方可以放松，这也是出于成本的考虑）。
在过程中，QA一般比较注重的是过程是否符合规范？测试是否合理、充分？评审是否及时、有效等，这些是重要的“检验”过程，可以列为重点。对于过程符合规范来说就比较复杂了，首先要看过程有没有计划，计划详细与否，可行与否，工作量评估是否可行（主要是检查评估方法）？日常管理是否可行？配置管理是否可行？过程遵循那些标准？实施什么样的裁减......
QA在做这些工作的时候，必须遵照公司的要求进行，如果公司没相关规范，那你就中奖了！除非你懂得项目管理，可以从中知道PM，要不然，嘿嘿......
在整个过程的监督中，QA需要具备一定的数据意识，要不断的收集各种数据，尤其是质量数据。现在大多数的QA基本只是收集与时间有关的数据，这是不够的！
QA最好具备一定的项目管理经验，要不然，你只能是一种边缘参与，是进入不了项目的。最好能帮助PM将问题分析清楚。PM会思考要将问题做成什么样子，而QA可以思考如何去做，这样就可以达到一种配合的效果。
其次还要注意一点，就是QA以什么心态去监控项目组，我们公司提出的是“质量服务”，也就是说，项目组是我们的客户，我们是为他们提供质量服务的。
QA不是监督人，但是必须了解人！
QA应该注重过程！
QA应该加薪！
QA应该升职！
.......
zuoxuhe
SQA本身就要求按照项目式进行动作，即要遵循计划-执行-变更控制，所以应该根据你的SQA计划来确定是否对此报告组织评审，而不是等到PM提交了项目开发报告才决定怎样做，否则您只能对其过程按照公司规定的流程或模板进行检查.
hjhza
我们所谈论的SQA可能在不同的公司有不同的要求。据我了解，中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型。前两者基本上需要跟踪项目，但后者不一定了。
fondtiger
hjhza 说得非常好，特别是“项目组是我们的客户”这句话。 不过有个问题想问一下，SQA的工作时间当中，真正用来监控项目组的时间是不是只占一半，另一半时间是用来提高自己的水平的，或者说是用来提高自己的项目分析能力和项目的过程改进等问题的？
hjhza
这个也不一定，至于用多大的力度，分配多少时间来监控项目，可以根据不同时间来安排。基本上SQA需要负责质量体系的建立，编写各种质量规范文档，如果再监控多个项目，那就不一定了......
根据我的经验，项目监控占不了一般时间，我最多时监控3个项目。这个时候就可能需要全部时间了！
rhettchj
To APING15A,
我个人认为，你现在一方面需要想办法如何执行一些具体的工作，如你上面提到的问题。另外一方面，你更加需要做更重要的事：你们公司的SQA活动如何去做，需要做什么？
你再看一看SQA KPA中的CO，AB，对照于你公司现状，现在是否具备了呢？
我觉得hjhza谈的非常好，SQA应该有工作重点，工作重点就是由管理层的策略延伸出来的。而且只有把SQA的工作与公司的整体动作一致，才能显出来SQA的价值。hjhza把SQA分为三种类型，有一定的道理(这个当然也和具体公司有关系)，但是你想象一下：如果别人其实期望SQA做过程改进，他整天只能发现测试人员和SCM的问题，那样如何满足SQA的工作目标呢？所以，没有整体的，则公司级进行的统一考虑，那么SQA只能是会干什么，想到该干什么不，就做什么。这样，对公司，对个人都是不利的。
rhettchj
To hjhza,
我觉得你说的很精彩，不过想再向你请教一个问题：现在公司中常常会因为成本，或者其他的什么原因，而造成项目有可能不按规范而执行。这有两个前提：规范是最全面的，要求较高的；另外所有不按规范执行的，即项目裁剪的部分必须得到(SEPG)的同意。这样就达到了你所说的工作有重点的目的。
但是依据什么样的原则呢？我觉得是有两个层次的：公司的，项目的。但是依你所说，好象不是很明显，你是如何看的呢？
hjhza
to Rhettchj：
关于工程裁减的标准还真是个难题。我也不清楚，不过可以谈谈我的看法。现在在中国很少有人经历过其他开发模型，基本上都是瀑布模型。所以这个裁减首先是比较“狭隘”的。就说说在瀑布模型上的裁减吧（我稍微经历过）。
裁减首先分为过程裁减、文档/产物裁减和裁减阶段。这两种裁减可以根据不同的项目有不同的表现，比如一个外包项目，是从详细设计接到的，那就不需要做上游的工作了。再比方说某项目进行一个Demo开发等。
我觉得划分标准应该从：
1、裁减过程
2、裁减文档/产物
3、裁减阶段（包括过程和产物）上来划分。但最好是经过客户的允诺。
我们要求的是质量，信服的是“质量是制造出来的”，所以对过程的节减更加重视（包括阶段裁减）。如果公司已经有了质量体系，并且是被严格按照执行的，那么就应该通过权利部门审批/SEPG的评审，这可能就像你所说的公司级别的吧。如果你的质量体系非常明确的提出了每个工程过程，那么在裁减这些过程的时候（整个过程的裁减），可以作为一个公司级别的标准。
对于文档裁减可以适当放松，但是仅仅局限于比较小的文档，如果是非常重要的，如概要、详细设计说明书，就应该作一些必要的审核，应该上报。那些文档的裁减和项目可以自己灵活处理的事情的裁减可能像你所说的项目级别的。
其实一个项目在实施之前就应该将这些裁减内容写到质量保证计划中，然后提交评审。裁减不应该是随意的。裁减的最好依据就是客户，如果实在时间非常紧的情况下，客户是会同意的，但一定要他签字，否则他有可能赖帐！
其实裁减本身就是一种质量等级的划分，如果完全按照规范走，那就会生产出“最佳”产品，但如果不安规范走，可能会出问题，这就是“次佳”品。如果质量等级能达到量化的水平，那就可以解决这个问题了。
CMM是基于项目的，这个意思是每个项目都有不同的地方，这是承认的，可以有工程过程上的不同，CMM在这方面没有作要求！
对于其他模型的裁减，我想也只能按照裁减内容的大小，再加上本项目的重要程度来划分。
对于裁减的标准很难说清，比方说一个项目对公司来说是至关重要的，但又是工期紧张的，那么这时候的裁减应该时时汇报，至少要让权力部门了解。只有灵活处理了。
rhettchj
高，hjhza写的真是太好咧!
我真的很受启发。我把自己的理解也在这儿说一说吧。因为我很想再谈深一层，看看裁剪的标准是不是有个规律，我觉得应该还是有大致的规律。
我现在遇到的问题就是我们在CMM实施的过程中，经常需要对SEPG组制定的规范进行裁剪，以适合项目的需要。但因为我们做的是2级，所以刚开始优先级不高，但现在改进到一定阶段，这个问题就突出了。
如果把裁剪分为三种：过程裁剪、阶段裁剪、文档/产品/工作产品裁剪。那么我想过程裁剪应该是与公司的质量保证体系的结构有关的。比如说：公司的质量体系是由10个过程文件组成的，其中一个是有关阶段性管理评审的
。那么对于小于X月的，就可以不走这个管理评审过程(等评审的时候，还不如把周例会抓严一些呢)。
对于阶段裁剪、工作产品裁剪，我觉着就是与软件项目所选择的软件生命周期有很大关系了。在选择软件生命周期时，又与项目的具体内容、目标、环境和执行策略有很大关系，所以可以在划分项目类型(产品项目、工程项目、
维护型、特殊任务型、系统迁移型等等)，再考虑其它附加因素，决定对项目的特定执行阶段及工作产品进行裁剪。比如说：我们有一个Domino平台上的项目，那么它可能在配置管理方面，就暂时没有好的工具可用，那么为了效率，可以减少一些配置管理活动的输出。对于这类项目的设计，也可以用一个不同的设计模板(因为设计要素与其它平台的不同)；维护型项目就可以免掉一些阶段。
所以，我刚才想了想，基本上有以下几个原则可以作为裁剪的标准点：
1)项目规模(可以按项目组成员数、项目估计工期、项目估计工作量等，但最好同时进行权衡)分为大、中、小3级？
2)按软件生命周期的不同。原型法、增量型、瀑布？
3)按项目内容的不同。如全新项目、维护型、特殊任务型、迁移系统型等等。
然后考虑以上标准，作两张矩阵表：
1)对各工作产品的影响；
2)其它不能由工作体现出来的影响。(如阶段，SCM活动，SQA活动，评审活动等等)。我还基本上觉得可行，不知道hjhza有何见教？
哎，同志们有想法的，还有实际正在做的，多指点指点，多谢了!
rhettchj
To APING15A,
能起“沟通桥梁”的作用也不错。我非常理解你现在的情况，因为我有一段也是这样的。看来要添第4种类型的SQA了。
不过，我认为现实一些的话，千万不要抱怨(否则还不如早些闪人)，而要想办法“改进”一些。
进度、成本、规模、质量，这4个基本度量要素中，越来越难。也难怪高层领导不重视。刚开始时，一般都是这样的，大部分人都把进度等同于后面的。其实他们也想看到后面的数据，但是进度是最明显的，所以一般都是先拿进
度开刀，进行管理。
但仅偏于进度的管理是远不够的。要想说服高层领导，获得PM及SM的支持，最重要是让他们看到效益。所以说话时，要转成金额，用钱说话。
你可以想像得到：对于只重视项目进度的项目经理来讲，一般2个月的工期，至少有2周的返工时间是纯粹用来重复干活的。这也是钱哪!
还有一个数据最有力的，就是项目的延期比率，估计一般都至少延70%。
如果管理者看到他们在赔钱，在浪费预算，就开始重视了。这时就要看你如何把想法变成现实了。我自己的建议是：
1)过程无谓好歹，但弄一套。最简单的，最实用的，漏洞最多的，文档化的(就象画地图，先画中国的公鸡状，再画各省的边界，再画市县，一步一步来吧。最重要是：纲举目张)。
2)分析影响进度的最主要原因，只抓1
2个，用3个月时间，在至少1个项目中间证明你的办法有效率(但切记，一开始绝对不要承诺管理层可以缩减进度，这是不可能的。最关键是：项目感觉上可控了，了，返工时间减少了)。
个人经验，供参考。
aping15a
非常感谢rhettchj！
我想我现在最重要的是先把过程给做出来，老是这么口头上说说没有实际的文档是等于空谈！
本来我是这样做的，不过我写出来的东西没人看，所以我也就失去信心了！我得硬着头皮把这件事情先完成再考虑后续的工作，有了文档也好和领导沟通，是不是？
还有什么建议吗？悉心请教！
hjhza
to Rhettchj：
对于一个项目的大小的评估，建议你采取国标里的那个方法，我觉得很好，也很全面的。
我觉得在裁减的时候，首先应该考虑到技术，如果已经比较成熟，可以办到，那就可以裁减；其次考虑管理。如果管理过程比较成熟了，那也可以进行。我们可以将流程性的（工序方面的，比方说需求、概要、详细等）作为技术过程，将支持性的过程（比方说SCM、SPTO、SPP等）作为管理过程。
在中国，一般来说，这种裁减应用在管理过程（包括项目组内部的会议和相关制度）和文档/产物上，基本上不敢采取阶段的裁减，在国外也很少。
裁减的目的是尽快产出一个“可用”的产物，如果不可用，那就不能裁减。经常发生的一种情况是：“裁减了，反而工期延长了，而且总工期比原不裁减的工期更长??自找麻烦！
所以在裁减的时候，还应该考虑公司的技术水平和管理水平。
裁减应该慎重！
rhettchj
想请教hjhza，国标中的哪个标准提到了项目大小的标准呢？俺回头找找？
To aping15a,不知道你现在有没有CMM评估的压力。如果有评估的期限压力的话，那么最关键的就是先找着自己公司什么地方可以改进，划分优先级。然后多调动一些资源来进行行动计划的制定和实施。 我的体会，虽然有时有期限的压力，但真要做到实处，还是要一步一步来的。我觉得你目前最重要的还是投入问题，即是资源问题。如果你不能加人的话，那么就需要向你的经理提议：成立虚拟的PAT（Process Action Team）来补充人力和能力。PAT在会制定过程、实施过程中起到很大的作用。你们现在质量部毕竟还人少吗。
当然，这些人员控制和协调还是有些麻烦的。但好歹能向下走。
hjhza
是GB8567－88的附录O,
注意啊，最后那个O不是零啊！
aping15a
To rhettchj,
一个好消息：我没有评估的压力
一个坏消息：质量部就我一个人，公司一直说要组织这组织那，但一直没有实现！我光杆一个！
虽然没有评估期限上的压力，不过有工作上的压力！
因为总不能坐在这里什么活都不出吧，而且对自己的发展也没好处！资源是严重不足！
hjhza
to Aping15a:
我觉得你的公司现在缺少的是一种质量意识。他们可能还不是很了解质量管理到底会带来什么？应该如何去做？我的感觉是“当一个事情停滞不前的时候，是因为没有认识清楚”。你先多作作宣传性的工作吧！
宣传性的工作最好能够得到竞争对手的情况，这对公司来说是很有影响力的。其次将国内外的一些情况做一下报告，尤其是大公司的质量管理情况。
你有一份质量工作计划吗？比方说2年计划等，如果没有就做一个，至少可以让自己有个目标。
aping15a
质量意识啊，人人都知道质量带来效益，大道理人人都知道啊，但是具体要落实到自己头上的话，未必就愿意了！
我现在是很没有目标。质量工作计划没有，能指导一下吗？
确实，SQA要求别人工作都要有计划，自己却没有计划，我工作上存在很多的思想问题啊！还须好好的理解！
hjhza
质量意识不光是“认识”，更要让他们认识到紧迫性，要让他们了解实施的可行性，可操作性。要让别人觉得不难，很容易做到。关键是对我们现在有什么改变，可以改变那些状态？现在这种状态如何？最好能够阐述清楚。
一般来说，一个没有经过任何规范限制的程序员在进入CMM的限制的时候，会有很大的抵触，但一旦他实施了CMM，他也就不会再把CMM（规范）丢掉了，他也体会到了好处。
工作计划吗，你自己先给一个假设（两年后，质量应该达到什么程度？过CMM2？），不要太空洞。然后将工作分解，这样一步一步的走。当遇举步唯艰或者没有头绪的时候就回头总结，会给你很多灵感的！在这个过程中，你也就发现了自己的不足，也知道了该学习什么了。
不要讲困难，去研究方法吧！
grief
安排召开项目计划复审会议的时间
项目计划复审会议的与会者应该包括高级管理层代表以及按照软件开发计划要求为项目投入资源的所有团体的代表（例如开发/工程、操作、QA、测试、客户支持等）。一般情况下，这些代表将是项目复审委员会的组成成员以
及负责项目团队中不同职能部门的团队领导。
一旦确定项目计划复审会议的与会者，就要确定会议的召开日期/时间。务必要为与会者提供足够的准备时间，让他们能够复审将用作批准决定依据的项目材料。
召开项目计划复审会议
查找计划中的任何错误假设或遗漏。应当考虑如下方面：
A.该计划是否能够满足在商业理由和前景中确定的需要？
B.计划能否在商业理由大致规定的日程和预算内交付出预期结果？
C.制定计划的详尽程度是否达到可以符合实际地预计项目的结果？
D.是否已做好使用合理的分析方法进行项目估计的准备？
E.是否以足够频繁的间隔安排了各个复审点和里程碑的时间？
F.计划是否能够减轻/避免所有重大风险？
G.计划中是否确定了足够的资源？这些资源是否是现有的/可获得的？
H.角色和责任是否已明确规定？
I.计划规定的监测与控制过程是否可以接受？
J.是否所有完成的支持计划和指南都有可接受的详细程度？
决定是否批准该计划。结果可能是：
A.批准计划 项目将按计划进行。高级管理层为项目投入其余的资金和资源。
B.取消项目 鉴于已知的风险和项目预算/时间表，项目不再可行。
C.推迟决定 需要获得更多信息，或必须进行进一步的调查，然后才能作出是否批准的决定。