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

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

嘗試分類

有各種分類方法可以把使用者故事重新組織一下，下面這種是我自己做的分類，不是一個成熟的方法。在利用這些方法時，一定要了解其用意而不是方法，這樣當自己有别的用意時，就能靈活修改。

顆粒度	客戶可見	産品經理可見	開發團隊可見
産品功能描述	資料級别	史詩	重構 債務
操作級别	功能
版本釋出描述	增強級别	增強	外部缺陷	内部缺陷

顆粒度次元

所謂資料，就是一組使用者要操作的業務資料，比如一個要有使用者管理的系統，就肯定有“使用者，角色，權限……”這些要操作的資料。其特點是檔案是系統的使用者能了解的“業務”資料，而非技術資料（比如資料庫表）。資料都是名詞。

所謂操作，就是對某組或多組資料的業務操作，對一組資料的操作入手“建立角色”“删除使用者”，對多組資料的操作如“為使用者配置設定角色”，其特點是操作是系統使用者的業務操作（就是“平時幹活”的操作；像之前提到的“把按鈕挪到螢幕上方”就不是使用者的業務操作）。操作都是一個動詞。

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

這個次元，在“客戶可見”的層面上了解，非常友善。

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

比如描述産品版本釋出描述（更新公告）時，則應該展示發生變化的史詩、功能、增強三者。

展現程度次元

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

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

重構則是因為開發的友善性、可維護性、性能、功能的實作方法重新設計等原因引起的内部工作，無需向客戶及産品經理透露（雖然産品經理往往知道）。

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

實際使用情況

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

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

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