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

文章目錄

• 介系嘛故戲
• 分類目的

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

 

介系嘛故戲

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

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

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

……

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

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

這類故事怎麼辦呢？

分類目的

國內的若干描述使用者故事的圖書中，《使用者故事與敏捷開發》算是內容最為豐富的，但也沒有明確提及使用者故事的分類。

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

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

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

第二個情境，是產品經理審視當第二個月做出來的那個“迭代-故事”視圖，瞭解前二、三個迭代所作的功能，以及為未來的二、三個迭代分配故事。這個時候，要瞭解的資訊要詳細地多，從客戶能感知的功能、對功能的增強、內部的重構乃至缺陷，都要有。

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

其他情境……

在各種情境的不同需求中，逐漸顯露出兩個較為清晰的維度：可見度，顆粒度。

前者決定了客戶-產品經理-Team Dev的可見類型；後者則決定了整體-版本的展示類型。