MSF for CMMI 中的错误和更改请求有什么区别？

Question

我目前正在评估 MSF for CMMI 下的流程模板 TFS 用于我的开发团队，但我无法理解单独的错误和更改请求工作项类型的需求。

我知道在生成报告时能够区分错误（错误）和更改请求（更改需求）是有益的。

然而，在我们当前的系统中，我们只有单一类型的变更请求，并且仅使用一个字段来指示它是否是错误、需求变更等（该字段可用于构建报告查询）。

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

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

Answer 1

@卢克

我并不反对您的观点，但这种差异通常是对为什么有两种不同的流程可用于处理这两类问题的解释。

我想说，如果主页的颜色最初设计为红色，但由于某种原因变成了蓝色，那么很容易快速修复，不需要涉及很多人或工时来进行更改。只需签出文件，更改颜色，重新签入并更新错误即可。

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

举个例子，我是红/绿色盲，改变某种东西的颜色对我来说并不是一件轻而易举的事情。网络上有足够多的网页给我带来了问题。只是为了指出一点，如果你考虑到一切，即使是最微不足道的改变也可能是不平凡的。

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

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

变更请求更像是 但我们还需要考虑另一件事......唔....

当然也有例外，但让我把你的例子分开。

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

我同意，在这种情况下，到底是设计缺陷还是实现缺陷，取决于它未能达到预期的实际原因。例如，如果有人假设磁盘的速度是实际速度的 100 倍，并且这被认为是服务器无法按预期执行的原因，我会说这是一个设计错误，需要有人重新设计。如果仍然要满足那么多页面浏览量的原始要求，则可能必须进行包含更多内存数据和类似数据的重大重新设计。

但是，如果有人没有考虑到 raid 磁盘的运行方式以及如何正确地从条带介质中受益，那么这就是一个错误，可能不需要那么大的更改来修复。

同样，当然也会有例外。

无论如何，我所说的最初的差异是我发现在大多数情况下都是正确的。

Answer 2

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

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

然而，对于“Bug”，应用程序的任何用户都应该能够发起Bug。

在我实施 TFS 的组织中，只有部门负责人可以是“变更请求”的发起者 - 但“错误”是从“服务台”票证创建的（不是自动的，只是通过流程......）

Answer 3

一般来说，虽然我不能代表 CMM，但更改请求和错误的处理和考虑方式有所不同，因为它们通常涉及应用程序生命周期的不同部分。

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

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

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

---

通常，修复错误被认为是比执行更改请求便宜得多的操作，因为错误从未打算成为程序的一部分。然而，设计是。

因此，可能需要不同的工作流程来处理这两种不同的场景。例如，您确认和提交错误的方式可能与更改请求的方式不同，这可能需要更多的工作来列出更改的后果。

Answer 4

错误是指已批准实施的需求中出现的问题。

变更请求需要经历一个周期，在该周期中必须估计该变更的影响和工作量，然后必须在开始工作之前批准实施。

两者在CMM下有本质的不同。

Answer 5

那么我的假设是否正确，即更改请求应该由错误生成？我很困惑，因为我不认为所有错误都应该自动批准实施——它们可能是微不足道的，至少在我们的例子中，在分配给开发人员之前会经历与变更请求相同的审查过程。