春節長假結束之後回到公司，我參加了有關cmmi的training。整個課程總有7個部分，涉及的內容十分廣泛：從基於風險的專案管理到軟體生命
週期，再到專案計畫和跟蹤等等。而到上個星期為止，課程已經過半，而我對於cmmi有了一點點的認識，也引發了一些思考。
還是先從認識開始吧。當你第一次看到cmmi這個名詞的時候，或許你會不由得想起cmm。是的，cmmi就是cmm intergration(cmm 整合)，而cmm
則是compability maturity model的縮寫，就是眾所周知的軟體能力成熟度模型了。要深入了解cmmi，還是得從cmm的歷史說起。2023年，卡內基
梅隆大學軟體工程研究院(cmu-sei)為了評估軟體企業的成熟度創造了cmm，版本為1.0。而在2023年4月，sei舉行了乙個cmm的研討會，在廣泛聽取
了眾多軟體工程專家的意見之後，又於2023年推出cmm 1.1版，這也是目前世界上比較流行和通用的cmm版本。就在cmm1.1發布到sei於2023年不再更
新cmm和支援cmm這10年間，全球成千上萬的軟體公司紛紛以cmm馬首是瞻，依照cmm制訂軟體開發流程，並且對cmm認證趨之若騖。那麼，為什麼cmm
會有如此大的魅力呢？我們都知道在乙個軟體專案中，有三個要素：人、技術和過程。很明顯，前兩個要素是不穩定的，人自然是首當其衝：對於項
目組來說，在一段時間內，人員可能會發生變動。再關注到某乙個組員，其工作狀態也會出現起伏。技術的不穩定性也是明顯的，相同技術的版本變
遷，不同技術的推陳出新都突顯了這種不穩定性，尤其是在當今技術發展迅速的年代，技術的不穩定性則更為突出了。三個因素當中就剩下了過程，
它呈現出來的穩定性使它成為專案管理者的救命稻草。於是乎，軟體領域的目光都集中到了過程，相應的，cmm中所謂的軟體能力成熟度實質上就是軟
件過程的成熟度了。說到這裡，您是否跟我一樣，心中又多了幾個大大的問號呢：過程跟能力真的可以劃上等號嗎？將軟體過程進行了良好的定義是
否就意味著擁有了無堅不摧的能力呢？
在sei的**上，我們可以找到兩個有關cmm的權威文件，其中之一就是capability maturity model for software (version 1.1)。文件對
cmm做了全面概括的介紹，自然也包含了我們所熟知的cmm五個等級的相關資訊。文件中2.2節understanding the maturity levels是相當有意思的
，它講述了應該如何理解maturity level，同時細化到了如何分別理解五個等級的定義。這一節開篇的時候提到了cmm對成熟度不同的過程做了足夠
抽象的定義，同時並沒有限制每個組織應該採取怎樣的方式去實現與某個成熟度相對應的過程。
既然是如此之抽象的定義，軟體公司又根據什麼進行
自己的過程定義呢？cmm評估組織又根據什麼標準對軟體公司進行能力評定呢？該文件的第三和第四章給出這兩個問題的粗略答案，有興趣的朋友可以
參閱該文件。
在瀏覽sei**上有關cmm的內容時，隨處可見sunset of the software cmm的鏈結。確實如前面提到的一樣，cmm在sei的眼裡已經是昨日黃花
了，cmmi才是sei時下主推的標準。確實，cmm的成功經驗都**於上世紀八十年代，而在近二十年間，軟體的發展又如此之神速，新標準的提出自然
是大勢所趨了。從字面上看，cmmi比cmm多了乙個i(integration)，這是我們最容易發現的差異所在。而事實上，cmmi標準的提出也是在整合了多個
cmm標準的基礎上的。對於cmmi的介紹，也就不多說了，有興趣的朋友，可以參閱what is cmmi一文。
對於cmm和cmmi這兩個key words的介紹就到這裡了，大家是不是覺得很悶了呢？ 是的，我寫得也快瘋掉了，因為我找不到源自思考的文字，數
十頁的文件包含著數以百計的概念、目標以及標準，即使是所謂的實踐性介紹，我都找不到絲毫的感覺。也許是自己的層次沒有那麼high level吧
，看著cmm和cmmi的介紹，我一如兩年前那樣迷惘。因為從這些長篇累牘的文字中，我找不到自己的角色，也找不到自己的方向，對於它們的理解，
我仍然停留在 cmm = 一大堆文件的認知層面上。不過，這樣的痛苦歷程還是讓我了解不少有關軟體過程定義的知識。我知道自己從內心排斥這種把
人的因素擺在一邊的標準，但是我也不禁要給自己的排斥多問幾個為什麼，同時我也清楚只有充分理解了cmm及cmmi才能夠讓自己的排斥來得更加理性而有說服力，而不是停留在厭惡繁多的文件的層面上。
然而，我知道自己的排斥是有充分的理由的。根據cmm和cmmi所涵蓋的範圍來看，它們關注的僅僅是過程，也就是說人
的因素並沒有包含其中，這就意味著這兩個標準的本意並非是輕視人的因素，只是沒有論述而已。事實上，乙個良好而規範的過程確實是必須的，一
旦工作陷入無序，擁有再厲害的人物，使用再強大的技術，也是無濟於事的。但是，對於過程的強調是不是有些過分了呢？而在過程的定義當中，我看到了更多的是performance和commitment，卻鮮見individual。我想，乙個良好的過程不應該只討好客戶和專案管理者，還要顧及奮戰
在第一線的開發人員的感受。在過程中增加提高開發人員能力的步驟，讓開發人員在專案開發過程中逐漸成長，這不是乙個很不錯的想法嗎？然而，
在我上training的過程中，我還是無法發現這個步驟的蹤影，這不免讓我有些失望。
在接下來的日子裡，公司會依據cmmi的規範採取更多的措施，會把開發過程制定得越來越規範，至於效果，現在還不得而知，唯有拭目以待了。
總之，過程的定義與規範是重要的，但是無視個人因素的教條化定義則令人反感。
關於設計模式的胡思亂想
設計模式是乙個指導，並不強制。有很多地方並不需要設計模式介入，因為設計模式是分離變化，很多 是一次性的，不會變。如果我們一開始寫程式的時候就加入設計模式，這樣就顯得過度設計，既耗時又費力。並且設計模式大多數會增加 量，不必要的設計又有了乙個額外的弊端。設計模式並不能解決所有的問題，都是解決特定的問題...
關於近期的焦躁與胡思亂想
近期很焦躁，大腦胡思亂想 身處網際網路這個行業中，作為乙個不咋的的開發人員，在此想吐吐自己的一點想法。敏捷到今天似乎已經很普遍了，產品是運營出來的理念也幾乎已成為網際網路每間公司掛在口頭上的東西。小步快跑，不斷根據使用者的反饋在產品體驗上做快速的變更這也是大家都懂的.快，關鍵就是快。作為乙個後台開發...
修訂 關於需求管理的胡思亂想
先來張圖 1.分支不解釋了。2.內容分支 為什麼需要名稱？便於記憶 引用 為什麼需要描述？定義需求的細節 為什麼需要關係？這樣才能知道某個需求變更會對其他需求 任務 模組帶來什麼影響 為什麼需要屬性？提供了分類的視角，便於檢索 篩選 統計具有共性的需求 為什麼需要id？地球人都知道 為什麼需要狀態？...