CMMI or AGILE

最近有很多類似的題目，CMMI 很完備，Agile 很輕量，中間的差異似乎非常大，軟體公司到底要採用哪一種方法?

CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。

Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?

結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?

後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...

太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法

衍生閱讀：
1. 軟體設計思維
2. 建構管理