重讀舊書有感：Debugging The Development Process

May 28 10:43~12:11

十幾年前Teddy剛剛脫離那種「單兵作業（一人開發軟體）」模式，開始學著如何帶領一個6-7人的小團隊一起開發軟體。如果是現在，Teddy當然知道可以讓團隊採用Scrum以及各種敏捷實務做法來開發軟體。很不幸的，當年開始做專案的時候完全沒有聽過這些東西。不過在那個年代Teddy的確也讀到幾本不錯的書，某種程度影響了Teddy對於軟體應該如何開發的「信仰」。

《Debugging The Development Process》就是其中的一本好書，Teddy手邊這一本是由當年紅極一時的「華彩軟體（已經倒閉）」所發行的中文版，中文書名叫做《微軟研發致勝策略》（感覺好像電影的命名方法，英文片名和中文片名完全連不起來…XD）。這本書的中文定價才240台幣，真的好便宜啊。Teddy記得當時華彩好像發行了2-3本類似的書，除了《微軟研發致勝策略》以外，Teddy手邊還找的到的有一本《微軟專案求生手冊》，英文書名是《Software Project Survival Guide》，這本留待以後有機會再談。

上個週末因為某個原因Teddy必須要把《微軟研發致勝策略》這本書拿出來翻看一番，此時赫然發現，其實書中很多觀念跟廣義的敏捷方法，或是Scrum與XP的精神都很雷同。其實這也沒什麼好大驚小怪的，古人早就有說：「英雄所見略同」不是嗎。本書的內容先不管他，直接看到封底的文字敘述，標題就是Teddy最喜歡的：

您了解如何讓研發專案如期完成，且不需要加班嗎？

根據封底的介紹，這本書要告訴讀者：

• 如何增進團隊工作效率，且讓每個人都樂在其中。
• 為什麼你會想把超級程式設計師趕走算了。
• 如何避免落入行政程序的天羅地網。
• 有那些小小的改變，可以換取極大的獲益。
• 不必加班就可以如期完成軟體的秘訣。（讀完這本書之後Teddy好像只記得這一點啊…XD）
• 如何讓所有的工作都價值加倍。
• 如何讓團隊保持鮮活的創造力。
• 如何提升程式設計師的整體技術水平。

奇怪，現在回頭一想，當年Teddy讀完這本書的時候，好像沒有學到那麼多耶…Orz。應該是當時功力還不夠，所以無法全部吸收。總之，上面這八個問題，相信時至今日還是很多軟體開發團隊想要追求的目標。如果鄉民們身為專案團隊領導者，有沒有想過，自己所帶領的團隊，上面這八個問題可以做到幾點呢？或者換個方式來問，如果鄉民們有在導入Scrum，那麼上面這八個問題，目前已經被解決了幾個？剩下沒有辦法解決的原因在那裡？這些尚未解決的問題就是未來可以改善的目標。

翻開這本書，挑幾個Teddy當初有畫重點的地方。第4頁：

領導者的任務是努力消除程式設計師工作上的一切障礙，讓程式設計師全力專注在真正重要的工作---改善產品。

還好現在有專職的Scrum Master可以做這件事。什麼，你們的Scrum Master都在寫程式！這樣不行啦，趕快來報名http://www.accupass.com/go/ezscrumcourse201206這Scrum課程吧…XD（迷之音：這就是所謂的置入性行銷嗎？）。

所以，主管沒事不要一直找工程師來開會。會議能不開就不開，真的要開的話也要跟女生的迷你裙一樣，越短越好。不該有的會議與報告最好全部廢除。還有，不要一直因為一些小事去中斷工程師手邊正在進行的工作。

第18頁：

明確的目標之所以帶來效率，正是由於它能幫助你擋掉別的專案丟過來不相干的垃圾，讓你專注在本專案的策略性事項。…組員的努力應該有代價，而長期加班、飽受壓力的小組，多半是工作漫無目標的後果。

很可惜，很多老闆、業務、行銷、產品經理、專案經理都不知道專案的目標是什麼。

產品經理：誰說我不知道，專案目標就是要拍老闆的馬屁啊。錯，應該說生活的目的，在於拍好老闆的馬屁。生命的意義，在於讓在其他人失去工作的動力。

Teddy：又是一隻「牠」。

第44頁。

要求程式設計師一發現bug就立即清除。

看到這一點Teddy知道有人在偷笑了。「哈哈，如果這一點做得到，那手邊的專案就不會累積數十到上百個bugs了」。

直接跳到第127頁。

不要讓程式設計師的學習停滯不前，要讓程式設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。

所以Teddy才會經常建議團隊除了要組成cross-functional team以外，還要採用pair programming與shared code這兩個practices。

最後一點，第181-182頁。

別誤信加班等於增加生產力，長期加班只會傷害生產力，對專案沒有幫助。成功的人不都是拼命工作的嗎？…有更多人的人日以繼夜工作卻一事無成，只是我們部會津津樂道他們的故事。批命工作並不是成功的關鍵，成功的關鍵是有一個明確的目標、具體且切合實際的計畫，以及每天不斷向這個目標邁進。

***

看了這本書對於作者Steve Maguire的介紹，說：「在過去十九年中，Maguire一直在美國和日本從事專業的程式設計工作」。嗯…日本…難道有學到Toyota生產管理那一套嗎？Teddy猜測Steve Maguire書中提到的作法應該不是那個年代微軟公司內部主流的開發方法。不過經過10幾年後再往回看，本書提到的大多數做法（不是全部，其中有一些Teddy覺得有點過時。例如，deadline到了但是產品品質不夠好，就把deadline延期）到今日不只是依然適用，而是成為軟體開發的主流做法…嗯嗯，至少看起來在國外是如此，至於台灣，落後國外何止十年啊。

***

友藏內心獨白：公司裡面有太多牠，怎麼可能搞好軟體。