軟件測試中的CMMI雜感
敏捷和CMMI是否矛盾問題
首先應該是考慮為何要實施CMMI的問題，如果僅僅是獲取PassPort的話那很多后話都不用再談．但真正的目的還是應該是降低軟件開發生命周期的總成本，這個要用發展觀點來看應該是一個中期或遠期的考慮．如果實施了CMMI成本沒有降低，那就只能說CMMI的實施是失敗的不管是做了多數KPA,輸出了多少文檔，改進了多少過程．
對于敏捷或快速開發，如果過多的依賴是個人英雄主義，但勢必和CMMI的理念是矛盾的．如果采用敏捷思路是提高開發效率，降低開發成本，考慮中長期軟件開發的成本，那和CMMI的思路就是一致的．差別僅僅是在了你需要關注哪些KPA,產出物的要求上面，而這是可以通過裁剪來解決的．組織級定義的是通用過程，項目必須根據自己情況裁剪．
CMMI五級的境界問題
任何一個組織都會遇到層出不窮的新問題，關鍵是自我形成一套識別，分析和解決問題的過程．在五級企業已經形成PDCA或IDEAL的自我改進循環，達到持續自我改進的目的．組織是自適應的，組織是自我學習的．如果不具備這種自我診斷或學習的目的，那始終達不到五級的水平，到了五級就應該代表自己的問題自己能夠解決水平，而這個問題不是老問題而是各種新問題，需要你遵循相關的過程或方法論去解決．
關于估算的準確性問題
對于估算不可能做到100%的準確，重點是將偏差控制在可以接受的范圍．比如軟件項目具體的軟件需求沒有開發完成時候是很難估計的很準確的，要估計準確就得花時間，這個時間其實就是在細化軟件需求和功能．所以估算仍然需要進行成本效益分析，投入額外的工作量去估算以增加估算精度是否有必要．不管是類別法，專家法，三點法還是功能點法，沒有誰好誰壞的問題，關鍵是哪個準確度高的問題．為何CMMI有時候強調功能點估算，重點就是使估算更依賴于過程而非個人．
關于崗位角色和分工的問題
如何劃分角色崗位，分工要多細完全是一個平衡的問題．平衡的目標仍然是開發效率和質量．崗位分工越多則溝通成本越大，信息失真可能越大，需要更多的評審,Review和配置管理工作．但分工的好處是支持大規模作業，分工細化后降低了對單個角色需要具備的技能水平的依賴，分工細化后便于流水化作業．對于大型軟件項目更需要強調這一點，需要的是專才而非通才，通才的結果可能就是樣樣懂但都不精通．
過程的重要性
在高度成熟的企業，過程是用信息化的手段來沉淀的，可以最大程度減少對人自覺性的依賴，并且減少監督的成本,提高執行力，最大程度的減少重復工作，避免帶來數據積累、統計手工計算帶來的問題。所以組織中的人更多的是依賴于過程或規程在做事情，而不是依賴于個人的經驗在做事情．企業需要創新，但決定不需要人人都去創新．
如果企業始終處在頭痛醫頭，腳痛醫腳的狀態．則完全是處于一種被動，挨打和救火的狀態．最好的防守就是出擊，最好的處事原則就是防患于未然．如果始終是善于識別問題的根源，去預防問題那就始終占據主動地位．
先進理念
先進的理念如果不能給公司帶來真正的效益，那么說明理念本身的適應性有問題，或者說組織根本就不適合這個理念．你可以打著先進的幌子在短期內無收益，但不可能在中長期仍然無實際的收益．檢驗的重點就是成本效益，時間可以說明一切．存在即是合理的，完全否定項目實際而推廣高屋建瓴的先進理論注定失�。�
我們說CMMI實施更多應該是思想的轉變，但要轉變思想首先要能夠看到對自我和組織有益處．望梅是止不了渴的，要宣傳未來的餅有多大最好現在就能夠讓大家吃上一小口．
人的重要性
要做過程改進首先要回答的是為何要做過程改進的問題．只有自主，自發和組織自我需求驅動的改進才能夠真正達到改進的目的．過程改進是一種氛圍，是積累組織中的每個人不斷創造價值的氛圍．因此請尊重人，重視人，激勵人，善用人，但又不能過度的依賴人．否則你依賴的是經驗，而非過程．
文章來源于領測軟件測試網 http://www.k11sc111.com/
