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 必須要有: 使用這個服務/功能的人 (主角) 這個主角要用這個服務/功能完成什麼事(敘述) 為什麼這個主角需要用這個服務/功能(目標)