故事式規劃設計

Agile/Scrum的開發流程中有許多傳統方法沒有的新概念，例如採用Story Point而非Ideal day/man hour去計算工作量；用Burndown Chart取代Gantt Chart等等。

比起使用Issue Tracker來管理工作，Agile/Scrum更傾向於使用Task Board，那是一面貼著各種工作的牆，猶如RPG世界中的冒險工會中擺放任務的告示板，不過更有系統也不至於混亂。

各類型的Task Board

User Story是Agile的常用語，用一二句簡單的說話描述要求、工作以至其他訊息，通常會以手寫的方式寫在便條紙又或者資料卡上。

左 - 資料卡 右 - 便條紙

Task Board的作用就是放置這些User Story，通常會再以TODO、In Progress、Verify及Done等不同階段分類。每天會通過一個10~15分鐘的小型會議重新調整。

對於習慣使用Issue tracker的我而言，最初接觸這個概念只感到不可思義，為什麼有著高科技的軟件不用而走回紙本啊！？

實際經歷過後找到了答案。

剛開始引入Agile/Scrum時覺得便條紙不太可靠，所以選擇了用資料卡。很快就發現這些資料卡除了在Task board外還有很多其他的用途。

經歷一) 快速決定功能的重要性

話說有一個專案，客戶要求的功能是沒有辦法在指定的時間內完成，這點客戶都明白。

唯有先把最有價值的功能弄出來，次要的功能則在死線後加回。
 
把需求列表印了出來，接著大家七嘴八舌討論，意見太多、缺乏焦點、就是沒有辧法決定出優先序。

最後我把心一橫，把所有功能寫在資料卡上，在客戶面前攤開，然後玩起拼圖遊戲。

 最重要的工作放在最頂點，平放代表拿不定主意，
這些平放的"故事"交由開發團隊決定優先序

最初的排列是隨機的，可是當各項工作以視覺化的形式呈現了出來後，思考會變得輕鬆，而且各人直接動手更改排序令敏捷度大增，結果很快就敲定了決議。

其實這過程還不知不覺地把問題本質改變。

最初是的要求是「請為每個工作定優先序」，這等於請你去為工作的價值估值。

當然每個人都有能力做估值這工作，可是該怎樣把各人的估值整合？平均數法固然公平，可是不一定代表能做出好的設計，基於大家的著眼點並不一致，平均數法可能得出違背最多人想法的決定。

可是通過這方法，問題卻變成 － 「請問桌上面的排序有你不滿意的地方嗎？」

現在追求的不再是優先序絕對值，而是各功能的比較值，其實各人根本沒有興趣知道功能A的優先序有多高於功能B，只要知道功能A優於功能B便可。

如果沒有反對則默認通過，反對則直接動手改變次序，當然仍然需要溝通，但反覆排了幾次，爭論點就會減少，代表大家重視的工作及衝突得以解決，漸漸一個比較接近各人心中理想的答案就會以視覺化的方式呈現在眼前。

經歷二) 快速需求分析及設計雛型

要求文件確實地收到了，不過團隊是初成立的，經驗豐富者堪少，這時候採取的方法有二，一是單獨派發任務後自動執行，二是透過共同協商解決問題。

前者自生自滅，在整合時便因為撞車而屍橫遍地；後者一不小心就會變成開會或文件地獄。

結果採用後者，一起討論需求文件，每次在文件中找出一項工作、需求、限制、疑問、資源、對應的設計策略、或者找出了潛在的要求時，都會立即寫在資料卡上。

首先把寫上疑問的資料卡收集，依此跟客戶澄清。之後把工作的卡片卡抽出，經過Planning Poker定下Story Point把所有卡片放在桌上，然後大家就再玩起拼圖遊戲，最後變成工作的計劃。

一份需求文件寫成40多張故事卡已經算少了，看似辛苦卻是先苦後甜的一項作業，首先把不確定性排除不小，而且各人對計劃都能有比較一致性的認識。

如果有經驗深厚者在場，也可以順道做出一些設計的雛型規劃，給予其他人一個明確的方向。

跟著就把工作貼在Task Board上好了，把這些資料重新輸入Issue Tracker可是一件相當之累人的工作！Defeat及Bug等工作的記錄才出動Redmine吧。

已經習慣了使用Planning Poker來計算工作難度，再推論出實際所需的時間。

 Planning Poker也可以好萌 (以上二款均為Odd-e出品)

延伸應用
 
在Agile的定義中，User Story是指用簡短文字描述的工作要求，不過我覺得可以把Story的定義再擴闊，User Story也可以是限制、假設、原則、設計提案、設計模式、問題、疑惑、風險、不確定性，所有經過討論產生的內容，只要內容夠精練也可以是一個故事。

至於寫在資料卡上，則是一項減省文件工作量的方法，像是經歷二中提到的會議，首先可以讓各人淪流書寫，最好是提出者自己寫下，犯不著要犧牲任何一位工程師去當秘書做會議記錄，資料卡（現在可以叫做故事卡）概是記錄、也是設計的一環，只要存放在所有工程師們都能取閱的地方，概可以保持執行的一致性，也可以避免文件地獄。

這也可以算是一種協同寫作。

至於開會地獄呢，這得看主持人的功能及各人會否就個別故事展開過長的討論，關於這點我另寫一篇文章再談。

數個月就可以花掉那麼"厚"的資料卡啊

總結
 
資料卡有不同的大少，我喜歡購買5" x 3"這種大少的，因為書寫空間有限，所以一張卡最好只放單一的命題，並用簡短卻又切入核心的文字及圖案補充。

這種方法在資料內容上有很多的限制，但限制也不一定是件壞事，套用《The Design of Design》一書中提到的說法，限制或許是負擔，但也可能是好事，有所限制比較容易聚焦並加速設計。

用精練文字描述故事也是一種設計的磨練。

雖然這篇文章的標題是"故事式規劃設計" ，但其實真正想介紹的卻是資料卡的運用 ;)

在閣下的團隊正式引入Agile / Scrum時，不妨先試一試用資料卡書寫故事，像是在「經歷二」中的那種會議中使用，把分析出來的內容故事化，你會發覺記錄的效率會大大的提昇，而且之後還會發現更多有趣的延伸應用方法。