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

一、背景說明

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

公司正在認證CMMI4，正在確定項目度量項，暫時制定了工作量、偏差、缺陷幾項指標，感覺無法反映出項目產品實際運行的質量情況。

二、補充：

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

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

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

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

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

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

2. 代碼走查，代碼評審

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

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

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

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

3. 公司學習進步機制

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

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

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

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

4. 完整測試流程

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

但保證的過程是要將質量暴露在內部。

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

結語：

質量控制的同時也要關注質量保證。

討論內容整理 ：

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