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

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

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

有一个单独的错误工作流程有什么好处？

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

解决方案

回答

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

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

在CMM下，两者根本不同。

回答

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

回答

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

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

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

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

通常，修复错误被认为比执行更改请求便宜得多，因为该错误从来都不希望成为我们程序的一部分。但是设计是这样的。

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

回答

@卢克

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

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

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

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

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

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

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

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

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

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

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

同样，当然会有例外。

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

回答

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

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

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

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