3.7 品质
品质,谈的是一致性与改进的问题。这两方面总是需要同时考虑,因为我们必须以一致性为基础,才能据此做出改进。
在很多人的印象中,质量管理总是与繁复而庞大的文档相联系。笔者对此表示遗憾,我认为产生这种状况的根本原因,还在于管理者对程序员及设计者的技能水平缺乏信任,因此想通过质量管控计划来加以弥补。为了使大家理解其中的误会,我现在做个比喻。一位优秀的厨师本身是知道怎样制作蛋奶酥的,然而品质管控计划却不是告诉厨师应该怎样去做这个蛋奶酥,它甚至连烹制配方都不会提供。它所要确保的,是每一枚蛋奶酥都能做得一样好。
有迹象表明,品质管控计划可以较好地运用于IT开发工作。在Evaluating Agile and Scrum with Other Software Methodologies这篇文章[17]中,Capers Jones对各种软件开发方法的有效性进行了衡量。在效果比较好的开发方法里面,有一种方法叫做TSP,也就是Team Software Process(团队软件过程)。这个结果对笔者来说是有些意外的,因为我原来在网上看到很多人以负面的口气评论过TSP。TSP是由一个组织所引领的,该组织长久以来一直在品质管控过程方面提供领先的思想,这个组织就是卡内基梅隆大学(Carnegie Mellon University)的软件工程学院(Software Engineering Institute)。
通过研究TSP,笔者有三项体会。
首先,品质是从上到下得以贯彻的。TSP构建在PSP之上,PSP指的是Personal Soft-ware Process(个体软件过程),它要求程序员与设计者必须监测自己所做的事情、寻找自身的弱点,并努力提高工作水平。TSP是把一套与PSP相似的流程,运用在整个团队上面。
第二,品质建立于测量之上。如果你无法测量功能点的实现速度、bug的探查速度以及这些bug的性质,那么你就很难想到应该如何更好地完成工作。PSP或许把这种想法推向了极致。编程者总是抱怨他们必须把每天的实际编程时长记录下来,而且要精确到分钟,不仅如此,而且还必须记录编译器所给出的错误数量与错误类型。笔者觉得这样做有些过头,要是开发工具本身可以把这些指标记录下来,那还显得好一些。有了这些指标做基础,我们可以很好地发现并改正自身的缺点。
第三,品质不是靠烦琐的规章制度来保证的,而是应该在一个学习型的组织之中培养而成。学习型的组织,不单单会送员工去参加培训并定期开会以讨论相关的流程,而且还可以保证员工在无需担心打击报复的前提下,能够直接表达出自己的不满,并且使员工乐意尝试新的东西。笔者在第2章中曾经简要地讨论了DevOps,这在某种程度上是为了反制运维部门(operations department)中那些所谓的品质系统。笔者对品质衡量指标及学习型组织的看法,同样适用于运维部门。
笔者从品质管控之中所得到的第三项体会,就是明白了应该怎样检验软件产品。3.8节就来谈这个话题。