估計

發行項
02/28/2013

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

2012 年 1 月

Mitch Lacey 討論軟體專案評估的困難，並提供可在評估專案時使用兩個敏捷式軟體評估技術的提示與訣竅。

套用至

Application Lifecycle Management; Team Foundation Server

內容

簡介
估計為何困難
估計技術
做為測量單位的劇本點。
規劃撲克牌 (Planning Poker)
圍牆估計
估計
排定優先順序
結論

評估有創意的和無法預期的工作根本就相當困難。選擇這項作業的執行方式可能同樣煞費心思。 Fred Brooks 對這點說明得最好：「如果一項估計不是透過數量方法推論得到，僅憑一點資料來支持和經理人的預感做為證明，要為它做出鏗鏘有力、似乎合理又賭上飯碗的辯護，實在很困難」。

但我們必須儘早提前提出軟體專案評估，而且，即使我們一再提醒主管們這些只是粗略預估，但我們的初始預估往往會變成承諾。

在這篇文章中，我將告訴您為什麼預先評估專案富有挑戰性、敏捷式軟體評估技術如何協助您，以及如何使用規劃撲克牌 (Planning Poker) 和本文點評估您的產品待處理項目。

估計為何困難

在大部分的專案中，我們要求在最前面預先評估。為了解為何會出現這類問題，我們必須檢查不確定性圓錐圖，這是 Barry Boehm 於 1981 年介紹、Steve McConnell 在 1997 年在其著作《Software Project Survival Guide》中再次介紹的概念。

不確定因素圓錐圖

圓錐形示範在所有專案的一開始所存在的大部分不確定性 (介於 4x 至 0.25x 的差異 )。這個變化表示評估需要一年的專案實際上可能需要花上 3 到 48 個月的時間。所有專案的起點是在至少對專案有確定性的時候，也是該時候要求提供非常精確的評估。

在敏捷式作法上，我們會嘗試以盡可能短的週期，將不確定性轉化為確定性。這可以透過盡早學習系統及系統設計方式來達成。若要這麼做，我們建立一個通過系統的單一通道、一個完整有用的劇本。我們使用這個排除早期的設計和需求假設，以便快速確認並更有自信。

估計技術

有許多不同的有效評估技巧，包括計算、專業判斷 (個人和群組)、分解、類比、Proxy 估計、規劃舖克牌，以及圍牆估計。我們也可以使用 Cocomo II 之類的工具。所有這些技術的需求是，我們要選擇估算單位：時、天、週、月、理想的日子 (Ideal Days)、T 恤大小、點或所有這些單位。如果我們不了解這個單位，估計就沒有任何意義。綜觀上述各項，也難怪我們進行評估會這麼困難。

雖然 Agile 小組傾向於採用特定類別的估計單位及技術來評估產品待處理項目 (本文點和規劃撲克牌 (Planning Poker))，您的小組還是可以自由使用任何最符合需要的方法。依我的經驗，使用規劃撲克牌 (Planning Poker) 或圍牆估計，以本文點表示估計會產生最佳結果。 will learn about story points as a unit of measure and two estimation techniques that I prefer: planning poker and wall estimation.在以下段落中，您將了解做為測量單位的本文點，以及我慣用的兩個估計技術：規劃撲克牌 (Planning Poker) 和圍牆估計。

做為測量單位的劇本點。

Mike Cohn 將本文點總結說明得最好：「本文點是一種測量單位，用於表示使用者劇本、功能或其他工作項目的整體大小」。「本文點以大小或複雜度的方式表示，告訴您一個劇本相對於其他劇本來說有多大。 Mike 在協助小組了解相對大小的概念時，經常會提到「狗點」(Dog Point)。 2 個點的 (小型) 狗會是一隻吉娃娃。 13 個點的 (大型) 狗會是一隻大丹狗。只要考慮到這兩個方針，很容易就能根據吉娃娃或大丹狗調整其他種類的狗。畢格爾獵犬 (約為吉娃娃的兩倍大) 可能是 5。拉布拉多獵犬 (體型較畢格爾獵犬大，但小於大丹狗) 可能是 8。

當您初次學習使用本文點時，您的小組需要建立您自己的固定比較點。若要這樣做，請從產品待處理項目中選擇一個全體同意的小型劇本 (無論就大小或複雜度而言)，以及一個全體同意的大型劇本。我想讓我的小劇本變成兩個點的劇本，原因是，如果我需要選擇較小的項目 (假設我發現玩具吉娃娃)，我就能這麼做。如果我將我的最小已知劇本限制為一個點的劇本，但是我需要移至更小的，就會遇到困難。那麼其他劇本可以調整成與這些相關。

選擇代表這些大小的數字時，我發現 Fibonacci 序列是最好的方式。 Fibonacci 是前兩個數字的總和。 1 和 2，下一個是 3。 3 和 2，接下來就是 5。 5 和 3，接下來就是 8，依此類推。我比較喜歡用斐波納契數列，例如 T 恤尺寸或等比級數 (4/8/16/32/64/128/256 等) 就不是我要用的，因為我們人類對十進位比較在行。我們超出該範圍時，即使是 xs, s, m, l, xl，也會造成混淆。 Fibonacci 數字很簡單，容易了解，並且提供足夠的正確性讓達到目標 (提供相對估計)。您可以選擇一組不同的號碼，但請記住，重要的作業必須保持一致。

劇本點是相對值，不是固定值。時數和點數之間沒有絕對的相互關係。例如，我們沒有任何把握說得準兩個點之間的劇本等於 12.2 小時，因為要完成兩點範圍內的劇本所需要的實際時數會大幅變動。同樣地，您也無法比較一個小組與另外一個小組的劇本點的任何可能性。劇本點會因估計它們的小組，可能會包含由小組才能了解程度的複雜度，而且不是絕對的。

規劃撲克牌 (Planning Poker)

在選擇度量單位並且建立縮放之後，就應該進行評估。大部分的敏捷小組會使用規劃撲克牌 (Planning Poker) 來估計劇本的相對大小。這種現象常見於敏捷小組，因為這是包含數項主觀評估技術 (包括類比和專家評判) 的客觀測量。規劃撲克牌 (Planning Poker) 的關鍵是參與。小組的每一個成員都要參與 (就是所有的人)。功能測試人員會估計開發工作 (反之亦然)。功能專案管理人員也可以估計開發工作。這樣做可確保您的目標數字盡可能包含最多的主觀估計。

從規劃撲克牌 (Planning Poker Cards) 的準備開始。規劃撲克 (Planning Poker) 卡片可以輕鬆地使用索引卡片來製作，或者購買 (Visual Studio 甚至可以產生這付牌)。每張卡片都具有您所選本文點 (1、2、5、8、13 等) 範圍的其中一個數字。每個參與者手上都會有發給他們的牌，這手牌包含完整範圍的可用本文點。

計劃撲克牌範例

發牌之後，遊戲隨即開始。

Scrum 主管對小組報告產品待處理項目中最重要的項目。
小組討論劇本。
產品擁有者釐清問題、假設、未知以及接受度準則。
每個小組成員都會私下決定這個劇本相對於參考劇本、一系列參考劇本或產品待處理項目中所有劇本的大小。
數到三時，每個人都要同時出示其選擇的卡片。

如果每個人都出同樣的牌，小組就可以記錄項估計並繼續下個劇本。

如果變異很大 (例如，顯示的數字範圍從一到八)，小組就要花費時間討論劇本。若要集中討論，請最低投標者和最高投標者說明其估計的理由。該對談很有價值，這裡不是指數字，因為那是任何學習及假設都沒有提及的。在簡短的 30 秒至一分鐘討論之後，小組重複步驟 4 和步驟 5。這個程序會繼續直到小組同意劇本評估為止。

這看起來相當易懂，不過了解其中某些基本規則十分重要。首先，如果小組無法全員達成某種協議，您不應該繼續執行。例如，假設小組中有一個人挑八，但其他人都選五。如果會議召集人說「夠接近了」。我們決定這個專案使用五個；繼續討論「有八的人會怎麼做？」根據我的經驗，那個人會配合小組所做的任何決定，但要完全參與時就會止步。計劃儘管可以那樣加快進行，但您會遺失重要的事。不僅這個人未能了解工作，小組也失去一個成員提供的意見和看法。此外，不同意也沒有關係。針對某人為何選擇比其他人大的數字進行討論，可以增進了解。如果您發現自己陷入僵局，請要求召集人嘗試「拳頭五指表決」(Fist to Five) 技巧。它發揮了神奇功效能，讓會議順利進行，而與會的人都沒有格格不入的感覺。

由於規劃撲克牌以點數表示估計，因此非常適合用來評估產品待處理項目。不過，Sprint 待處理項目應以小時為預估單位。一般而言，規劃撲克牌 (Planning Poker) 能夠且已經成功地用來評估 Sprint 待處理項目，雖然卡上的數字會變成時數，而不是點數。因此，規則很簡單 –

產品待處理項目估計是以點為單位。
Sprint 待處理項目評估為小時。

您可以在任何專案的初期及整個生命週期中使用規劃撲克牌來提供新資訊、變更優先順序，以及讓介面更清楚。

圍牆估計

規劃撲克牌 (Planning Poker) 是估計使用者劇本的絕佳工具，但是若要使用這付牌一次一個估計數百個劇本，花費的時間就會超過正常限度。如果您有一個未經處理的待處理項目，填滿數百個尚未評估或排定優先權的劇本，您將需要更快速的方式來進行估計。

圍牆估計的設計可讓小組不需廣泛討論 2 對 3 和 5 對 8，反而可以至少在初期的時候純粹依照相關性進行分組。這也能讓專案關係人為大型劇本群組指定一般優先權排定，不會因為要判斷某個劇本是否比另一個稍微重要而拖延。

若要進行圍牆預估，您必須先將您的使用者劇本列印在卡片上。接著將小組和專案關係人聚集在有一大面空牆 (大約 14 英尺長、8-10 英尺高) 的房間裡；了解兩件關於這面牆的資訊：

高度決定優先權。在頂端的劇本有較高優先，在下方的劇本有較低優先。劇本的優先權可以根據 ROI、商務價值或某個「莫名其妙就是很重要」的簡單項目來排定。
寬度是預留大小。在左邊的劇本會較小，在右邊的劇本會比較大。 (舉例而言，如果您使用日文且反轉這個順序會更有邏輯，那麼就可以這樣做，由右至左移動)。最重要的是設想定一條平行線，一條垂直線。小組成員和專案關係人應問他們自己，相對於其他劇本，它是否合用?

小組會使用圍牆調整所有劇本的大小。專案關係人會使用圍牆排定劇本優先順序。如同規劃撲克牌 (Planning Poker) 的情形一樣，我們使用相對大小，而不使用兩個參考劇本進行比較，因此圍牆成為常數。小型劇本? 移動到左邊。大型劇本？移動到右邊。重要劇本嗎？將它放在高處。我們暫時不使用仍然可行的劇本？將它放在低處。

雖然評估劇本時專案關係人不需要在場，但是排定劇本優先權時，小組必須在這個房間內。 Scrum 主管和產品擁有者必須參與活動的估計與排定優先順序。

如果您已經有估計的待處理項目，現在就可以只進行這個練習的優先順序排定部分。如果您的產品擁有者和專案關係人已經提供排定優先權的待處理項目，您可以只是進行這個練習中的估計部分。 (您的產品擁有者可能會想要在完成評估後重新審視優先順序。總之，成本對優先權有很大的影響)。讓我們從小組的角色開始，仔細查看這項運作方式。

估計

為小組提供未經處理的產品待處理項目，並開始估計。指示圍牆最左邊的小組應持有最小的可能劇本，而最右邊的小組應包含最大的可能劇本，不考慮數目。小組根據這兩極將劇本放在圍牆某處。這麼做的好處就是沒有兩點或三個劇本的先入為主的概念，事實上是根據圍牆有多大，即實際的大圍牆為何派上用場。

如果小組這麼做有困難，您可以提供範圍從 1 到 8 點的其他參考劇本，讓這面牆更具結構。建立更大的參考劇本時請勿擔心，任何變大的項目通常都會在優先順序提升時進行分割。在小組識別出五個劇本之後，請將這些劇本放在牆壁上與其大小相關聯的位置中 (同樣由左至右排列)。在圍牆的右邊保留一些空間給大於八點的劇本。將這些劇本放在牆上，並指示小組將其餘的劇本相對於這些參考劇本放在牆上，記住較小的劇本移至左邊，而較大的劇本移至右邊。

將劇本貼在牆上，讓小組找出劇本大小之間的邏輯中斷。在劇本群組中選取一條垂直線以描繪這些中斷。很快地您就會有一道很像在這裡的那道牆。第一個群組中的所有項目可能是 2，第二個中所有項目可能是 3，第三個中所有項目可能是 5，而最以一個群組中所有項目可能是 8。數字不重要，只要實際上所有劇本現在都視為彼此相關就好。

壁式評估範例 - 關聯性排序

現在您的劇本已評估，您需要讓專案關係人參與處理，以便您指定劇本優先順序。

排定優先順序

雖然您的客戶和專案關係人會想要知道劇本可在決定其優先權提供多大的幫助，他們更是著重於尋找與其相關的劇本，並確定這些劇本可以完成。預期您的專案關係人不同意優先權，您的產品擁有者將會使用這項資訊協助決定最終的優先權。

向專案關係人說明圍牆。告訴他們牆卡會反映想要在最終產品中看到所有的功能。說明小組已評估每個劇本，以及他們可以根據劇本位在牆上的哪一欄內判斷劇本的點數估計。提醒所有的人，小組成員並不是排定優先順序的主動參與者。它們可以觀察、記下行為、互動，以及某些劇本的優先順序上升或下降的原因。必要時也可以回答專案關係人提出的任何問題。如果因為需要特定專案關係人的答覆，小組沒有把握調整一個或多個劇本的大小，當時間允許時，小組也可以詢問關於那些劇本的問題。

要求專案關係人上下移動由膠帶粘住的欄位內的這些劇本，協助決定所有這些劇本的相對優先權。提醒他們，牆上的劇本越高，其商務優先權也越高。設定下列規則：

如果您將劇本放在最上方，請準備充分的理由說明這個位置。
您可以彼此互問某個劇本比另一個劇本重要的原因何在。別客氣，儘管彼此質問「誰將這個往下移 (或往上移)？」，或是大聲說「我認為這一個需要移動」。誰要提出反對？」這樣可以讓相關人員產生對話，不需要鼓勵。
如果您在牆上將劇本移至比別人移動得更低的地方，請標示以有色點來提醒我們。

群組優先權的最大優點是所有專案關係人可以深入了解各種劇本優先順序。如果討論太久而沒有決議，產品擁有者應收集卡片、找出那兩個無法同意的專案關係人，並註記要在日後私下與他們會談。

該練習會需要 2-6 小時，視劇本數目與本數目和專案關係人數目而定。完成時，圍牆會如下圖所示。

壁式評估範例 - 優先性排序