限制搜尋空間 加速設計

在2月份Barcamp中跟Steven Mak一起做了一場演講，題目是「少文件、大設計、快開發」，講述以少量文件開始計劃，並以設計技巧加速開發的心德分享。因為涉獵的範圍太廣，當初就題目的決定可真費煞思良。實踐果然是最佳的驗証法，收到不少的意見，其中有段的反應不錯，所以決定獨立成文跟大家分享。

關於限制

限制總是令人討厭，有時會聽到說要是當初沒有這個限制就能好了～事情一定更美滿之類的說辭。

可是細心思考，失去所有限制真的是好事嗎？

試想像突然間要你寫一篇作文，題目不限，你會寫什麼？結果是飛快把文章寫出來，還是遲遲動不了筆？

<<人月神話>>的作者Frederick. P Brooks，在他的新書<<設計的設計>>中提到：

「限制或許是負擔，但也可能是好事。限制可以縮減設計師的搜尋空間，有所限制，比較容易聚焦並加速設計。
……
讀國中的時候，我們很多人都不喜歡「自訂題目的作文」，我們發現有些事是真的；把限制統統拿掉，會使「設計」作文的工作更加困難，而不是更簡單。

……

人為限制對設計工作來說，好處是可自由放寛限制，理想情況下，它可以把設計師推向設計空間中未經探索的角落，從而激發出創意。」

限制並非創意的制肘、相反詞，好的限制反而可以激發出創意，問題是一些誤解、過時甚至矛盾的限制，例如下圖……

要平？要好？又要快？去你的。

需求不清

沒有限制的作文令人猶疑不決；需求不清的軟件開發則舉步為艱，二者的情況其實很相似。

有些人明確地認知到，有些人潛意識地知道，完全的自由並不存在，沒有說明限制不代表沒有限制，通常在交付時才知道。故總是恐懼著做出少於隱藏限制的工作，又害怕做出多於要求的事浪費氣力，結果精力都消耗在摸索那條不可視的界線。

所以一份清楚的需求可以幫助導論出明確的限制，但不幸的是需求不清下開發已經變成了業內的常態，雖然不支持卻只能照著辦。

設計不足的困境 

常見於菜鳥或技能狹窄的團隊，以不變的舊方法挑戰新問題，缺乏對應問題的設計，又因解決方案的涵蓋範圍不足，結果問題多多最終難尾收場。這種團隊的常見特質是把High Risk的東西都放到最後。 

過度設計的抓狂 

另一種極端是過度設計，為了應付不清淅、未知的需求多想多設計不是壞事，但往往會無止盡地思考、搜尋可能性，不自覺地做出過於複雜的架構，拉長了開發時間，而更糟的是有可能做出超出能力的設計，直接出局。

有點相當之有趣，就是設計不足的團隊往往比過度設計的團隊成功，因為前者最少能做出讓客戶收貨的第一個版本，雖然會因為需求修改、又或者結構太爛導至technical debt的債台高築，令開發的時間及成本不斷上昇。

但最少能快速地做到第一個版本，投資者願意付錢，又能發佈出去令士氣得以維持，正付合MVP的精神；總好過因為不肯定是否需要的問題而拖長開發時間，所以Extreme Programming有所謂"You aren't gonna need it" (YAGNI)的原則，需求修改則以TDD及Refactoring應對。

明確的時限是一種避免過度設計的限制

把想法歸成四類的分析法

有次跟某開發團隊會面，討論他們的設計，期間提出了許多試探性的問題，例如做不做得到一項不在規格內的功能？為什麼要用／不用這方法？這個問題發生時該怎麼辦？

大部份問題都是無理，甚至是愚蠢的，持續發問是為了考驗他們對自身設計的掌握，但結果工程師的回答速度越來越慢，漸漸失去自信。

這不能怪責他們，因為需求本身就處於不清淅的狀態，在無限制的設計中，搜尋（回答）的速度必然下降。

為了讓設計得到限制，我們做了一個嘗試。

就會議中提出的所有點子、Story，不論是問題、原則、想法、猜測，只要認為重要的，請寫下並歸類成以下四種狀況：

Requirement 

明確地由客戶、老闆提出的需求，那是一種proven fact，無用質疑的Story都歸類在這裹。

在那次會議中可以被歸類為Requirement的想法遠比其他種類少，正是問題的所在。

Constraint 

在項目管理中，Constraint指應被檢查、限制、禁止的資源及要避免的行為，同時又包括為此而採取的行動，用途是為專案所覆蓋的範圍定出明確的界線。你可以理解為完成需求而應該及不應該做的事。

Assumption

也可以稱之為Educated Guess，沒有實質的証據支持，但憑籍經驗進行猜度的各種想法。

Uncertainty 

專案中的大敵，混沌的根源，理應盡早排除，但若因此過份賣力，卻會陷入過度設計的地獄。最糟的其實不是項目存在不確定、不清淅的地方，而是自己都不知道不清楚什麼，所以把Uncertainty記錄下來是有幫助整理思考的作用。

參考

• Project-Speak: Assumptions and Constraints
• Assumptions Vs Constraint

若Requirement及Uncertainty處於二個極端，那麼Constraint及Assumption就是彌補二者之間的空缺，在進行軟件分析及設計時會在腦中跑出許多的點子，對這些點子過早進行批判是無益的，一來在大藍圖清淅前欠缺足夠理據下決定，二來為每個點子進行深度分析是很費時的，需要的僅是記錄及歸類。

完全不明白、猜不透的想法	Uncertainty
我覺得專案需要...吧...?	Assumption
我們要做或不要做個	Constraint
原來文件有寫的	Requirement

這個歸類是很簡單的，建議可以先自行準備，然後拿出來給團隊一起研究，他們可以幫助確認想法的正確性，例如把不對的Assumption拿掉、跟客戶老闆談Uncertainly，最後變成Requirement或者Constraint等等。

故此這個分析表的內容會隨著時間而改變，理應越來越準確，在這個前提下第一版與最後版本必定有很大的出入，所以起草人不妨「大膽假設」，而非慢慢分析，寧可快點拿出起討論，反正有錯是正常的。

限制搜尋空間的設計

並非所有編程師都有規劃的能力，按部就班編程還可，規劃整個軟件卻無能為力或者費時日久，這與經驗有關，也與思考方法有關，試想像同時把數十至數百項要求同時放進腦部思考有多困難？

能同時處理、思考的數目多寡主要由天資及思維決定，不過可以用方法補救，就是利用之前寫下的分析列表，以檢核表法(Checklist Method)方式輔助思考。

在未有一個大藍圖之前，先由Requirement著手，就每個單獨的要求做一個設計：

1. 只針對這個要求做設計，不考慮其他。（除非你認為行有餘力)
2. 內容可以是Use-case diagram、Class Diagram、Activity Diagram、Sequence Diagram、Deployment Diagram、Collobration Diagram，建議採用圖像化方式，但Pseudo Code及point form也可
1. 如果做的是Class Diagram，不用把需求外的Class列入，比起一張overall的Class diagram，針對use-case所繪的class diagram更容易令人理解.
3. 建議手繪，因為快，易加入注解，在設計成形後才轉用數碼方法

註:如果之前已經有重覆的設計，可以考慮修改而非做一個新設計

檢核表法驗証

為一個單獨的需求做的設計可以很快很簡單，但驗証卻要難得多，會無止盡地思考擔心是否足夠呢？

這時候就該把之前的分析成果拿出來用。

首先把剛完成的設計跟過往的設計比較：

1. 有衝突的地方嗎？ => 有則一起修改，尋求一致性
2. 有重覆的地方嗎？ => 抽出來變成模組

然後跟分析結論再做比較：

1. 有未完成的條件嗎？
1. 再設計 or
2. 列入Uncertainty (其實可能是不需要的做的，先記下來再討論吧！)
2. 有分析文件中沒有的功能嗎？
1. 再設計、刪除 or
2. 列入Assumption (憑我的經驗推斷，這功能是需要的)

結論

以上嘗試提出的是一種系統性的分析及設計方法，檢核表法的作用是限制搜尋的空間，放棄無止盡地去思考，而是與過去的設計及分析結果逐一對比，若沒有修改就代表初部設計完成，定出一個明確的完成條件.

對於經驗豐富的架構師來說，大概用途不大，因為他們已經有自己一套的分析及設計論，最大的作用是用來培育仍不得要領的新手，在有限制的時間內讓他們累積設計經驗.

事實上當我們完成了以上的分析後，工程師們回答問題的速度明顯地提昇了許多，另外發現到設計出現問題的原因多數在於Assumption出錯或Constraints不足，基本上只要協助澄清這些需求及分析結果，他們就能自行修正設計。菜鳥的話則加多把勁吧。

這方法其實是把分析及設計放在一起進行，在設計完成時分析的內容或會因此改變，這跟傳統的SDLC的先分析再設計有一定的分別，但若果說這其實更接近Winston Royce(提出Waterfall model的人)原來的想法，而且他本人就不相信Waterfall model，你會相信呢？

好比如這篇文章的主旨「利用限制加速」一樣，有時候有些固有的觀念並不一定通用，不妨用更靈活的方式去思考問題吧。這是一個初步提出的想法，歡迎大家一起討論。

故事式規劃設計

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時，不妨先試一試用資料卡書寫故事，像是在「經歷二」中的那種會議中使用，把分析出來的內容故事化，你會發覺記錄的效率會大大的提昇，而且之後還會發現更多有趣的延伸應用方法。