共用方式為


建立與管理產品待處理事項

Mitch Lacey 原著。 擁有者是 Mitch Lacey & Associates, Inc 顧問公司,專精於採用及增強敏捷與 scrum。

2012 年 1 月

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

套用至

Application Lifecycle Management; Team Foundation Server

本文內容:

  • 簡介

  • 產品待處理項目

    • 使用者劇本

    • 估計

    • 排定優先順序

  • 現行產品待處理項目

    • 整備
  • 總結

產品待處理項目是完成專案所需之所有功能與機能的優先順序排列清單。 所有運作正常的 Agile 小組都非常注重良好的產品待處理項目,其具備下列特性:

  • 進行優先順序排定可以確保小組首先建置最重要的功能。

  • 這是由小組進行估計,以便向產品擁有者說明白,使他能回答像「這些劇本何時會完成?」這樣問題,

  • 這包括完成專案的所有必要工作。

  • 這是一份現行的文件,常常會變更,並且不斷進展以反映專案目前的實際狀況。

良好的產品待處理項目不會自然而然保證取得良好軟體。 不過,缺少良好的產品待處理項目通常會導致軟體因為不符合客戶和專案關係人的需求而不完整。

管理產品待處理項目是一份全職工作。 簡單技巧有助於改變那些會影響到團隊成員、客戶、以及專案關係人的程序,像是負荷過重、費時的程序、互動或反覆進行的程序等。 因此,學習實用的技巧以協助您建置、優先順序排定和維護產品待處理項目是必要的。

產品待處理項目

產品待處理項目是完成專案所需之所有功能與機能的排好優先順序之總清單。 產品待處理項目通常包括要求使用者劇本 (即.. 要求), Bug、研究工作 (裝訂) 和工程改良。 這些項目以抽象單位估計,這種單位通常稱為本文點。

產品待處理項目包括專案所需要以及經一段時間演化的所有工作。 因此,不僅包含產品的新功能,而且還包括錯誤修正和研究 (任何會耗費小組時間的事項)。 小組將會執行的所有工作都必須來自產品待處理項目:這是專案的正門。 如果產品待處理項目包括所有工作,產品擁有者、小組和管理階層就會更了解完成剩餘工作和減少緊要關頭意外的情況。

在任何專案開始時,您都不可能已經備妥定義明確的產品待處理項目清單,以進行評估和排定優先權。 不過,您很可能有一疊劇本提示卡,也可能有功能規格,或者兩者。 身為產品擁有者,您的職責就是將這種散亂情況整理成一定的次序,讓小組可以開始評估待處理項目。

Hh765980.collapse_all(zh-tw,VS.110).gif使用者劇本

第一步是將所有的概念與注意轉換成使用者劇本,它明確表示出使用者需要的功能 (何種軟體應該有),但不會有實作詳細資料 (如何建立符合那些需求的軟體)。 每個使用者劇本的標題都必須遵循下列格式:「身為 <user>,我想要 <functionality> ,讓 <reason>」。

腳本卡範例

和產品待處理項目本身相同,每個使用者劇本都會隨著時間進展。 在專案進行期間,您的小組會排定劇本優先權並加以估計、將詳細資訊加入至其中,並將它們細分為更小的劇本或一併刪除。 實作列入衝刺 (Sprint) 中的並交付給客戶。

若要進一步了解使用者劇本,請參閱 建立或新增產品待處理項目藉由使用 PowerPoint 的圖片敘述積存的項目

將所有概念與附註轉換成使用者劇本之後,就應該進行評估並排定優先權。

Hh765980.collapse_all(zh-tw,VS.110).gif估計

根據定義,估計不精確。 不過,隨著時間、練習和整個小組的參與,您可能會變得更擅長建立相對精確的估計。第一個步驟就是召集,一起提供關於產品待處理項目的預估。 當小組估計每個劇本時,會以抽象的度量單位指定相對大小估計,稱為本文點。

評估是必要的,有兩個原因:

  1. 它們有助於回答「我們什麼時候可以完成?」這個問題

  2. 他們協助產品擁有者判斷每個項目的優先順序。

評估可提供產品擁有者及小組對於特定劇本成本的概念,進而協助產品擁有者排定劇本之間相對的優先順序。 此項目的估計越高時,反映在時間與資源就愈多。 因此,產品擁有者高度預期的項目若成本偏高,優先順序就有可能降低。

小組可以使用規劃撲克牌 (Planning Poker)、大圍牆或其他技術來根據本文點預估工作。 如需評估技術以及本文點快速課程的詳細資訊,請參閱估計整備與評估待處理項目

在小組估計所有劇本之後,就應該排定優先權。

Hh765980.collapse_all(zh-tw,VS.110).gif排定優先順序

所有產品待處理項目的優先權都是根據商務價值和風險來排定。 產品擁有者會將待處理項目內每個項目與其它項目做比較,以決定其相對優先權。 為了這麼做,產品擁有者會考慮每個項目的大小、該項目對於企業的價值,以及任何相關風險。 項目接著以遞減的優先權次序排序。 高優先權的項目會出現在或接近產品待處理項目的頂端,而較低優先權的項目則位在或接近底部。 小組會選擇他們在即將來臨的衝刺 (Sprint) 中最高優先的工作項目優先進行,也因此最重要的項目會先被完成。

並非待處理項目中的每個項目都有相同的大小。 某些在一次衝刺 (Sprint) 內可完成,不過,其他太大的部分,小組成員不能完全確定那些功能包含在內,或需要多少時間來開發它們。 沒有關係。 當項目更接近待處理項目頂端時,小組會讓這些項目變得更小且更為聚焦,使所有的人更加了解即將在這次衝刺 (Sprint) 中處理的工作。

如同評量的情形,排定初始產品待處理項目的優先權恐怕一樣令人怯步。 考量最終產品、風險和成本時,您如何有效平衡競爭的專案關係人需要? 所幸,讓工作更輕鬆的幾種方法存在,包括 Innovation Games 和相對加權。 如需更多相關與其他技術資訊,請參閱優先處理順序整備與評估待處理項目

無論您選擇哪一種排定優先順序的技巧,都必須安排工作順序,確保小組建置的功能可以提供對企業、專案關係人及客戶最有利的價值。 如果您沒有排定工作優先權,就會增加風險,當資源和排程變更時,您可能會交付較低優先權的使用者劇本 (而不是較優先項目) 和不完整的使用者劇本。

(如需待處理項目性質的詳細資訊,請參閱建立或新增產品待處理項目敏捷式計劃和反覆項目)。

現行產品待處理項目

目前所描述的著重於從一無所有到估計與排列優先順序的產品待處理項目。 不同於需求文件,產品待處理項目不會在專案開始時建立然後閒置。 相反地,產品待處理項目會逐漸發展,隨著專案的實際狀況擴張和緊縮。 某些產品待處理項目將會變成不相關而需要被移除。 其他則會浮出表面,需要細分成較小的劇本。 當額外需求合併時,會加入、估計和優先順序排定新的使用者劇本。

小組和專案關係人負責建立和管理產品待處理項目,但最終負責人是產品擁有者。 產品擁有者必須確定待處理項目都已清除、排定優先權以及更新,以便讓客戶和小組都對專案發行有明確的工作計畫。 即使在專案緊鑼密鼓進行之後,產品擁有者仍然有大量的工作要做以維持產品待處理項目的良好狀態。

  • 加入新劇本並設定其優先順序

  • 要求小組估計新劇本,並在小組對舊劇本有更深入的了解時要求重新評估舊劇本。

  • 與小組一起檢閱即將進行的使用者劇本,視需要將項目細分

  • 會同客戶和專案關係人一起檢閱並加入需求

任何人都可以隨時將項目加入至產品待處理項目,但是只有產品擁有者才能排定其優先權。 產品擁有者也是唯一可以指派優先權給劇本的人。 加入劇本時,小組所有其他成員和專案關係人都應該讓優先權空白,即使所使用的電子工具提示要求這項資訊,也要這樣。

加入劇本時,產品擁有者會根據對劇本的了解進行優先順序初步評估。 他將會與建立者討論這個劇本做進一步了解,接下來讓自己能夠回應小組的問題。 在每個衝刺 (Sprint) 的預先決定的時間,產品擁有者將與小組開會討論新劇本,並合作評估這些劇本,以便相對於待處理項目中其他劇本更精確地排定其優先權。 這個處理序稱為修飾待處理項目。

Hh765980.collapse_all(zh-tw,VS.110).gif整備

如先前所述,產品待處理項目整備必須定期進行。

在 Scrum 中,小組應於每次衝刺 (Sprint) 中花費 5%-15% 的時間在整備活動上。 小組必須了解進度及變更,才能將所發生的任何大劇本按優先順序細分、預估已建立的劇本,以及進行緊急設計與後續劇本的規劃。 要確保已執行此作業,產品擁有者和小組應在每次衝刺 (Sprint) 規劃會議期間花一點時間一起修改待處理項目。 若要進一步了解衝刺 (Sprint) 計劃,請參閱 衝刺計劃計劃反覆項目

在兩週的衝刺 (Sprint) 期間,我想要在第二週期間開這個會議。 這可讓產品擁有者有時間與客戶和專案關係人進行有意義的對話、充分了解產業中的變化,以及釐清使用者劇本和優先順序中的新劇本或上升的劇本。 這也是衝刺 (Sprint) 期間的邏輯推理時間,要開始預先考慮接下來的幾個衝刺 (Sprint)。 您可以決定舉行會議的時間。 最重要的是在衝刺 (Sprint) 期間允許足夠的時間去完成整備活動。

在典型的整備會議期間,產品擁有者會簡報新功能、已做的變更以及接下來幾個衝刺 (Sprint) 的計畫。 除了估計新劇本並細分必須很快完成的劇本以外,小組還要花時間在此會議期間系統目前的架構,並規劃或設計近期活動的功能。 在這個過程中,劇本估計經常變更,而通常顯得較大的新劇本會細分為較小的劇本。

這個處理序似乎簡單,不過可能有點困難。 為了協助事情順利進行,產品擁有者必須準備好回答問題。 例如,如果產品擁有者正在規劃要在下一次衝刺 (Sprint) 完成的劇本,但無法清楚表示小組需要提供有效的估計,那麼隨後就可能發生衝突。 如果會在衝刺 (Sprint) 計劃會議期間發生這種情況,Scrum 主管應該指導產品擁有者關於他應該將客戶和專案關係人的哪些資訊提供給小組。

在每次整備會議結束時,產品擁有者應向專案關係人和客戶發佈這些變更,讓每個人都可以看到最新進展、即將發生的事項和更新的發行計畫。

良好的產品待處理項目有助於確保您建置的軟體具有大部分重要功能,如您在與客戶及專案關係人的交談中和使用者劇本中所定義。 若要建立和維護良好產品待處理項目,您必須積極地與專案關係人/客戶群組及小組定期 (每次衝刺 (Sprint)) 進行接洽。

建立良好的待處理項目並不保證系統良好,但是缺少良好的待處理項目幾乎最終確定您的系統不會執行客戶要求的項目。 換句話說,不隨時保持待處理項目在最新狀態,幾乎都會導致專案失敗。

產品擁有者是一個全職工作,待處理項目則是他們的職責。 認真對待這個角色。 保持產品待處理項目良好狀態,您的客戶將會感謝您。

請參閱

概念

小組使用者入門

敏捷式計劃和反覆項目

要求,並使用小組網站存取的處理程序的利害關係者意見反應

追蹤工作和管理工作流程

其他資源

從準備到執行單一伺服器安裝 [教學課程]

Team Foundation Server 的流程指引和流程範本