這是敏捷開發使用者故事系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）
在之一、之二、之三中，我們曾經提到了「作為乙個……可以……以便……」的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。
下面請嘗試一下描述這兩個故事：
1. 如果把「儲存按鈕」統一放在頁面上端而非下面，有些螢幕上側控制項的修改，就無需滾屏即可儲存。
2. 所有自定義字段，統一改為4000長度的nvarchar。
第乙個勉強可以寫為：「作為乙個使用者，可以方便地點選上端的儲存按鈕，以便在某些控制項修改的時候無需滾屏即可儲存」，但是這個故事顆粒度顯得過小，開發可能只需要1小時，而在客戶眼中，也不應該和「作為乙個使用者，可以對故事進行增刪改查，以便……」放在一起。
第二個故事，則找不到「使用者」的位置，因為它是我們自己要做的改進，客戶完全可以不感知。
這類故事怎麼辦呢？
有各種分類方法可以把使用者故事重新組織一下，下面這種是我自己做的分類，不是乙個成熟的方法。
所以在利用這些方法時，一定要理解其用意而不是方法，這樣當自己有別的用意時，就能靈活修改。
我自己在開發乙個不大的軟體時發現，把所有使用者故事羅列在一起顯示顯然極度混亂，於是做了乙個相當大的樹形結構來顯示。
結果發現儘管螢幕利用率很高了，還是難以一眼看到產品的主要功能，原因就是大大小小的故事都擠在一起，有些是產品的賣點應該讓客戶看到的，有的是要做的重構只和開發團隊有關，有些則介於其中，產品經理需要知道，但又不用告訴客戶。
另外同樣想給客戶看的東西，也有大小差異，比如上面例子中的1，如果在「產品版本更新公告」裡邊，可以寫上；但對新客戶而言，就不需要，他們完全可以當作產品原來就是這個樣子接受下來。
所以最後我的大致分類維度是：橫座標是向外界展現的程度，縱座標是顆粒度。顆粒度在一定程度上是「有必要呈現的程度」，就是可以以簡繁有別地顯示產品功能。
顆粒度客戶可見
產品經理可見
開發團隊可見
產品功能描述
資料級別
史詩重構 債務
操作級別
功能版本發布描述
增強級別
增強外部缺陷
內部缺陷
所謂檔案，就是一組要操作的資料，比如乙個要有使用者管理的系統，就肯定有「使用者，角色，許可權……」這些要操作的資料。其特點是檔案是系統的使用者能理解的資料，檔案都是名詞。
所謂操作，就是對某組或多組資料的操作，對一組資料的操作入手「建立角色」「刪除使用者」，對多組資料的操作如」為使用者分配角色「，其特點是操作是系統使用者的業務操作（就是」幹活「的操作），操作都是乙個動詞。
所謂增強，就是此外的用來做定語、狀語、補語的內容了。比如開始引子裡邊的案例1，就是為了使用者方便做的東西，既不是使用者要管理的資料，也不是使用者平時工作的操作。
這個維度，在」客戶可見「的層面上理解，非常方便。
比如描述產品有何功能的時候，只需要展示客戶可見的史詩和功能。
比如描述產品版本發布描述（公升級公告）時，則應該展示發生變化的史詩、功能、增強三者。（缺陷後面談）
關於這個維度，請參考：
除了給客戶看的東西，有些東西需要產品經理、開發團隊自己知道就可以了。他們所知的範圍，向前包括，意思就是說客戶能看的，產品經理都能看，產品經理能看的，開發團隊都能看。
缺陷有兩種，客戶提出的，自己發現的。前者要向客戶展示（在產品公升級公告裡邊），後者產品經理知道就可以了。
重構則是因為開發的方便性、可維護性、效能、功能的實現方法重新設計等原因引起的內部工作，無需向客戶及產品經理透露即可。
債務是開發人員「走捷徑」留下的可能出問題的地方。這種「可能出問題」，是指未來的功能、結構發生變化後可能出問題，而不是當前的做每種操作可能出問題（那就應該稱為缺陷了）。因此既不需要現在就要改正，也需要留下乙個記號日後好查。
在實際專案裡邊，我發現這種分類可能會因為專案的不同而不同。比如最近我們想增加三種內部史詩、內部功能、內部增強，因為有些功能是為了內部開發方便做的，而且也有檔案、操作、增強的區別。
我們還為不同的故事設定了類似「作為乙個……，可以……以便……」的描述模板，但還不是很成熟，日後會分享給大家。
所以，在具體管理中本人也會常常改變分類方法，因此本文的內容日後會發生變化；而大家也應該在每個專案中重新思考以往的分類是否合適。
敏捷開發使用者故事系列之六 使用者故事的產生與組織結構
這是使用者故事系列的第六篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 一條需求敢跳出來，基本上就能被化成一條使用者故事，看完一二三四五，上山打老虎都不怕，這個似乎已經不太難了。難的是，專案或產品的第一天，給一張白紙 請列出有哪些故事 那個時候其實不是大腦空空，而是有千言萬語就是說不出。前...
敏捷開發使用者故事系列之六 使用者故事的產生與組織結構
這是使用者故事系列的第六篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 一條需求敢跳出來，基本上就能被化成一條使用者故事，看完一二三四五，上山打老虎都不怕，這個似乎已經不太難了。難的是，專案或產品的第一天，給一張白紙 請列出有哪些故事 那個時候其實不是大腦空空，而是有千言萬語就是說不出。前...
敏捷開發使用者故事系列之一 何為使用者故事
這是敏捷開發使用者故事系列的第一篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織結構，等等若干問題，力求將此中問題盡量解決乾淨。按 作為乙個 可以 以便 樣式和思路寫成的使用者需求，就是...