SCRUM 之 product backlogs - 如何寫出一個有用的使用者故事 (user stories)

在之前分享的 Rapid Application Development (RAD) 文章裡有提到要怎麼做到一個快速開發的流程. 文章中也有稍微帶到 近年來非常火紅的 SCRUM 專案管理方式. 這次的文章, 我不會介紹 SCRUM因為網路上已經有多到讓腦筋爆炸的 SCRUM 文章.就上網查一查, 看一看, 應該可以照到你想要的答案. 如果你還是有 SCRUM 方面的疑問, 我還是歡迎你發訊息來詢問.
這個嘴臉....

我想看了這照片之後, 大家當過員工的, 不管你是工程師, PM, Sales, 還是老闆, 都能夠感受到他的一種非常令人賭爛的磁場...
我遇過太多的團隊, PM 跟 RD 跟 Sales 吵成一團. 原因通常是
- 怎麼案子delay了?
- 我要的怎麼跟你做出來的差這麼多?
- 你怎麼當初沒說?
- 你@#$#$T##$%@#!!#$%$#$..........
當然還會有更多的原因讓團隊中的每一個人抓狂, 憤怒, 跟賭爛 ! 我們先不管原因是什麼, 因為都來不及了.
重要的是我們應該要知道怎麼去避免這種狀況發生.
在我協助過的50+企業團體裡, 高於80%的企業都有遇到專案delay, 產品做不出來的問題. 而最常發生的原因就是需求不清不楚造成團隊盲目的去開發, 去猜, 去自由發揮... 這真的會很糟, 也會很慘... 如果你是老闆的話 !
那產品需求要怎麼定義的清楚? 要怎麼定義的能夠理解? 這就是這篇文章的主軸.
在 SCRUM裡面, product backlogs 就是所謂的產品功能清單. 我想這點很多人都應該是很清楚楚了. 那 product backlogs 裡面會有什麼? 裡面的什麼就是 User Stories. 中文會翻譯成使用者故事. 但是此故事非佊故事. 為什麼要叫做 User Stories ? 因為這一些需求必須是以使用者的角度來去發想, 來去構想的功能. 也就是你認為使用者會怎麼用這個產品, 在什麼樣的情境下來使用這個產品? 使用中的會有什麼'樣的狀況會發生? 等等....
所以簡單來說, 一個 user story 必須要有:
- 使用這個服務/功能的人 (主角)
- 這個主角要用這個服務/功能完成什麼事(敘述)
- 為什麼這個主角需要用這個服務/功能(目標)
另外, 一個讚到爆的 user story 必須要符合 INVEST 的規範:
- Independent 獨立 - 它們可以按任何順序開發,對一個使用者情景的更改不會影響其他使用者情景。
- Negotiable 可協商 – 由團隊決定如何實施它們;沒有嚴格的固定工作流。
- Valuable 有價值的 – 每個使用者故事都為最終使用者提供了一個分離的價值單元。
- Estimable 可估量 - 很容易猜測使用者情景的開發需要多少時間。
- Small 小 - 它應該經過整個週期(設計,編碼,測試)在一個衝刺。
- Testable 可測試 – 應有明確的驗收標準,以檢查使用者情景是否得到正確實現。
例如:
作為[使用者],我想要[一個操作],以便[收益/價值]
以一個網路服務的登入頁面來說, 我可以想像到有許多個 user stories:
作為一個使用者, 我需要用我的 email address + password 來登入到網路服務的主網頁.
作為一個使用者, 如果我忘記密碼的話, 我可以用我的 email address 來重新設定我的密碼.
作為一個使用者, 如果我的登入次數超過5次失敗. 我將會收到告警email來提示我的帳號有異常狀態.
這只是給一個登入畫面而已. 而且實際上, 應該要有更多的 user stories 才對. 不過只是範例而已. 我也不想打太多的字 :)
一個完整的專案前期規劃是必須要把每一個大功能以及大框架先給定義出來. 然後 Product Owner 才好方便的去者所有的 stakeholders 把需求給挖出來. 然後在把 user stories 給定義的越細越好.
另一個需要注意的狀況是在和開發團隊一起寫故事時,切記 !!! 一定要先針對使用者的目標來思考、討論:
- 為什麼他們想要使用你的服務?
- 他們想要達到什麼目的?
- 是什麼需求,促使他們尋求這服務的幫忙?
- 他們在什麼情境使用這些服務 – 在家/工作/手機上/照顧孩子的時候?
- 他們多常使用?
在跟團隊討論的過程中, 每一位隊員也可經由寫故事的過程中來去理解為什麼產品規格要這麼定. 當然, 這也一定會避免掉這文章一開始說的團隊衝突.
如果你還是有看沒有懂的話,沒關係. 你可以隨時跟我們聯絡. 讓我們的專業來協助您.
About Konijn Design Studio:
KDS is a consulting firm that specializes in software development, business and marketing strategies, digital marketing and SEO. We have helped clients globally in a wide range of industries from business services, consulting services, IoT service, software and hi-tech, to traditional manufacturing companies.
Comments
Post a Comment