一邊是某咨詢公司在項目管理培訓中宣講：“CMM2級企業不適合實施6sigma，應該等到CMM4級之后，度量體系比較完善時再進行�！币贿吺�2004 年世界軟件工程大會上，各國專家達成共識：“CMM/CMMI與6sigma能夠結合，互相促進”。我們怎么辦？我以前主張：爭執暫放一邊，抓緊時間邊實踐邊改進，否則結果就很可能是：“我們在進步，但是我們與競爭對手相比更加落后�！庇行┩陆邮芰宋业目捶�，于是又有一問：“你有沒有在軟件中實施 6sigma的成功案例？”6個月前我還沒有，但是現在我有了幾個典型案例，它們各具特色，讓我們在此一一分享。
一、6sigma能幫助解決軟件技術問題嗎？
第一個項目是在去年年末，參加一個事業部的6sigma優秀項目發布會看到的。項目名稱是《XX網管系統提高告警吞吐率》，問題是在大量告警上報時， UNIX服務器的告警處理吞吐率僅為8條/秒，同時占用CPU達90％，導致其它模塊的操作基本上不能進行。用戶對此非常不滿，要求我公司盡快解決此問題，提高吞吐率到至少48條/秒，而系統成本不能有較大幅度增加。如何解決這個問題？一個解決方案是提高硬件的配置，從而提高處理性能，但是這樣做會大大增加采購成本，而性能并不會有極大的提升，實際上降低了產品的可銷性，這樣的投入收益比極不合算，此方案被拒絕。項目組在花了大量時間和精力，仍然尋找不到合適的解決辦法之后，想到了6sigma。大家知道，6sigma項目的選擇就是那些“難度大、影響力大”的問題，于是這個項目組的成員將此問題立項，期待6sigma能在黑暗中帶來曙光。
除去定義與測量階段，此項目的分析思路是這樣的：首先是頭腦風暴魚骨圖，羅列所有大家能想到的可能原因；然后將這些原因按照告警的邏輯處理流程組織成 FMEA，進行RPN分析，篩選出RPN值大于100的少數因素，作為潛在的關鍵因子；之后對這些潛在因子逐一試驗，進行確認。整個項目的突破就出現在第一個因子的試驗中，其試驗數據如圖1所示，橫坐標表示輸入的告警流量，縱坐標表示告警處理延時。圖中的曲線顯示有周期性的拐點，而在拐點之后，告警流量增加，服務器的處理延時反而有較大的降低。這個現象如果沒有針對此原因的試驗，沒有這些數據是無法看到的。分析這個現象的原因，難不到我們的軟件工程師，很快就得出了結論：TCP協議參數設置不當。修改此參數后，重新做同樣的試驗，得到數據如圖2所示，可見其告警吞吐率基本上與輸入流量呈線性關系增長，瓶頸已經消除。這不僅僅是確認了此因子是關鍵因子，同時也驗證了改進措施的有效性。另外幾個因子也是類似的，通過針對每一種可疑因子的試驗，或確認此因子為關鍵因子，或篩選影響不大的因子；然后針對每個關鍵因子尋找技術上的解決辦法，就更不在話下了。此項目的成功為公司創造了每年166萬的收益。
回顧這個項目，又應驗了一句老話：“解決難題經常是99％的努力在于尋找關鍵原因所在，而修改只需要1％的努力�！�6sigma本身并不提供技術解決方案，但是它的思路引導我們向著正確的方向邁進，而數據是保障我們方向正確的重要依據。此項目雖然是軟件項目，但是問題本身Y是可以清晰度量的，這也是它能夠適應6sigma特色，得以成功的一個原因。
圖1 某項目針對關鍵因子一的告警處理流量試驗數據圖
圖2 某項目修改了協議參數后的告警處理吞吐率圖
二、主觀判斷的結果有說服力嗎？
這個案例是黑帶項目《降低異常代碼故障率》，它從CQ分析的主要故障類型之一：異常代碼故障率居高不下而來，這體現出負責人主動從失誤中學習和進步的精神，也給很多仍然為找不到合適項目的同事一個啟示：CQ庫是一個很方便的項目寶庫。
此項目對于故障分類的測量系統分析，是離散數據做測量系統分析的典型。在研發過程中，我們經常遇到“只可意會不可言傳”的情形，大家都是主觀判斷“拍腦袋”，這樣的分析如何具有說服力？主觀判斷不等于拍腦袋，這個項目可以作為參考，感覺上的東西通過制定一定的準則，能夠將大家的主觀判斷達到基本一致和準確的標準。以下摘自此項目負責人的總結文章：
在確定了故障的分類規則后，對于故障進行分類，對于同一個故障不同的研發人員分類可能出現不同的結果。出現這種問題可能是有兩個原因：(1)故障分類的標準還不夠明確，參加故障分類的研發人員對于故障理解不同。(2)參加故障分類的研發人員沒有能力按分類標準對故障進行分類。解決的辦法是在故障分類前進行測量系統分析，確認故障分類標準是否已經明確，參加分類故障的研發人員是否具備了故障分類能力。
文章來源于領測軟件測試網 http://www.k11sc111.com/
