四種專案複雜度

August 14 10:45~11:58

本圖由吃飽飽親手繪製XD。

最近置入性行銷講了太多design pattern與軟體架構，今天把焦點移回Scrum。在八月三日的「Scrum大師講座 (Emerson Mills)」活動中，Emerson在白板上畫了一張類似上面的圖，當時Teddy看到好多參加活動的學員們努力的在做筆記。此時Teddy心裡在想：「這張圖不是書裡面就有了…XD」。還不只一本書，Teddy在《Agile Software Development with Scrum》與《The Scrum Field Guide》這兩本書中都有看到。不過其實這個圖是出自於另外一本書《Strategic Management and Organisational Dynamics: The challenge of complexity》。

不過這都不是重點，重點是這個圖代表什麼意思？這個圖的X軸表示「技術確定性的高低」，Y軸表示「需求確定性的高低」。越靠近原點，表示專案的需求很穩定（不太會變），而且專案所使用的技術也很確定，風險不高。上圖分成四個區域，表示四種不同類型的專案：

1. Simple：需求與技術都很穩定，所以稱之為簡單專案。
2. Complicated：需求或技術兩者之間只有其一是穩定的，另外一個比較不確定，所以稱之為複雜專案。
3. Complex：需求與技術兩者都不太確定，所以稱之為錯綜複雜專案XD。
4. Anarchy：需求與技術兩者都非常的不確定，所以稱之為混亂專案。

***

請鄉民們想一下，你手邊的專案是屬於哪一種？如果是Simple，這種專案做起來很簡單，但是通常也沒什麼賺頭。Anarchy，這種專案應該不是一般人類有能力可以解決的，所以跳過。接下來比較有可能的，就是Complicated和Complex這兩種類型的專案。如果是Complicated專案，也還好，至少需求或是技術兩者之間有一個是相對比較穩定的，所以雖然有點小複雜，但是聰明的鄉民們，只要小小加班一下就可以處裡的非常妥善XD。真正麻煩的是Complex專案，需求還技術都存在著相當程度的不確定性，這也應該是大部分鄉民們做專案的寫照。

鄉民甲：靠…近一點我才聽得到…什麼…三個月前談好的需求又要改了！？

鄉民乙：ㄟ，這個JavaScript library倒底是應該選擇哪一套啊。還有、還有，NoSQL要用哪一個solution呢？

遇到這種Complicated專案，要如何控管？

說穿了也很簡單，因為需求與技術都在改變，所以很難在專案一開始就規劃好所有的事情，因此傳統瀑布式專案流程就絕對行不通。此時要跟開車一樣，雙眼、雙耳隨時注意路況，然後大腦隨時接受到最新路況，控制雙手與雙腳，隨時調整方向排並決定要踩煞車或是油門。這種控制的方式，有一個術語，叫做：

Empirical Process Control ---以經驗為基礎的流程控制。

 

看到這張圖鄉民們有沒有想到什麼？對啦，這就是Scrum的流程或是說Scrum的專案管理機制啊，只不過Scrum的回饋路線有兩條。

詳情請參考「Scrum 是什麼（1）：雙重回饋機制」。

***

友藏內心獨白：2012年Scrum第三梯次課程明天開課。