[zt]軟體研發的6sigma案例解析

原文出處：Sawin         作者：茹海燕

   
一邊是某諮詢公司在專案管理培訓中宣講：“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)參加故障分類的研發人員沒有能力按分類標準對故障進行分類。解決的辦法是在故障分類前進行
測量系統分析，確認故障分類標準是否已經明確，參加分類故障的研發人員是否具備了故障分類能力。
對於故障分類進行的測量系統分析可採用離散測量系統分析。進行離散測量系統分析的基本步驟為：

1、 在需要分析的故障中隨機抽取30個故障。
2、 多個開發經理按故障分類標準共同確定每個故障的分類結果。（作為“真值”——本文作者）
3、 讓參加故障分類的研發人員按故障分類標準進行分類。（作為“測量值”——本文作者）
4、 一周后，讓參加故障分類的研發人員重新按故障分類。
5、 進行離散測量系統分析，確定故障分類的準確性、重複性和再現性。

   
如果通過測量系統分析，發現故障分類的重複性有問題，同一個研發人員對於同一個故障的判定結果不相同，則一般是研發人員自身素質的問題，採取的措施是需要
加強對分類標準的學習。如果不同研發人員之間的再現性有問題，則一般是由於分類標準不明確造成，需要進一步明確分類標準。若重複性、再現性都符合要求通
過，基本可以保證故障分類的標準定義是明確的，參加故障分類的研發人員的技能已經符合要求。
 實際上這種測量系統分析的方法並非第一次使用，去年我們研究所的一個綠帶項目做法極其類似，其原理3所示。

 
圖3 某綠帶項目的測量系統分析原理圖示

   
這是一種典型的離散資料MSA的案例，在展示時，不少研發人員很吃驚：“原來MSA是可以這樣做的”，或者“原來是可以這樣得到量化資料的”。有很多人總
是說研發過程中的資料量化不足，所以不適合做6sigma項目。其實不是6sigma不能用於研發領域，而是很多時候是我們沒有找到正確的方法而已。所以
多思考、多動手，這個從小老師就教我們的話，在工作中一樣適用。

三、如何提高執行力？

   
記得前不久一位領導說：“我們公司從來不缺好的策劃，我們缺的是好的執行。”軟體中的問題有些就是執行的問題，如規範的執行不嚴格，流程不合理等等。有人
會問：“如果解決方案就是執行的問題，可以依據其影響力選擇合理化建議，或者Team 專案來解決，並不適合做6sigma項目。”實際上，一來6sigma項
目在開始時並不知道關鍵因子是什麼，二來執行也不簡單，知道和做到是兩碼事，正如一個黑帶所言：“聽到你會忘記，看到你會記住，做到你才會明白。”

   
言歸正傳，這個案例是另一個黑帶項目《提高功能測試儀的軟體研發效率》，研發效率的定義為單位軟體的軟體開發和維護人力成本。這個項目的特點首先是非常細
致，每一個步驟都按照6sigma的思路、方法完整、清晰地描述，可以作為初學者的樣板指導。然而對我而言，它更加重要的特點是它強大的執行力。在分析階
段，已經確認了三個關鍵因子：

1． 模組化程度不高；
2． 介面文檔不規範；
3． 系統部、軟體部、硬體部溝通機制不健全；

   
為瞭解決第一個問題，此項目提出建立10個模組的目標，而目前它只有3個模組；為瞭解決第二個問題，需要建立介面文檔的模板，但是更重要的是得到使用者的
認可和操作；而第三個問題更是需要三個部門的最高長官——部長來親自溝通協調解決。以上這些，這個項目都做到了！怎麼做到的？看看他的團隊成員，有研究所
的所長，一個產品總經理，三個相關部門的部長，還有相關的所有科長、開發經理，以及部分開發人員，這樣的團隊架構，還擔心解決方案得不到執行嗎？

   
案就是這麼簡單，每個項目負責人都需要謹慎選擇您的團隊成員，力爭讓每個人各盡所長。團隊中需要各種人員：首先是各方客戶代表，然後是善於分析者，善於操
作者，善於協調者，以及流程主管或組織負責人等等。記得以前有個項目，成員基本上都是專案經理，這樣的團隊溝通倒是通暢了，可是說到做具體的事情，大家都
沒有時間做，項目怎麼進展呢？最後只有取消。想想有多少項目在到達終點之前倒下去，少有找不到解決辦法的，但是做出來的方案無法兜售給使用方，從而不能達
到項目目標，這倒是常見。為什嗎？多數是因為團隊中沒有使用方的代表，強加的東西誰都不喜歡。

   
也許有人會講，其實說到執行，就是要把領導拉進來，搞定了領導，讓領匯出面推進執行和追蹤，就一切OK了。這話不對，因為我們不可能把領導搞定的，只會是
領導把我們搞定：選擇項目一定要把握領導最關心的問題；即使不是最關心的，也要是在他的問題列表中位於前列的問題。如果你要做的就是領導非常想解決的問
題，那麼邀請他加入項目團隊，請他做一些追蹤工作自然順理成章；然而如果選擇的課題，在領導問題列表中遠沒有排在前列，讓他分散精力，同時消耗他的資源來
做事，他自然不肯。這就是目前我們強調自上而下產生項目的原因。目前，我們公司在一定程度上還是人治的社會，承認這個現實，並且主動調整我們的做法適應現
狀，才是做事的明智之舉。

   
以上是我近期收集到比較典型和成功的軟體6sigma項目。然而我不得不承認，在公司已經完成的上千個項目中，軟體項目仍然是占非常少的比例。如果是因為
沒有成功的案例，影響到大家的信心，或者不知道怎麼入手來做，希望本文能夠為大家提供一些參考。CMM/CMMI與6sigma的結合和互相促進，在雙方
領域內都是新課題，還有很大的拓展空間。目前我們公司也有不少黑帶身處EPG，選擇的項目正是這個新課題。一年之後，我們再來回顧，希望能有更大的突破，
讓我們也在6sigma的曆史上留下光彩的一筆。

 參考資料：
《讓失敗成為成功的母親》，徐金爐，2004-3