l

2012年5月28日 星期一

重讀舊書有感:Debugging The Development Process

May 28 10:43~12:11

image

十幾年前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延期)到今日不只是依然適用,而是成為軟體開發的主流做法…嗯嗯,至少看起來在國外是如此,至於台灣,落後國外何止十年啊。

***

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

2 則留言:

  1. 問題是大部分的老闆都不讀書的@@

    回覆刪除
  2. 這兩本書我也有買,後來就不想浪費錢買這種書了,因為該看的人根本就不會看,還是一樣想怎麼蠻幹就怎麼蠻幹

    回覆刪除