《火星人開發紀實：靈活開發一千零一夜》第四個月：使用者故事的分類（上）

（序言，之一，之二，之三，之四，之五）

介系嘛故戲

         使用者故事嘛誰還不知道，如果大家仔細看我們第一個月的截圖，就能看到所有故事的描述都被預先置為模闆“作為……，可以……，以便……”，就等着填入實際内容了，可是沒想到，怪物來了。請看介幾個都系嘛故戲：

1. 如果把“儲存按鈕”統一放在頁面上端而非下面，有些螢幕上側控件的修改，就無需滾屏即可儲存。

2. 所有XX字段，統一改為4000長度的nvarchar。

……

第一個勉強可以寫為：“作為一個使用者，可以友善地點選上端的儲存按鈕，以便在某些控件修改的時候無需滾屏即可儲存”，但是這個故事顆粒度顯得過小，開發可能隻需要1小時，而在客戶眼中，也不應該和“作為一個使用者，可以對故事進行編輯，以便……”放在一起，太晃眼。

第二個故事，則找不到“使用者”的位置，因為它是我們自己要做的改進，使用者完全可以不感覺，産品經理不知道甚至都沒事。

這類故事怎麼辦呢？

分類目的

國内的若幹描述使用者故事的圖書中，《使用者故事與靈活開發》算是内容最為豐富的，但也沒有明确提及使用者故事的分類。

怎樣分類呢？有些一望而知的詞彙似乎可以選擇：史詩故事，使用者故事，重構，增強，缺陷……但是它們之間到底是什麼關系，這樣分類的目的何在？如果不能解決這個根本問題，分類方法就是錯誤的。

逐漸地，我們開始注意到我們有幾種不同的場景，希望看到不同的故事。

第一個場景，是産品經理審視第三個月做出來的那個故事樹，以決定在哪裡增加新的故事。在這個場景中，産品經理希望靜态地檢視所有已經開發過的“功能”，由于故事數量龐大，隻能展示那些使用者“粗略”地評價産品的時候，就能感覺到對自己有價值的故事。而增強、重構、缺陷等，都不太需要顯示。

第二個場景，是産品經理審視當第二個月做出來的那個“疊代-故事”視圖，了解前二、三個疊代所作的功能，以及為未來的二、三個疊代配置設定故事。這個時候，要了解的資訊要詳細地多，從客戶能感覺的功能、對功能的增強、内部的重構乃至缺陷，都要有。

第三個場景，還沒有遇到但是卻能預見，就是在産品上市後，每個版本的“發版”報告。裡邊會有新産生的功能，已有功能的增強，由使用者報告且已修複的缺陷等；但重構、内部缺陷等就不需要了。