這是敏捷開發使用者故事系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）
使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。
有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話：「真的啊……我好像不知道誰會使用我的產品……」這其實是一種常見的現象。
比如前文所說的敏捷開發管理軟體，如果想把乙個使用者故事描述為「作為乙個使用者，可以登入「我的空間」，以檢視我我在的所有專案的進展以及自己的任務」，就會遇到這個麻煩。所謂領導，肯定想淺層次低能看到多少專案，就看到多少專案，而且最好能彙總一下顯示；作為普通程式設計師，則肯定不止是想知道自己在哪些專案中有任務，而是想知道自己有哪幾個任務是急需完成的（領導肯定也有著急的事情比如要審批，但肯定不如把控大局更重要）；作為專案經理，又介於其間。
分析到這一步，就已經做了使用者建模的第1步：列出盡可能多的使用者。
第2步則是：識別關鍵使用者。
按剛才的劃分，還是很難確定誰是關鍵使用者，因為「專案進展」的關鍵使用者是領導和專案經理，而「我的任務」的關鍵使用者則是普通程式設計師更常用。
這說明這個故事太大了，應該予以分拆，直到能識別出關鍵使用者為止。後面還會提到另外一種更科學的判斷故事顆粒度過大是否應該分拆的方法，這裡先用這個方法。
第3步則是：面向關鍵使用者，描述故事
假設我們先研究普通程式設計師的「我的任務」的功能，那麼問題就簡單一些了。故事可以描述為：「作為乙個程式設計師，可以登入「我的空間」，以檢視自己的開發任務中有哪些需要處理。」
為何要寫上「那些需要處理」這句話？因為一般沒有人會無緣無故面對自己的任務列表發呆的，他肯定來了就有它的目的。比如我們描述了這個「哪些需要處理」的價值觀，眼前就能浮現出這些任務肯定不是一視同仁地列在那裡，至於要突出「延期的任務」還是「亟待解決的任務」還是「領導關注的任務」，都是具體需求了，不難實現。
可惜經常不是這麼簡單的三種角色，而是上來一堆程式設計師、指令碼設計師、測試人員、黑盒測試人員等等，不可能給他們每人寫乙個故事，這時候要做的是第2.5步：合併次要使用者。
在上面的例子裡邊，我們發現剛才列舉的幾種人可能在使用其他功能上有所不同，但在「我的空間」裡邊，還是基本相同的，所以把它們合併為乙個「開發人員」，並把故事描述為：「作為乙個開發人員，可以登入「我的空間」，以檢視自己的任務中有哪些需要處理。」
重新排序總結一下使用者建模四部曲：
第1步：列出盡可能多的使用者
第2步：識別關鍵使用者
第3步：合併次要使用者
第4步：面向關鍵使用者，描述故事
本來寫到這裡就萬事大吉了，國外書上也是這麼說的，之前有幾次課也是這麼講的，大家也聽得挺開心的。
但自己在專案中實踐了一段時間後，發現自己經常有一些「過度合併」的傾向。比如在那個敏捷開發管理系統中，角色設定是非常自由的，「新增使用者」這個操作，任何授權的使用者都可以做，而不一定是「系統管理員」，所以開始就寫成「作為被授權的使用者，可以新增使用者，以便……」。但這種「授權的使用者」越來越多了，就感覺其實逐漸墜入最開始的一股腦「作為乙個使用者」的情況，又都改成「作為乙個系統管理員，……」。寧可放棄實際功能，而模擬使用者可能的使用場景。
一會說要分清使用者，一會又說太多了要合併，一會又說合併過頭了不行，到底應該怎樣？
這裡借用《金剛經》裡邊的一句話，來穩定心法：「菩薩為利益一切眾生故，不著於法。」就是菩薩的出發點是眾生的利益，因此怎樣做好他們就會怎樣做，而不會糾纏於方法（比如韋陀菩薩經常殺生）。在如何使用者建模這件事情上，出發點是「更清晰更有價值地描述故事」，而不是符合什麼建模方法，因此實際使用時，應固守心法，而靈活掌握技法。
本系列乃至本部落格其他所有文章所描述的方法，都是即是非法，又是非非法，要本著對開發團隊是否有價值，如何更有價值的心法來加以採納或調整。
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...
敏捷開發使用者故事系列之一 何為使用者故事
這是敏捷開發使用者故事系列的第一篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織結構，等等若干問題，力求將此中問題盡量解決乾淨。按 作為乙個 可以 以便 樣式和思路寫成的使用者需求，就是...