淺談軟體質量管理
最近某專案組爆出了一個小問題,本應該在開發過程就解決的Bug,結果上了生產還把客戶生產伺服器給搞宕機了,這個小問題導致的影響讓某高層高呼“災難啊!”
糟糕的質量有哪些災難的影響呢?
l Financial loss from lost business.
l Financial loss from customer reparations.
l Financial loss from lost customers.
l Financial loss from lawsuits.
l Lower brand equity for the organization.
· 業務流失導致的經濟損失
· 賠償導致的經濟損失
· 客戶流失導致的經濟損失
· 法律訴訟導致的經濟損失
· 品牌價值的損失
在軟體生產過程中,個人覺得最重要的質量控制還是在開發過程中把控軟體的質量,在開發過程中我們都做哪些工作來保障我們的軟體質量呢?
1. PDCA在軟體開發過程中應用:
團隊借用Agile的開發模式(為什麼用“借用”一次呢?因為敏捷還在實踐摸索中。),引入PDCA的質量管理模式:Plan-Do-Check-Action
P:舉行計劃會議;
D:每日早會、軟體開發;
每日早會例牌的問題:昨天完成什麼?感覺有哪些不順暢的地方?今天干什麼?
C:各種評審會議:
在開發過程中對關鍵的環節進行評審,如工作量估算評審、需求評審、設計評審…;
A:回顧會議:
回顧會在一個週期開發結束後舉行,主要總結本開發週期內工作成果,工作中Good、could be better 、improve的各方面;
在回顧會議後,根據回顧不足的地方爭取在下一個週期中進行持續改進,之前做的好的地方繼續發揚。
2. 開發過程中的一些質量控制:
a.結對程式設計;
關於結對程式設計,由於各方面的原因在實施過程中只有小部分的關鍵開發中用結對的方式進行程式設計開發,如:介面、公用元件的開發等一些關鍵的業務或者公用的程式來進行結對,確保程式開發質量問題降到最低。
b.單元測試;
關於單元測試主要引入JUnit並建立相應的規範來確保單元測試的質量,同時也有用到其他工具,Selenium (UI測試)以及FitNesse,不過這兩個工具目前沒有很好的應用起來。
c.持續整合:
目前採用的是Jekins平臺結合maven、Ant等工具,定期打包釋出,執行單元測試case,並出單元側測試報告、程式碼覆蓋率等一些質量報告,並針對這些測試結果進行分析,並修正相應的程式碼及test case;
3.一些質量活動與質量改進
a.一些規範:
根據專案的特性制定一些規範,如JAVA JS規範、Junit單元測試規範,當然還有客戶要求的程式碼安全規範、敏感資訊處理等一些規範。
b.Code Review
安排專人推進 Code Review 工作,定期舉行Code Review,Code Review 在專案組內被定義成群體活動,不僅僅是交叉檢查,而是叢集眾(開發者們)的力量一起對專案組的所有開發的程式碼進行Review(這或許是團隊小好處)。
4.其他
a.交流培訓
交流是團隊中最重要的活動之一,同時為交流付出了巨大的時間代價,一直在優化交流的方式方法,如會議舉行時間、會議的安排組織方式、會議的模式都一直在優化,培訓方面目前團隊內部的培訓尚未開展到位,主要做團隊的定期總結,例如寫blog;
b.人才培養
根據不同人員的性格特性安排以及個人發展需要進行安排工作以及引導,儘量做到各施所長,發揮最大的能量。
以上是團隊中一些軟體質量管理的簡單總結,在此也喊一下老X的口號:“我們對質量問題0容忍!”
========後記========
質量管理體系是一個龐大的體系,對於軟體質量管理各方面的文章書籍有很多,最實際的質量是將公司、專案組制定的規範落地,做好工作的沒一個步驟,空談誤國(“災難啊!”就是一個很好的例子),實幹興邦。如有需要的可以去看看CMMI、PMBOK這些成熟的體系。