以下是近期對敏捷開發中由以往“調研-文件-討論-文件-開發-文件”向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。

如何編寫使用者故事？

1：使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 。不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。

2：格式：

<編號>：作為一個<角色/職位>, 我想要<活動/操作>, 以便於達到<功能目標/商業價值>

3：如果使用者的故事點很密集和連貫要使用下面的格式加以隔斷：

使用者（角色）做…...

系統做…...

使用者做…...

系統做……

4：可以不需要格式規整的需求說明書，但是必須有一個大家都能看懂的業務流程描述。

5：使用者故事的主要目的是和使用者討論而不是寫。

使用者故事如何排序？

1：客戶明確的要求的工作

2：價值和成本（開發工作量）

3：功能相互關聯的故事挨著一起

如何使用使用者故事？

1：和使用者溝通使用者故事中的細節。

2：和客戶交談我們會怎麼樣完成故事（介面草圖，原型）

3：經常向使用者展示我們開發的小成果，演示我們已經完成的功能，讓使用者看到我們的進度。

4：聽取使用者的意見。

5：按使用者故事來分解工作任務，指派開發，開展測試。

特殊情況下的敏捷如何開展？

1：客戶不能保證持續在場

由project owner在迭代開始前與客戶討論清楚業務流程，迭代開始後由PO擔當客戶應該做的部分，但PO必須和客戶保持暢通的聯絡。

2：客戶無法表達清楚自己想要的，或者還沒想清楚

需要在PO或PM之外有一個需求分析員（或者溝通能力比較強大的開發），和使用者進行更深層次的探討，團隊可以構建一些Demo給客戶參考，直至使用者堅定自己的意願。