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 值頗高的活動，有興趣的鄉民不妨一試。
友藏內心獨白：說感激，說不完的感激... (用唱的)
Agile Retrospectives 是本好書，入面很多技巧值得學習，我想你也在這方面學習了很多。 :)
回覆刪除To Steven:
回覆刪除謝謝賞光，沒想到您也有空來看小弟的部落格。文中經常出現『台式中文』尚請見諒。