我不知道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之前不用再集体加班……