本期話題：怎樣衡量監(jiān)控敏捷型軟件項(xiàng)目質(zhì)量（指標(biāo)？工具？）【續(xù)】

一、背景說明

受診人：有實(shí)體產(chǎn)品的項(xiàng)目一般都有成熟的質(zhì)量管理體系，成熟通用的標(biāo)準(zhǔn)要求，但軟件項(xiàng)目一般偏迭代和敏捷，沒找到有成熟的度量體系指標(biāo)，做為項(xiàng)目經(jīng)理如何直觀的監(jiān)控到項(xiàng)目的軟件產(chǎn)品的開發(fā)質(zhì)量，有哪些好的通用的指標(biāo)或管理工具。

公司正在認(rèn)證CMMI4，正在確定項(xiàng)目度量項(xiàng)，暫時制定了工作量、偏差、缺陷幾項(xiàng)指標(biāo)，感覺無法反映出項(xiàng)目產(chǎn)品實(shí)際運(yùn)行的質(zhì)量情況。

二、補(bǔ)充：

看了一下精華，大家聊的很嗨，簡單統(tǒng)計(jì)了下，精華里面提到最多的指標(biāo)是bug數(shù)，bug數(shù)可以作為一個指標(biāo)，也可以將bug分為不同的等級來標(biāo)注。但是即使這樣，也無法把bug數(shù)與不同層級的開發(fā)人員相關(guān)聯(lián)，不過這個不是我要講的主要觀點(diǎn)。

我要講的是，精華中大部分提到的是質(zhì)量控制，而忽視了質(zhì)量保證。

CMMI 是企業(yè)實(shí)現(xiàn)質(zhì)量保證的重要部分。

ISO9000 質(zhì)量保證8個原則 ： 以顧客為中心、領(lǐng)導(dǎo)作用、全員參與、過程方法、管理系統(tǒng)方法、持續(xù)改進(jìn)、基于事實(shí)的決策方法、與供方互利關(guān)系（摘自高項(xiàng)第三版P314）。

具體的技術(shù)層面的實(shí)際中，QA QC的作用比較重要。講些實(shí)際的例子：

1. 做過開發(fā)的應(yīng)該知道，每個公司都會有開發(fā)規(guī)范。這些是從制度上規(guī)范代碼的一致性，雖然無法保證這樣寫出來的代碼沒Bug，但從公司層面，代碼一致性及各開發(fā)人員相互對彼此代碼熟悉對公司有利。

2. 代碼走查，代碼評審

代碼質(zhì)量的好壞跟開發(fā)人員的水平有相當(dāng)大的關(guān)系，大公司可能會嚴(yán)格定義好相關(guān)功能及開發(fā)邏輯。但小公司一般還是給開發(fā)很多自由的空間。

定期代碼走查的制度會讓相關(guān)開發(fā)人員知道，我的代碼是會有別人來看的，不能亂寫，新人還好，都是老人了被人挑錯面子上可能沒那么好過。

代碼評審：在關(guān)鍵模塊發(fā)布前我們會集中做代碼評審。

因?yàn)槲覀儼l(fā)布的東西是給互聯(lián)網(wǎng)用戶使用的，無法預(yù)估到使用量。質(zhì)量差的代碼，少量用戶就要占用大量資源，并且可能導(dǎo)致上線失敗。但一般經(jīng)過質(zhì)量評審的代碼，極少資源可以支撐海量并發(fā)。

3. 公司學(xué)習(xí)進(jìn)步機(jī)制

技術(shù)這塊，可能做錯過幾次也能進(jìn)步。但這樣的進(jìn)步成本太大，我們會組織相關(guān)技術(shù)討論會，將之前踩過的坑拿出來分享，不但如此，直接模擬的方式會讓大家更加印象深刻。

A類寫法10個用戶訪問可以拖垮一臺中等服務(wù)器；

B類寫法同樣硬件可以支撐上萬用戶同時訪問。

這種對比會讓新手或者沒踩過坑的成員印象深刻。

4. 完整測試流程

包括自動化單元測試、集成測試、系統(tǒng)測試、用戶測試等幾個部分

但保證的過程是要將質(zhì)量暴露在內(nèi)部。

暴露在用戶端基本就失敗了，小公司生成不易，如果一直讓用戶覺得你們做的產(chǎn)品有問題，那么很可能對公司戰(zhàn)略造成影響。

結(jié)語：

質(zhì)量控制的同時也要關(guān)注質(zhì)量保證。

討論內(nèi)容整理 ：

【以下關(guān)于項(xiàng)目團(tuán)隊(duì)管理的內(nèi)容都來自于希賽「PM創(chuàng)造營」群內(nèi)診斷會，由?@小M妹妹? 整理，由以下小伙伴分享完成@Jacob@mx-南京-軟件@小糊涂仙-重慶-物聯(lián)網(wǎng)@喵咪咪喵-天津-互聯(lián)網(wǎng)】