People over Process 番外篇

November 06 20:11~21:12


People over Process 寫了  (1)，(2)，(3) 還剩下一點點沒寫完，Teddy 又犯了虎頭蛇尾的老毛病丟著不管，反正也沒人發現...XD。這一陣子花了點時間在讀 The Design of Design 這本書，其中有一章提到了 design processes 和 great designs 之間的關係，最後作者（Frederick P. Brooks）的結論是：


Great designs do not come from great processes; they come from talented people doing hard work.


在台灣有許多公司用『製造生產』的觀念來看待『軟體開發』，認為只要有好的『開發流程（工廠作業流程）』，便可以產生『高品質的好軟體』。Brooks 告訴我們，很棒的設計是來自於有才能的人辛勤的工作成果，並非來自於偉大的流程。


路是人走出來的，軟體是人寫出來的。找一群普普的人，不管導入何種流程，要把軟體做好，有點緣木求魚的感覺。軟體開發的重點在於『個人的能力』，還有『團隊合作』。


市面上軟體工程相關的書籍以及網路資料那麼多，『阿斗仔』看的到，Teddy 看得到，鄉民們也都看得到。所以『獲得知識的困難度』相對來講已經不是影響軟體開發的主要因素。先撇開國家文化與公司制度層面的問題，從『單兵（個人）』的角度來看，能否『傻的願意相信』這些方法是有用的，並且逐步加以落實才是困難之處。


Teddy 在『用 Robot 寫自動化功能測試到底有沒有用』提到，團隊前後花了超過一年的時間，才敢很大聲的以自身的經驗說出『用 Robot 寫自動化測試是有用滴』。這是因為團隊導入 Scrum 才可以獲得的成果嗎？並不是，因為使用 Robot 和採用何種開發流程並沒有直接的關係。還是因為 Teddy 很會寫 Robot ？也不是，因為 Teddy 根本沒有動手寫過任何一行 Robot test cases。這件事情能夠持續做下去，只有一個主要的原因：

• 開發人員傻的願意相信，持續的投入，研究，分享，並解決許多技術上的問題。

雖然一開始是 Teddy 建議團隊採用（Teddy 是經由指導教授告知而得知 Robot 這個工具），並且一開始嘗試在每個 sprint  中安排寫 Robot test cases 的時間，但是如果開發人員在嘗試之後給 Teddy 負面的回饋，這個活動可能執行個短短幾個 sprints 就被終止了。在採用 Robot 的過程中，團隊也遇到了許多技術上的問題，也都自行想辦法克服，這才是這項活動得以持續下去的原因。


同樣一件事，找不同的人來做，極可能會得到不同的結果，這個道理，相信鄉民們都懂。有了好的人，加上好的開發環境與開發方法（流程），這樣的順序開發起軟體才可達到事半功倍之效果。


最後只剩一個問題：好的人哪裡找啊....

***

友藏內獨白：The Design of Design 天瓏書局有在打折，要買要快。