在寫程式之前,請先搞清楚這程式到底是要解決什麼問題(user story)
用User story取代規格書,做一個符合期望價值的產品
工程師通常與程式溝通久了,總是講出來一些音調上聽起來是人類的語言的外星語。
但是工程師與工程師總是能互相聽得懂,好像需要裝個電線調整頻率似的。
User story 就是一個可以扮演調整頻率的角色。
它可以拆解專案/目標,化為可執行的最小單位
以此對應程式端的功能,讓所有事情自動跟著規格走。
User story 不僅僅是給一般非工程職的人使用的工具。
對於工程師本身也是非常有用的。
畢竟也不是很少聽到程式高強的團隊意氣風發的出來創業,
最後做出一個技術高深但不知道市場在哪的產品。
如果再開始做產品之前先有效的分析市場(顧客)與真正重要的功能,
雖然不能保證成功,但機率還是會上升許多。
沒看過上一篇嗎? 傳送門:專案一直被修改?可能是沒有找到客戶真正的需求。
在談 User story 之前,先跟各位聊聊大家一定有經驗的團康遊戲,如果是參加過學校迎新或是團康的人一定不陌生「超級比一比」
如果不清楚的人可以先看看影片:
或是以圖像表示:
圖片來源:http://partygames.guide/
「見樹,還是見林,不如用故事來開啟對話達成共識」
在每一次的遊戲經驗裡,我們發現,在資訊的傳遞中,「認知落差」
再換一個生活實例來討論,假如今天有人問我「讓你用一句話規劃你理想中的假期」,我回覆「想和情人一起出國旅遊」,對我來說的理想假期的重心是【情人】,也就是【情人】是我的必要條件,但也許對其他聽眾而言,會解讀成【出國】才是必要條件。
連簡單直接的話語作陳述,
「透過協作機制,來彌平雙方的認知落差」
在前面的範例裡,我們都忽略了一件事情,叫做【詢問】(
「什麼是 User story?」
使用者故事「User story」重視的並不只是把故事說出來,而是要透過故事的設計和陳述,把過去既往冷冰冰的需求和規格,
1.觀看全局,了解問題的核心
2.作更少,直接解決主要問題
3.準時交付,避免違約
當然,為了達成上面的三大目的,說故事的重點就更需要被具體化,不外乎是前幾篇文章討論到的Who、What、Why,但只有3W,卻還沒有辦法構成一個完整的故事。
因為我們的故事沒有辦法被作出所謂的【優先度 priority】,而是更應考慮到【 產出 output 】、【 影響 impact】。現在就開始了解怎麼寫一個好的user story吧!
「故事裡最重要的,當然是角色吧」
在每一個故事裡,一個事件裡面通常都會充斥著各種不同的角色,例如去咖啡廳買咖啡,咖啡廳裡就充斥著泡咖啡的員工、
假如我們要開一間電子商務公司,主要的產品就會是網路商城,
小明 是想要買東西的人:購買者 shopper
小美 是想要賣東西的人:店家 merchant
小華 是想要管理的人:
所以從上面的初步分解,我們就來討論小明吧!
想要在第一次見面的時候買一個小禮物(what)。
所以需要一個購物網站(output) ,讓他可以送給心儀的女生來終結單身(impact)。
用一個簡單的故事,
但這只是 user story,
「從 3W 衍生到 As .. I want..So that.. 」
身為"誰",我希望可以"功能" 以便能讓我 "達到目的"
As 小明(消費者) , (I want 我想) 去 (逛網站的商場 ), (so that 所以) 我可以 (買到禮物)
所以第一個 story 就可以被明確的劃分出來了,而劃分的同時,
把模糊的需求變的具體,然後驗收,
「看見全貌,做得更少,準時交付」
當然在一個產品上,不會只有一種輪廓的使用者,越透過討論,
但在擬定各種 user story的同時,
在有限的時間裡,
例如:
1. 身為一個購買者(as shopper) ,我想(I want) 去逛網站的商場,所以(so that) 我可以買到禮物。
產出(output): 網站商場主功能,
影響(impact):
2. 身為一個購買者(as shopper) , 我想(I want) 去檢視購買紀錄,所以(so that)我可以回顧我買了什麼東西。
產出(output): 購買紀錄功能
影響(impact):
若是我們可以同步把每一條故事列出,
「
然而,這樣切分的 story 也許還是會太粗淺了些,
而再下訂的流程裡該怎麼付款、
下一篇, 你有刪除功能的勇氣嗎? 別人程式有所以我們也要有?(Task)
最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!