我目前正在评估TFSMSF for CMMI下的流程模板以供我的开发团队使用，但我无法理解对单独的错误和更改请求工作项类型的需求。
我知道在生成报告时能够区分错误（错误）和变更请求（变更需求）是有益的。
然而，在我们当前的系统中，我们只有单一类型的变更请求，并且只使用一个字段来指示它是否是错误、需求变更等（该字段可用于构建报告查询）。
为错误设置单独的工作流程有什么好处？
我还对开发人员可以针对错误或更改请求提交工作这一事实感到困惑，我认为预期的工作流程是让错误生成更改请求，这是开发人员在进行更改时引用的内容。
@卢克
我不同意你的观点，但这种差异通常是解释为什么有两种不同的过程可用于处理这两种类型的问题。
我想说的是，如果主页的颜色最初设计为红色，但由于某种原因它是蓝色的，那么这很容易快速修复，并且不需要很多人或工时来进行更改。只需签出文件，更改颜色，重新签入并更新错误。
但是，如果主页的颜色被设计成红色，而且是红色，但有人认为它必须是蓝色的，那对我来说无论如何都是一种不同的变化。例如，是否有人考虑过这可能对页面的其他部分产生的影响，例如覆盖蓝色背景的图像和徽标？会不会有看起来很糟糕的事物的边界？链接下划线是蓝色的，会显示吗？
举个例子，我是红/绿盲，改变某物的颜色对我来说，不是我掉以轻心的事情。网络上有足够多的网页给我带来问题。只是要指出，如果你考虑一切，即使是最微不足道的变化也可能是不平凡的。
实际的最终实现更改可能大致相同，但对我来说，更改请求是另一回事，正是因为需要更多地考虑它以确保它能够按预期工作。
然而，一个错误是有人说这就是我们要这样做的方式，然后有人以不同的方式做。
更改请求更像是，但我们还需要考虑其他事情......嗯......。
当然也有例外，但让我把你的例子分开。
如果服务器被设计为处理超过 300,000,000,000 次浏览量，那么是的，这是一个错误，它没有。但是设计一个服务器来处理这么多的浏览量不仅仅是说我们的服务器应该处理 300,000,000,000 次浏览量，它应该包含一个非常详细的规范，说明它如何做到这一点，一直到处理时间保证和磁盘访问平均时间。如果代码完全按照设计实现，并且无法按预期执行，那么问题就变成了：我们是设计不正确还是实现不正确？.
我同意在这种情况下，是否将其视为设计缺陷或实施缺陷取决于它未能达到预期的实际原因。例如，如果有人假设磁盘的速度是实际速度的 100 倍，而这被认为是服务器无法按预期运行的原因，我会说这是一个设计错误，有人需要重新设计. 如果仍然要保持这么多页面浏览量的原始要求，则可能必须进行具有更多内存数据和类似数据的重大重新设计。
但是，如果有人刚刚没有考虑到 RAID 磁盘的操作方式以及如何正确地从条带化媒体中受益，那么这就是一个错误，可能不需要进行那么大的更改来修复。
同样，当然会有例外。
无论如何，我所说的原始差异是我发现在大多数情况下是正确的。
请记住，TFS 的工作项类型定义的一部分是它的“工作流”的定义，这意味着工作项可以处于的状态以及状态之间的转换。这可以通过安全角色来保护。
所以 - 一般而言 - “变更请求”将由组织中相对较高的人（具有与花费资源对系统进行（可能非常大的）变更相关的“赞助”权利的人）发起和批准。最终这人将是批准更改已成功进行的人。
然而，对于“Bug”，应用程序的任何用户都应该能够发起 Bug。
在我实施 TFS 的组织中，只有部门负责人可以成为“变更请求”的发起者 - 但“错误”是从“帮助台”工单创建的（不是自动化的，只是通过流程......）
通常，虽然我不能代表 CMM，但更改请求和错误的处理和考虑方式不同，因为它们通常涉及应用程序生命周期的不同部分。
错误是您的程序实现中的缺陷。例如，如果您将程序设计为能够将两个数字相加并为用户提供总和，那么缺陷将是它不能正确处理负数，从而产生错误。
更改请求是指您有设计缺陷。例如，您可能已经明确表示您的程序不应该处理负数。然后提交更改请求以重新设计并重新实现该部分。设计缺陷可能不是故意的，但很可能是因为您在最初设计程序时没有考虑该部分，或者在创建原始设计时不存在的新案例已被发明或发现自从。
换句话说，程序可能完全按照设计运行，但需要更改。这是一个变更请求。
通常，修复错误被认为比执行更改请求便宜得多，因为错误从未打算成为您程序的一部分。然而，设计是。
因此，可能需要不同的工作流程来处理这两种不同的场景。例如，您确认和提交错误的方式可能与变更请求不同，这可能需要更多的工作来说明变更的后果。
错误是已被批准实施的需求中出现的问题。
变更请求需要经历一个周期，在这个周期中，必须估计该变更的影响和工作量，然后必须批准实施，然后才能开始工作。
两者在 CMM 下有着根本的不同。
我的假设是否不正确，那么应该从错误中生成更改请求？我很困惑，因为我不认为所有的错误都应该被自动批准实施——它们可能是微不足道的，至少在我们的例子中，在分配给开发人员之前，它们会经历与变更请求相同的审查过程。
实施总是来自需求。它可能来自产品经理，也可能来自你们中的一些人的随机想法。它可能被记录在案，它可能来自一些对话。归根结底，即使是简单的事情a := a + 1，“真正的”实现也将基于编译器、链接器、CPU 等，这取决于现实生活中的物理定律。
错误是针对原始要求实施的。除此之外，这是一个变更请求。
如果需求改变了，实现也需要改变，那就是变更请求。
如果依赖项已更改，例如 Web 浏览器停止支持某些标签并且您需要进行一些更改，则这是一个更改请求。
实际上，任何未正确记录的内容都应视为变更请求。产品经理忘记在故事中添加内容？抱歉，这是更改请求。
所有变更请求都应该被正确估计和指出。开发人员因提出变更请求而获得报酬，而不是因制造错误和修复他们提出的问题而获得报酬。