我不知道CMMI都影響了些什么，除了留給我無盡的meeting和文檔，但是迭代周期，構建頻率，測試方法等等跟開發息息相關的卻沒有任何實質性指導。我不知道這個是不是就是根據我們這個沒做前號稱超級輕松 時間超級富裕tailor過的結果。

可是CMMI就像大象，即使體格小，也是象，一旦計劃制定了，似乎無論情況怎樣，都無法迅速反應。像我們這個小小的，需求拿了一個多月，編碼卻只有 2周的項目，CMMI沒有任何控制的跡象。可能說：沒有CMMI你們更加混亂。會么？我看不出來還能再混亂到什么地步了。

在客戶在海外，需求不明，QA反應遲鈍的情況下，CMMI只能讓我們用meeting來充斥一次次等待客戶確認需求的時間。

我相信如果用敏捷方法指導開發絕對不會導致目前的混亂局面。首先測試一方面，我感覺V MODEL十分適合，在需求拿到了 demo產出的時候，function test case就應該設計出，那個時候會讓我們盡可能少的去想實現，而把用戶體驗和功能徹底做好。而high level design完成的時候 Intergrated Unit test case就應該設計完成(也許對一個技術十分不成熟的團隊來說此要求過高，大家沒有任何設計測試用例的經驗)，當detail design完成的時候，Unite Test case 也應該隨之產生，這樣也不知不覺地開始了測試驅動開發。而我想周圍的同事都習慣性的寫好了一個功能點了部署到服務器，跑一下，出錯了以后，根據tomcat可憐的報錯信息開始跟蹤調試，無數的log.debug更甚至無數的system.out。這個還好，僅僅影響效率而已。可是沒有任何對迭代的指導，導致各自為戰，馬上要集成了，哇，崩潰了。一個程序集成的時候是麻煩最大的時候。大家自己的模塊集成單元測試都沒做好，怎么能做這種IT呢？如果我們至少一周構建一次(根據開發計劃，因為我們不是一個敏捷團隊)，怎么會導致今天這種崩潰的局面呢？まいたな！

事總要有人做的，程序員修煉三部曲之項目自動化之道已經躺在我的枕邊。但愿我的努力和大家這次的教訓能讓我們下個項目在deliver之前不用再集體加班……