使用排序法對User Story進行相對估算

本文是 王曉明同學在InfoQ發表的文章《關於項目估算的微博討論》中提到的排序法詳解。

一、引言

軟件項目的估算曆來是一個難題。由於軟件開發活動還無法實現土建工程那種成熟度，所以也無法像做土建工程那樣通過預算速查手冊來評估。但是，對於一項投資來說，總要說出要投資多少吧，軟件開發也要給出投資額，這就需要做估算了。

本文主要討論敏捷軟件開發中的用戶故事（User Story）估算。估算方法有很多，但大體上分爲絕對估算和相對估算。在本文中，“絕對估算”就是指以絕對時間（如小時或天）爲單位進行估算。而“相對估算”就是通過用戶故事之間的大小對比進行估算，估算後的結果沒有時間單位（它們之間的差異，不在本文討論範圍之內）。在相對估算方法中，也有很多種不同方式。而相對估算的過程中常常會出現下面的現象，尤其是對那些第一次使用相對估算的團隊：

• 當確定相對估算的基準單位“1”時，開發人員很難找到一個合適的用戶故事做基準；
• 開發人員更關注於討論單個用戶故事的點數是多少，而不是關注與其它用戶故事比較的相對大小；
• 估算所花費的總時間比較長（常常是整個下午，甚至一天）。

本文所述的估算方法僅是作者在指導工作中曾經使用過且收效不錯的經驗總結，但並不確保任何情況下都有效。

二、排序估算法

1、使用目標

制定發佈計劃，通常有一定數量的故事卡。

2、曾使用過的場景

項目規模較大（一到三個月的週期），已根據用戶故事的拆分原則（INVEST原則）得到一個用戶故事列表，該列表由各角色共同討論過，且對每個用戶故事的內容已達成共識。同時，團隊基本上可以保證，每個卡片都會有兩個或兩個以上的開發人員瞭解，並有能力開發。

3、基本依據或假設

1. 用戶故事的客觀規模不會因爲具體開發人員的差異而不同（儘管人員不同，花費的時間可能不同）。
2. 開發人員基本瞭解每個用戶故事的工作內容。
3. 由於用戶故事有一定的數量（從統計學的角度看），所以客觀規模不會偏差太多。
4. 開發人員是整個交付過程的瓶頸，所以僅由開發人員估算其開發規模，不包括用戶故事的測試規模。

4、估算過程

1. 將待估算的所有用戶故事寫在卡片上，並分發給每個參與項目的開發人員（均分即可）；
2. 先讓一個開發人員取一張卡片A，貼到牆上（隨便哪張都可以）；
3. 然後讓每個開發人員按以下規則將手中的卡片貼在牆上：
   1. 從自己手中取出一張卡片B，與牆上已有的那些卡片進行對比（開始時僅有一張卡片，即A）。
   2. 如果手中的卡片B與牆上A的大小相當，就將其貼在卡片A的下方；如圖1所示。

      圖1. A與B的大小相當

   3. 如果手中的卡片B比卡片A大，就將其貼在A的右側，如圖2所示。

      圖 2 B大於A

   4. 如果手中的卡片B比卡片A小，就將其貼在A的左側。
   5. 繼續再拿出一張卡片C，與牆上的卡片相比，如果比牆上所有卡片都小，則放在左側；如果比它們大，放在右側；與牆上某張卡片差不多大小，就放在其下方。
   6. 如果C的大小在A和B之間，就把它放在A 和B 之間，如圖3所示。

      圖3 C介於A和B之間

   以此類推。在這個過程中，可以讓所有開發人員同時貼卡片，只要彼此不干涉，保持獨立判斷即可。

4. 當全部卡片貼完以後，再請全體開發人員重新看一看，是不是每個卡片的位置都很適當。如圖4所示。

   圖 4 排好序的卡片牆

5. 如果對某個卡片的位置有異議，請拿出來討論。這也許是因爲大家對它的內容和理解不一致造成的。因此需要對其進行深入討論，直至一致認爲它應該在哪一列爲止。
6. 使用數字 1,2,3,5,8,13或 1,2,4,8,16按順序將其放在有對比關係的列上，如圖5所示。注意，這時團隊成員間還會發生對一些卡片的大小進行討論，有可能也進行位置調整。圖5中，列在“2”的每個故事卡片，其大小應該是“1”列的一倍左右。由於是估算，所以並不需要精確，只要相當即可，以此類推。

   圖 5 已設定好每列大小的卡片牆

7. 對於那些列頭上還沒有數字標識的列（如圖5中“L”列、“A”列和“K”列），請開發人員根據其規模的接近程度將其放到相鄰的列中。 如圖6所示。

   圖6 已估算好的卡片牆

最後，將每列的用戶故事數與列頭的數字相乘，得到的數字再相加以後，就得到該項目的總體規模。

三、注意事項

1. 在估算之前，應該確保所有用戶故事之間的規模差異不要過大。例如，某個用戶故事大約需要一個小時完成，而另一個用戶故事則需要兩週。此時說明，用戶故事的粒度不合理，不INVEST原則中的S原則，需進行合併或分拆。
2. 如果各列卡片的數量不符合正態分佈，而是兩頭的卡片多，中間的卡片少，也說明用戶故事粒度可能有問題，需要重新審視一下。在這種情況下，會爲後續的迭代計劃帶來困難。
3. 如果在一列中有數個相關聯且同樣大小的故事（比如支持銀聯卡、支持MasterCard、支持VISA卡），且先做完一個卡片，其它兩個工作量會減少的情況下，可以將任意一個放在當前列，其它兩個可以考慮放在比較小的一列中。但是，具體情況還是要具體分析，因爲實際情況較複雜。但在整體審視環節中，這類的分析和驗證工作不可缺少。
4. 在討論和移動卡片時，應該更多地與其它卡片進行對比，而不是直接說某個卡片屬於哪一數字列。因爲列頭的數字都是相對值，沒有其它卡片的對比，這些數字沒有意義。
5. 在討論的過程中，會捕捉到一些之前沒有發現的問題或信息，此時一定要及時記錄下來。對於不清楚的問題，應該當場由業務人員給出結論。
6. 這種方法在那些沒有嘗試過相對估算的團隊中首次使用時，最好能有一定經驗的人加以引導，對已排定的順序進行適當驗證。

四、實際應用的一個案例

這種方法比較快捷。作者已做過數次實踐，所帶團隊各不相同，但結果比較滿意。在最近一次實踐中，一共有40多張用戶故事，用時大約1.5小時，就完成了規模估算和發佈計劃的制定。下面兩張照片就是當時估算的情景。由於該團隊一直使用傳統的瀑布開發方式，首次嘗試使用敏捷開發方法，所以在這次估算中，作者並沒有要求團隊一定使用僅包含1,2,3,5的數字序列，而是使用是1,2,3,5,8,13的數字序列。但在開發後期，團隊已經有能力將較大的用戶故事（8和13）進行拆分，使其變成由1,2,3,5組成的多個用戶故事。另外，值得注意的是，如圖8所示，本次估算中，在大小爲“1”的這一列上，並沒有任何用戶故事。這也是正常現象，從側面反映了，並不是所有的估算都需要基準“1”。

圖7 開發人員正在向牆上貼用戶故事卡片，尚未決定每列的數字。

圖8 開發人員正在討論將一個沒有數值的用戶故事放在哪個數值列下

五、小結

對於剛剛接觸敏捷軟件開發方法的團隊來說，這種規模估算和計劃的方法的確不太容易接受，尤其是在那些已習慣於使用WBS分解方式做計劃的團隊中，他們會糾結於“1”到底代表多長時間，是代表資深開發人員的一天呢，還是新手的一天？因此，如前所述，這種排序法有其前提條件與假設。而且，在進行用戶故事拆分時，進行充分的討論，讓團隊成員瞭解每個用戶故事，這是該方法成功的前提，當然，也是敏捷軟件開發方法成功的前提。

值得再次強調的一點是，該方法只估算開發工作量。其前提假設是測試工作不是整個交付過程的瓶頸。

另外，用戶故事的INVEST原則包括：獨立性（Independent），可協商性（Negotiable），有價值（Valuable），可以估算性（Estimable），小的（Small and similar size）和可測試性（Testable）。作者認爲，其中的“S”有兩方面的含義。一是“small”：一個好的故事在規模上要儘量小，至少要確保在一個迭代內能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。二是“similar size”：所有用戶故事規模不應相差太大，不要爲了追求“小”而出現半個小時就能完成的用戶故事，結果使得最大和最小的用戶故事之間相差數十倍（不要笑，現實中的確見過這種情況）。

原文發表於 InfoQ中文站，原文鏈接爲：http://www.infoq.com/cn/articles/ql-using-sort-method-to-estimate-user-story