在东软的工作随想

相关链接：《在东软的工作随想》评论之评论<script language="javascript" type="text/javascript"> document.title="《在东软的工作随想》评论之评论 - "+document.title </script>

量化的作用

在CMMI4中，软件过程能力被概括为可预测的。该阶段内，在明确软件产品和过程的质量目标的同时，需要采集有关产品和过程的组织层测量并将其妥善定义确保一致，以此来保证用于评价过程性能的定量基础。要达到可预测的目标，首先要做到量化。因此，在长期以来的实际工作过程当中，我一直将量化作为一项基本依据来指导工作的持续改进。通过最近的一个阶段在东软的实际工作，我对量化在对日软件项目中的作用有了新的认识。

首先，要承认量化对实际工作的指导意义。例如：统计式样变更点数以指导计划的变更、统计测试点数以估算测试周期等等。但是，在东软，量化数据除了用于指导和持续改进自身工作以外，还发挥了更大的作用，那就是作为沟通依据。

在工作过程中，我十分注意在会议中记录与客户的沟通方式。尤其关注在发生矛盾时，是如何表达自己的意见来说服对方。举个例子：有一次客户突然提出要删除一个库表，而该库表的删除会直接导致近20个机能的大幅修改。这个改动工作量对我们本来就很紧张的项目来说是非常庞大的。项目组因此召开了紧急会议。针对这个问题，提出了3点处理办法：第一，统计变更工作量。要量化到变更点这个层次；第二，做好修改项目计划的准备，估算可能发生的延迟周期；第三，与客户沟通尽力挽回该库表的变更。会议结束后，项目组全体成员开始统计数据，待变更点和延迟周期等数据有了明确结果，并且找到了变通的办法时，正式向客户提出我们的意见。以明确的数字作为依据的论据确实很有说服力，客户很快接受了我们的折衷方案：新建一个视图来代替原来的库表。从而避免了大量的变更工作。虽然整个过程用了全组近一整天的时间，但我觉得，这个成本很值！

以明确的量化数据作为论据，无疑大大增加了说服力。这让我认识到，CMMI虽然是一种作为指导软件过程的过程模型，但如果将其用好用活，是具备增强沟通说服力的重要功能的。这一功用，在外包项目中，体现的尤为明显。

 

测试的目的

东软的测试工作是贯穿于软件开发过程始末的。编码前，要求每个程序员预先做好测试式样书。他们采取的方法是：leader提供一个测试式样书模板，程序员只需按照该模板，对照式样书，写出相应项目的信息。编码工作结束后，首先按照该测试式样书统计测试点数，然后统一安排测试工作。

之前，曾经有人对测试式样书的模板提出质疑：“这个模板能全面反应功能需求吗”并且举出实例：的确有很多式样书明确提出的功能，在模板上未能体现。这表明：测试式样书的模板是不够完善的，需要改进，但如何改进，我当时难以提出完善的建议。

进入了测试期，这些原本并不完善的测试式样书开始体现出它的巨大作用：易于实施，便于量化。这些功能是显而易见的，但其意义却非同寻常。

首先，东软采用大批新人参加工作，这些新人，几乎是没有任何开发经验的，培养他们非常费时费力。但由于这样一套“不完善”的模板的存在，便促使他们可以尽快的进入角色，发挥作用。因此，这些模板有助于节约成本。

其次，象统计测试工作量这样繁琐的工作，因为这些模板的存在而具备了新的定义：那就是模板制定的测试点数。这些测试点之间的工作量绝对是不一样的，有些需要制造很多测试用例进行测试，有些则只需要截取一个画面。但是，东软并没有因为这些工作量上的差异而进一步讨论其合理性，而是仅以测试点作为测试工作量的衡量标准。因为，这些数字足以说明一个问题！

那么，这些测试点要说明的是一个什么样的问题？测试式样书本身就是不完善的，测试点自然也不全面，那么一定不能说明：“这些测试点的实施可以确保编码质量。”而这个问题不能得到解决，测试工作的目的到底何在。为了这个问题，我特意查看了很多东软测试的成果物。这些成果物主要包括：BugList、测试证据（针对每一个测试点的截图或者测试数据及其结果，不论是否有Bug，都会有证据，不过有Bug的会在文档中用红圈标出）、测试成绩书（已填写了测试结果的测试式样书，并在测试点后标出证据类型：DbDump或者截图），当然还有编码。通过这些文档，可以明显的看出测试式样书的不完善：有些测试后的编码，按照测试式样书已经完全没有Bug，但事实上还存在一些很明显的Bug；有时一些明显的Bug无法在测试式样书里找到填写的位置。但是，这些测试文档可以说明一个问题，即我们在测试方面认真做了大量工作。

    站在客户的角度。两种产品，更容易接受哪一个呢？一个Bug很少，甚至没有，但在这之前做了哪些工作并不是很清楚；另一个仍旧存在相当数量的Bug，但是在测试方面提供了实施大量有效工作的证据，并且可以证明许多内容都是没有Bug的，但也有一些内容未列在测试工作之中。客户的心理可能更容易接受看得见的东西。客户很难相信一件不太了解的产品质量有多好，那么我们就需要拿出更多的证据让他信服。那些不完善的模板，很大程度上就是一件让客户更加了解我们工作的证据。通过这些证据，可以让客户知道，我们已经做了很多工作，在某些方面，已经确保了质量。进而让客户认为：我们的产品性价比是很高的。

这就是测试工作的一个主要目的：拿出高性价比产品的证据，以及追求高质量产品的高质量过程的证据。

那么，和证据相比，高质量的产品本身成为次要目标了吗？对比以前所做的系统，我们现在的软件开发有一个很特别的地方。那就是不完整。以前做的系统，都是一个完整的系统，无论是开发还是测试，总是先从入口开始，一步一步推进，直到全部完成。这一过程中一般不会有不良数据等许多意外情况的干扰。测试用的数据，也是通过系统本身或者专用测试工具输入的。而现在，我们要做的仅仅是整个系统的一部分。这个部分所需要的数据，一般没有完善的输入机制相配合。这就导致大量不良数据对我们的工作造成了干扰，测试时面临的情况更加错综复杂。数据输入、运行程序、验证结果等等工作量都要成倍甚至几十倍的增加。工作量巨大，甚至还有想不到的情况。想要完整的将所有情况列出，并且加以测试，在紧张的开发周期中，几乎是一件不可能完成的事情。

那么我们应该做些什么呢？几种设想：

1． 参考东软的模式。我觉得不能一下子考虑得太深，仅管理好我们能够管理的这一部分、做好以量化为基础的客户沟通，剩下的只能依赖每个程序员自身能力的发挥和在大家共同努力下的持续改进。我觉得这是一种最简单，也是比较实用的模式。

2． 培养专业队伍，大量利用测试机。每个项目，甚至每个问题都专门设计最适合的自动化设备，不断完善这些工具的积累。这个成本可不低，但对于减少工作量，保证测试的有效性，增加质量保险系数大有益处。但是，我觉得这个方法虽然有优势，却不适合短期运作，想要一次成功几乎不可能。为了避免负面影响过高，仅作为持续改进阶段的内容，点滴增加似乎更合适一些。

相关链接：《在东软的工作随想》评论之评论<script language="javascript" type="text/javascript"> document.title="《在东软的工作随想》评论之评论 - "+document.title </script>