進度條

在寫程式之前,請先搞清楚這程式到底是要解決什麼問題

用User story取代規格書,做一個符合期望價值的產品

作者: Vincent Ke 更新日期:
校正小編註記:

工程師通常與程式溝通久了,總是講出來一些音調上聽起來是人類的語言的外星語。
但是工程師與工程師總是能互相聽得懂,好像需要裝個電線調整頻率似的。
User Story 就是一個可以扮演調整頻率的角色。
它可以拆解專案/目標,化為可執行的最小單位
以此對應程式端的功能,讓所有事情自動跟著規格走。


User Story 不僅僅是給一般非工程職的人使用的工具。
對於工程師本身也是非常有用的。
畢竟也不是很少聽到程式高強的團隊意氣風發的出來創業,
最後做出一個技術高深但不知道市場在哪的產品。
如果再開始做產品之前先有效的分析市場(顧客)與真正重要的功能,
雖然不能保證成功,但機率還是會上升許多。

 

 

沒看過上一篇嗎? 傳送門:專案一直被修改?可能是沒有找到客戶真正的需求。



再談User Story之前,先跟各位聊聊大家一定有經驗的團康遊戲,如果是參加過學校迎新或是團康的人一定不陌生「超級比一比」這個遊戲,規則通常都是由第一個人出題,讓後面的人接著比擬他的動作,等作到最後一個的時候來還原一開始的題目,有可能是成語也有可能是電影、歌詞或是音樂等。

 

 

如果不清楚的人可以先看看影片:

(早期綜藝節目)華視《 超級星期天 》超級比一比
 

 

或是以圖像表示:

圖片來源:http://partygames.guide/partygame/charades.html

 

 

 

「見樹,還是見林,不如用故事來開啟對話達成共識」

 

 

在每一次的遊戲經驗裡,我們發現,在資訊的傳遞中,「認知落差」會不自覺的一層一層傳遞下去,而最後一位遊戲者的解讀,卻往往佔了最關鍵的角色,但中間每一段的誤差傳遞,卻往往是造成誤判的最關鍵因素。

 

再換一個生活實例來討論,假如今天有人問我"讓你用一句話規劃你理想中的假期",我回覆"想和情人一起出國旅遊",對我來說,的理想假期的重心是情人(必要條件),但也許對其他聽眾而言,會解讀成出國(才是必要條件)。

 

連簡單直接的話語作陳述,都會發現不同人對於一句話的理解,就佈滿著平行的落差,更何況是比手畫腳呢?

 

 

「透過協作機制,來彌平雙方的認知落差」

 

 

 

 

在前面的範例裡,我們都忽略了一件事情,叫做【詢問】(不管規則允不允許啦)透過詢問做確認,來彌補資訊上的落差,透過詢問的方式,使對方成為協作(或是稱共編)的一員,才有辦法把對話的想像空間作同步,取得共識,而UserStory使用者故事,正是為了完整闡述對話而設計出來的。

 

 

「什麼是 User Story?」

 

 

使用者故事「User Story」重視的並不只是把故事說出來,而是要透過故事的設計和陳述,把過去既往冷冰冰的需求和規格,變成一種關於問題的解決方案,而目的,正是為了要完整化我們的問題,透過討論、詢問而達成共識。而在軟體開發上的共識,所希望達成的目的如下

 

1.觀看全局,了解問題的核心

2.作更少,直接解決主要問題

3.準時交付,避免違約

 

 

當然,為了達成上面的三大目的,說故事的重點就更需要被具體化,不外乎是前幾篇文章討論到的Who、What、Why,但只有3W,卻還沒有辦法構成一個完整的故事。

 

因為我們的故事沒有辦法被作出所謂的"優先度Priority",而是更應考慮到"產出Output","影響Impact",現在就開始了解怎麼寫一個好的UserStory吧!

 

 

「故事裡最重要的,當然是角色吧」

在每一個故事裡,一個事件裡面通常都會充斥著各種不同的角色,例如去咖啡廳買咖啡,咖啡廳裡就充斥著泡咖啡的員工、買咖啡的顧客,而顧客又有分外帶、內用...等等,如果"咖啡廳"是產品,那我們裡面的使用者就有如上面的角色。

 

假如我們要開一間電子商務公司,主要的產品就會是網路商城,那我們的產品使用者到底會有誰?又該怎麼定義每一個User的輪廓呢?這樣講很空洞,不如故事的起頭,我們就來定義角色吧?

 

 

小明 是想要買東西的人:購買者Shopper

小美 是想要賣東西的人:店家Merchant

小華 是想要管理這Eric和Emily的人:網站員工WebStaff

 

所以從上面的初步分解,我們就來討論小明吧!

 

小明(Who)可能是一個單身多年的魔法師(專情單一的意思),今天她終於有機會約到心儀的女生吃晚餐了(Why)。
想要在第一次見面的時候買一個小禮物(what)。
所以需要一個購物網站(output) ,讓他可以送給心儀的女生來終結單身(Impact)。

 

用一個簡單的故事,又就可以把我們所需要的元素全部都定位出來了,也把目標和需求明確化。

 

但這只是UserStory,為了要讓功能明確化,必須要把功能再切分成更精準的用詞,才可以確保這樣的故事(story)可以明確地被傳遞,於是轉換如下:

 

「從3W衍生到As .. I want..So that..」

 

 

 

身為"誰",我希望可以"功能" 以便能讓我 "達到目的"

 

As 小明(消費者) , (I want 我想) 去 (逛網站的商場 ), (so that 所以) 我可以 (買到禮物)

 

所以第一個Story就可以被明確的劃分出來了,而劃分的同時,我們也同時在作"制定規格"和"驗收標準"這件事情,一來我們要做的項目可以被視覺化和明確化,二來對客戶來說,能不能在我的網站上面買到禮物,也當然就成為了他心中的需求,變成可以被實現的具體項目之一。

把模糊的需求變的具體,然後驗收,這不正是我們(專業人士)要做的事情嗎?

 

 

 

「看見全貌,做得更少,準時交付」

 

 

當然在一個產品上,不會只有一種輪廓的使用者,越透過討論,就會擬列出更多的故事線,就像大家買東西的理由總是千千萬萬種。

但在擬定各種UserStory的同時,我們同時也要去思考這些產出(Output)與影響(Impact)是不是正符合我們初衷與需求,

在有限的時間裡,我們能投入開發的需求相當有限,產品是絕對不會一次到位的,故常常會需要判斷"優先度Priority" 做到開發上的排序。

 

例如:

1. 

身為一個購買者(As Shopper) ,我想( I want) 去逛網站的商場,所以(so that) 我可以買到禮物。

產出(Output): 網站商場主功能,

影響(Impact): 可以有更方便的購物習慣。

 

2. 

身為一個購買者(As Shopper) , 我想( I want) 去檢視購買紀錄,所以(so that)我可以回顧我買了什麼東西。

產出(Output): 購買紀錄功能

影響(Impact): 可以回顧自己買了什麼做帳務管理

 

 

若是我們可以同步把每一條故事列出,並把產出output和影響Impact攤開,就可以輕易了解到每一個Story上面需要設立的"優先度Priority" ,而次要的功能在哪時候應該要做,做什麼功能,就可以再和客戶溝通決定。

 

 

透過Mapping來討論使用者故事Story和任務Task,達成開發共識。」

 

 

 

然而,這樣切分的Story也許還是會太粗淺了些,畢竟逛網站的使用者也許還會有各種不同的使用動機,例如要今天一定要送到禮物的、想送禮卻不想尷尬碰面的、禮物需要冷藏的..等等。

 

而再下訂的流程裡該怎麼付款、怎麼加入購物車..等等這些更細微的Task,也才是開發上需要考量的任務,Task與Stroy的動機更不能只用單一種使用者來定型。

 

 

那使用者們的交集是什麼,答案會在下一篇揭曉

 

下一篇, 「從Morning map去細切UserStory的Task」

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧