Scrum與Design Patterns

May 24 13:48~13:09

 

都快下午兩點了，怎麼今天的搞笑談軟工還沒「出刊」，該不會要開天窗了吧。放心，都已經撐到快五月底了，2012年每天寫一篇的承諾一定會堅持下去。只是因為Teddy前天晚上失眠，翻來覆去等到凌晨四點多才睡著，因此昨天回家吃完晚飯之後早早就躺平了，所以昨天晚上就沒動筆 動手寫部落格。看來有空還是要準備幾篇庫存會比較保險一點。

***

「軟體開發是一種團隊合作的活動」，不知道有多少鄉民們贊成這種看法。Teddy是滿認同這樣的觀點，很可惜在Teddy以前求學的年代，因為升學主義的關係，學校的教育很少教導學生要如何跟其他人合作。學生滿腦子所想的，就是要如何考高分，或是「如何阻礙別人考高分」。總之只要先幹掉班上的其他同學，自己的成績排名才不會太難看。

不只學校的教育制度不鼓勵團隊合作，在工作上同樣如此，至少在軟體開發上是如此。在台灣，很多軟體專案雖然表面上看起來是由一群人一起合作完成，但實際上這個專案被細分成若干個模組，而每一個模組通常就是交由某一個工程師來負責，出了任何問題就是找這個人負責就對了。要是模組負責人做不完或是遇到問題怎麼辦？很簡單啊，就加班啊。多麼簡單、低成本的管理方法啊，真是太完美了。

既然每個模組交由一個人來負責，就代表團隊成員通常是不需要去看其他人所寫的程式。也就是說，這些同屬相同專案、不同模組的程式碼，彼此之間是「各自獨立演化」。這種現象有點像是現代社會中，住在同一棟公寓或是大樓的不同樓層住戶們，彼此互相都不認識的情況是一樣的。

扯了這麼多，這跟Scrum與design patterns有何關係？有些鄉民們可能知道，最近這幾個月Teddy在某公司打工教design patterns。話說學design patterns這件事對於某些工程師來講，可能是一件很無聊的事情。

工程師內心獨白：你管我程式怎麼寫，程式可以動就好了啊，學什麼design patterns啊。

這種反應是非常正常且合理的現象，尤其是如果每個工程師的工作模式都像Teddy剛剛所說的「各做各的（每個模組都只有一個人負責）」，不需要去跟別人合作，更不用去看別人所寫的程式。在這種情況之下，最高指導原則就是「只要程式能夠動就好了」。

但是，萬一原本負責的員工生病、請假、拿俏（耍大牌）、工作輪調、甚至是離職呢？這時候平常被隱藏的「軟體維護與修改的成本」就會被暴露出來。

回歸到design patterns這件事身上，Teddy最近觀察到一個使用design patterns的正面現象。Teddy去教design patterns的這家公司，同時也有團隊在導入Scrum。Teddy觀察到這個導入Scrum的團隊，因為團隊成員有嘗試著以「每個人都可以認領task board上的任何工作」這種方式來施工，因此就必須要去看其他人所寫的程式碼。在這個過程中，由於有某開發人員在設計中用了某些patterns，自然而然的其他開發人員在看這些程式碼的時候也學到如何實際在工作上應用這些patterns。

這種經驗的交流與技術擴展的模式是一種很自然且很好的傳遞知識方法。假設團隊有三個開發人員，每個人每個月各應用了一個新的pattern，那麼團隊成員在這個月之內就有機會可以實際看到三個不同patterns的應用。而這種在工作上對於patterns的應用才是design patterns真正的力量，如果只是靠上課學習而沒有實際使用在工作上，沒過多久很快就會忘光光。

***

Teddy在1997年的時候剛剛接觸到design patterns，不久後在公司內部擔任教導其他同事design patterns的工作。還記得那時候除了上課以外，Teddy並沒有想到什麼好方法來讓同事們實際去套用patterns。不過還好當時Teddy的同事都是「有理想、有抱負、有能力的年輕人」，在上了幾次課之後，很快的的能夠自學design patterns且實際應用在工作上面。

10幾年之後的今天，有了Scrum把團隊活動緊緊地串聯起來，Teddy發現傳統的訓練課程搭配Scrum框架的工作模式，是一種提升與深耕軟體開發團隊技術能力的好方法，有興趣的鄉民們可以嘗試看看。不過，前提是要先找到一個很會教design patterns以及有著豐富Scrum實戰經驗的好老師啊…XD。

***

友藏內心獨白：不用找了，遠在天邊，近在眼前。