批CMMI軟體流程改善

CMMI的4,5級高成熟度等級強調資料和量化專案管理，前提必須是過程本身已經穩定，而且組織已經有成熟易用的軟體開發過程管理支援平台，日常的任務反饋，變更和缺陷記錄等都應該融入到日常工作中。資料的採集要盡量自動化，而且資料的收集不能經常打斷開發人員的工作，影響到他們的思考和效率。

組織級在技術平台和開發模式不統一的情況下，在流程定義上一定要避免一刀切的標準軟體開發過程。需要根據項目本身的特點和人員情況在滿足項目目標的情況下進行適當的裁剪。

軟體是人開發出來的，過程重要但是人更加重要，兩者必須要考慮結合起來，任何強調和誇大一方面的都不合適。對於小型敏捷團隊我們更加強調人的重要性，對於大型軟體項目可能更加強調規範和過程的重要性，這必須要結合項目特點和實際情況。

所有認證和培訓的市場，到中國就變味的原因，還是在於管理層的急功近利和不務實的態度，結果過了CMMI只是完成了一個形象工程和招標談判的籌碼。如果CMMI流程改善沒有為組織真正帶來品質提升和效率的提高，那麼就很難長久。

CMMI提供了對多次迭代和快速原型的支援，但是實際上很多的PA，很多的評估師給出的建議仍然是基於瀑布模型的。而在實際的軟體開發中，特別是交付周期只有2-3個月或更短的項目，很難基於瀑布模型進行開發。

全部遵循了CMMI的過程規範和要求，項目是否就一定能夠成功？在這裡答案仍然是不一定，關鍵的問題還是CMMI基於了太多的假設，比如組織能夠提供技能合格的人員，需求基本上都能夠保證是穩定的，而這些假設往往本身就無法滿足。CMMI給我們一個基於很多假設的理想模型，而實際情況就是如果這些假設都能夠很好的滿足的話，可能你並不需要CMMI也可以很好保證項目成功。

CMMI強調證據，資料，過程和文檔。CMMI告訴你需要做什麼，你需要有證據來說明你確實做了，因此準備資料和文檔過程是一個要耗費很大成本的過程，在前期我們本身還不成熟的時候更關心的是一項工作投入成本做了以後帶來的實際效益即投入產出比。比如需求追蹤會被我們經常認為是性價比不高的工作。

一個成熟的敏捷團隊（例如ThoughtWorks）自然就具備CMM5級的成熟度等級，因為我們在面對項目時解決問題的過程是清晰的、可重複的、可度量的、可管理的、自我最佳化的。如果在軟體流程改善中沒有達到這些目標，就沒有達到真正的改進效果。

文檔不能完全代替溝通，但是不能夠否認文檔和代碼的重要性。當我們注重開發過程的管理和規範的時候，軟體項目和團隊會走向成熟，而過程成熟的一個好處就是整個項目和團隊不會完全依賴一兩個牛人。項目在不斷執行過程中的先進經驗和教訓能夠真正的固化到過程中，形成組織和項目重要的資產。

CMMI每個PA需要做的事情，CMMI不會告訴你怎麼去做，但是你必須要首先搞清楚的是為什麼要做這件事情，其意義何在？我們在進行軟體流程改善的過程中必須是目標和問題驅動的，這樣才能夠有批判的主動去改進。