敏捷開發目前已成爲互聯網公司的首選方案，爲應對市場的快速變化，我們公司也在大力推廣敏捷，最近在讀《用戶故事與敏捷方法》一書，我想邊讀邊做一些分享，傳播知識的同時加強記憶。
1. 基於用戶建模是一個比較好的起點。
產品團隊可以採用頭腦風暴等形式，挖掘出產品實際存在或者潛在的用戶或客戶，給他們一些角色。
多種角色出現重疊時，再將重疊部分成立一個獨立角色。
比如“運維角色”和“部署角色”都需要做一件事情：做數據修改，那麼我們就考慮一個“數據修改角色”專門做這個事情，然後“運維角色”和“部署角色”就都不包含這個職能了。
再然後呢，給每個角色找一個生動的虛擬人物來代替，讓團隊熟悉這個人，就像身邊的一個朋友一樣瞭解。
例子：“借款人角色”，代表人物叫“張窮”，30歲，小餐館經營者，這兩年生意做得不錯，想擴大店面，但是手頭吃緊，正絞盡腦汁想找一筆貸款。
用戶建模時，可以考慮一些特殊的人羣，他們有助於發現一些細緻的需求。比如老太太需要屏幕字體夠大。
2. 尋找用戶。
最理想的方式是能夠找到軟件真實的使用者，瞭解他們的需求。
條件不成熟的情況下就只有尋找用戶代理，不同的人羣都可以擔任用戶代理，但是要注意不同的用戶代理看待問題大多是從個人需要出發的，要摸清他們的一些小脾氣。
實際用戶的經理：他們對於產品細節的關注度可能不高，因爲他很可能平時不做實際操作，對於羣衆疾苦了解得不夠；他們可能會過分關注一些管理功能，比如任務調度、查看每個手下現在的任務完成情況等，而這些功能很可能不是產品核心的東西。
開發經理：他們通常缺少對軟件的實際體驗，其內心驅動因素很可能是業務壓力或者成就感，這樣的動機很容易背離產品核心業務價值。
銷售人員：他們的核心價值觀通常是儘量多的訂單，爲了不丟單，他們總會承諾“沒問題”，各種稀奇古怪的東西都想丟進產品裏面，使得產品沒有規劃、隨遇而安。
領域專家：他們通常能夠在產品設計上提供很大的幫助，但要小心他們弄出一個太“高大上”的東西，不接地氣，讓小白的用戶覺得軟件極其難用。
系統分析師：他們是很有想法的文藝青年，既懂技術又懂業務，是很好的用戶代理。但要小心他們的空想症，他們有可能花上兩天去精心設計一個業務流程，但根本沒有做過任何調研。最壞的結果是最後不得不推翻一個精心雕琢的樓閣，浪費、肉疼。。
3. 切割故事。
傳統的切割方式大多是按實現層面或者技術棧來切割，比如一個功能別切割爲前臺、後臺、數據庫幾個任務，或者按照技術棧切割爲java相關、C#相關、移動端幾個任務。
這樣的切割方式最大的問題是：單個任務不能產生業務價值、相互依賴導致無法快速交付並得到反饋。
推薦做縱向的切割，每個故事儘量是一個功能閉包，一個故事完成意味着一個功能可交付。
以京東提交訂單功能爲例，其業務流程爲：基於預先選好的商品信息，先選擇支付方式、再選擇配送方式，然後提交保存。
傳統的切割方式可能爲：
T1: 前臺交互實現（選擇支付方式、配送方式），形成可提交的訂單數據後提交給servlet
T2:後臺接收訂單數據，保存到數據庫，給成功提示。
考慮換一種切割方式：
S1：基於預先選好的商品信息，使用默認支付方式和配送方式，提交訂單並保存。
S2：支持用戶選擇支付方式並保存訂單。
S3：支持用戶選擇配送方式並保存訂單。
我們不要寫哪種大而全的故事，一個故事只爲一種客戶編寫，只滿足其一個小小的業務價值。
編寫故事時儘量避免涉及界面的描述，這會誘導開發人員按照某人腦海中印象來實現功能，這實際是把設計意圖強加到故事之中，更致命的是會隱含的擴大故事範圍。
比如這樣一個故事：
在首頁的右上方，用戶可以看到“註冊”按鈕並點擊它，之後彈出一個對話框，用戶錄入註冊信息後，點擊提交按鈕，若註冊成功就回到首頁，併發送激活郵件。
它的問題：
涉及太多的界面信息，它阻止了開發人員或者分析師跟客戶做進一步溝通的慾望，也許這樣的交互設計是蹩腳的呢？
考慮寫成這樣也許更好：
在首頁醒目位置可以進行用戶註冊，註冊成功需要發送激活郵件，註冊失敗需要失敗提醒。
下期分享：故事估算和制定計劃，謝謝圍觀~~