敏捷優先級：一種全面的，可定制的，簡單實用的方法

沒有足夠的時間或資源來做所有事情。因此，敏捷團隊必須使用優先級來決定關注哪些功能以及哪些最低級別順序功能在接近時間框sprint或發布的末尾時可能會超出範圍。對於敏捷開發項目，您應該對待處理順序進行線性排序，而不是粗略優先級排序，其中將功能集中到幾個優先級存儲區中，例如低，中，高，關鍵優先級。線性等級排序（即1,2,3,4 … .n）避免了優先級的膨脹，使每個人保持誠實，並強制決定什麼是真正重要的。當商業方面吵著所有事情都是高優先級或同等重要的時候，它會阻止“孩子在糖果店”的行為。

對於敏捷和Scrum項目，sprint backlog包含積壓項目，包括故事，缺陷和測試集。每個積壓項目的工作範圍都足夠小，以適應典型的短至兩到四周的衝刺。發布積壓中存在的史詩（大型故事）可能在發布計劃期間未被分解為故事; 他們將在sprint計劃期間被分解。

敏捷優先級的責任由團隊的所有成員共享; 但是，優先級工作由產品所有者領導。在這裡，我將使用通用術語“特徵”來表示史詩或故事。上下文將清楚地表明“特徵”是指“故事”（在sprint backlog的上下文中）還是“epic”（在程序或組合的上下文中，並且發布積壓）。請注意，史詩排名順序與積壓項排名順序是分開的。Epics和backlog項目在概念上是不同的，在開發排名順序時不應混合或聚合。

在這篇博文中，我將介紹一種簡單但相當全面的方法來對待積壓的線性排序。該方法是可擴展的，可定制的並且非常實用。

讓我從一個簡單的例子開始。表1顯示了五個特徵（F1-F5）的積壓樣本以及每個特徵的“總值”（B列）和“總努力量”（D列）。

表1：具有總價值，總努力，
總投資回報率和排名順序的樣本積壓

我將很快解釋我的意思是總價值和總體努力。功能的總價值由敏捷團隊估算; 它是一個相對數字而不是絕對數字（如美元）。同樣，功能的總工作量由敏捷團隊估算; 它也是一個相對數字，而不是絕對數字（例如理想的天數或小時數）。相對數字比絕對數字更容易估計，並且足以用於敏捷優先級排序。所有五個特徵的總價值為1,791，總的努力量為14.百分比總值（C列）用簡單的數學計算; 例如，特徵F1的％總值是（190/1791）= 10.61％。類似地，％總努力量（E列）的計算方法類似; 例如，特徵F3的％總努力量是（3/14）= 21.43％。圖1顯示了五個功能中每個功能的％總值和％總工作量，F1-F5，作為兩個餅圖。請注意，根據定義，Total Value或Total Effort的完整餅圖始終代表Total Value或Total Effort的100％。

圖1：樣本中五個特徵的％總值和％總努力分佈

表1的F列計算特徵的總投資回報率（TROI，相對數量），作為特徵的總值的百分比（C列）與特徵的百分比總量的比率（在E列中）。這是一個經濟模型，它告訴我們一個特徵基於其TROI的價值。表1的G列計算每個特徵的％TROI; 例如，對於功能F2，其％TROI為（0.87 / 5.72）= 15.18％。表1的H列顯示了基於其％TROI數據的五個特徵的等級順序。F4按等級排序＃1，F3為＃2，F2為＃3，F5為＃4，F1為＃5。

Scrum Related Reference

Leave a Reply 取消回覆