還是要讀書：解釋篇

Nov. 07 12:48~14:15

 

昨天在《還是要讀書》中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年的時間才可以算得上略有小成。同樣地，一但你的團隊做得到，別人做不到，這就是團隊開發能力有所區隔之處。

***

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