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

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

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

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

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