Springok's Blog

User Story入門

| Comments

User story 是什麼?

“ User Story(使用者敘述)是一段簡單的功能敘述,以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation),不如說它代表(represent)客戶的一個需求而已,因為實做細節將延後至開發時才會確定。 ”

藉由討論產生的User Story就可以進一步規劃產品各項功能、ERD、使用者行為,工程師依據這些資料來做產品開發。
而通常在Run Scrum 會用,Scrum七分鐘簡介影片

為什麼我們要用 user story?

1. 去蕪存菁,幫助聚焦

“User stories 是一種非常好用且容易上手的需求文件,它是一種極簡主義,只要求寫下最有價值不要忘記的東西,而且夠讓我們足以估計時程以及與客戶溝通。”

“User Story 強調透過一份簡單的情境規格,具體的描述出軟體在「使用者」的手上,是怎麼樣被「操作」的。能夠讓 RD 在開發時,能夠盡可能地貼近真實被需要的 Application。而不需要的功能,或者無法被實作的功能,將在一個一個循環之中,被捨棄。“

2. 幫助溝通,並鼓勵使用者/客戶參與

“ 以User stories導向的軟體開發,客戶最好要實際參與User stories的撰寫,而不只是簽名而已。作為開發者我們可以協助撰寫和提供建議,但是這應該是客戶的責任。由客戶主導的好處有 1. 由自然語言撰寫,不會充滿技術詞彙,這樣客戶也才可以根據商業價值排定優先順序。而不是由開發人員根據技術相依性來決定順序。(不過這其實也有新的問題:技術風險。開發人員會希望先進行技術風險高的 stories,這時候就需要與客戶協商討論) 2. 承上,也因為是自然語言,非技術人員也可以輕易了解內容,進行跨部門的合作 3. 由實際的使用者來描述軟體行為,再適當也不過了。”

“對客戶來說,撰寫 User story 可以幫助他們思考什麼才是真正他們想要做到的東西(商業價值 business value)”

有使用者/客戶共同參與這個過程,也能降低因溝通不良、或雞同鴨講,造成專案開發結果不符合當初期待的風險,間接節省因走錯路而需花費的成本。

3. 有助於專案開發流程規劃進行、工作拆解與節點檢討

“對開發者來說,User stories 可以給開發者很快的了解開發”目標”、要做到什麼功能,而不會見樹不見林。”

“透過把冰冷的規格轉成具體的小情境,RD 可以更知道要怎麼將架構切分成較小且可以單次就開發完畢的小元件。利用一個一個小的故事,開發出一個一個的小功能,再堆疊成一個完成的網站。同時透過 User Story 的內容對比,RD 能夠開始有辦法排出輕重緩急,甚至估算出正確時程。”

User story 的撰寫形式

User Story撰寫

一般最常見的User Story範本是:
作為一個 (某個角色) 使用者,我可以做 (某個功能) 事情,如此可以有 (某個商業價值) 的好處。
As a (role of user), I want (some feature) so that (some business value).

幾個 User Stories 的範例如下:

  • 使用者可以在網站上張貼履歷
  • 使用者可以搜尋有哪些工作
    • 使用者可以依工作地區、經歷、相關性分類工作
  • 公司可以張貼新工作
  • 使用者可以限制誰可以看到他的履歷

像依據上述的User Stories,就可以初步展開網站功能,像是張貼工作時,需要有哪些欄位,另外也需要一個使用者後台來管理履歷狀態等等,之後再更有清楚條理的拆解成可實作的步驟,進行開發。

小結

雖然自身目前的開發經驗還相當不足,User Stories的實作經驗也不多,但還是簡單整理相關解釋與做法,我個人覺得這種方式來做開發產品的依歸似乎還不錯,相較於開規格,讓人更聚焦在專案本身想要達成的目標或是解決使用者的需求,比較像是任務導向,說不定在討論User Stories的過程,反而琢磨出更簡單就能解決需求的方法也不一定,以上個人淺見囉~如果有錯,還請野生路過不世出的高手,提點小弟。

參考資料:

Comments

comments powered by Disqus