l

2010年5月4日 星期二

Retrospective Meeting 之我謝謝你

05/04 22:49~23:55

10 幾年前 Teddy 退伍後出社會的第一份工作,就是到一個小公司寫程式。Teddy 是該公司第一位 programmer,後來公司陸陸續續招募了好幾位剛畢業的新人,原本是希望大家共同開發一個產品,但是公司為了生存下去,在不知不覺中接了好幾個性質各不相同的案子,導致每個人手邊都有一件以上的案子要負責。由於各自的工作都忙不過來了,因此大家都是各做各的,鮮少有團隊合作的氣氛。Teddy 還因此做過可能是台灣第一個以 Java 開發並且實際使用的『進銷存系統』,用 VB 做過『支援 one-to-one marketing』的洗衣店系統,還有一些奇奇怪怪的東西。當時 Teddy 做的累的要死,而 Teddy 的主管與公司的顧問一直灌輸 Teddy 一個觀念,『一個人負責很多案子在業界是很平常滴』,因此 Teddy 心中一直有兩個疑問:

  • 難道 Teddy 真的這麼遜嗎?為什麼案子會做的這麼累而 bugs 卻又這麼多?客戶一直要求要改東改西的,而 Teddy 只能無奈的接受?
  • 軟體開發真的是這樣嗎?一個人同時負責好幾的案子是很平常滴? Teddy 覺的就算是一個人負責一個軟體開發的案子也是一件很困難的工作,從需求訪談,寫分析文件,coding,測試 (當時還沒有什麼自動化單元測試的概念,都是人工手動測試),製作安裝程式,寫手冊,教育訓練,甚至包含要幫戶客買硬體設備,裝機,還有更慘的『後續維護』等等。

經過 N 年之後,對於軟體開發流程的知識 Teddy 已經有了更深入的了解,因此 Teddy 天真的以為大家都知道『軟體開發是一種團隊活動』錯,Teddy 大錯特錯。在台灣,很多軟體還是由一個人完成。有些軟體雖然可能有好幾個人共同開發,但是專案切分成幾個子專案,每個人認領一些模組,自己做自己的那一份工作,結果還是走回『分工,但不合作』的老路子。

不知道是不是因為大家從小為了分數競爭慣了,養成了『藏私』與『獨立作業』的習性。這樣的個性或是做事態度,對於要採用 agile methods 的開發團隊而言,是一大挑戰,也是造成導入 agile methods 失敗的主要原因之一。要如何『根治』這個問題,Teddy 也不知道,不過有一個『小撇步』對於採用 Scrum 的團隊可以參考一下,就是在 retrospective meeting 的時候實施一個『感謝 某某某』的活動。


這個方法是 Teddy 從 Agile Retrospectives: Making Good Teams Great 這本書學來的,作法很簡單,就是在 retrospective meeting 的時候,請每個團隊成員輪流感謝在這個 sprint 當中幫助他的其他團隊成員,例如:

小胖:我要感謝『小明』,在和他 pair programming 的時候他教我如何在 Eclipse 中使用 refactoring 工具。

小英:我要感謝『阿呆』,他在測試的時候找到好幾個我程式裡面的 bugs,讓我可以把功能做對。


阿呆:我要感謝『小英』,當我找到 bugs 的時候,她很快就把這些 bugs 修正了,讓我可以繼續測試下去。


小明:我也要感謝『小英』,他告訴我要如何修改持續整合系統的 ant script,讓我可以把新增加的模組放到持續整合系統上面。

小胖:我要感謝 ...


就這樣繞一圈一直感謝下去,如果團隊成員沒有對象可以感謝了,那就說 pass,一直到所有的人都 pass 為止。以 Teddy 的經驗,通常繞個三圈左右就差不多大家都 pass 了,所以這個活動只需要短短幾分鐘的時間 。當聽到別人公開的感謝你的時候,心情總是會比較愉快一點。就算在開發時有些不爽的情緒,也會因此慢慢氣消。此外這個活動還會有一種很奇妙的正面效果,讓團隊成員在之後的 sprint 中更願意幫助其他團隊成員 (因為如果你從頭到尾都沒有被別人感謝到,這樣會覺得自己挺遜的...XD)

Teddy 覺的這是一個 C/P 值頗高的活動,有興趣的鄉民不妨一試。

友藏內心獨白:說感激,說不完的感激... (用唱的)

2 則留言:

  1. Agile Retrospectives 是本好書,入面很多技巧值得學習,我想你也在這方面學習了很多。 :)

    回覆刪除
  2. To Steven:

    謝謝賞光,沒想到您也有空來看小弟的部落格。文中經常出現『台式中文』尚請見諒。

    回覆刪除