為需求加上故事

.

我們無法通過智力去影響別人,情感卻能做到這一點。”

-亞里斯多德

.

說故事有多重要

為什麼技術人員需要重視故事呢? 原因在於,即使個別的訊息 (需求)看起來都很有邏輯,讓人看了一清二楚,但是只要這些訊息之間相互的關係不是那麼明確,接收者(客戶)所吸收到的程度就容易受限。即使你塞了再多的片段資訊給對方,也很難讓他確切的了解。這一點可以在檢核會議(Review meeting)時的客戶回饋裡看出來。客戶經常是現在沒問題或對單一的功能沒問題,但在最後串起來時卻能提出許多意見。

 

故事能賦予產品生命

敏捷對需求所陳列出的一個個小的使用者故事(小增量、迭代與尋求回饋的對象),需要被串接起來成為更大的故事。PO需要對大故事的環境、演進最為熟悉用心,而團隊則負責弄清楚需求的故事細節與情境。如此才能讓產品有一個足夠量的故事來支撐它,而工程師能做的則是賦予一個一個功能的小故事,它是一個個心血的結晶而終將成為工程師們生命歷程中的經驗所得。因為故事裡帶有情感的要素,可以讓人們產生更多的聯想,而賦予了產品額外的生命。

.

故事可以將訊息組合成邏輯金字塔。重點在於能以明確的連接詞串起所有的訊息,就成了一個大道理。

麥肯錫顧問公司的金字塔原理用於說故事

.

故事連結了片段的訊息

好的溝通需要有清晰的邏輯內容,更需要一個簡單的結構來引導聽者的思維。而故事可以將訊息組合成邏輯金字塔,並讓片段的訊息串成更完整的系統邏輯並讓產品的生命得以成形。

如果在開發的漫長週期裡,我們始終知道自己正在完成的是故事裡的哪一個片段,我們就會做得更好,程式裡也會更有感情、意境與創意也就更容易油然而生。

.

階層的需求故事

敏捷運用故事來描述需求

.

使用者故事不是故事

一個好的故事詮釋了一個產品被開發出來的意義,就好像賦予了它生命一般。如上圖;一個大的故事,在敏捷的需求範疇裡我們稱之為EPIC,有關他的長篇敘述最適合在啟動會議(Kickoff meeting)拿來打動人心,讓大家知道辛苦工作的目的也就是我們是為何而戰的。再小一點的故事可以稱為 Feature 他適合在梳理會議(Refinement meeting) 裡拿來說明這幾次短衝(sprint)的目的,有利於團隊在明確的目標下發揮更好的協作。

 

接下來是使用者故事(User story),雖然名稱是使用者故事但她不是故事。她是敏捷團隊裡PO、團隊與Scrum Master拿來溝通用的共通語言。一般以3C的方式做呈現,也就是 Card卡片、Conversation溝通及 Confirmation確認。它不是需求的文件,而是引發團隊探討需求的手段。再來便是開發工程師將一個使用者故事Breakdown 成可工作的任務Task,它能夠在一天內完成是在好不過的了,因此以小時做估算,最後則是守住這些 Tasks 的測試案例或單元測試。

 

上圖中;故事的範圍結束在 Feature層, 但情感的注入則應該再下去,延續到使用者故事裡,理由是帶著情感、有意識下的開發行為能讓人表現得更傑出、更有創意。因此我們應該為需求加上情感加上創意。而透過的方式便是擁有一個可以活化她的故事。

 

.

演講時;經歷是最好的故事體裁,也是最有說服力的故事。

.

 

結語

早年學寫程式時都是看著開發文件;也就是所謂的 follow Spec依據規格書來寫程式。這種做法很制式很難有創意,偶而浮現出來的 idea 也會擔心是不是會偏出主題的路線,因此經常督促自己還是選擇保守一點的好、少搞怪。在開始進入敏捷領域之後,想法就變了。由於是小增量、多迭代的關係,目標變小了,忽然間就開始不怕搞怪了,而且會經常刻意的去嘗試一些新的想法,樂此不疲。

 

因此在做Scrum Master的時候;總是要求產品負責人 PO要把需求整理成故事,用一段帶著感情的陳述把需求涵蓋進來,運用故事的情境把團隊帶入開發的課題裡,讓工程師們聽完了需求就恨不得能夠立即為他們解決問題(也可以讓工程師反思自己是否有能力做到?),大家對此都沒有意見,但照著做的PO卻不多,也沒看出來有多大的差異,因此久而久之就越來越少PO這麼做了。這對工程師是一種損失,它忽視了故事的力量也減少了許多可能的創意與樂趣。

 

記得為需求加上故事,請不用擔心會走偏了;因為

事實確實重要,但情感卻能將事實的意義傳達給你的聽眾。

 

-Annette Simmons

註:

  1. 你的團隊需要一個會說故事的人》by: 安妮特·西蒙斯 Annette Simmons
  2.  影響地圖 Impact Mapping 是編劇、講故事的絕佳工具。
  3. .神鬼獵人_impactMapping電影: 神鬼獵人的影響地圖分析,適合拿來做劇情說明
  4.  一個PO做需求描述的故事與使用者故事的拆解範例
  5. .83故事在描寫一家三口出遊的需求
  6. .84陳列出來的使用者故事

 

 

先讓英雄救貓咪

 

未命名
這是一本很棒的編劇教學手冊,作者: 布萊克.史奈德。

 

(這裡不打算介紹這本書,我只是要把從書裡面學到的東西,講出來。當然我一直相信,我們是自己人生的導演,所以就一定要有好的劇本囉!)

 

英雄為什麼要先救貓咪呢? 目的只為了在電影一開始的時候,能夠快速的朔造英雄的形象。而執行Scrum的計畫會議也是要如此。

 

Scrum的計畫會議;要由PO說故事開始

我總是要求需求提出者,也就是PO(Product Owner),在計畫會議(Planning Meeting)一開始時,不要直接把使用者故事一個一個陳列出來,隨後就開始平鋪直敘的進行討論。要倒過來;要把感情放進去的好好地說一段完整的故事,一段能把團隊拉進任務裏頭的故事。首先,要做一段 200字以內的故事描述,試試看工程師是否被你感動了,然後團隊決定主動的協助你完成任務。也就是,嘗試把要討論的個別存在的使用者故事,都濃縮在這段要描述的故事內容裡。目的正是;先讓英雄救貓咪。(讓團隊清楚的知道為何而戰,這一段衝刺的真正目標在哪裡?)

 

PO常常會反問我,所有的使用者故事都要放進去嗎? 這樣會有一點困難,且會有一點不順暢!

 

 

老實說;這正是我的目的,那些串不起來的,很難硬塞進來的使用者故事,他們通常就是那些比較不重要的需求了,或是完全屬於另一個功能區塊的使用者故事了,所以當然會比較難融入到一個完整的故事裏頭。這種作法,可以讓 PO在會議之前的準備工作中,透過自己編寫故事的時候,自行意識到要做的這些使用者故事,是否真正的解決了使用者的需求,做完之後是否就能夠得到真正的價值。(另一個好方法是透過製作影響地圖 impact mapping的方式,讓團隊弄清楚 Why? 也就是為何而戰,Who?我們要價值給誰以及How? 如何交付價值)透過這種思維的自我回饋,先做一次優化,對使用者故事先做好一定的區隔。

 

範例: 由po以故事的方式描述了他的需求。

83

故事開始: 從先詢問在場的學員,你(妳)們出遊會拍照片嗎? 會拍很多照片嗎?

那拍完的照片什麼時候會看呢?

(這是一個家庭出遊後回到家中齊聚一起觀賞照片時的景象)

84

 

使用者故事已經隱含在上面的整體故事裡了

 

溝通是為了造成共識

其實要求PO講故事的目的還不只於此;因為使用者故事的目的就是為了描述需求,然後對需求進行溝通討論,進一步造成使用者與開發人員之間的共識。而以這種講故事的方式作為開始,對需求的探討而言會有一個比較好的融入感和完整性。當然,故事說得好的時候,效果自然也會好上許多。這種作法,比起一個一個使用者故事的表列式討論方式要好上許多(離題一下,這也是 refinement meeting最為人詬病的地方,大家只是想快速的對個別的使用者故事進行大小估算與討論,很容易忽略了這個衝刺(Sprint)增量的目的,也就是它所應該有的整體性目標)。

 

我們都知道;要想在演講的前5分鐘就抓住聽眾的心,只有一種方法,就是講一個感人的故事。PO的任務就是要把需求明確的轉達給大家,讓團隊有感同身受的意味,自然的把任務當成是自己的事,為完成任務來負責,所以就該從故事開始囉!

 

下一回;我們來談「先讓英雄救貓咪2」 – 老實說,二版更精彩! 它對軟體開發更為有用。你相信嗎?

 

 

看見的力量 – (III)使用者故事地圖

.

使用者故事地圖」是用來組織和對需求排列優先順序的最佳工具。

User Story Mapping is an an approach to  Organizing and Prioritizing user stories

 

寫書的道理

書;因為要闡述一堆道理,因此需要由淺入深、按部就班地讓讀者吸收到裡面的資訊,因此排列的井然有序是必要的,為了吸引讀者,它竭盡所能的運用各種圖像、色彩來加深讀者的吸收能力。這跟專案開始之初,PO 運用卡片來撰寫使用者故事作需求的描述,希望工程師能夠讀懂它,然後拿來開發製作軟體,幾乎是同一個道理。

我喜歡拿規劃出書來比喻排列組織「使用者故事地圖」的過程。在看書時,我們總是由前言開始 — 目的是,知道他想表達些甚麼。然後翻到目錄 –希望能一眼望穿有多少東西在裡面。翻到有興趣的章節,接著便是用眼睛來聆聽作者所想講的故事。使用者故事地圖也是這麼回事。尤其是它能讓我們看到專案開始之初的全貌 (Big Picture)。

 .

The big picture 指的是一件事的全貌, 或是長期的願景, 真正的目標。

.

敏捷開發的浮現式開發方式 — 容易遺漏全貌

由於敏捷開發採用使用者故事來描述需求,因此專案在開始之初便是大量的產出需求,也就是透過大量的使用者故事來描述需求,然後開發團隊再針對這些故事進行討論,透過會議、討論、溝通,嘗試讓團隊對需求有進一步相同的認知與了解以便進行開發作業,接著便是期待著每一個Sprint 的開發過程,都能夠產出一個大家預期的功能,用這種漸增的方式讓產品越來越完整,這便是敏捷開發。但這種運用一個一個故事來描述需求的方式很容易讓我們過度專注於故事所描述的細節而反而忽略了專案的全貌。

.

 專案開始之初,最重要的一件事便是看見全貌,劃出邊界。

.

使用者故事的缺點 — 見樹不見林

基本上,使用者故事並不容易得到,因為使用者並不知道所有的需求,所以不能單靠使用者給我們解釋需求。當需要大量產出使用者故事時;有一種常用的克服方式,便是找一些專家(SME,Subject Matter Expert)進行一場頭腦風暴,然後很快地便能找到許多使用者故事了,接著再來進行需求梳理的動作。但這種作法有一個明顯的缺點,便是要花上許多時間來對使用者故事進行一一的梳理動作,這樣的動作非常容易讓我們落入所謂的見樹不見林的迷惑中。尤其是針對一群專業的工程師們,因為專業性的作祟,一看見需求,便很容易迅速地就落入解題的思維,於是很快地開始畫架構圖、選擇適用的設計模式等等,而忽略了應該先審視一下專案的全貌,先確定工作的範圍才是專案開始時最最重要的一件事。

另外;便是受使用者故事粒度太細所牽引的關係,越細的故事越容易讓人立即落入估算、解題的思維,所以在面對一堆較細粒度的故事時,就很容易落入見樹不見林的情境。

解決的方法: 採用使用者故事地圖user story mapping來看見全貌。

(我喜歡Jeff Patton在他的名著:使用者故事地圖一書裡的第一章第一節所用的抬頭 The “A” Word,拿這個字來描述專案的全貌,讓人感覺既抽象又很容易記住。)

 

The “A” Word – The Big Picture

讓使用者故事地圖 User Story Mapping 協助你看見全貌(The Big Picture)。怎麼做呢? 我們用寫一本書的步驟來比喻如何建立使用者故事地圖。

》首先;列出章、節。

「章」便是使用者的活動User Activities。一般就是按照使用者完成操作的顺序,從左到右依序擺放。重要的放在前面。

「節」便是使用者的任務User Tasks。就是撰寫一級(較大)的使用者故事(Epic),一般會用動詞開頭的描述來說明較完整的任務(例如: 建立郵件、發送郵件、等功能 )。

這樣便完成Jeff 所謂的“行走的骨骼”walking skeleton,還有他的書裡頭那張有一點嚇人的圖片。

00 walking skeleton

Walking skeleton

他是拿來講故事用的。我們可以按照 “行走的骨骼”來描述使用者的行為,從這一行開始講述故事,確保你沒有遺漏任何使用者必要的行為(user activities)和使用者任務(user tasks)。明顯得很“行走的骨骼”是用來隱喻,需求尚缺少大部分的物件(沒有肉體),但實質上已經具有一個外型及架構了。

 

》接著,加一點東西

此時;我的習慣是立刻加入下一層的「小節」段,而且通常只加入一二個項目,不會加多或企圖加的完整,目的只是讓思緒再深入一點點而已,它是一個標誌點(tag)。我覺得這樣可以讓我在下一次新增項目時有一個參考點可以很快地繼續想下去。下圖是我的書”精實開發與看板方法”的目錄,寫作時就是先用user story mapping 來做構思的。

0 chapter

作者之所以想出書,通常都是有一大堆東西想跟讀者分享,所以才會動起寫書的念頭,但千頭萬緒該從哪裡開始呢?! 使用者故事地圖正是此時拿來做為解題用的佳作,它尤其適合在太多觀念想說的時候(也就是使用者故事太多,造成需求模糊的時候)。我想;不管你想不想出書,試試看,把一堆觀念作成階層式的排列,井然有序的外觀,對思緒的淨化是有相當的幫助的。

 

0 看板方法 map

書的行走的骨骼 walking skeleton

使用者故事本身是文字化的描述,我們很難依據字面上的描述來看出它的大小階層,然後進行排序,但一旦採用上圖的階層式的排列之後。大的章節便清晰可見,上圖中的第二層,也就是 User Tasks層正是書的骨架,也就是整個產品的骨幹。( jeff Patton 把第一層稱之為使用者的活動User Activities第二層為使用者任務層 user tasks。這二層構成了他所謂的行走的骨骼 walking skeleton)。

 

最後;依據功能多寡,推定迭代的範圍及預訂的產出功能。

完成後書使用者地圖的全貌:

書的結構

 

對照使用者故事地圖轉換成product backlog,並依照需求重要性排列優先順序的圖示如下。便可以看見概略的估算在哪一個迭代的Sprint開發之後,將會產出哪一些功能(如右側圖示的Sprint 週期)。

 

00 需求排序

結論

使用者故事地圖可以讓我們更容易看清需求的全貌。它能協助你進行決策,篩選功能(grooming)和制定需求的優先順序,尤其是讓我們很容易看見使用者故事描述到的功能有重疊的現象,便於我們進行篩選、定位。當然它尤其對架構的設計有相當的幫助,讓開發作業較為井然有序,甚至讓我們據以預測未來(錯! 實際上是規劃未來)。

乍看起來真是好棒的功能,我們可以從中間獲得(確定)好多利益,但是老實說,在專案開始之初由於不確定的因素或是資訊佔大多數,所以使用者故事地圖最大的目的應該是放在協助我們抽象的看見全貌,然後依據它來思考專案的起始點,拿來規劃每個迭代循環的階段性目標(產出物),也就是規劃要產出的潛在可交付的產品為何,而不是進行完整的規劃工作。在本質上;因為專案的全貌是會變動的,這一點與使用者故事十分相同。人們在剛開始接觸到使用者故事時,往往用靜態的觀念來思考它,但其實它是一直在蛻變的(請參考Gojko Adzic的實例化需求),也就是說全貌是會隨著開發過程而演進的。使用者地圖會隨著需求功能的新增或刪除而改變,因此我們的規劃也必須隨著它的變化進行調整,而這才是敏捷開發的本質。

下圖是採用FeatureMap 所製作的使用者故事地圖,需要的人email給我,歡迎分享。(https://www.featuremap.co/maps/ruddytest22/使用者故事地圖)

 user story mappingJeff Patton 所著的"用戶故事地圖" 的用戶故事地圖。

參考:  http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html

 

 

 

 

 

 

使用者故事 User story

最近看到許多傳統的企業正在努力的轉型中,這絕對不是一蹴可及的工作,若你問我改革應該從哪裡開始呢?我會回答從改善品質,加重測試開始,但對於真正的開發工作,則我會選擇從用來描述需求用的「使用者故事」User Story 開始,因此想在這裡寫一些東西,希望能有些幫助,完整的PPTX檔我一直以為:

.

敏捷開發送給世界最好的需求描述,就是用「故事」的方式來說明需求。

.

它是1998年被 Kant Beck 首先運用在XP極致編程裡,供使用者用來描述專案範圍的方法。這種威力無窮的需求描述方式,因為看起來太簡單了些(註1),常常會讓人們忽略了它的影響。老實說;敏捷專案開發的成敗可是完全靠它來作支撐(註2),要知道如果沒有好的需求描述、問題探討,怎麼會有好的產品產生呢?!

.

all agree_0
Kent Beck 的初始目的是為了避免大家沒有討論清楚,就各自自以為是的點頭開始工作。

.

註1:  看起來簡單的東西,實際執行起來並不一定會簡單。因為規範少了反倒很難具體的來實踐他。後來Bill Wake想出了INVEST的六個法則,最近則以Jeff Patton的使用者故事地圖。對產出好用的使用者故事都有著莫大的貢獻。

註2: 據 Don Reinertsen 所說 80~85%的專案之所以未達到要求,完全是不正確的需求所造成。

Studies show that 80 to 85 percent of project failures are due to incorrect requirements. 

by: Don Reinertsen

author of : The Principles of Product Development Flow

.

使用者故事是最佳的溝通利器

業務人員要依靠它來跟技術人員進行溝通,而工程師要依靠它來了解需求並拆解成為可以實作的任務。而它更是二者之間共同探討真正的問題所在是否有更多選項挖掘更多細節接受更多變化的依據。下圖中顯示了需求的二個面向, 一個是對使用者的,它讓使用者足以用自己所熟悉的業務用詞來談需求,完全不用去描述到任何技術的東西。另一個是對程式設計人員的,它是以畫面、場景或是流程方式,來協助工程師快速學習業務知識用的。

投影片5_1
善用溝通才能發掘真正的問題,也才能提煉出更好的設計。

.

Ron Jeffries在2001寫下了使用者故事著名的 3C理論,用來討論、確認故事的各部分組成。1C:卡片(Card): 極端抽象又簡潔的說明(建議以中性動詞來描述它)。2C:談話(Conversation): 無時無刻都可進行的溝通與討論。3C:確認(Confirmation): 為談話的內容及目標作成越正式越好的結論(註3.)。明顯扼要地說明了,使用者故事是用來溝通用的。(很多使用者把它拿來做為規格文件使用,那就大錯特錯了。)

3CC
Ron Jeffries 的 3C

.

舉一個例子來描述一下運用步驟:

步驟一、如以下的陳述,針對某一個目的寫下使用者故事  –> 查詢客戶資料。

             身為一個使用者,我希望可以運用姓氏或名字來搜尋我的客戶。

              As a user, I want to search for my customers by their first or last names.

.

步驟二、工程師由使用者故事推敲如何解題  –> 進行功能拆解。

        ※將使用者故事拆解成任務(Tasks):

              Task 1:  畫面製作。至少需要輸入: 姓氏、名字的輸入欄位搜尋的按鈕

              Task 2:  訊息顯示。顯示進行中、錯誤訊息。

              Task 3處理搜尋功能呼叫及取回資料

              Task 4:  結果顯示。討論以何種元件(List、Grid、…)作為結果顯示。

步驟三、雙方進行討論,定義何謂完成 –> 討論這樣做是否解決了真正的問題。

客戶與程式開發人員就可以針對使用者故事進行討論,確認描述的故事是否解決了真正的問題。

也許找到"使用者的 email “或 “電話號碼“才是查詢者真正的目的。為此;就應該把查到的資料用這兩個欄位作為顯示的重點。還有;一次顯示資料的筆數? 是否需要進行排序? 再加上必要標誌等功能,也需要視各種情況進行適當調整。

.

經過與客戶討論之後的可能結果 範圍與限制都更明確了

上面的範例並沒有將最後的利益說清楚,因此留下了讓客戶與程式設計人員有很大的討論空間(是優點也是缺點!)。下面則是二則運用不同的使用者(角色)將同一個使用者故事利益設限的範例:

身為一個電話傳呼員,我希望可以運用姓氏或名字來搜尋我的客戶電話以便於我可以直接按鈕呼叫出去。

身為一個推銷員,我希望可以運用姓氏或名字來搜尋我的客戶Email 地址以便於我可以直接按鈕送出我的廣告。

.

進階詮釋的3C

這是一個單一且明確的範例,若是把它加以運用在一個團隊開發的專案上。則3C便成了:

[ 1C ]  一份書面的故事描述,用來當作計畫或提示用。

[ 2C ] 在計畫會議時做為有關故事的對話、討論,用來具體化故事的各種細節。

[ 3C ] 測試。用來確認撰寫的故事是否完成解決了它的問題,最終則成為了基本的文件。

.

 

小結

建構滿足使用者需求的軟體,最好的方法是從"使用者故事"開始。它即簡明扼要又清楚明確地描述對實際用戶有價值的功能。但它(使用者故事)不是規格文件,而是用來探討解答的抽象化方式,它的任務是讓客戶跟工程師能夠就解決真正的問題而進行溝通。對於敏捷而言;真正的規格文件是誕生於持續的開發與維護當中。(敏捷文件;它跟程式的架構有著相同的產生方式,也就是衍生出來的,是一邊設計而同時又一邊撰寫出來的)

如果你已經計劃要開始採用「使用者故事」的方式來撰寫需求的話,先跟你說:接下來你就會面臨「估算」的問題了,請務必弄清楚「故事點」,它將會決定你的開發敏捷度。

.

回答問題:

1. 為何「改革要從改善品質,加重測試開始」呢?

因為加重測試可以喚來紀律,而紀律是開始進行改革時最最需要的東西。

2. 使用者故事的來源典故:

(Kent Beck explained where the idea came from:)

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does.
[For example,]
if I type in the zip code and it automatically fills in the city and state without me having to touch a button.
I think that was the example that triggered the idea.
If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

— Kent Beck via personal email, Aug 2010

3. 實質上它就是測試案例,是屬於較抽象化的確認,通常他不會描述反向的結果,而是指向絕對正向的輸出。例如: 一般我們寫單元測試時,會採用 3正1反的案例,3正指的是極小、極大值和一個正常值(通常就是它了,甚至還要抽象一些),1反指的是一個可以造成錯誤的輸入值。