由 “靈活開發”PK“CMMI”引起的思考和困惑

我曾是CMMI咨詢師，離開“CMMI 咨詢”這個圈子也有一、兩年了，久不參加行業内的活動，很想了解行業動态。是以，上個月積極參加了軟體行業協會的過程改進年會，見到過去的老同僚，老朋友、老同行，非常高興。其中，觀看了一場辯論賽，收獲不少，也由此引發了思考和困惑。

 “靈活開發”PK“CMMI”，從辯論賽的角度，還是很熱鬧的，唇槍舌戰了一番。 “CMMI”一方因為大都是咨詢師，口齒伶俐些，引經據典，“靈活開發（Agile）”一方大都來自企業，有實際感受，卻難以上升到理論高度。是以一旦說到理論，立刻就會被C方壓倒，最後的辯論結果也是C方大獲全勝。其實誰勝誰負并不重要。組織者和主持人也說了，并非CMMI和靈活開發互相排斥，隻是想以這種極端的方式讓大家把軟體工程領域的不同觀點表示出來，供業内人士探讨。我雖熟悉CMMI，但對靈活開發并無研究，這場辯論賽讓我了解了很多東西，确實挺感謝組織者和雙方辯手的。但有些問題一直困擾在我腦子裡，久久找不到答案。

我對靈活開發隻知道大概，沒有實踐過，是以自認沒有太多發言權，聽辯論，似乎靈活開發更能支援企業業務目标的實作，因為它的要旨就是“快速響應”，快速響應客戶的需求，市場的需求，并且由于将廣大的工程師從繁鎖的流程和文檔中解放出來而受到歡迎。I CMMI重在“成熟度”，成熟度的背後是能力，解決的是組織的過程要有序，有規矩；當然也反複強調要從企業的業務目标出發，但是由于其内容和要求較多，實際上操作起來是否能很好支援“業務目标”恐怕真是值得業界人士好好研究探讨一番的。

比如過程改進人員如果不懂業務，如何能推進過程改進活動？這是觀衆提出來的一個問題，如果僅從答辯的角度，不難回答，可以說過程改進活動是有很多種的，有層次的，不是非懂業務不可的，可以做組織和協調工作，一樣可以推動過程改進。C方的辯手基本回答得也是這個意思。我卻覺得實際上這個問題很不好回答。過程改進活動的确需要有人組織和協調，但是如果沒有相當的職位，很難組織起來，而有幾家公司會對不懂業務的人員委以重任呢？ 這也反映了目前企業實施CMMI的一個現狀，很多企業根本不舍得投入業務骨幹來做過程改進，骨幹一般都很忙，根本沒有精力做額外的工作。名義上，企業的EPG裡有很多人，包括項目經理等絕對骨幹，但主要幹活的都是那幾個 QA人員，我當年做咨詢時，甚至有個客戶要安排公司的行政人員參加EPG，被我堅決反對才換了人。

而我現在的公司在咨詢師眼裡，那可是絕佳的客戶呢！

我們有個品質部，專門負責ISO9000的工作，老闆對流程執行極為重視，各級管理者反複強調，連大部分普通員工也都有流程和規範的意識，甚至個别員工還知道拿“不遵守流程”去攻擊其他同僚。

但是大家經常發牢騷的就是“事事都要按照流程來”，明明都火燒眉毛了，還在那裡慢吞吞得走流程。而真正要應付上司，似乎也不難，因為QA人員隻會查查模版對不對，挑挑錯别字什麼的。

過程改進年會上，聽神州數位的一位副總介紹，他們也是同樣有很多困惑，CMMI做到了4級，卻感覺越來越沒啥用似的。他舉了個例子，寫風險管理計劃，每個項目都寫得差不多， 如風險 －“客戶需求會變更”，應對措施－“加強和客戶的溝通，引導需求”，風險－“工期太緊張，不能按時傳遞：，應對措施－“加班，加人”，寫這些到底意義在哪裡呢？

本公司、神州數位遇到的這些問題，如果以咨詢師的角度，都能回答出一堆道道來。比如要留下記錄啦，要注重實效啦等等。但是今天，當我自己不再是EPG Leader，不再是咨詢師，而是公司核心營運部門的負責人時，我所關注的與從前完全不同，我不關注與CMMI的符合度，我關注的是如何高效得解決關鍵問題（“關鍵”二字極為要緊），如何有效得避免類似問題。

那麼，究竟應該怎麼實施CMMI呢？“靈活”思想又怎麼和CMMI搞平衡呢？