January 29 22:21~23:24
前情題要：
- 〈Scrum 是什麼（1）：雙重回饋機制〉
- 〈Scrum 是什麼（2）：Scrum 的內涵〉
- 〈Scrum 是什麼（3）：三種補充文件〉
- 〈Scrum 是什麼（4）：Product Backlog〉
- 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
- 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
- 〈Scrum 是什麼（7）：Daily Scrum〉
- 〈Scrum 是什麼（8）：Sprint Review Meeting〉
- 〈Scrum 是什麼（9）：Retrospective Meeting〉
- 〈Scrum 是什麼（10）：時程估算〉
Teddy在「Scrum 是什麼（9）：Retrospective Meeting」這一篇介紹了三種流程改善的思考方向，其實說到底廣義的流程改善也好，或是狹義的實施Scrum與agile practices也罷，都需要有一種「傻的願意相信」外加「不信邪」的精神。「傻的願意相信」的觀念Teddy已經提過好幾次了，大意是說書上教授的軟體工程方法，鄉民們自己要先「傻傻地願意相信」這些是可以奏效的方法，先嘗試照著去做，而不要在學會之前就先急著去否定這些方法。
然而，傻地願意相信只是第一步，因為有時候就算是真的傻傻地照著書本上所教的方法去做，實務上還是會遇到很多困難，導致於無法達到書本上所說的那種效果。例如，幾乎所有軟體工程與敏捷方法的書都告訴鄉民們「要寫自動化測試，要寫自動化測試」，老師在講鄉民們有沒有在聽 ？沒有嘛（翻桌）。不過這也不能怪鄉民們，實務上團隊就是沒有編列「testers」這種標準配備啊，自動化測試要叫誰寫 ？好吧，山不轉路轉，沒有testers就請programmers自己寫吧。問題又來了，programmers要嘛就是說不知道怎麼寫自動化測試，要嘛就是直接嗆說不爽寫，還有些PM（專案經理）會跳出來阻擋，理由是「寫code都來不及了哪有時間寫什麼自動化測試啊」。
正所謂「天將降大任於斯人也，必先苦其心志，勞其筋骨，餓其體膚，空乏其身，行拂亂其所為（難怪Scrum Master當久了很容易起肖），所以動心忍性，增益其所不能。」 遇到這些阻礙也當屬正常現象，請安心服用。所以，「傻的願意相信」的下一步，就是要有「不信邪」的精神。老子/老娘就不信沒有tester就寫不了自動化測試；有了這樣的覺悟，假以時日團隊自然會找出改善之道。
約十天前Teddy在寫「Single Code Base」時，把Extreme Programming Explained: Embrace Change, 2nd這本書關於Single Code Base的解釋又讀了一次，在68頁作者寫了一段話讓Teddy感觸良多：
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.
***
當Teddy在開發團隊中扮演Scrum Master角色的時候，心中日思夜想的事情都是如何改善團隊的軟體開發流程。為什麼這個sprint產生的bugs特別多，為什麼bugs沒有被自動化單元測試與自動化功能測試給找出來，為什麼有一個版本的安裝程式根本無法執行，為什麼與平台相依的專案（native projects）無法在持續整合系統上面自動被建構，為什麼... ？
這麼多為什麼，也許都可以用一句「人力不足」或是「時程太趕」來交代過去，但是這樣的話就談不上什麼向上提升，只能祈禱不要向下沉淪就該偷笑了。
「基礎practices達成度」、「進階practices達成度」、「消除浪費」這三點已經幫Scrum團隊樹立了許多改善的方向或是目標，然而要如何接近這些目標每個團隊卻是要依據自己的現況與組織的文化自行調整。達成目標的過程可能很漫長，但只要抱持著不信邪的精神，Teddy相信改善的效果總是會逐漸顯現。
***
下一集：〈Scrum 是什麼（12）：不要再用focus factor與unplanned items了〉
***
友藏內心獨白：清宮劇裡面不是常常都說要「想輒」嗎，沒輒的時候還是要想輒，這就是一種改善的精神...XD。
沒有留言:
張貼留言