建置和管理產品待處理項目

作者 Mitch Lacey。 擁有者 Mitch Lacey & Associates, Inc,是一家致力於 agile 和 scrum 採用及改進的諮詢公司。

2012 年 1 月

在本文中,Mitch Lacey 說明產品待處理項目 (Backlog) 的重要性、描述如何建立良好待處理項目 (Backlog),並提供一些建立和維護待處理項目的最佳做法。

套用至

Application Lifecycle Management;Team Foundation Server (TFS)

本文內容:

  • 簡介

  • 產品待處理項目

    • 使用者劇本

    • 評估

    • 優先順序

  • 即時產品待處理項目

    • 清理

產品待處理項目是已設定優先權的清單,該清單包含完成專案所需的所有特性和功能。 在 TFS 中,您可以使用工作項目來管理您產品的待處理項目。 您所選擇的工作項目類型將會依用來建立 Team 專案的流程範本而有所不同。 若要深入了解流程範本以及這些範本所支援的工作項目類型,請參閱使用 Team 專案成品,選擇流程範本

所有運作正常的敏捷式軟體開發團隊都非常注重良好的產品待處理項目,產品待處理項目具有下列特性:

  • 已設定優先權,以確保團隊先建置最重要的功能。

  • 團隊會負責評估,以讓產品擁有者清楚明瞭,並讓他可以回答「這些劇本何時會完成?」這類問題。

  • 它包括完成專案所需的所有工作。

  • 它是即時文件,不斷變更及演變,以反映專案的目前現實情況。

好的產品待處理項目不會自動保證好的軟體。 不過,缺乏好的產品待處理項目經常會導致不符合客戶和專案關係人的不完整軟體。

管理產品待處理項目是一項全職的工作。 簡單的技術可協助變更將強勢耗時處理序變更為涉及團隊成員、客戶和專案關係人之互動反覆處理序所需的內容。 因此,徹底了解實際使用的技術可謂相當重要,這能協助您建置、維護產品待處理項目,並設定其優先權。

產品待處理項目

產品待處理項目是已設定優先權的即時主要清單,該清單包含完成專案所需的所有特性和功能。 產品待處理項目通常包括需求使用者劇本 (例如 需求)、Bug、研究工作 (增量) 和工程改進。 評估這些項目時,會使用抽象單位,通常稱為本文點。

產品待處理項目包括隨著時間的推移,專案需要及發展的所有工作。 因此,待處理項目不僅包含產品的新功能,還包括 Bug 修正和研究等任何會花費團隊時間的項目。 團隊要做的所有工作必須取自產品待處理項目,換句話說,待處理項目是通往專案的大門。 如果產品待處理項目包括所有工作,則產品擁有者、團隊和管理層能更了解工作,如此就不會在最後一刻感到特別驚訝。

任何專案開始時,您不可能擁有一份清晰完善的產品待處理項目清單供您評估和設定優先權。 相反地,您可能擁有一堆劇本要點卡片,或許還有一兩張功能規格表。 身為產品擁有者,您必須從混亂中釐清頭緒,以便團隊可以開始評估產品待處理項目。

使用者劇本

第一步是將所有的想法和要點轉換為使用者劇本,以表達一般使用者想要的功能 (軟體應該實現的功能),但不是實作詳細資料 (如何建立符合這些需求的軟體)。 每一個使用者劇本的標題應該遵循下列格式:「身為 <使用者>,我想要 <功能>,原因是 <原因>。」

腳本卡範例

就如產品待處理項目本身一樣,隨著時間的推移,每一個使用者劇本都可能發展。 在整個專案時間內,您的團隊會設定這些劇本的優先權,並對其進行評估,將詳細資訊加入至劇本,並將它們細分成較小的劇本或一起刪除它們。 進入衝刺的那些劇本會實作並傳遞給您的客戶。

若要閱讀更多使用者劇本相關資訊,請參閱 建立待處理項目使用 PowerPoint 將想法轉為分鏡腳本

在將所有想法和要點轉換為使用者劇本之後,接著應該加以評估並設定優先權。

評估

當然,評估是不精確的。 不過,您可以讓整個團隊一起,透過不斷地實踐,來建立相對精確的評估,從而變得越來越好。第一步凝聚整個團隊,對產品待處理項目進行評估。 當團隊評估每一個劇本時,他們會使用稱為本文點的抽象度量單位,對其進行相對大小評估。

評估之所以重要,是因為下面兩個原因:

  1. 評估有助於回答「我們什麼時候會完成?」這個問題。

  2. 評估也可協助產品擁有者判定每一個項目的優先權。

評估可讓產品擁有者和團隊了解特定劇本所需耗費的成本,從而協助產品擁有者設定劇本之間的相對優先權。 項目的評估越大,實作該項目所花費的時間和資源就會越多。 因此,如果產品擁有者極度希望實現的項目成本太高,其優先權可能會因而降低。

團隊可以使用 Planning Poker、Big Wall 或其他技術,以本文點來對工作進行評估。 如需評估技術及本文點快速課程的詳細資訊,請參閱 評估整備與評估待處理項目

在團隊評估完所有劇本之後,接著應該設定優先權。

優先順序

所有產品待處理項目會透過商務價值和風險設定優先權。 產品擁有者會將待處理項目上的每一個項目與其他項目相比較,以判定其相對優先權。 判定相對優先權時,產品擁有者必須考量每個項目的大小、商務價值及任何相關風險。 隨後,會依照優先權的遞減順序,對項目進行排序。 高優先權的項目會顯示在產品待處理項目的頂端或附近,而較低優先權項目會在底端或附近。 團隊會從最高優先權項目中間選擇即將進行之衝刺的工作,以便最先完成最重要的項目。

待處理項目中並非每一個項目的大小都相同。 部分項目可在一個衝刺中完成,但其他太大的項目就無法如此順利,因為團隊無法完全確定其中涉及的技術或實作需要的時間。 不過這不要緊。 當項目移至待處理項目頂端附近時,團隊會讓它們變得更小,且更受關注,以便每一個人都能更了解他們在即將進行之衝刺中所處理的工作。

如同評估一樣,設定初始產品待處理項目的優先權是一項艱鉅的任務。 您要如何有效地在互相競爭的專案關係人需求中找到平衡,同時考慮最終產品、風險和成本? 幸運的是,有數種技術可讓該工作變得更加輕鬆,包括 Innovation Games 和相對加權。 如需上述和其他技術的詳細資訊,請參閱 排定優先順序整備與評估待處理項目

無論您選擇何種設定優先權技術,您都必須對工作進行排序,以確保團隊建置對企業、專案關係人和客戶而言最具價值的功能。 如果您不設定工作的優先權,則會增加在資源和排程變更時,傳遞較低優先權使用者劇本,而非較高優先權使用者劇本,以及不完整使用者劇本的風險。

(如需待處理項目本質的詳細資訊,請參閱 建立待處理項目使用 Portfolio 待處理項目)。

即時產品待處理項目

到目前為止所述的內容重點是從無到評估產品待處理項目,並設定其優先權。 與需求文件不同,產品待處理項目不是在專案的開頭建立,然後放到書架上的。 相反,產品待處理項目會發展,隨著產品的現實情況擴展和收縮。 部分產品待處理項目會變得無關,需要移除。 其他的則會浮上表面,需要細分為較小的劇本。 當其他需求出現時,會加入、評估新的使用者劇本,並設定其優先權。

團隊及專案關係人會建立及管理產品待處理項目,但產品擁有者對其具有最終責任。 產品擁有者必須確保產品待處理項目清晰、最新,並已設定優先權,以便客戶和團隊清楚地了解專案發行的工作計劃。 即使專案已經全面展開之後,產品擁有者仍有大量工作要做,以讓產品待處理項目保持良好的狀態:

  • 加入新劇本並設定優先權

  • 要求團隊評估新劇本,並在更了解舊劇本時,重新評估舊劇本

  • 與團隊一起檢閱即將進行的使用者劇本,以在必要時對項目進行細分

  • 與客戶和專案關係人開會,以檢閱並加入需求

任何人可以隨時將項目加入產品待處理項目,但只有產品擁有者可以對它們設定優先權。 產品擁有者還是唯一一個可以將優先權指派給劇本的人。 團隊的其他成員及專案關係人在加入劇本時,應該將優先權留為空白,即使他們使用的電子工具提示他們輸入該資訊亦同。

加入劇本時,產品擁有者要基於其對該劇本的理解,對其優先權進行初步評量。 他會就劇本與其建立者進行討論,更進一步了解該劇本,以便之後可以回答團隊的問題。 在每一個衝刺期間的預先決定時,產品擁有者會與團隊開會,討論新的劇本,並協同對它們進行評估,以便他可以更精確地相對於產品待處理項目中的其他劇本,對它們設定優先權。 此處理序稱為清理產品待處理項目。

清理

之前提到的產品待處理項目清理必須定期進行。

在 Scrum 中,團隊應該花費 5%-15% 的時間在清理活動的每一個衝刺上。 團隊必須了解接下來會發生的狀況以及正在變動的部分,以便他們可以細分任何優先權上升的大型劇本、評估任何已建立的劇本,以及對即將處理的劇本執行部分緊急設計和規劃。 若要確保發生此情況,產品擁有者及團隊應該在每一個衝刺規劃會議期間,留出該衝刺期間的部分時間,以一起清理設定產品待處理項目。 若要閱讀衝刺規劃的詳細資訊,請參閱 衝刺計劃衝刺工作

在兩週衝刺期間,我喜歡在第二週期間主持此會議。 這為產品擁有者提供了足夠的時間,與客戶和專案關係人一起進行有意義的交談,取得對商務變更的了解,以及釐清新建或優先權上升的使用者劇本和劇本。 這也是衝刺期間的邏輯時間,可開始預測接下來的衝刺。 您可以決定何時主持會議。 容許衝刺期間有足夠的時間完成清理活動是件重要的事情。

一般在清理會議中,產品擁有者會報告新建的內容、已變更的內容,以及他對接下來幾個衝刺的計劃。 除了評估新劇本並細分必須盡快完成的劇本之外,團隊還要在此會議中,花費時間檢閱系統的目前架構,並計劃或設計即將擁有的功能。 在此處理序期間,劇本評估經常會變更,當較大的劇本細分為較小的劇本時,傾向於顯示新劇本。

此處理序看似簡單,但也可能需要付出努力才能實現。 若要讓事情順利執行,產品擁有者必須準備回答問題。 例如如果產品擁有者計劃在下一個衝刺時完成劇本,但無法提供團隊所需要提供良好的評估時,可能會不停發生衝突。 如果這種情況發生在衝刺規劃會議期間,則 ScrumMaster 應該對產品擁有者進行指導,讓其了解他應該從客戶和專案關係人那裡,將什麼資訊帶給團隊。

在每場清理會議結束時,產品擁有者應向專案關係人和客戶發佈變更項目,讓每個人都可以了解最新進度、即將發生的事情,以及更新後的發行計劃。

一個好的產品待處理項目有助於確保您所建置的軟體具有最重要的功能,就如同您與客戶和專案關係人交談中確定,以及使用者劇本中定義的一般。 若要建立及維護良好的產品待處理項目,您必須定期 (每一次衝刺) 主動與專案關係人/客戶群組及團隊合作。

建置一個好的待處理項目並不一定能確保好的系統,但沒有一個好的待處理項目幾乎可以肯定您的系統不會實現客戶的要求。 換句話說,如果不保持時刻更新待處理項目,將會幾乎導致您的專案失敗。

產品擁有者是項全職工作,待處理項目就是他們的責任。 請認真看待該角色。 盡可能讓產品待處理項目維持良好狀態,客戶絕對會感謝您的付出。

請參閱

概念

使用 Visual Studio ALM 和 TFS 追蹤工作

要求和檢閱利害關係者意見反應,藉由使用Team Web Access

開始安裝單一伺服器 TFS

使用 Team 專案成品,選擇流程範本