场景：
用户需求是某项数据不能删除，所以在设计数据层的时候，没有设计删除的方法。
但是，当我们在设计单元测试（Unit Test）的后，发现没有删除方法就无法实现单元测试的自动化。
所以我建议要修改数据层设计，增加删除方法。
最开始的想法：
过程识别1：
一种意见认为这应该识别为一个Issue，（在TFS CMMI模板中有这个WorkItem），Issue提交到变更委员会，经过分析，可能产生一个或多个Task，这些Task包括修改测试，修改单元测试，修改代码等。
过程识别2：
另外一种意见认为这应该识别为一个Change Reuqest，Change Request提交到变更委员会，变更委员会在识别为Issue，然后后面的流程和“过程识别1”相同。
分析：
这两种意见的分歧在于：要不要走Change Request
其实，这两者可能都不正确，我们认为
最终过程应该是：
第一步: 提交Issue：单元测试无法自动化
第二步: 分析Issue，得出的结论可能是提交给CCB一个Change Request：建议新增删除方法（其实提交一个CR并不是一个必然结果，只是我们有时候习惯把不一定的事情当成是一定的了。因为解决Issue的办法也可能是其他）
第三步: CCB按照Change Request的流程走
原因：
为什么是Issue：
Issue定义：The issue work item documents an event or situation that may block work or is currently blocking work on the product.
分析场景，单元测试无法自动化标志着currently blocking work，符合Issue特征。
为什么要ChangeRequest：
Change Request定义: A change request work item identifies a proposed change to some part of the product or baseline. Change requests must be created when a change is proposed to any work product that is in the configuration management system. 一切针对产品和基线的修改都需要提交CR给CCB。
分析场景，设计已经并入基线，修改设计必须走CR流程。
其他情况：
1：其实在Change Request的时候确实可能出现Issue，这个过程发生在“Track Change Requests”，Release Manager在“Monitor Change Requests”时候，可以“Generate an Issue work item to address any negative trends or behaviors.”
以上是我的想法，欢迎讨论