敏捷開發的使用者故事怎麼寫?
阿新 • • 發佈:2018-12-24
以下是近期對敏捷開發中由以往“調研-文件-討論-文件-開發-文件”向新的開發方式的學習一些總結,和大家分享,有任何好的想法歡迎和我溝通。
如何編寫使用者故事?
1:使用者故事不要用技術語言來描述,要使用使用者可以理解的業務語言來描述 。不要提及任何有關語言邏輯,資料庫,軟體,欄位的客戶無關描述。
2:格式:
<編號>:作為一個<角色/職位>, 我想要<活動/操作>, 以便於達到<功能目標/商業價值>
3:如果使用者的故事點很密集和連貫要使用下面的格式加以隔斷:
使用者(角色)做…...
系統做…...
使用者做…...
系統做……
4:可以不需要格式規整的需求說明書,但是必須有一個大家都能看懂的業務流程描述。
5:使用者故事的主要目的是和使用者討論而不是寫。
使用者故事如何排序?
1:客戶明確的要求的工作
2:價值和成本(開發工作量)
3:功能相互關聯的故事挨著一起
如何使用使用者故事?
1:和使用者溝通使用者故事中的細節。
2:和客戶交談我們會怎麼樣完成故事(介面草圖,原型)
3:經常向使用者展示我們開發的小成果,演示我們已經完成的功能,讓使用者看到我們的進度。
4:聽取使用者的意見。
5:按使用者故事來分解工作任務,指派開發,開展測試。
特殊情況下的敏捷如何開展?
1:客戶不能保證持續在場
由project owner在迭代開始前與客戶討論清楚業務流程,迭代開始後由PO擔當客戶應該做的部分,但PO必須和客戶保持暢通的聯絡。
2:客戶無法表達清楚自己想要的,或者還沒想清楚
需要在PO或PM之外有一個需求分析員(或者溝通能力比較強大的開發),和使用者進行更深層次的探討,團隊可以構建一些Demo給客戶參考,直至使用者堅定自己的意願。