iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 13
0

https://ithelp.ithome.com.tw/upload/images/20190914/20106486c3MSaHjPwe.jpg

使用者故事(User Story)是敏捷方法中用來描述需求的一個方式,而確認一個使用者故事是否『完成』(Done)則是需要『驗收條件』(Acceptance Criteria)來輔助。

使用者故事(User Story)

在敏捷方法中常用的『使用者故事』(User Story),包含了幾個元素

  • 使用這個服務的人,稱之為『角色』(Role),使用的語句為『身為一位⋯⋯』(As a ⋯⋯)。這一部分描述的重點是『誰』(Who)。
  • 這個人要用這個服務完成什麼事,稱之為『描述』(Description)或『行動』(Action),使用的語句為『我想要⋯⋯』(I want to ⋯⋯)。這一部分描述的重點是『做什麼事』(What)。
  • 為什麼這個使用者需要這個服務,稱之為『目標』(Goal)或『商業價值』(Business Value),使用的語句為『因此我可以得到⋯⋯』(So that ⋯⋯)。這一部分描述的重點是『為什麼做』(Why)。

https://ithelp.ithome.com.tw/upload/images/20190914/20106486DEawAX9rIa.jpg

好故事的條件

一個好的故事具備了幾個條件,分別是 V.I.N.C.E。

  • 有價值(Valuable):故事最重要的一個部分是故事描述的『商業價值』,可以很清楚地讓團隊知道正在進行的工作是對『用戶』是有價值的,了解為何而戰,才能更有動力。
  • 可獨立(Independable):所謂的『可獨立』是指使用者故事和使用者故事間應該儘量避免相互依賴。傳統需求描述方式由於描述的事件較大,彼此間的依賴過多,導致在開發階段時互相牽制,造成開發時程的延宕。獨立性較高的使用者故事比較容易能夠獨立交付。
  • 可協調(Negotiable):使用者故事的「可協調」是指團隊對這個使用者故事的理解是透過不斷的對話、協商後慢慢達成一致的共識,進而開始開發階段,而不是產品負責人說了算的。曾經在奧美廣告的會議室看到了『對話、對話、不斷對話;優化、優化、不斷優化』,這句話的深層涵義是『持續的對話才能讓產品持續的優化』。
  • 可驗證(Checkable):所有的需求都是需要可以被驗證的,因此一個使用者故事,不只是故事的句子,還需要有相關的驗收條件可以驗證核對。
  • 可估計(Estimable):如果一個需求是不可被估計的,一則表示這個使用者故事太大,一則表示這個使用者故事太過模糊。太大的故事需要被切小,簡單來說就是分階段完成,太模糊的故事需要時間釐清需求。

【文思不藏私】敏捷 30 天養成計劃~搶先看

https://ithelp.ithome.com.tw/upload/images/20190914/20106486sw3hSNQA9O.jpg


上一篇
敏捷小班~Scrum 完成的定義
下一篇
敏捷小班~驗收條件
系列文
敏捷 30 天養成計劃30

尚未有邦友留言

立即登入留言