用新行為取代舊行為

June 07 09:54~10:49

 

曾經讀過一本談論改變習慣的書《為什麼我們這樣生活，那樣工作？》（英文書名《The Power of Habit》），書中提到要改變舊習慣，必須要用「新行為」來取代「舊行為」。例如，抽菸的人菸癮一犯（提示訊號）就想要抽菸（舊行為）。如果可以在「提示訊號」（菸癮）出現的時候，用新行為來取代舊行為，就有可能可以改變人的習慣。所以有些戒菸方法會用「嚼口香糖」這種新行為來取代抽菸的舊行為，期望可以藉此改變抽菸的習慣。

當然改變行為沒有那麼簡單，還有牽涉到人們可否從新行為獲得獎酬以鼓勵持續保持新行為。從這本書對於行為改變的觀點，回頭看〈問誰很重要〉所提到的問題：「為什麼很多嘗試採用敏捷開發的人會將Waterfall套用在敏捷開發的各項活動中？」答案就很清楚—因為新習慣還沒養成，遇到問題人們還是回到舊習慣找答案，才會發生將Waterfall套用在敏捷開發的現象。包括：

• 將sprint planning meeting當成傳統Waterfall的需求分析階段，開了好幾天的會議。
• 把敏捷開發的估算當成傳統專案管理的估算，變成專案經理壓時程、催進度的工具。原本敏捷開發的pull model（往上游拉工作）變成傳統專案管理的push model（往下游推工作）。
• 將sprint execution當成mini-waterfall。Sprint第一天所有story同時開工，review前一天早上把程式碼凍結，開始測試工作。
• 把原本透過面對面溝通的「建立團隊共識」機制推給「寫文件」，溝通不良的問題變成「文件寫得不夠清楚、不夠多」。
• 沒有組成feature team（cross-functional team）的敏捷團隊，而是沿用傳統的component team。
• 依靠大量的人工測試而非自動化持續整合與測試。

***

要用新習慣取代舊習慣，通常需要一段不算短的時間，更何況採用敏捷開發要取代的「舊習慣」很多。所以才會有人說具備「敏捷思維」很重要，需要有一顆持續改善、從錯誤中學習的心，才有可能逐漸用新行為取代舊行為。

扯了這麼多，軟體開發總而言之就兩個問題：

• 人
• 專業

許多人經常會把這兩個問題混為一談，例如：「我主管不准我們重構軟體」、「我們PM沒有留寫單元測試的時間給我們」、「程式可以動就好了公司根本不管什麼clean code」。一但有了公司、主管做為藉口，就可以不用管專業的做法：

• 不是我不重構軟體喔，是公司不准。
• 不是我不寫單元測試喔，是PM沒有安排時間。
• 不是我不寫clean code喔，是公司根本不重視。

捫心自問，我們真的知道如何重構、做好單元測試、寫clean code嗎？在學習階段，人和專業的問題應該要套用「separation of concerns」原則，個別分開來看。當這兩者放在一起考量的時候，才不會因為缺少任何一個能力，而變成原地踏步的藉口。

***

友藏內心獨白：牽拖別人總是最容易的。