l

2012年11月7日 星期三

還是要讀書:解釋篇

Nov. 07 12:48~14:15

image

 

昨天在《還是要讀書》中Teddy引用了一段Kent Beck的話,有鄉民留言希望能夠把這段話「英翻中」一下 挑眉質疑。為了讓鄉民們有感,今天就來解釋一下這段話的意思。先做一點背景說明,Kent Beck在《 Extreme Programming Explained, 2nd 》書中介紹一種軟體開發的做法稱作「Single Code Base」(請參考《Single Code Base》)。大意是說,假設你的專案有很多客製化的客戶需求,不要幫每一個客製化的客戶在版控系統上都建一個版本,而是要想辦法將所有客製化的版本都放在單一的版本之中,然後透過參數設定的方式,從這個單一程式版本建構出不同客製化客戶的版本。對某些習慣為每一個客製化客戶產生一個版本的鄉民而言,可能會覺得Kent Beck的建議「窒礙難行」。以下這段話就是Kent Beck對於這類鄉民的一個小小提醒。

If you have a legitimate reason for having multiple versions, look at those reasons as assumptions to be challenged rather than absolutes. It might take a while to unravel deep assumptions, but that unraveling may open the door to the next round of improvement.

如果你有一些維持多個版本的合理的理由,請將這些理由視為可受挑戰的假設,而非必然的結果。你可能需要一段時間來打破這些根深蒂固的假設,但是這個打破陳規的過程可能是開啟下一輪改善的大門。

***

舉幾個例子。

  • 10分鐘的建構:Teddy剛開始聽到「要在10分鐘之內完成一次建構(build)」也是覺得不太可能,後來還是抱持著《傻的願意相信》的精神,花了幾個月的時間,想盡各種方法來縮短每次建構所需的時間(請參考《Ten-Minute Build 》)。在這個「打破陳規的過程中」,Teddy因此學會了不少持續整合與建構的方法與技巧,不只縮短了建構的時間,同時也讓所開發產品的品質變得更穩定。
  • Shared Code:Kent Beck建議開發團隊應該要實施「Shared Code」(請參考《Shared Code:讓我們變成博格人吧》),乍聽之下又是一個異端學說。要允許開發團隊的每個人都有權力可以修改任何的程式碼,這樣不是會越改越亂嗎?而且大家都聽過「三個和尚沒水喝」的道理,如果程式碼沒有所謂的「owner」,到時候出了問題要找誰?「Shared Code」的目的之一就是希望能夠打破傳統「專業分工」的作法,這一點也不容易做到。但是,一但做到了之後,會發現團隊開發的能力又向上提升了一個境界。
  • Scrum框架:Scrum規範了少數幾個活動,像是Sprint planning meeting、Daily Scrum、Sprint、Sprint Review Meeting、Retrospective Meeting、Product Backlog Refinement Workshop。有人認為,把Scrum稱為一個「框架」這只是一種「行銷手段」,這些活動根本不需要全部採用,只要「挑著用」就可以了,不需要完全遵守。這種想法,Teddy也不能完全說沒有道理,因為Teddy自己在實施Scrum的時候,Product Backlog Refinement Workshop就沒有每個sprint都舉辦。但是,這時候Teddy要賴皮的說一句「叔叔有練過」,因為專案的特性所以沒有每個sprint都需要舉辦Product Backlog Refinement Workshop。Teddy也見過有些Scrum團隊自己省略了「Daily Scrum」(改成Weekly Scrum,一周開一次,變成周會)或是「Retrospective Meeting」(久久才開一次,或是根本不舉辦)。很不幸地,這些團隊實施Scrum的成效從Teddy的角度來看都不是很好。

還有沒有其他的例子?太多了,像是要組成cross-functional team、self-organized team、實踐自動化單元測試、持續整合、持續交付、套用設計模式等等。這些實務做法都不是三兩天就可以搞定的,有些甚至需要幾個月到1-2年的時間才可以算得上略有小成。同樣地,一但你的團隊做得到,別人做不到,這就是團隊開發能力有所區隔之處。

***

友藏內心獨白:不是開玩笑,而是有沒有決心。

1 則留言: