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