這是敏捷開發使用者故事系列的第五篇。（欄目目錄）

引子

在之一、之二、之三中，我們曾經提到了“作為一個……可以……以便……”的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。

下面請嘗試一下描述這兩個故事：

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

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

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

第二個故事，則找不到“使用者”的位置，因為它是我們自己要做的改進，客戶完全可以不感知。

這類故事怎麼辦呢？

分類

有各種分類方法可以把使用者故事重新組織一下，下面這種是我自己做的分類，不是一個成熟的方法。

所以在利用這些方法時，一定要理解其用意而不是方法，這樣當自己有別的用意時，就能靈活修改。

我自己在開發一個不大的軟體時發現，把所有使用者故事羅列在一起顯示顯然極度混亂，於是做了一個相當大的樹形結構來顯示。

結果發現儘管螢幕利用率很高了，還是難以一眼看到產品的主要功能，原因就是大大小小的故事都擠在一起，有些是產品的賣點應該讓客戶看到的，有的是要做的重構只和開發團隊有關，有些則介於其中，產品經理需要知道，但又不用告訴客戶。

另外同樣想給客戶看的東西，也有大小差異，比如上面例子中的1，如果在“產品版本更新公告”裡邊，可以寫上；但對新客戶而言，就不需要，他們完全可以當作產品原來就是這個樣子接受下來。

所以最後我的大致分類維度是：橫座標是向外界展現的程度，縱座標是顆粒度。顆粒度在一定程度上是“有必要呈現的程度”，就是可以以簡繁有別地顯示產品功能。

顆粒度維度

所謂檔案，就是一組要操作的資料，比如一個要有使用者管理的系統，就肯定有“使用者，角色，許可權……”這些要操作的資料。其特點是檔案是系統的使用者能理解的資料，檔案都是名詞。

所謂操作，就是對某組或多組資料的操作，對一組資料的操作入手“建立角色”“刪除使用者”，對多組資料的操作如”為使用者分配角色“，其特點是操作是系統使用者的業務操作（就是”幹活“的操作），操作都是一個動詞。

所謂增強，就是此外的用來做定語、狀語、補語的內容了。比如開始引子裡邊的案例1，就是為了使用者方便做的東西，既不是使用者要管理的資料，也不是使用者平時工作的操作。

這個維度，在”客戶可見“的層面上理解，非常方便。

比如描述產品有何功能的時候，只需要展示客戶可見的史詩和功能。

比如描述產品版本釋出描述（升級公告）時，則應該展示發生變化的史詩、功能、增強三者。（缺陷後面談）

展現程度維度

除了給客戶看的東西，有些東西需要產品經理、開發團隊自己知道就可以了。他們所知的範圍，向前包括，意思就是說客戶能看的，產品經理都能看，產品經理能看的，開發團隊都能看。

缺陷有兩種，客戶提出的，自己發現的。前者要向客戶展示（在產品升級公告裡邊），後者產品經理知道就可以了。

重構則是因為開發的方便性、可維護性、效能、功能的實現方法重新設計等原因引起的內部工作，無需向客戶及產品經理透露即可。

債務是開發人員“走捷徑”留下的可能出問題的地方。這種“可能出問題”，是指未來的功能、結構發生變化後可能出問題，而不是當前的做每種操作可能出問題（那就應該稱為缺陷了）。因此既不需要現在就要改正，也需要留下一個記號日後好查。

實際使用情況

在實際專案裡邊，我發現這種分類可能會因為專案的不同而不同。比如最近我們想增加三種內部史詩、內部功能、內部增強，因為有些功能是為了內部開發方便做的，而且也有檔案、操作、增強的區別。

我們還為不同的故事設定了類似“作為一個……，可以……以便……”的描述模板，但還不是很成熟，日後會分享給大家。

所以，在具體管理中本人也會常常改變分類方法，因此本文的內容日後會發生變化；而大家也應該在每個專案中重新思考以往的分類是否合適。

點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》