l

2015年3月23日 星期一

你願意花更多時間和這個團隊一起工作嗎?

March 18 20:40~21:30

螢幕截圖 2015-03-18 21.22.32

Eiffel:你願意花更多時間跟我一起玩嗎?

Teddy:我願意 XD。


剛創立泰迪軟體的哪一年,有一次和一位認識多年的朋友聊起Scrum。朋友覺得Scrum沒什麼特別,因為當初他創業的時候,核心團隊成員的工作模式,就和Scrum一樣。整個公司上上下下就是一個自我管理團隊,大家快速回應客戶需求,得到回饋之後快速修正。

聽了朋友的描述,Teddy當下心中頗不以為然。你根本不了解Scrum啊,就在那裏大放厥詞。幾年過去了,現在回想起來,Teddy反倒是有點贊同朋友的說法。

一件事情的成功,不必然和方法有絕對的關係。如同模式(pattern)的定義:

A pattern is a proven solution to a recurring problem in a specific context.

 

不管這個「成功模式」是什麼,叫Scrum也好,叫「血汗工廠」也罷,總是在一個特定情境(a specific context),針對一再重複出現的問題(recurring problem)所提出行之有效的解決方案(proven solution)。朋友覺得Scrum的若干做法,具有他當時創業精神的若干特質(quality),所以他覺得Scrum沒什麼特別。從某個角度來看,的確如此。只要團隊成員持續學習、改善,不怕失敗,能夠從失敗中學習,具有這類quality,比宣稱自己在做Agile或Scrum,還要來的重要。

***

Alexander提出的觀念:Quality Without A Name(請參考〈這就是無名特質〉),只要用心體會、認真生活,當一個環境、建築物、社群、團隊或軟體系統,具備或缺乏好的特質,人都有能力能夠發現。在導入Scrum的時候,一開始團隊會先學著doing Scrum,把Scrum要求的角色、活動、產出物逐一「生出來」(「守」的階段)。依據團隊組成不同與專案特性,這段「守」的期間至少需要半年到一年。在與Scrum框架變成好朋友之後,慢慢有能力可以依據不同的狀況,來調整Scrum。例如,Daily Scrum一定每天都開嗎?Sprint Backlog Item一定不能異動嗎?是否一定要估算?PO、ScrumMaster、Team之前的溝通模式一定要那麼制式嗎?能不能在Taskboard上面加一個緊急通道呢?(「破」的階段)。

最後,鄉民們可能會發現,一開始Scrum是一頂好的「帽子」。但如果死守這頂「帽子」,最終它可能成為「頸箍咒」,反倒限制了團隊採用其他工具的彈性。也許這時候就是「離」的時機。

***

看到這裡鄉民們可能會問:「什麼是好的軟體開發團隊的quality呢?」這個問題可以用一個很簡單的問句來判斷:

你願意花更多時間和這個團隊一起工作嗎?

答案越肯定,這個團隊就具有更多好的quality。

***

友藏內心獨白:還是太抽象…Orz。

1 則留言: