如何製作需求的場景 – 示意圖

.

使用者故事不是文件，它是用來溝通及確認用的需求說明。真正的文件必須視描述時的需要程度而適當的加入資料(例如:加上畫面、場景或是較複雜的流程)來加以補充說明。而其中場景可能是跟使用者故事最為速配的一種情境的描述方式。

.

誰應該負責畫製場景？

畫示意圖不是一個人的責任，應該由團隊共同繪製。示意圖是一個客戶與產品之間互動的情境說明(因此可以稱它為一個故事，當然它可能來自第一個使用者故事)，而這個故事又包含了許許多多的小故事，也可以說成我們運用示意圖把個別的使用者故事穿串了起來，成為一個有意義的情節或是一幕有意義的操作模式。但；其實順序是倒過來的，我們大部分時間是先想好使用者是如何操作的劇情(也就是先想出操作的情境)之後，有了大綱之後才開始思考細節的。所以可以說成是團隊一起討論補足故事情境的細部功能說明。它往往可以克服需求太少(也就是使用者故事不足的問題) 。

 

場景正好可以補足「使用者故事地圖」所缺少的故事情境描述，及「影響地圖」太過於針對個別需求描述的缺陷。尤其是當團隊一起站在示意圖前面，一起填寫、討論如何達成情境描述的補充功能卡片時(HMW，How Might We我們可以如何)，這正是團隊互動最珍貴的一環。

.

示意圖，由Google 所提供的一種只有方塊、文字、箭頭及線條的圖示工具。

.

帶有問題陳列的示意圖(上半部是問題，下半部是示意圖)。

.

上圖為一種帶有問題陳述的示意圖，它更容易引發團隊的討論（因為目標跟問題就列在上面）。它十分適合拿來協助使用者故事成為場景討論的文件。Google 把它拿來運用在5天衝刺計畫Sprint的第一天，用來描述衝刺計畫的目標結構。由於它的簡單好用，幾乎不需要任何的專業素養也能快速的融入問題的討論，因此我把它拿來用作場景的描述，真是事半而功倍。尤其在配合上HMW的隨處黏貼與即興討論，可以讓整個開發團隊迅速的融入場景的設計中，同時能補足先前規劃時的遺漏，非常適合團隊ㄧ起討論用。

.

 

敏捷缺乏制式的文件規範

敏捷開發團隊缺乏標準文件的規範(由於沒有規範或許會更好，所以始終沒有一種標準誕生)，因此許多敏捷團隊就凌亂的各自使用自己的標準來進行文件描述。這一點讓剛入門或剛剛轉換跑道(由傳統開發方式轉換到使用敏捷開發)的工程師們比較難以遵循，往往必須經過多年的經驗累積後才能有所頓悟。因此，這裡我打算提供幾種繪製場景Scenario的方法，供大家視需要作選擇。首先來談談《Google創投認證！SPRINT衝刺計畫》這本書裏頭所介紹的「示意圖」方法。

 

示意圖

我把它拿來作為場景描述的圖示，原因是因爲它簡單好用。如果只是用來描述應用程式的操作或是邏輯情境，採用一般的工程用流程圖示應該就能夠勝任了。但如果考慮到可以讓一般非工程人員也能輕易地看懂我們在說什麼的話，還是以採用看起來更簡潔，而且完全不用學習就看得懂的圖形來作說明會更好些(以簡單為上策)。這一點從電影星際效應(原片名：Interstellar)裡的星際穿越作例子說明就可以看出來(如果想要深入探討星際穿越的話，你得先了解黑洞學說、宇宙的次元說等艱深的理論，而前提是；你要先懂得相對論才行XD)。因此物理學裡在討論越是複雜的理論時越會採用較簡潔的方式去做表達（請参考下面的圖示），才不容易產生誤解，或是讓人聽了一頭霧水完全無法理解(然後就只能點頭示意了，千萬不要這麼作溝通)。

.

電影星際效應的星際穿越理論圖示

.

示意圖的目的是讓大家都能一目了然，一看就知道要解決什麼樣的問題以及團隊該怎麼作才能完成任務。這一點跟物理原理的說明一樣，總是採用最少最簡潔的話語(例如海森堡的測不準原理: 海森堡主張，只有在可以設定的實驗環境下對於粒子的位置做測量，則位置才具有物理意義，否則位置不具有任何物理意義)，所以在邏輯的細節越複雜時，我們越應該以簡單的方式來進行溝通，而越簡單它就會越顯得出它的效果來(可以減少誤解)。

.

在示意圖前面，進行團隊協作

當運用示意圖時，是給予團隊協作的機會。我們可以讓團隊在示意圖前做即時性的共同討論，然後在需要它的地方一起補上如何作(HMW: How Might We )的卡片，這是非常有價值的一種互動方式，能讓大家都進入狀況，比交給情境設計師一個人把它畫完後再做討論的效果要好得多了，或是事後再做任務分配要有效得多。

.

繪製「示意圖」的步驟:

1. 列出重要的角色(最左側)。

2. 寫下最後結果(最右側)。

3. 中間就是文字和箭頭 (必要時加上一些判斷符號)。

4.  以簡單為上策。

5. 尋求團隊協作 – 持續詢問團隊成員「這個圖看起來正確嗎?」還要補上些什麼?

.

一個網站Sign In的示意圖，只有方塊、文字、箭頭及線條的圖示(註1)

.

小結

敏捷文件；讓我們在實施敏捷開發後仍能擁有足夠作為維護，或後續開發的規格文件。其中使用者故事幾乎是所有的ALM工具都拿來作為依據的基本需求描述資料，但它不是規格文件，它是拿來觸發需求討論的小卡片而已。所以談到務實的維護作業時，我們最想弄清楚的是程式會怎麼去應對使用者的操作方式呢？這便是場景所負責描述的情境了，請務必留下當初在進行開發時的情境分析資料，它可以讓後續開發或維護的作業順暢許多。

 

.

註:

1. Google創投認證！SPRINT衝刺計畫 (試讀本在此)

為Google內部實用工作手冊，作者： 傑克．納普, 約翰．澤拉斯基, 布雷登．柯維茲 共同著作。「示意圖」在第二章、星期一 Monday 畫出問題時所採用的方法。

2. 附上書裡頭所談到的場景圖部分及重要問題的部分(取材自網路)

3. GML(銀河建模語言Galactic Modeling Language) by Kent Beck，正是在描述這種極其簡單的描述方式。

.

》示意圖對需求的明確化有著極大的幫助，上面介紹的Google Sprint的示意圖方式，有著容易繪製易於討論的優點，但製作場景還可以採用傳統的電影劇本「情境圖」的方式，那就會讓場景圖示再加上了「啟、承、轉、合」的能力，我們下回再談。

.