問題

我目前正在評估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