敏捷開發使用者故事系列之五使用者故事的分類

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

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

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

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

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

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

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

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

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

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

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

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