关于tfs：MSF中的CMMI中的错误和更改请求之间有什么区别？

我目前正在TFS下评估MSF for CMMI流程模板以供我的开发团队使用，并且我在理解是否需要单独的bug和更改请求工作项类型方面遇到困难。

我了解在生成报告时能够区分错误(错误)和更改请求(更改需求)是有益的。

但是，在当前系统中，我们只有一种类型的变更请求，仅使用一个字段来指示它是否是错误，需求变更等(此字段可用于构建报告查询)。 >

使用单独的错误工作流程有什么好处？

我也为开发人员可以针对错误或更改请求提交工作而感到困惑，我认为预期的工作流程是让错误生成更改请求的错误，这些更改请求是开发人员在进行更改时所引用的。

---

@卢克

我不同意您的意见，但是这种区别通常是对为什么要使用两种不同的流程来处理这两种类型问题的解释。

我要说的是，如果首页的颜色最初设计为红色，并且由于某种原因它是蓝色的，那么这很容易解决，无需花费很多人或工时改变。只需签出文件，更改颜色，重新签入并更新错误。

但是，如果主页的颜色被设计为红色，并且是红色，但是有人认为它需要是蓝色，那对我来说就是另一种变化。例如，是否有人考虑过这可能会对页面其他部分产生影响，例如覆盖蓝色背景的图像和徽标？事物边界可能看起来不好吗？链接下划线为蓝色，会显示吗？

例如，我是红色/绿色盲人，对我来说，改变某种颜色并不是我轻视的颜色。网络上有足够的网页给我带来麻烦。仅仅指出一点，如果考虑所有因素，即使是最微不足道的变化也可能是不平凡的。

实际的最终实现更改可能大致相同，但是对我来说，更改请求是另一种野兽，正是因为需要更多考虑以确保其能够按预期工作。

但是，一个错误是有人说这是我们要做的，然后有人做了不同的事情。

一个更改请求更像，但是我们也需要考虑其他事情...嗯....

当然也有例外，但是让我分开您的例子。

如果服务器被设计为可处理超过300,000,000,000次浏览量，那么可以，这是一个错误，而事实并非如此。但是，设计一台服务器来处理这么多的页面浏览量不仅仅是说我们的服务器应该处理300,000,000,000的页面浏览量，它还应该包含一个非常详细的规范，说明如何做到这一点，包括处理时间保证和磁盘访问平均时间。如果代码随后完全按照设计实现，并且无法按预期执行，那么问题就变成了：我们设计不正确还是实现不正确？。

我同意在这种情况下，将其视为设计缺陷还是实现缺陷取决于其未能达到预期的实际原因。例如，如果有人认为磁盘的速度是其实际速度的100倍，并且这被认为是服务器无法按预期运行的原因，我会说这是一个设计错误，因此有人需要重新设计。如果仍然要保留原来的多次浏览量要求，则可能必须进行重新设计，以使用更多内存数据和类似数据。

但是，如果有人只是没有考虑到RAID磁盘的运行方式以及如何正确地从条带化媒体中受益，那将是一个错误，并且可能不需要进行太大的更改即可解决。

同样，当然会有例外。

无论如何，我说的原始差异是我发现在大多数情况下是正确的差异。

---

请记住，TFS的"工作项类型"定义的一部分是其"工作流"的定义，意思是工作项可以处于的状态以及状态之间的转换。这可以通过安全角色来保护。

因此-一般来说-"变更请求"将由组织中较高级别的人员(具有"赞助"权限的人(与花费资源对系统进行(可能非常大)更改相关))发起并批准。最终，此人将是批准更改成功的人。

对于"错误"，该应用程序的任何用户都应能够启动错误。

在我实施TFS的组织中，只有部门主管可以成为"变更请求"的发起者-但是"臭虫"是从"帮助台"故障单创建的(不是自动的，只是通过过程...)

---

通常，尽管我不能代表CMM，但是更改请求和错误的处理和考虑方式有所不同，因为它们通常引用应用程序生命周期的不同部分。

错误是程序实现中的缺陷。例如，如果您将程序设计为能够将两个数字相加并为用户提供总和，则缺陷将是它不能正确处理负数，从而导致错误。

更改请求是指您有设计缺陷时。例如，您可能已经明确表示您的程序不应处理负数。然后提出变更请求，以便重新设计并重新实现该零件。设计缺陷可能不是故意的，但很容易是因为您在最初设计程序时就没有考虑到这一部分，或者发明或发现了原始设计创建时就不存在的新情况。因为。

换句话说，程序可能完全按照设计的方式运行，但需要进行更改。这是一个更改请求。

通常，与执行更改请求相比，修复bug被认为比执行更改请求便宜得多，因为bug从未打算成为程序的一部分。但是，设计是。

因此，可能需要不同的工作流程来处理两种不同的情况。例如，与更改请求相比，确认和提交错误的方式可能有所不同，这可能需要更多的工作才能确定更改的后果。

---

错误是已被批准用于实施的需求中所破坏的东西。

变更请求需要经历一个周期，在该周期中，必须评估该变更的影响和努力，然后必须批准该变更才能开始实施。

在CMM下，两者根本不同。

---

实施始终来自需求。它可能来自产品经理，也可能来自您中某些人的随机想法。它可能被记录在案，可能来自某些对话。归根结底，即使是像a := a + 1这样简单的东西，"实际"实现也将基于编译器，链接器，CPU等，这取决于现实生活的物理定律。

错误是根据原始要求实施的。除此之外，它是一个更改请求。

如果需求发生变化，并且实现也需要发生变化，则是更改请求。

如果依赖性已更改，例如Web浏览器停止支持某些标签，而您需要进行一些更改，则这是一个更改请求。

实际上，任何未正确记录的内容都应视为变更请求。产品经理忘记在故事中添加内容了吗？抱歉，这是一个更改请求。

所有变更请求均应正确估算和指出。开发人员因提出变更请求而获得报酬，而不是因为提出错误并修复他们提出的错误。

---

我的假设是否正确，那么更改请求应该由错误生成？我很困惑，因为我不认为所有错误都应自动批准实施，因为它们可能很琐碎，至少在我们看来，在分配给开发人员之前，它们将经历与变更请求相同的审核过程。 >

---