2.2 CMM的精髓

2.2.1 過程定義

CMM（Capability Maturity Model，能力成熟度模型）對軟件開發過程的關注是其最重要的貢獻之一。能力成熟度越高，說明軟件開發過程越成熟。成熟的軟件開發過程，是一個軟件開發組織進行團隊開發的基礎，而如何運用軟件開發過程，則是保證團隊項目持續成功的關鍵。

對于軟件開發組織來說，無論是否實施CMM，軟件開發過程都是存在的。

什么是過程呢？舉個例子。

如果你現在打算去釣魚，那么有一系列的事情要做。

首先，要確定地點。你打算野釣還是塘釣？海釣還是江釣？通常情況下，你會從以往的經驗中找一個地方。由于很多塘釣點會按天（或按斤）計費，所以，經濟因素也是確定地點前要考慮的。

確定地點之后，要計劃一下交通路線和交通方式。

然后，要確定時間，為此你可能需要關注一下天氣預報。

然后，你要準備釣魚裝備。根據地點不同，選擇不同的魚竿。魚線、魚鉤、浮標這類的小裝備就不用多問了，你可以帶得很全。如果夜釣，需要照明工具以及帶燈光的浮標。此外，可能還有一些常用的裝備，像桿包、釣箱等。

接下來，根據目標地點的魚的種類，例如，鯉魚、鯽魚、草魚等，你可能會在家里自己配制不同的餌料，也可能直接從漁具店購買商業包裝后，簡單加水混合即可。

到了目的地之后，一般需要找一個固定的釣臺。你先要在這個釣臺前方的水域中打窩拋餌。吸引魚群進入你的釣區。一段時間后，你要試桿調標。根據魚群活動的垂直區層，確定釣底、釣中還是釣面的戰術。你要做一些試驗，揣測并驗證魚群今天最喜歡的口味，高手可能還會現場調制餌料。

最后，你開始釣魚。

以上就是釣魚的過程。很有趣，盡管我們的目標是釣魚，卻需要做很多相關的事情。這些事情都是一些經驗知識。隨著釣魚經驗的增長，這些知識可能會不斷被修正，變得越來越合理，越來越成熟，最終越來越容易幫助我們完成釣魚的目標。

盡管在釣魚過程中很少有人去系統地思考這個過程，但是，這個過程是存在于人們的意識中的，以一種不是很嚴密卻根深蒂固的方式存在著。

和釣魚一樣，軟件開發存在著類似的過程。不同的是，軟件開發通常需要團隊成員的協作，換句話說，那些和軟件開發相關的事情，是由不同的人完成的。而且，一件事情的完成情況，可能會影響另一個人正在做的另一件事情。

在這種情況下，僅僅依靠個人的想法，片面決定自己的工作內容，就可能會對團隊目標的實現造成負面的影響。

有一種例外情況，如果團隊成員非常穩定，而且他們在長期的共事中形成了一種默契，也許不用過多強調過程的意義。

當人們需要共同完成一件事情時，常常需要一些契約來規范人們的行為。在軟件開發中，這些契約以過程的形式存在著。

為了使契約更加合理，軟件開發組織需要對過程進行系統地思考和總結。這是一種持續的行為。另外，在軟件開發實踐中，過程會不斷地得到優化。那些更合理的過程，會被保存下來并重復使用，最終成為知識資產的一部分。

在理想的情況下，CMM所關注的軟件開發過程，應該是解決軟件開發中各種混亂現象的一種理想方案。但是，在現實中，CMM往往被很多軟件開發組織、甚至軟件開發人員個人所排斥。有一種說法是這樣的。因為軟件項目的計劃經常受各種不確定的因素干擾，所以，要保證嚴格遵守繁瑣的過程是不現實的。

這種想法是錯誤的。

在軟件開發實踐中，我們經常會遇到很多模糊的反對意見。在不成熟階段產生的判斷，被固定成一些錯誤的想法，而這些錯誤想法，又會阻止一切邁向成熟的嘗試。糟糕的是，這些反對意見往往來自掌握話語權的軟件開發人員。

這有點像司法中的“有罪認定”。原告（反對者）沒有舉證的義務，當他指控一個人或一件事的時候，只需要一分鐘的時間。這有點不公平。雖然我并不完全認同CMM，但是，我仍然非常感慨。因為這種“有罪認定”，很多軟件開發組織甚至放棄了嘗試了解CMM的機會。

我一直認為，排斥CMM是錯誤的。CMM中包含了很多有價值的想法，盡管它很少提及人的因素（在敏捷軟件開發中，人的因素得到了充分的關注，甚至有被夸大的嫌疑）。

開源軟件的開發過程，幾乎不用考慮人的因素，這并不代表個人因素不重要，而是因為人們的想法簡單而統一。

開源軟件的開發人員，常常以一種松散的形式組合在一起，興趣愛好是他們最主要的驅動力。對于這樣的組織來說，過程可以最簡化，只需要保留減少混亂、提升效率的活動，而剔除在缺乏主動性的情況下進行約束的所有內容。

有哪些有價值的想法呢？

首先，CMM對于軟件開發過程的關注是系統性的。在CMM中，定義了質量保證、配置管理、需求管理、項目管理、軟件開發管理、同行評審、項目資源協調、人員培訓等概念，涉及軟件開發過程中方方面面的活動。

其次，CMM推薦了大量被證明有效的活動，并把它們納入一個模型中。在這個模型中，CMM定義了這些活動的類型，以及先后次序和依賴關系。

最后，CMM鼓勵軟件開發組織基于模型和推薦的活動來定義自己的軟件開發過程。CMM會依據規范來評估自定義的軟件開發過程，換句話說，CMM是一個參考模型，它不要求軟件開發組織嚴格遵守。CMM只是建議，在軟件開發組織自定義的活動和CMM規范推薦的活動之間做一些映射。這些映射可以非常靈活。

我很少看到有人提及最后這一點。這也許是很多人對CMM產生錯誤印象的原因之一。在我看來，CMM所倡導的靈活實踐，使它的老學究形象平添了一份可愛。

我認識一位SEI認證的CMM評估師。在與他的交流中，我深刻地體會到，CMM其實是一個非常靈活的模型。

事實上，只要有想象力和創造力，你定義的軟件開發過程，將會完全適合你的組織現狀和企業文化。你可以為不同類型的項目定制不同的過程，從而最大限度地提升工作效率。

有興趣的讀者可以去閱讀相關的參考書。

為了進一步了解CMM的靈活性，我們不妨來談談CMM中的同行評審活動。

同行評審是我非常推崇的一項活動。通過同行評審可以及早發現軟件開發工作中的一些失誤，可以及早為一些問題找到解決方案。

CMM建議，同行評審應該執行這樣一些活動：

• 計劃同行評審，并將計劃寫成文檔。
• 按照已文檔化的規程進行同行評審。
• 記錄有關同行評審的執行情況和結果的數據。

這幾句話沒有錯。團隊活動總是需要一份計劃，活動形式也需要事先規劃好，結果也需要記錄一下（否則，要犯同樣的錯誤）。有誰會對此心存疑議呢？

可是，當看到這些活動的“一般性”規定時，很多人產生了抵觸情緒。例如，在講到文檔化的規程時，CMM上是這樣說的：

• 由經培訓的同行評審領導者計劃和領導同行評審。
• 預先將評審材料散發給評審者，以便他們能為同行評審作好充分的準備。
• 已對評審者分派了在同行評審中的任務。
• 詳細說明和執行用于同行評審的準備就緒準則和完成準則。
• 使用檢查單，以便以一致的方式確定用于評審軟件工作產品的準則。
• 跟蹤同行評審中所確定的措施，直至它們得到解決。
• 同行評審的成功完成。包括解決同行評審中所識別出的問題的返工，被用作為相關作業的完成準則。

這些“一般性”規定涉及了不少文檔和事務性的工作，例如，評審材料、檢查單、跟蹤表等。再加上質量保證這類如影隨形的活動，所以做一次同行評審似乎非常麻煩。

還有更麻煩的。有些軟件開發組織對同行評審活動是這樣定義的：項目開始后，每兩天進行一次同行評審，并且要提交詳細的報告。你會瘋掉嗎？

可是，如果我告訴你，上面的活動一樣不做，也是同行評審，你相信嗎？

CMM提供了“裁剪”的概念。在遵循CMM核心思想的前提下，變通是無限的。

CMM的核心思想是：過程，要事先定義（否則是無政府主義）；過程的實施效果，要不斷驗證（可以持續改進）；過程中的基本活動形式，要保證（你不會排斥同行評審本身吧？）。

假設，你正在做3個人月的小項目。你的同行評審活動，就是找個身邊的同事討論10分鐘（也許你需要和他的團隊打個招呼）。如果這是最好的形式，把它定義下來。你得通過文檔，告訴所有參與此類規模項目的軟件開發人員，不要干擾其他人的工作了。可是，如果那些和身邊同事的討論沒有給你帶來實質性的幫助，你可能就需要換個形式了。很顯然，新的形式應該替換舊的形式，并定義到組織級別的過程中去。你的實踐經驗應該被記錄下來，免得重復發生無效的活動。不就是這樣的嗎？

針對同行評審，我們繼續往下思考。

如何制定同行評審（這里單指針對代碼的同行評審）的計劃呢？

首先，軟件設計人員在設計時，對于算法實現的難易程度，應該是心中有數的。在這個前提下，設計人員可以標記出需要進行同行評審的位置。

其次，可以參考程序員本身的業務水平，來制定同行評審的計劃。例如，有經驗的程序員，或多次被證明合格的程序，在沒有明確求助的情況下，沒有必要進行強制的同行評審。反之，對缺乏經驗的程序員，則需要加以關注。

如何進行同行評審活動呢？

如果，你的組織擁有先進的設備，那么，白板上的結論，或許可以直接保存為同行評審的報告。另外，定義了簡單格式的郵件可以作為報告，結對編程的代碼也可以作為報告。

報告存檔的意義，不在于應對質量檢查。它的意義在于，將來有可能從這些檔案中提煉出有價值的信息。那些有價值的信息，將成為組織內的知識資產的一部分。關于知識資產的話題，我們會在第10章中展開討論。

總之，當我們不斷產生關于同行評審的問題，不斷思考它們，并給出解答，然后驗證解答，然后再次給出解答的過程，就是我們的軟件開發能力成熟的過程。

CMM建議，有價值的過程應該被記錄下來，并在實踐活動中完整地驗證。相比于那些沒有任何記錄、重復討論、人走茶涼的垃圾會議，CMM的做法不值得贊許嗎？