以下是近期對敏捷開發中由以往「調研-文件-討論-文件-開發-文件」向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。
如何編寫使用者故事？
1：使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 。不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。
2：格式：
《編號》
：作為乙個
《角色 職位》
, 我想要
《活動 操作》
, 以便於達到
《功能目標 商業價值》
3：如果使用者的故事點很密集和連貫要使用下面的格式加以隔斷：
使用者（角色）做…...
系統做…...
使用者做…...
系統做……
5：使用者故事的主要目的是和使用者討論而不是寫。
使用者故事如何排序？
1：客戶明確的要求的工作
2：價值和成本（開發工作量）
3：功能相互關聯的故事挨著一起
如何使用使用者故事？
1：和使用者溝通使用者故事中的細節。
2：和客戶交談我們會怎麼樣完成故事（介面草圖，原型）
3：經常向使用者展示我們開發的小成果，演示我們已經完成的功能，讓使用者看到我們的進度。
4：聽取使用者的意見。
5：按使用者故事來分解工作任務，指派開發，開展測試。
特殊情況下的敏捷如何開展？
1：客戶不能保證持續在場
由project owner在迭代開始前與客戶討論清楚業務流程，迭代開始後由po擔當客戶應該做的部分，但po必須和客戶保持暢通的聯絡。
2：客戶無法表達清楚自己想要的，或者還沒想清楚
需要在po或pm之外有乙個需求分析員（或者溝通能力比較強大的開發），和使用者進行更深層次的**，團隊可以構建一些demo給客戶參考，直至使用者堅定自己的意願。
敏捷開發 怎麼驗收敏捷故事
接著上篇 估算故事 講，故事估算完成以後就要開始考慮如何進行驗收測試了，只有驗收通過故事才算開發完成.對於乙個故事，開發人員和客戶可能會討論很多，討論的內容可以以測試用例的形式記錄下來，這樣就為我們故事測試做了鋪墊，目前敏捷開發中測試大約有如下2個步驟 1 將測試要點記錄到敏捷的故事卡的背面，任何時...
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...
敏捷開發使用者故事系列之一 何為使用者故事
這是敏捷開發使用者故事系列的第一篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織結構，等等若干問題，力求將此中問題盡量解決乾淨。按 作為乙個 可以 以便 樣式和思路寫成的使用者需求，就是...