敏捷開發使用者故事系列之三：使用者建模

這是敏捷開發使用者故事系列的第三篇。（欄目目錄）

 

使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。

使用者建模四部曲

有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話：“真的啊……我好像不知道誰會使用我的產品……”這其實是一種常見的現象。

比如前文所說的敏捷開發管理軟體，如果想把一個使用者故事描述為“作為一個使用者，可以登入“我的空間”，以查看我我在的所有項目的進展以及自己的任務”，就會遇到這個麻煩。所謂領導，肯定想淺層次低能看到多少項目，就看到多少項目，而且最好能匯總一下顯示；作為普通程式員，則肯定不止是想知道自己在哪些項目中有任務，而是想知道自己有哪幾個任務是急需完成的（領導肯定也有著急的事情比如要審批，但肯定不如把控大局更重要）；作為專案經理，又介於其間。

分析到這一步，就已經做了使用者建模的第1步：列出儘可能多的使用者。

第2步則是：識別關鍵使用者。

按剛才的劃分，還是很難確定誰是關鍵使用者，因為“項目進展”的關鍵使用者是領導和專案經理，而“我的工作”的關鍵使用者則是普通程式員更常用。

這說明這個故事太大了，應該予以分拆，直到能識別出關鍵使用者為止。後面還會提到另外一種更科學的判斷故事顆粒度過大是否應該分拆的方法，這裡先用這個方法。

第3步則是：面向關鍵使用者，描述故事

假設我們先研究普通程式員的“我的工作”的功能，那麼問題就簡單一些了。故事可以描述為：“作為一個程式員，可以登入“我的空間”，以查看自己的開發工作單位中有哪些需要處理。”

為何要寫上“那些需要處理”這句話？因為一般沒有人會無緣無故面對自己的工作清單發獃的，他肯定來了就有它的目的。比如我們描述了這個“哪些需要處理”的價值觀，眼前就能浮現出這些任務肯定不是一視同仁地列在那裡，至於要突出“延期的任務”還是“亟待解決的任務”還是“領導關注的任務”，都是具體需求了，不難實現。

可惜經常不是這麼簡單的三種角色，而是上來一堆程式員、指令碼設計師、測試人員、黑箱測試人員等等，不可能給他們每人寫一個故事，這時候要做的是第2.5步：合并次要使用者。

在上面的例子裡邊，我們發現剛才列舉的幾種人可能在使用其他功能上有所不同，但在“我的空間”裡邊，還是基本相同的，所以把它們合并為一個“開發人員”，並把故事描述為：“作為一個開發人員，可以登入“我的空間”，以查看自己的任務中有哪些需要處理。”

總結

重新排序總結一下使用者建模四部曲：

 

第1步：列出儘可能多的使用者

第2步：識別關鍵使用者

第3步：合并次要使用者

第4步：面向關鍵使用者，描述故事

 

靈活應變

本來寫到這裡就萬事大吉了，國外書上也是這麼說的，之前有幾次課也是這麼講的，大家也聽得挺開心的。

但自己在項目中實踐了一段時間後，發現自己經常有一些“過度合并”的傾向。比如在那個敏捷開發管理系統中，角色設定是非常自由的，“添加使用者”這個操作，任何授權的使用者都可以做，而不一定是“系統管理員”，所以開始就寫成“作為被授權的使用者，可以添加使用者，以便……”。但這種“授權的使用者”越來越多了，就感覺其實逐漸墜入最開始的一股腦“作為一個使用者”的情況，又都改成“作為一個系統管理員，……”。寧可放棄實際功能，而類比使用者可能的使用情境。

 

一會說要分清使用者，一會又說太多了要合并，一會又說合并過頭了不行，到底應該怎樣？

這裡借用《金剛經》裡邊的一句話，來穩定心法：“菩薩為利益一切眾生故，不著於法。”就是菩薩的出發點是眾生的利益，因此怎樣做好他們就會怎樣做，而不會糾纏於方法（比如韋陀菩薩經常殺生）。在如何使用者建模這件事情上，出發點是“更清晰更有價值地描述故事”，而不是符合什麼建模方法，因此實際使用時，應固守心法，而靈活掌握技法。

本系列乃至本部落格其他所有文章所描述的方法，都是即是非法，又是非非法，要本著對Team Dev是否有價值，如何更有價值的心法來加以採納或調整。

 

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》