March 18 20:40~21:30
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。
