工作项跟踪管理系统需求
工作項跟蹤管理系統(tǒng)需求
WIT (Work Item Track)
包含:缺陷跟蹤、任務指派、突發(fā)事件處理、需求管理、客戶定制
體現(xiàn):流程性、規(guī)范性、流程可定制性
目的:幫助大家把工作做好、讓工作更輕松、使得工作具有可管理性
原則:
?
用戶場景
?
?
?
?
?
?
?
?
?
?
?
?
工作項:用于跟蹤工作的分配和狀態(tài)的數(shù)據(jù)庫記錄
工作項類型:
- Bug(缺陷)
- Task(任務)
- Requirement(需求)
- Accident(突發(fā)事故)
Bug(缺陷):
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
| 字段 | 英文名稱 | 說明 |
| 標題 | Title | 必選。標題提供要修復的問題的簡要概述。標題應具有足夠的描述性以使會審團隊能夠了解該產(chǎn)品的哪個區(qū)域受影響以及如何受影響。 |
| 區(qū)域 | Area | 區(qū)域用于根據(jù)項目層次結構中的功能或團隊對 Bug 進行分組。區(qū)域必須是項目層次結構中的有效節(jié)點。 |
| 迭代 | Iteration | 迭代標識在其中修復 Bug 的迭代。 |
| 指派給 | Assigned To | 此字段標識該 Bug 當前指派給的人員。如果該 Bug 需要多次開發(fā)修復,則可將其視作方案并指派給依賴項鏈中的下一位人員。當所有部分合為一體時,Bug 報表發(fā)回到測試人員。 |
| 優(yōu)先級別 | Priority | 必選。優(yōu)先級別是主觀重要性分級。優(yōu)先級別 1 指示產(chǎn)品不可正式發(fā)布,并且必須盡快修復。優(yōu)先級別 2 表示重要的 Bug,該 Bug 無需立即修復,但必須在版本發(fā)布前修復。優(yōu)先級別 3 表示可選 Bug,根據(jù)資源、時間和風險的不同,該 Bug 可以修復也可以不修復。 |
| 狀態(tài) | State | 必選。Bug 可處于“活動”、“已解決”或“已關閉”狀態(tài)。 |
| 原因 | Reason | 必選。Bug 處于當前狀態(tài)的原因。例如,因為 Bug 為“已修復”,所以它可處于已解決狀態(tài)。 |
| 說明 | Description | 說明提供了一個區(qū)域以描述問題以及重現(xiàn)該問題的步驟。 |
| 歷史記錄 | History | 此歷史記錄是有關 Bug 報表的持續(xù)進行的論述,它積累了隨著所做的更改而額外寫入的項。每當對 Bug 進行更改時,“歷史記錄”字段中就會生成一項,該項描述所進行的更改和更改的原因,以及關于此次更改的任何額外相關信息。 |
| 問題 | Issue | “問題”是一個“是”或“否”值,它指示對 Bug 的修復是否以某種方式被阻止。如果此字段設置為“是”,則該方案將出現(xiàn)在項目經(jīng)理的問題報告中。 |
| 發(fā)現(xiàn)版本 | Found in Build | 此字段顯示在其中發(fā)現(xiàn) Bug 的版本號。 |
| 解決版本 | Resolved in Build | 此字段保存在其中解決 Bug 的版本號。 |
| 測試名稱 | Test Name | 此字段標識與此 Bug 關聯(lián)的測試的名稱。 |
| 測試 ID | Test ID | 此字段標識與此 Bug 關聯(lián)的測試的 ID。 |
| 測試路徑 | Test Path | 此字段標識與此 Bug 關聯(lián)的測試的路徑。 |
| 鏈接 | Links | 指向相關工作項、超鏈接、變更集或源代碼文件的鏈接。 |
| 文件附件 | File Attachments | 附加相關文件,這些文件提供圍繞風險的附加文檔。 |
| 級別 | Rank | 相對于其他工作項的相對優(yōu)先級別。 |
| 會審 | Triage | 會審會議的結果。空白會審意味著 Bug 未會審。 |
?
Task(任務):
?
| 字段 | 英文名稱 | 說明 |
| 標題 | Title | 必選。標題提供要完成的任務的簡要概述。標題應具有足夠的描述性以使團隊能夠了解該產(chǎn)品的哪個區(qū)域受影響以及如何受影響。 |
| 專業(yè)領域 | Discipline | 指示該任務是開發(fā)任務、測試任務,還是僅僅是普通任務。將“專業(yè)領域”字段設置為開發(fā)或測試將產(chǎn)生有關任務關閉時的工作狀態(tài)的獨特意義。 |
| 區(qū)域 | Area | 用于將任務分組到相應的功能或團隊區(qū)域中。區(qū)域必須是項目層次結構中的有效節(jié)點。 |
| 迭代 | Iteration | 預定的迭代是在其中修復 Bug 報表的迭代。 |
| 指派給 | Assigned To | 任務所指派給的當前人員。 |
| 狀態(tài) | State | 必選。任務可處于“活動”或“已關閉”狀態(tài)。 |
| 原因 | Reason | 必選。任務處于當前狀態(tài)的原因。例如,因為任務為“已完成”、“已推遲”、“去除”、“已推遲”或“已過時”,所以該任務可以為“已關閉”。 |
| 級別 | Rank | 必選。“級別”字段是主觀重要性分級。如果“級別”字段設置為 1,則該任務為必須完成的任務,并且應盡快完成。如果級別設置為 2,則該任務為應該完成的任務,應在級別為 1 的所有任務完成之后完成。如果級別設置為 3,則該任務為可以完成的任務,應在級別為 1 和 2 的任務完成之后完成。 |
| 摘要 | Summary | 任務的簡短摘要。 |
| 詳細說明和歷史記錄 | Detailed Description and History | 工作項的詳細信息和歷史記錄。 |
| 文件附件 | File Attachments | 指向文件或其他工作項的鏈接。在開發(fā)任務或測試任務的情況下,應附加支持方案或服務質(zhì)量要求。它還包含對任務的注釋之類的任何附件。 |
| 問題 | Issue | 問題是一個“是”或“否”值,它指示任務是否以某種方式被阻止。如果此字段設置為“是”,則該任務將顯示在項目經(jīng)理的問題報告中。 |
| 退出條件 | Exit Criteria | “退出條件”字段指示任務對于開始或結束迭代是否重要。當?shù)捎跁r間的消逝而退出時,應合理地使用此字段。但是,某些任務(尤其是在項目開始時)被標記為退出條件以指示它們必須在項目開始之前完成。如果“退出條件”字段設置為“是”,則該任務將顯示在項目經(jīng)理的項目檢查表中。 |
| 集成版本 | Integration Build | 對開發(fā)任務的更改出現(xiàn)在所顯示的版本號中。 |
| 剩余工作量(小時) | Remaining Work (hours) | 完成任務之前剩余的工作量。此字段與 Microsoft Project 同步,并且可在選擇了 Microsoft Project 版本的迭代計劃時使用。 |
| 已完成工作量(小時) | Completed Work (hours) | 任務中已完成的工作量。此字段與 Microsoft Project 同步,并且可在選擇了 Microsoft Project 版本的迭代計劃時使用。 |
?
Requirement(需求):
?
| 字段 | 英文名稱 | 說明 |
| 標題 | Title | 必選。標題應盡可能具有描述性。 |
| 區(qū)域 | Area | 區(qū)域用于將服務質(zhì)量要求分組到一個相應的功能或團隊區(qū)域中。區(qū)域必須是項目層次結構中的有效節(jié)點。 |
| 迭代 | Iteration | 在代碼中實現(xiàn)服務質(zhì)量要求時所在的迭代。 |
| 類型 | Type | 有六種類型的服務質(zhì)量要求:“負載”、“壓力”、“性能”、“平臺”、“其他”和“安全”。 |
| 指派給 | Assigned To | 服務質(zhì)量要求所指派給的當前人員。 |
| 狀態(tài) | State | 必選。服務質(zhì)量要求可處于“活動”、“已解決”或“已關閉”狀態(tài)。 |
| 原因 | Reason | 服務質(zhì)量要求處于當前狀態(tài)的原因。例如,因為要求為“已完成”,所以它可處于“已關閉”狀態(tài)。 |
| 說明 | Description | 說明提供一個區(qū)域以描述服務質(zhì)量要求。應提供盡可能多的詳細信息以確保開發(fā)人員可實現(xiàn)該要求,并且測試人員可測試該要求。 |
| 歷史記錄 | History | 此歷史記錄是有關服務質(zhì)量要求的持續(xù)進行的論述,它積累了隨著所做的更改而額外寫入的項。每當對要求進行更改時,“歷史記錄”字段中就會生成一項,該項描述所進行的更改和更改的原因,以及關于此次更改的任何額外的相關信息。 |
| 問題 | Issue | “問題”是一個“是”或“否”值,它指示方案在進行過程中是否被阻止。如果此字段設置為“是”,則該方案將顯示在項目經(jīng)理的問題報告中。 |
| 退出條件 | Exit Criteria | “退出條件”是一個“是”或“否”值,它指示服務質(zhì)量要求是否為退出條件列表的一部分。如果此字段設置為“是”,則該要求出現(xiàn)在項目檢查表中。 |
| 級別 | Rank | “級別”指示此服務質(zhì)量要求相對于軟件產(chǎn)品的所有要求的重要程度。有效值為從 1 到 3。 |
| 集成版本 | Integration Build | “集成版本”是開發(fā)團隊在其中集成該要求的版本號。 |
| ID | ID | ID 是指派給服務質(zhì)量要求的唯一標識號。 |
| 量值的粗略預定 | Rough Order of Magnitude | 量值的粗略預定估計是方案或服務質(zhì)量要求復雜性的度量值。如果工作項要求實現(xiàn) 6 個或 6 個以下的 1-2 日開發(fā)任務,則選擇 1。如果工作項要求實現(xiàn) 6 到 12 個 1-2 日開發(fā)任務,則選擇 2。如果比這更多,則選擇 3 并考慮拆分方案或服務質(zhì)量要求。 |
?
Accident(突發(fā)事故):
轉(zhuǎn)載于:https://www.cnblogs.com/Bolik/archive/2006/06/16/427549.html
總結
以上是生活随笔為你收集整理的工作项跟踪管理系统需求的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 模板类的定义和实现可以分开吗?
- 下一篇: 一个简单又高效的日志系统