這是使用者故事系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）
一條需求敢跳出來，基本上就能被化成一條使用者故事，看完一二三四五，上山打老虎都不怕，這個似乎已經不太難了。
難的是，專案或產品的第一天，給一張白紙：「請列出有哪些故事」。那個時候其實不是大腦空空，而是有千言萬語就是說不出。
前年做另外一件事情的時候偶然得到一種方法，去年到今年用在乙個敏捷專案上，果然很舒服地列出了大量故事，後來的開發過程證實它們都滿足獨立交付、可測試、耦合低等特點，屬於好故事之列。
這件事情其實在之前的部落格中已經多次提到了，就是軟體專案的造價管理。注意這裡提到的是專案，而非產品研發。專案就是那種一手交錢一手交貨的甲乙方專案。
之前曾經提到過：無論有多少種方法對優先順序進行排序，作為產品而言，都永遠應該把最體現差異化價值觀的功能置於萬事之前。
這裡要說的則是：無論有多少管理方法，作為專案而言，都永遠應該把造價估算置於萬事之前。
這個前不是一般的前，最好能用幾張a4紙的篇幅就搞定，因為一般老闆剛去簽訂合同的時候，手裡沒有需求，沒有設計，沒有故事，就這麼幾張紙。當然另乙個尷尬的事情則是：即使有很厚的需求文件了，也仍然沒有方法知道要多久才能完成專案，真的很愁人。
其實這兩件事說的是一件事：如何在早期列出具有某種表徵意義的需求列表。
在之前的部落格詳細描述過了，這裡只從產生和組織使用者故事的角度談談，詳情請看文末的鏈結。
在我們的開發工作中一共有兩類東西要開發，一種是資料，一種是操作。
所謂資料，就是比如要編寫乙個crm，其中有「使用者、角色、許可權」這三種東西，就是要管理的資料，這裡權且記下使用者有「3個史詩故事」要管理。
所謂操作，就是對使用者，應該有增、刪、改、查、加入角色……這些稱之為操作，這裡權且記下對使用者，使用者會有「5個使用者故事」。
史詩都是名詞，都是要被管理的核心資訊，而且是使用者可以理解的資訊；
故事都是動詞，都是使用者平日裡使用軟體產品所進行的業務操作；
最後乙個小貼士是每個史詩故事平均有7個左右的故事，少於4個要懷疑是不是史詩，多於10個要懷疑是不是應該拆分新的史詩了。
最後這條是nesma 20年來的經驗資料，很值得參考但莫較真。比如上面例子分為使用者/角色/許可權3個史詩對19個故事（平均6.3個），你可以試試再拆拆或合合，效果肯定不如這三個乾淨。只能說他們20年真沒白幹。
這個方法聽起來很水很模糊，但因為開過幾次造價估算培訓課，在我經手的3次培訓中，通過短短1天培訓後，4～5個小組的（最大-最小）/平均 誤差只有正負12%，而誤差的很大**，是乙個模擬問答環節總是比較嘈雜，很多團隊沒有注意聽答案！@￥#…%！核對需求後，誤差可迅速降低到大約一半。課堂練習只有一張a4紙，裡邊很模糊地隱含了多達90多個使用者故事，練習時間只有1小時，能達到如此的一致性已經很滿意了。
最早我們在史詩之上，就是無意義的層級式目錄結構了，但就像太陽系外有銀河系，銀河系外有超星系，超星系外有超星系團一樣，事情還沒有完。
本來以為在史詩之上沒有有實際邏輯意義的結構了，但發現「使用者角色許可權」這三個故事的距離，遠遠近於其他故事，應該還有一種具有邏輯意義的東西來描述；其他一些史詩故事也發現了這種內聚性，但尚無合理的劃分方法將其定義下來。
筆者暫時創造了「故事群」這個概念來描述他們，但沒有找到合理的定義，讓不同的人可以一致性地劃分故事群。
之所以借用功能點分析的概念來產生和組織使用者故事，是因為關於使用者故事，一直沒有非常標準的顆粒度和組織方法；而對於資料、操作，則在接近40年前就開始嘗試標準化定義，當前有5個國際標準之多，中國的國家標準也馬上出來了。在接受這些標準培訓後，不同個體對資料和操作的計數差異，只有不到10%；尚沒有任何使用者故事的定義能達到如此一致性。
敏捷世界一向有封閉的特性，比如cmmi在嘗試擁抱敏捷，但從來沒聽過敏捷擁抱cmmi的。
不否認創造和使用敏捷開發的一線員工在定義需求、制定計畫、每日跟蹤中的經驗和權威性，但在大尺度上掌握使用者故事的組織結構，以及在甚早期判斷專案範圍的方面，則正是這一人群的弱項。
敏捷方法需要借鑑已有的外界方法。
為什麼不用uml方法？因為本人很不熟悉uml。uml比較適合在大尺度上組織使用者故事，但很難在甚早期開展（一張a4，隱含90個故事，1小時估完）。
當然這不會抹殺uml在分析使用者故事中的作用，日後或許會請另外一位老師寫篇文章《使用者故事與uml》，我**過來作為其中一篇，以求完整。
早期功能點估算1：
早期功能點估算2：
敏捷開發使用者故事系列之六 使用者故事的產生與組織結構
這是使用者故事系列的第六篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 一條需求敢跳出來，基本上就能被化成一條使用者故事，看完一二三四五，上山打老虎都不怕，這個似乎已經不太難了。難的是，專案或產品的第一天，給一張白紙 請列出有哪些故事 那個時候其實不是大腦空空，而是有千言萬語就是說不出。前...
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...
敏捷開發使用者故事系列之一 何為使用者故事
這是敏捷開發使用者故事系列的第一篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織結構，等等若干問題，力求將此中問題盡量解決乾淨。按 作為乙個 可以 以便 樣式和思路寫成的使用者需求，就是...