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

Question

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

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

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

为错误设置单独的工作流程有什么好处？

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

Answer 1

@卢克

我不同意你的观点，但这种差异通常是解释为什么有两种不同的过程可用于处理这两种类型的问题。

我想说的是，如果主页的颜色最初设计为红色，但由于某种原因它是蓝色的，那么这很容易快速修复，并且不需要很多人或工时来进行更改。只需 checkout 文件，更改颜色，重新 checkin 并更新错误。

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

举个例子，我是红/绿盲，改变某物的颜色对我来说，不是我掉以轻心的事情。网络上有足够多的网页给我带来问题。只是要指出，如果你考虑一切，即使是最微不足道的变化也可能是不平凡的。

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

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

变更请求更像 但是我们还需要考虑其他事情...嗯... .

当然也有异常(exception)，但让我把你的例子分开。

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

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

但是，如果有人刚刚没有考虑到 RAID 磁盘的操作方式以及如何正确地从 strip 化媒体中受益，那么这就是一个错误，可能不需要进行那么大的更改来修复。

同样，当然会有异常(exception)。

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