MSF for CMMI 中的错误和更改请求有什么区别？
我目前正在评估 TFS 下的 MSF for CMMI 流程模板以供我的开发团队使用，但我无法理解单独的错误和变更请求工作的必要性项目类型。
我知道在生成报告时能够区分错误（错误）和更改请求（更改需求）是有益的。
然而，在我们当前的系统中，我们只有单一类型的变更请求，并且仅使用一个字段来指示它是否是错误、需求变更等（该字段可用于构建报告查询）。
针对错误采用单独的工作流程有什么好处？
我还对开发人员可以针对错误或更改请求提交工作这一事实感到困惑，我认为预期的工作流程是让错误生成更改请求，这是开发人员在进行更改时引用的内容。
I'm currently evaluating the MSF for CMMI process template under TFS for use on my development team, and I'm having trouble understanding the need for separate bug and change request work item types.
I understand that it is beneficial to be able to differentiate between bugs (errors) and change requests (changing requirements) when generating reports.
In our current system, however, we only have a single type of change request and just use a field to indicate whether it is a bug, requirement change, etc (this field can be used to build report queries).
What are the benefits of having a separate workflow for bugs?
I'm also confused by the fact that developers can submit work against a bug or a change request, I thought the intended workflow was for bugs to generate change requests which are what the developer references when making changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
请记住，TFS 工作项类型定义的一部分是其“工作流”的定义，即工作项可以处于的状态以及状态之间的转换。 这可以通过安全角色来保证。
因此，一般来说，“变更请求”将由组织中相对较高级别的人员发起并批准（具有与花费资源对系统进行（可能非常大的）更改相关的“赞助”权利的人员）。最终，这是 人可以
但是，对于“Bug”，应用程序的任何用户都应该能够发起一个 Bug，
在我实施 TFS 的组织中，只有部门负责 是该 Bug 的发起者。 “变更请求” - 但“错误”是从“帮助台”票证创建的（不是自动的，只是通过流程......）
Keep in mind that a part of a Work Item Type definition for TFS is the definition of it's "Workflow" meaning the states the work item can be and the transitions between the states. This can be secured by security role.
So - generally speaking - a "Change Request" would be initiated and approved by someone relatively high up in an organization (someone with "Sponsorship" rights related to spending the resources to make a (possibly very large) change to the system. Ultimately this person would be the one to approve that the change was made successfully.
For a "Bug" however, ANY user of the application should be able to initiate a Bug.
At an organization I implemented TFS at, only Department Heads can be the originators of a "Change Request" - but "Bugs" were created from "Help Desk" tickets (not automated, just through process...)
@Luke
我不同意你的观点，但这种差异通常是对为什么有两种不同的流程可用于处理这两类问题的解释。
我想说，如果主页的颜色最初设计为红色，但由于某种原因变成了蓝色，那么很容易快速修复，不需要涉及很多人或工时来进行更改。 只需签出文件，更改颜色，重新签入并更新错误即可。
然而，如果主页的颜色被设计为红色，并且是红色的，但有人认为它需要是蓝色的，那对我来说无论如何都是一种不同类型的改变。 例如，是否有人考虑过这可能对页面其他部分（例如覆盖蓝色背景的图像和徽标）产生的影响？ 看起来糟糕的事物是否有边界？ 链接下划线是蓝色的，会显示吗？
举个例子，我是红/绿色盲，对我来说，改变某物的颜色并不是一件可以掉以轻心的事情。 网络上有足够多的网页给我带来了问题。 只是为了指出一点，如果你考虑到一切，即使是最微不足道的改变也可能是不平凡的。
实际的最终实现更改可能大致相同，但对我来说，更改请求是不同的野兽，正是因为它需要更多地考虑以确保其按预期工作。
然而，一个错误是，有人说这就是我们要做的事情，然后有人采取了不同的做法。
变更请求更像是，但我们还需要考虑其他事情...嗯...。
当然也有例外，但让我把你的例子分开。
如果服务器设计可以处理超过 300,000,000,000 次页面浏览，那么是的，这是一个错误，但事实并非如此。 但是设计一个服务器来处理这么多的综合浏览量不仅仅是说我们的服务器应该处理 300,000,000,000 次综合浏览量，它应该包含一个非常详细的规范来说明如何做到这一点，对吧细化到处理时间保证和磁盘访问平均时间。 如果代码完全按照设计实现，但无法按预期执行，那么问题就变成：我们是否设计错误，或者我们是否错误实现？。
我同意，在这种情况下，到底是设计缺陷还是实现缺陷，取决于它未能达到预期的实际原因。 例如，如果有人假设磁盘的速度是实际速度的 100 倍，并且这被认为是服务器无法按预期执行的原因，我会说这是一个设计错误，需要有人重新设计。 如果仍然要满足那么多页面浏览量的原始要求，则可能必须进行包含更多内存数据和类似数据的重大重新设计。
但是，如果有人没有考虑到 raid 磁盘的运行方式以及如何正确地从条带介质中受益，那么这就是一个错误，可能不需要那么大的更改来修复。
同样，当然也会有例外。
无论如何，我所说的最初的差异是我发现在大多数情况下都是正确的。
@Luke
I don't disagree with you, but this difference is typically the explanation given for why there is two different processes available for handling the two types of issues.
I'd say that if the color of the home page was originally designed to be red, and for some reason it is blue, that's easily a quick fix and doesn't need to involve many people or man-hours to do the change. Just check out the file, change the color, check it back in and update the bug.
However, if the color of the home page was designed to be red, and is red, but someone thinks it needs to be blue, that is, to me anyway, a different type of change. For instance, have someone thought about the impact this might have on other parts of the page, like images and logos overlaying the blue background? Could there be borders of things that looks bad? Link underlining is blue, will that show up?
As an example, I am red/green color blind, changing the color of something is, for me, not something I take lightly. There are enough webpages on the web that gives me problems. Just to make a point that even the most trivial change can be nontrivial if you consider everything.
The actual end implementation change is probably much of the same, but to me a change request is a different beast, precisely because it needs to be thought about more to make sure it will work as expected.
A bug, however, is that someone said this is how we're going to do it and then someone did it differently.
A change request is more like but we need to consider this other thing as well... hmm....
There are exceptions of course, but let me take your examples apart.
If the server was designed to handle more than 300,000,000,000 pageviews, then yes, it is a bug that it doesn't. But designing a server to handle that many pageviews is more than just saying our server should handle 300,000,000,000 pageviews, it should contain a very detailed specification for how it can do that, right down to processing time guarantees and disk access average times. If the code is then implemented exactly as designed, and unable to perform as expected, then the question becomes: did we design it incorrectly or did we implement it incorrectly?.
I agree that in this case, wether it is to be considered a design flaw or a implementation flaw depends on the actual reason for why it fails to live up to expectations. For instance, if someone assumed disks were 100x times as fast as they actually are, and this is deemed to be the reason for why the server fails to perform as expected, I'd say this is a design bug, and someone needs to redesign. If the original requirement of that many pageviews is still to be held, a major redesign with more in-memory data and similar might have to be undertaken.
However, if someone has just failed to take into account how raid disks operate and how to correctly benefit from striped media, that's a bug and might not need that big of a change to fix.
Again, there will of course be exceptions.
In any case, the original difference I stated is the one I have found to be true in most cases.
一般来说，虽然我不能代表 CMM，但更改请求和错误的处理和考虑方式有所不同，因为它们通常涉及应用程序生命周期的不同部分。
bug 是程序实现中的缺陷。 例如，如果您将程序设计为能够将两个数字相加并向用户提供总和，那么一个缺陷就是它不能正确处理负数，从而导致错误。
当您有设计缺陷时就会提出变更请求。 例如，您可能明确表示您的程序不应处理负数。 然后提交变更请求，以便重新设计并重新实现该部分。 设计缺陷可能不是故意的，但很可能是因为您在最初设计程序时没有考虑到该部分，或者发明或发现了创建原始设计时不存在的新情况自从。
换句话说，程序可能完全按照设计运行，但需要更改。 这是一个变更请求。
通常，修复错误被认为是比执行更改请求便宜得多的操作，因为错误从未打算成为程序的一部分。 然而，设计是。
因此，可能需要不同的工作流程来处理这两种不同的场景。 例如，您可能会采用与更改请求不同的方式来确认和提交错误，这可能需要更多的工作来列出更改的后果。
Generally, though I can't speak for CMM, change requests and bugs are handled and considered differently because they typically refer to different pieces of your application lifecycle.
A bug is a defect in your program implementation. For instance, if you design your program to be able to add two numbers and give the user the sum, a defect would be that it does not handle negative numbers correctly, and thus a bug.
A change request is when you have a design defect. For instance, you might have specifically said that your program should not handle negative numbers. A change request is then filed in order to redesign and thus reimplement that part. The design defect might not be intentional, but could easily be because you just didn't consider that part when you originally designed your program, or new cases that didn't exist at the time when the original design was created have been invented or discovered since.
In other words, a program might operate exactly as designed, but need to be changed. This is a change request.
Typically, fixing a bug is considered a much cheaper action than executing a change request, as the bug was never intended to be part of your program. The design, however, was.
And thus a different workflow might be necessary to handle the two different scenarios. For instance, you might have a different way of confirming and filing bugs than you have for change requests, which might require more work to lay out the consequences of the change.
执行总是源于需求。 可能是产品经理的想法，也可能是你们一些人的胡思乱想。 它可能被记录下来，也可能来自一些谈话。 归根结底，即使是像
a := a + 1这样简单的东西，“真正的”实现也将基于编译器、链接器、CPU 等，这取决于物理定律现实生活。错误是针对原始要求实施的。 除此之外，这是一个变更请求。
如果需求发生变化并且实现也需要更改，那么这就是变更请求。
如果依赖关系已更改，例如 Web 浏览器停止支持某些标签，而您需要进行一些更改，则这是一个更改请求。
实际上，任何未正确记录的内容都应视为变更请求。 产品经理忘记在故事中添加一些内容？ 抱歉，这是一个变更请求。
所有变更请求都应该得到正确的估计和指出。 开发人员通过提出变更请求来获得报酬，而不是通过制造错误并修复他们提出的错误来获得报酬。
Implementation always comes from requirement. It may be from product manager, it may be from some of you random thought. It may be documented, it may be from some conversation. In the end of the day, even something as simple as
a := a + 1, the "real" implementation would be based on compiler, linker, CPU, etc. which depends on the physical law of real life.A bug is something that is implemented against the ORIGINAL requirement. Other than that, it is a change request.
If the requirement is changed and the implementation need to be changed as well, it's a change request.
If the dependency has been changed, for example web browser stopped supporting some tags and you need to make some change, it's a change request.
In real word, anything that is not properly documented should be treated as change request. Product manager forgot to put something in the story? Sorry, that's a change request.
All change requests should be properly estimated and pointed. Developers get paid for making change requests, not for making bugs and fixing those made by them.
错误是指已批准实施的需求中出现的问题。
变更请求需要经历一个周期，在该周期中必须估计该变更的影响和工作量，然后必须在开始工作之前批准实施。
两者在CMM下有本质的不同。
A bug is something that is broken in a requirement which has already been approved for implementation.
A change request needs to go through a cycle in which the impact and effort has to be estimated for that change, and then it has to be approved for implementation before work on it can begin.
The two are fundamentally different under CMM.
我的假设是否正确，即变更请求应该由错误生成？ 我很困惑，因为我不认为所有错误都应该自动批准实施——它们可能是微不足道的，至少在我们的例子中，在分配给开发人员之前会经历与变更请求相同的审查过程。
Is my assumption incorrect then that change requests should be generated from bugs? I'm confused because I don't think all bugs should be automatically approved for implementation -- they may be trivial and at least in our case will go through the same review process as a change request before being assigned to a developer.