l

2012年8月15日 星期三

四種專案複雜度

August 14 10:45~11:58

image

本圖由吃飽飽親手繪製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 ---以經驗為基礎的流程控制。

螢幕快照 2012-08-14 下午11.50.21

 

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

螢幕快照 2012-08-14 下午11.56.56

詳情請參考「Scrum 是什麼(1):雙重回饋機制」。

***

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

沒有留言:

張貼留言