User Stories 二三事
Extreme Progamming - Installed
Author: Ron Jefries, Ann Anderson, Chet Hendrickson
Translator: 范綱志
Chapter 4 使用者陳述
(1) User Stories是從使用者的觀點出發, 來描述系統行為的簡短敘述
(2) User Stories只是分析的中間產物, 扮演著客戶和程式設計師溝通的媒介
(3) XP 體認到客戶一定會隨著功能逐漸完成, 而發現新的需求. 因此藉著保持簡短的陳述, 經常來發表版本, 以及讓客戶和程式設計師一起工作, 以確保過程中所學到的心得, 可以很快地回饋給專案, 以幫助最終的結果可以儘可能接近真正的需求
(4) User Stories的範例
- 每個客戶應支付的管理金都不同, 而且只會在一個月的第一個星期扣款. 本系統必須自動算出扣除額, 並且把總金額列在附加表格內
- 為每個帳戶印製結報單, 其資訊包括交易日期, 編號, 收款人, 以及金額. 範例結報器已附上, 請將報表製作得近此範例.
- 當交易導致客戶的帳戶透支時, 傳送一封電子郵件給該客戶, 告知交易資訊與帳戶餘額. 如果透支保護功能有效的話, 也把透支轉帳的資訊和轉帳的餘額, 一併用電子郵件通知
- 每個客戶都可能有一個或多個合法的薪資帳戶, 可利用某銀行的婉體線上查詢某客戶是否有薪資帳戶, 如果有的話, 再比對收款人和金額資訊. 每次扣款後, 登確認一次錢真的
有進到收款人的帳戶 (程式設計師註: 還不是很了解, 因此無法評估時程, 需要再討論, 或是再拆解此user story)
(5) 程式設計師需要寫User Stories嗎?
- 我們是希望是客戶撰寫, 而不是只要他簽名而已, 希望他能自己思考
- 如果客戶不知道要如何撰寫, 程式設計師需要和他或做, 以找出系統的真正需求, 期間的討論就會便成user stories
- 有時候你會覺得你可能知道客戶想要什麼, 請大膽和客戶討論你的想法, 而不要自己去寫user story.
- 客戶定義, 程式設計師建構, 請勿破壞這個規則
(6) 你需要寫多少User Stories呢?
- 視系統複雜度而定, 越複雜的系統越多user stories, 簡單的系統就不太需要太多的user stories
- 簡單的規則: 每個月程式設計師有1~2個user story. 如果你有很多user stories, 那也沒關係. 重要的是盡快找出最多的user stories出來, 再依你的estimation的方法來決定要做多久, 和其重要性
(7) User Stories 會太大或太小嗎?
- 一個User story應該要在1~2週內完成
- 這樣才比較好控制時程, 並且程式設計師會比較好預測可以做到哪些事
- 所以我們要做的事, 是把系統功能切成適當大小的user stories, 以及評估其難易度
- 切割user stories的方法: http://xp123.com/xplor/xp0512/index.shtml
(8) 如果沒有全部的User Stories該怎麼辦?
- 基本上, 不可能一開始找出所有的user stories
- 所以你可以之後在記下你所想到新的user stories, 在iteration planning meeting時, 決定是否要更新舊的user stories或加入新的user stories
- 不過要記得請程式設計師評估, 新的user stories所需要的成本.
(9) 有了User Stories下一步要做什麼?
開始處理accpetance test
留言列表
