问题

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

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

然而,在我们当前的系统中,我们只有一种类型的更改请求,只需使用一个字段来表示它是否是一个错误,需求更改等(这个字段可用于构建报告查询)。

有一个单独的bug工作流有什么好处?

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

  最佳答案

@Luke

我不同意你,但这种区别通常是解释为什么有两个不同的进程可用于处理这两种类型的问题.

我会说,如果主页的颜色最初设计为红色,并且由于某种原因它是蓝色的,那很容易是一个快速的修复,并且不需要让许多人或者man-ways来进行更改.只需检查文件,更改颜色,检查它并更新bug.

但是,如果主页的颜色设计为红色,并且是红色的,但有人认为它需要蓝色,也就是说,对我来说,是一种不同的变化.例如,有人认为这可能对页面的其他部分产生影响,例如图像和标识覆盖蓝色背景?是否有看起来不好的东西的边界?链接强调是蓝色的,会显示出来吗?

例如,我是红/绿色盲人,改变某些东西的颜色,对我来说,不是我轻视的东西.网上有足够的网页给我带来问题.只是要指出,如果你考虑一切,即使是最微不足道的更改也可能是毫无意义的.

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

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

更改请求更像,但我们也需要考虑这个其他东西...

当然有一些例外,但让我分开你的例子。

如果服务器设计用于处理超过300,000,000,000个pageviews,那么是的,它不是一个错误.但是设计服务器来处理这些pageviews不仅仅是说我们的服务器应该处理300,000,000,000个pageviews,它应该包含一个非常详细的规范,说明它如何做到这一点,直到处理时间保证和磁盘访问平均时间.如果代码完全按照设计实现,并且无法按预期执行,那么问题就变成:我们是否设计错误或我们实现错误?

我同意,在这种情况下,它被认为是设计缺陷或实现缺陷取决于为什么它不能达到预期的实际原因.例如,如果有人假设磁盘的速度是实际的100倍,这被认为是服务器未能按预期执行的原因,我会说这是一个设计错误,有人需要重新设计.如果仍然保持许多pageview的原始要求,则需要进行一个带有更多内存数据和类似的重大重新设计.

但是,如果有人刚刚没有考虑到突袭磁盘的操作方式以及如何正确受益于条纹媒体,那是一个错误,可能不需要那么大的更改来修复。

当然还有例外。

无论如何,我所说的最初的区别是我发现在大多数情况下都是真的。

  相同标签的其他问题

tfsworkflowlifecyclecmmimsf