我们最近正在做一项体验，就是体验TFS CMMI模板。（这个模板目标是CMMI 2到3级。）
我们按照TFS上面介绍的活动和流程一个一个的走，
从Envision阶段，走到Planning阶段，现在都走到Build阶段了。
一个负责设计同事提出，我们对错误信息的分类太简单了，应该至少还有一个分类方法。
作为配置管理员，我比较生气，
第一：按照TFS CMMI模板，在需求阶段，我们本来需要完成几个文档，Scenario / Storyboard / User Interface Flow Model ,但是小组的负责需求的同事却想偷懒，只是简单使用文字描述Scenario。
第二：在Review需求的时候，大家都好像事不关己，没有什么意见就通过了。
后果当然就不好，这个问题如果在需求阶段解决，成本会很小，几乎可以忽略，但是到了现在，成本倍增了。
这个问题，当然是我们常见的问题，在我们没有体验TFS之前，我知道这个问题我们每次项目都犯相同的错误，最严重的是，我们犯了错误都不知道，不知道如何处理也不知道如何避免，今天能够意识到，算是进步了，在之前的项目里，大部分情况是几乎没有什么控制，（除了源代码，几乎没有没有什么控制）
得到的教训是:
第一：需求文档不能省，就算是技术含量不高（同事认为写Storyboard / User Interface Flow Model没有什么技术含量，很简单），但是其实带给我们的用户确实很大的，它可以给我们一个需求的详细介绍，我们可以在细节达成一致，在项目的开始阶段就把细节达成一致，这个节约成本的途径，一个错误从一个阶段走到下一个阶段，要解决的成本就增加了很多倍了。
第二：Review的时候不是走形式，Review是检查错误，是大家形成共识的时候。
Envision阶段的里程碑就是大家有个一致的Vision，Planning阶段的重点，大家要有个达成共识的需求。