关于软件质量的思考-(thought of software quantity)

在网上看到一篇文章《软件质量管理之困境与对策思考》的文章，很有想法。和作者本人进行了沟通。一下是我对软件质量管理的砍翻以及作者的评论。希望对大家有所帮助。
1.
关于“哑铃型”组织结构
从你的分析可以得出，质量管理部门和软件开发部门很容易形成两种对立的部门。
由于在管理过程中，不能忽略的情感因素，两大部门之间沟通的桥梁 - 数据，很容易出现误差。
本身数据对软件质量的反馈，本身就存在不准确性，只能当做参照，反映当前软件开发的大致情况。
如果在唯一的依照 - 数据上也出现偏差，我觉得质量管理部门反而起不到应有的作用。说不定，根据错误的数据，制定错误的流程，反而对软件质量起反作用。

2.
关于“哑铃型”组织结构的改进
在你的改进中，两大部门产生交集。交集部门由“来自开发部门的、对软件质量管理有很好认识的技术专家”来担任。
我认为这样做虽然是让两个部门产生交集，但同样绕不开将质量管理和软件开发放在两个不同的对立面。
[Yun] 也许。这就看我们如何定义质量部门。它应是一个独立的部门？还是作为研发部门的一个子部门？如果是后者，又如何保证做为子部门又发挥作用？这是很难解决的一个问题。
我认为软件质量最终来源于软件开发部门。所以软件质量管理应该是深入软件开发的每个环节。
[Yun] 认同。
而良好的软件质量最终又归结于开发者本身的素质，也就是金字塔的80%。
所以在软件质量管理中，不应该过分强调金字塔顶端的作用，而是应该想办法提升80%那部分的质量意识。
[Yun] 不完全认同。80%要发挥作用，一定离不开上面20%的作业。这如同战场一定要指挥官一下。想想，如何保证80%的人走的路是对的呢？
3.
而提高开发者的质量意识，归根到底又是开发者心态的问题。下面是我认为开发者可能存在的心理：
1.
开发者习惯维护自己开发的代码
2.
开发者在遇到无法解决的问题时，可能会可以隐藏或者绕过代码的缺陷。
3.
Follow流程，但却不认可流程，从而不认真对待
….

即使我们有review可以来避免由开发者心态导致的问题，但是这样往往效率和质量都是不好的。
另外一点，程序员虽然不善于沟通，可是说服能力很强，很容易导致reviewer/tester被动的去认可，即使的确代码有缺陷

为什么我会这么认为。
开发从Design->Coding->UT->MT， Review贯穿其中，也就是说质量监督一直在进行。
[Yun] 在进行，并不表示进行到了位！
理论上来讲，排除Design过程中，可能产生的理解差错而遗漏的Trap。代码本身应该没有问题才对。
[Yun] 这个理论或许不成立。设计与实现是两人个完全不同的事物，前者重在塑造概念，后者则是表达概念。表达所需的概念并非简单的一一映射。
（因为UT，MT等于就是白盒测试，在这个阶段应该是最容易也最应该过滤软件Bug的阶段）
但事实上，大量的Bug都是在后期由测试人员发现的。
可以说明在前期代码开发过程中，开发者并没有很深的软件质量的意识。
[Yun] 可以这么说。但问题也可能是，开发人员不知道真正的质量是什么。在这种情形下，他很难建立真正的质量意识。所以我倡导以实践的方式来提升质量意识。
我认为如果一个产品到了需要靠软件测试人员进行大量测试来保证质量的阶段，就意味着这个产品的质量应该是不好的。
因为，对产品最了解的应该就是最底层的软件开发人员了。
[Yun] 很有一番道理。

所以我认为，软件质量管理应该将质量意识注入每个开发者的意识当中去。让开发者主动去做质量监督和控制。
然后向质量管理部门Share他们的数据，而不是被动的提供。再由质量管理部门对开发者进行信息的反馈。

下面，是我想象中的质量管理模型。







[Yun] 这个模型对开发人员的要求更高了。另外，数据分析一定不能由质量管理者来做，而应放在开发部门。数据所表达的内容，很难真正反映软件设计层面的问题。
我认为，人的因素在软件开发过程中很重要，开发者的技术和心理都很重要。
通常，我们总是将重点放在开发者的技术层面，所以想问问你的看法，以及在软件工程学中，有没有关于软件开发者心态的研究。
[Yun] 有一本书叫《程序开发心理学》，是温格写的。