大神教練來鈦坦，鈦坦人耳熟能詳的「coaching」到底在做些什麼？｜Part 1：PBR x SP2 x ATDD
乍暖還寒的三月初，甫過完一個 228 連假重回崗位，豹哥和其他小夥豹們身心都還正在緩緩收假之際，鈦坦科技高雄部門的某個團隊，竟把一間會議室借用了整整五天，除去休息時間的上班時段，所有團隊成員都全神貫注地在進行某個 item 的開發。
這群豹兄弟姊妹到底在忙些什麼？難道是有什麼緊急案件需要救火處理？！不過看著這些成員們每天走出會議室，都一副眼神發光心滿意足的樣子，又好像不是在處理什麼令人頭痛的麻煩事。
仔細一瞧，會議室裡除了原本部門內的小夥豹們，還有另一個熟悉的身影⋯⋯原來是 Joey Chen 江湖人稱「91」的知名業界教練又來到鈦坦了！
而會議室裡的這支團隊，本星期正在進行所謂的「coaching」，想瞭解是怎麼一回事？且讓哥為大家娓娓道來。
在鈦坦，coaching 代表的是與公司合作、具有豐富經驗的外部高手，特地來到公司團隊內部進行貼身教練指導，其中實打實、身經百戰的 91（官方網站）便是與鈦坦已經有多年合作經驗的技術教練。
每年都會數次造訪鈦坦不同的部門，在陪著團隊成員一起進行日常開發的過程中進行教育。憑藉過去大量的實戰經驗，91 的 coaching 有其特色，不只是在最基礎也最重要的開發知識與觀念方面，為團隊成員進行補強與調整。
在實務應用方面，每次都為團隊帶來能確實大幅提升效率的開發者技巧，在團隊所遭遇的實務難題上，則能夠有脈絡且循循善誘地引導團隊討論，做出有共識且合理的解決方案決策。
被指導的團隊最終都將對「寫出好維護的程式碼」以及「健康的團隊協作狀態」有更多的實際體驗與體悟，在開發者之路上再往上提升一個層次。稱每次的 coaching 都是一場教學盛宴兼團隊體質的健檢與治療，可說是一點也不為過。
豹哥本次特別參與 coaching 全程，為大家一揭鈦坦 coaching 的面紗，一起來瞧瞧高雄部門這次為期五天有教練伴隨的開發過程中，究竟發生了哪些事情！
事前準備
珍貴的教練時光一分一秒都不能浪費，因此在數週前得知 91 即將前來部門 coaching 之際，整個部門就已開始著手籌備，目的就是期望在 coaching 期間能夠排除所有阻力與瑣碎的雜務，與教練有最順暢的合作，將學習效能開到最大。本次部門所做的事前準備大致可分為以下幾項：
安排一位主要與 91 對口的 PIC（person in charge，負責人）
這件事看起來沒什麼，但其實有一位主要負責人是很重要的，他能確保部門與教練間的資訊同步有確實發生、做一些前期的安排、確保流通的訊息準確而不雜亂。
籌組與 91 合作的 virtual team
高雄部門現有三個團隊以 LeSS 的方式在運作，原先也有考慮是否直接在三團隊中挑一個團隊與 91 合作就好。但畢竟教練算是公司提供的珍貴學習資源，本次又是高雄部門首次以團隊 coaching 的型式進行教練，最終我們採用公開徵選的方式。
讓部門內有強烈意願，想藉由參與這樣高強度活動，得以深化開發技能的夥伴自由報名，再從中挑選適合人選組建此次的臨時團隊，這也是實踐了鈦坦核心價值之一的「坦率透明」。
在挑選人選時我們考量了職等、職能、團隊分布、先備技能 vim 的掌握程度等面向，最後組成一支來自三個團隊、成員職等範圍涵蓋最 junior 的 8 等到相對 senior 的 11 等、5 位開發人員加 1 位 ScrumMaster 的 virtual team。
一個團隊要能足夠敏捷，團隊人數是很重要的因素之一，Scrum 的建議是 7 加減 2 人，依據我們自身過去的經驗，5 至 6 人是溝通相對順暢的規模，因此本次團隊人數也就訂在這個數字。
值得一提的是，對於 vim 有額外的要求是因為在能夠熟練使用 vim 的前提下，與 91 的合作就能夠大幅減少無意義的冗餘操作，進一步讓單位時間發揮更大價值。
此 virtual team 的 6 位成員對於在 IDE 上操作 vim 都已有相當程度的掌握，有些人是曾參與過 91 的相關公開課程，有些人則是在部門中被 senior 訓練過而習得此技能，有人甚至是完全看著網路上的影片自學而成。
與 PO 溝通決定本次合作期間作為素材的 item
誠如上述，教練是珍貴的資源，自然不可能用這樣的資源來做過於簡單的 item，因為複雜的任務比起簡單的任務更有機會觸發團隊的 learning moment。
但也不能忘記只有一個 sprint 長度的時間限制，若做規模過於龐大的 item ，很有可能到 sprint 結束仍無法交付價值；同時 PO 本身對 product backlog 中，item 優先層級的安排也是必須考量的要素。作為合作素材的開發任務必須要恰到好處，這項準備工作的重要性不言可喻。
最後我們選擇一項在 product backlog 近期待辦範圍，且 PO 也期待能發揮其價值的 item，item 點數依據部門以 T-shirt size style 的評估標準是 L，白話來說是屬於偏難的任務，有些許未明之處但不至於難到太誇張。
此任務已可預期在實作上會橫跨三個專案，與前端 UI 相關，也會使用到資料庫既有內容，性質上算是個五臟俱全的項目。
事前調校開發環境，確保針對合作使用的 item 每個人都能順利地執行本機開發環境
部門掌管的專案在 GitLab 上多達 41 個，各專案都會因為不同團隊所處理的不同任務而有異動。virtual team 成員來自三個不同團隊，各自開發環境的專案狀態可能不盡相同。
因此在 coaching 開始前，我們特別安排一段時間來確保每位成員的專案狀態都是對齊一致的，也確保本機開發環境皆能夠正常地運作，以避免 coaching 過程中還要花時間調整環境。
同時因為可預期 coaching 過程中會大量使用快捷鍵，團隊成員們也各自再次確認自己的 IDE 和快捷鍵狀態都是正常運作的。
事前場地布置以及將所需材料到位
預想 coaching 時會採用 mob programming 的模式，因此調整會議室的桌椅安排，配置了一張桌子在投影機前，必要的延長線、計時器、白板筆、個人鍵盤、作筆記需要大量使用的便利貼、奇異筆等也都在開始之前準備到位，一切都是為了讓教練與團隊成員皆能有最順暢的 coaching 體驗。
Coaching D1
PBR 中的學習
在 91 到來的第一天早上，部門正好要進行的是 Scrum 的 PBR（產品待辦清單精煉會議）活動，在這種時刻，91 會變身為團隊運作的顧問在一旁觀察，必要的時候（通常就是看到問題的時候）給予指導。
在這場會議中，91 發現 PO 說明完需要請開發團隊們評估的項目後，該項目仍有許多不明確之處，但參與的團隊成員們並沒有多做詢問，他便以「作為外人不懂細節」為由，來不斷地以提問的方式去釐清表面需求背後的真正需求，同時也邀請在場自願的成員嘗試做總結，以創造當事人和聽者再一次釐清需求的機會，對於總結的當事人也是一種表達的訓練，是一個相當值得保留在部門中未來持續實踐的作法。
過程中 91 非常注重以實際的例子來說明抽象的需求，這也是 《Specification by Example》要求軟體開發人員必須有的素養，然而我們經常做得不夠到位，也因此經常會有我所理解的和你所理解的有落差這樣的狀況發生。
在不斷來來回回釐清需求的過程，有趣的化學效應發生了。參與會議的成員們，有些人開始提出一些想法，於是原本沒有被考慮到的公司政策限制、解決方案費用的考量、PO 心中既有的偏好解決方案等資訊一一被釣出來。
所以原本沒有人提問並非真的沒有問題，很可能只是當下的討論氛圍讓成員不太願意開口，又或者只是單純當下還沒有想到但聽到更多資訊後才聯想到新的想法，不論是何者，營造熱絡討論的氣氛讓更多資訊被拋出到公開場合，絕對是一件值得在 PBR 的環節中發生的事情。
91 有個值得一提的操作，在這種人多的場合有時發言者會待在自己既有的位置怯怯地說著自己的 idea，此時 91 會將當事者直接推到眾人面前，讓他能夠好好地把自己的想法闡述給所有人知道。這除了確保資訊正確傳遞，也是個對於講者相當好的慣性調整 — 既然有訊息要讓參與會議的人知道，那就該好好地、清楚地表明想法，哪怕是說錯了被糾正，對於整體團隊來說也是很有價值的資訊釐清。
結束了 PBR 的環節來到各小組分享 PBR 完的成果，PBR 中某一組的任務是針對一個規模相對大的項目，把它拆解成數個可行的小 item，最後結果是將它拆成了四個獨立的 item，分別對應於原始大項目流程中的不同階段。
這件事再度得到 91 的一次機會教育 — — 拆 item 不該是分部件去拆，而是要以 end to end 的思維去思考：最基本的正流程長什麼樣子？有沒有可能用最簡單的方法實現之以作為第一張 item，後續其它的 item 則是根據更多不同情境疊加上去的特例。
如此第一張 item 當然會顯得比較大，這是正常的，但這可以有效避免各部件被不同團隊負責卻進度不一所造成的對接問題，以及資源投不夠最後只做出毫無價值的半成品所帶來的沉沒成本浪費。
關於 end to end 的思維，91 還用披薩來做一個巧妙的比喻，切披薩的時候一定是從外往中心切，確保包含到外圈至內圈的所有餡料，這與 end to end item 的性質不謀而合。
其實很多被提點的事情是大家都曾經學過，心裡也知道的，但要堅持實踐卻又是另一回事了，有的時候也許迫於時間壓力、迫於人際風險而無法在第一時間採取正確的作為。教練的價值於此處也再次體現，因為他可以毫無顧忌地直指團隊的問題，作為一個公正第三方，以地圖炮的方式一次提醒所有人在工作上正確的姿勢應該是如何，對於未來要推行正確實踐的夥伴也算是一個有力的背書。
開始進入開發階段
PBR 後 virtual team 開始正式運作，所謂正式運作並非大家坐下來開始寫程式，在真正開始動手寫程式前，還要先針對這次的合作素材 item 開始進行 planning part2（簡稱 SP2）。
我們以往也都知道， SP2 應該要團隊所有人儘可能詳細地一起去釐清，具體要對專案的什麼部位做什麼改動並分拆 task，後續拿取 task 的夥伴才能在認知一致的情況下進行開發。
在 SP2 時， sequence diagram 便是一個我們常用的輔助工具，在 sequence diagram 上，團隊成員們能夠透過這個具體的圖，在動手寫程式碼前，共同預先對齊接下來即將發生的事情的認知，也可以預先把需要有共識的議題進行討論。
例如 API 端點名稱、新方法的簽章、新方法職責（哪個點會放置新邏輯、哪個點需要改動既有邏輯、重邏輯會發生在哪一個點、哪些點只是轉拋資料性質等），以及在這次開發中會產生的新檔案等等，這些都是開始實作前就可以先在這個時機點取得團隊共識的事情。
在這次 coaching 中的 SP2 有兩件事與過去不同，第一，91 為我們介紹除了 sequence diagram 的另一個 SP2 可以使用的工具，因為不確定正式的官方名稱，姑且依據其功能稱之為：系統互動圖 — — 把各個與此次新功能相關的專案系統、資料庫/表都畫出來，然後討論資料流在各種情境的路徑。
與 sequence diagram 不一樣，系統互動圖重視的是探討系統間的互動情境而非時序或是參數等細節，其實說穿不值錢，也不是什麼複雜的技巧，但這卻對於「情境」層面的聯想十分有用，能夠幫助團隊成員避免視野侷限在眼前的需求而忽略了既有的系統互動行為，造成開發上的疏漏。
第二件與過去不同的事情，是 91 在帶著團隊拆 task 的時候，依然秉持著 end to end 的思維來引導成員們寫下以邊界到邊界為 scope 的 task。
過往，從系統 A 進入的起點到離開的終點準備去往系統 B，如果會經過兩三層，我們可能就會因此開出兩三張獨立的 task，而這些獨立的 task 可能就由不同的 pair 去進行開發。拆 task 不是問題，把一條 end to end 上的任務分散做，問題比較大。這種拆分部件獨立開發的方式，始終會遇到的就是整合的問題，就好像從隧道的兩端各自開始鋪鐵軌，結果到了對接的時候才發現歪掉對不上，又得耗費一次溝通和修改的成本來導正，這種狀況時有所聞。
若所有人能夠先一起把對接的接點（例如：前端到後端、專案跨專案）核對過並共同完成（使用 mob programming 會是個好主意！），回頭再分 pair 各自補中間流程的內容，便可以減少延遲對接所帶來的風險。
item 起頭的技術決策：server side prepare V.S. click and AJAX
因為團隊有共識要共同以 end to end 的方式推進進度，所以所有人面臨的第一個議題就是，我們這次關於前端畫面要獲取的一項數值，應該要在畫面 render 出來的時候就先由 server side 準備好，還是要在使用者點擊後才發 AJAX 取得資料？
這一段在團隊中形成了一次的討論，過去的慣性是在 view model 中夾帶數值到前端畫面，因此也就是 server side prepare，但這次要實現的功能對於使用者來說其實並非絕對必要的資訊，因此讓使用者需要該數值且真正觸發相關事件後再打 API 拿資料，似乎也是相當合理的作法。
過程也討論到了，雖然如此會對使用者造成些微延遲的感受，但考量該數值並非該頁面核心流程的必要環節，因此在這一步做退讓是值得的，因為若採用另一面的做法，就代表要為「所有」來到此頁面的使用者都先在 server side 獲取該數值，然而該數值背後也是透過再往外打 API 獲取。
而已知該 API 是運算成本較高的，這帶來的結果就是，即便一名不在乎該數值的使用者，也必然要付出昂貴的運算成本。
91 在這之中扮演了建議、提出顧慮，以及依據自身經驗回答團隊成員提問的角色，其並非主導整場討論，整場討論仍是由團隊主責進行。作為教練，他也讓團隊成員知道技術決策大都沒有絕對的對錯，只有在什麼場合較適合採用哪一種方案的分別，不同的作法都可以達到相同的結果，端看團隊決定要承受什麼樣的代價。
這一段理性又有脈絡的分析經驗，除了讓 junior 對於在做出設計決策時應考量的面向有更多的認識，也幫助 senior 學習未來應如何在團隊內引導類似的討論。
今後的 coaching 中還有其他的決策討論，值得分享的案例也將在接下來的內容一一揭露。
所謂的 end to end 推進，本質上也是一種 TDD，因為是從畫面上實行真正使用者的行為來逐步長出相關功能，因此這被叫做 ATDD（Acceptance Test-Driven Development，驗收測試驅動開發）。
在 ATDD 的過程，團隊成員很快就遇到 end point 相關設定錯誤、controller 父類的錯誤處理行為不如預期等，這類在 run time 才能發掘到的問題並及早解決。
一般 run time 的問題在 unit test 的 TDD 中是很難在早期發現的，這也再次說明系統的品質並非僅靠 unit test，有許多開發上可以使用的方式都是提升開發品質的手段，ATDD 如是，mob programming 如是，code review 亦如是。
值得一提的是，在 ATDD 的過程中，其實也跟寫 unit test 做一般 TDD 的方式一樣，會頻繁地使用 hard coded 來驗證路是否有打通，取得 hard coded 的數值後（測試通過），把原本 hard coded 的部分改為向後層取值的實際作法。
而因為後層尚未實作，測試會再度失敗，這時再把原本 hard coded 的內容補在後層，測試又通過了。如此反覆循環，也就是一小步一小步地推進，讓新功能有條不紊地一點一點萌生出來。這樣的開發風格，讓開發者每一刻都知道自己在做什麼、每一動的結果都可預測，每一步都走得紮實。
第一天實際上沒有寫到什麼程式碼，因為在 SP2 投入相當多的時間討論與釐清，其中包含本次功能最關鍵的核心演算法應如何運作，團隊成員們代入各種可以想像得到的情境來做驗證。
91 作為外部指導教練，一開始並不熟悉部門產品的相關領域知識，但也在不斷釐清的過程中跟著大家一起榨乾腦力，為了實現過去不曾需要的罕見需求，還協助團隊查找各種可能可用的套件（ChatGPT 也被搬出來輔助查找了）。
也就是這種總是與團隊一起戰鬥的教練方式，造就 91 作為教練的魅力，儘管只是提案也總能讓團隊願意一試，即便第一天就一路工作到 19:30，團隊成員們也依然甘之如飴，期待著隔日開發的重頭戲。
作為軟體工程師，其實接到需求就埋頭下去寫程式碼實現，對我們來說是最簡單也最符合本能的。然而，生活和工作上，只跟著本能做最直覺的事情，不見得總能為自己和團隊帶來成長和利益，更多時候其實是吃著老本原地踏步，在團隊或部門層級甚至可能因為誤解了期待而造成資源浪費。
在 coaching 過程，有許多教導都違反著我們過去的經驗所養成的直覺，有些事情是「過去不知道可以這麼做」，所以沒有養成好的直覺，而有的事情「本身就是一種鍛鍊」，因為練習得還不夠所以還沒變成直覺，需要強迫自己透過持續實踐它來進行鍛鍊。
接下來的幾天開發也都時有類似的情況發生，讓我們繼續看下去。
延伸閱讀
大神教練來鈦坦，鈦坦人耳熟能詳的「coaching」到底在做些什麼？｜Part 2：Dev Do & Don’t（團隊篇）
大神教練來鈦坦，鈦坦人耳熟能詳的「coaching」到底在做些什麼？｜Part 2：Dev Do & Don’t（開發篇）
📢【鈦坦熱烈徵才中】
在鈦坦沒有Boss，但要有自組織的Guts ❗❗
想要投入 #彈性工時 #自主升遷 #薪資透明 的工作文化 ❓ 還有～～豐富的內外訓教育課程隨你申請、專為敏捷團隊設計的開放式辦公空間、上班隨時前往酒吧暢飲放鬆一下…
🙋♂️ 職缺看這邊～
👉 https://gotica.io/鈦坦職缺/Blog
