August 21 18:15~19:01
前言
Teddy跟著ezKanban團隊兩年的時間，帶著幾位北科資工研究生開發ezKanban系統。當初是以DDD與Clean Architecture為研究主題當作切入點，這兩年來雖然有點進度，但軟體本身卻還沒達到Teddy認為可釋出的標準。
這個兩年的lead time真的有點長，今年七月初放暑假時，Teddy決定利用暑假時間和ezKanban團隊採用remote mobbing的方式一起開發。學生在學校實驗室，Teddy在家裡，透過Skype分享桌面的方式開發ezKanban，一個多月下來頗有進展。
***
幾個禮拜前在Amazon亂買書，買了一本《Team Topologies: Organizing Business and Technology Teams for Fast Flow》，有一天晚上睡不著翻了一下，沒想到還挺有趣的。書中提到四種團隊型態以及三種互動模式，特別適合軟體開發公司。今天用Teddy這兩年來和ezKanban團隊的合作模式，解釋書中提到的三種互動模式。
***
X-as-a-Service
將另一個團隊視為一種服務來使用，團隊之間只有最少的協作。這種情況發生在學生遇到問題詢問Teddy的時候，此時Teddy-as-a-Service，提供學生某種解答，這個過程中雙方並沒有很多協作關係。
***
Facilitating
協助另一個團隊釐清阻礙，這種情況發生在兩周一次的sprint review。Teddy會看學生的設計與程式碼，觀察有沒有什麼設計問題是學生沒有看出來的，並與他們討論並訂定後續修正計畫。下個sprint review會繼續相同步驟，經過迭代的過層，系統設計品質越來越好。
但是，因為兩周review一次兩小時，說真的能夠看到的程式碼真的不多，因此每個迭代的增量幅度相對來講就比較有限。另外一個問題是，因為學生還在學習的過程，很多Teddy沒有看到的地方，雖然程式可以動，但設計通常都存在一些大大小小的問題，長期而言阻礙系統的可維護性。
***
Collaboration
兩個團隊彼此緊密合作。在今年暑假之前，Teddy和ezKanban團隊的關係幾乎不存在Collaboration（協作）。之前也幾度思考過是不是跟學生一起寫程式，但又擔心如此一來學生偷懶，過於依賴Teddy，搞到後來變成Teddy幫他們做碩士論文研究 Orz，因此就作罷。
但隨著ezKanban慢慢成形，但又無法達到Teddy心中的釋出要求，有種恨鐵不成鋼的遺憾。幾經思考，加上今年因為因為疫情的緣故，泰迪軟體生意比較清淡，Teddy空閒時間也比較多，因此決定「撩落去」，利用暑假時間一起合作開發。
***
成本不同
這三種互動模式，適合解決的問題不同，成本也不同。對Teddy而言，開發軟體如果可以和團隊緊密合作當然是效果最好的。畢竟Teddy也比學生多活了20幾年，還是比他們更能夠看出設計不合適之處。
除了學生獲益，Teddy也從這個過程中獲得很多design bad smells的寶貴範例，平常可能想破頭都不一定生的出來這些例子。這是一個雙方都互相學習的過程。
很多時候，想要成事，還是需要走到前線，親自動手。
***
友藏內心獨白：If you stop coding, you stop learning, by Kent Beck.
