大神教練來鈦坦，鈦坦人耳熟能詳的「coaching」到底在做些什麼？｜Part 2：Dev Do & Don’t（團隊篇）
承接前一篇文章《大神教練來鈦坦，鈦坦人耳熟能詳的「coaching」到底在做些什麼？｜Part 1：PBR x SP2 x ATDD》，在 virtual team 本次 sprint 的第一天當中，一部份的時間花在 PBR，剩下時間一大部分用在 SP2 釐清需求，實際開始寫 code 沒多久就來到下班時間了。
豹哥在 Part 2 文章將側重於 coaching 的第二天至第四天之間，91 所帶來的各種機會教育，以及決策討論的過程之紀實，讓各位看官品味品味。
Part 2 文章依性質拆分，分為與團隊運作相關、無程式碼的本篇，以及開發篇，在本篇文章，哥將分享一些團隊運作或決策上，團隊在 coaching 期間收到的建議。
Do：重新思考 daily Scrum 的本質
Do or Don’t：有新需求就加欄位、加表？且慢…
Do：pair programming 真的有比較慢嗎？
Coaching D2-D4
Do：重新思考 daily Scrum 的本質
在組成 virtual team 之際，大夥兒便已有共識要讓它在運作上與一般 team 無異，如此才能最真實地呈現我們日常的開發習慣，以好好地被 調教 調整。
第二天的序幕，就和日常一樣是從 daily Scrum 的會議開始 — — 大家站在白板前，看著前一天已列出貼在 sequence diagram 上的 task，並將需要同步給其他人的資訊更新給在場眾人。
例如，前一天最困擾人的那個「依據不同情況，以不同方式和不同資料來源來取得新功能數值」的關鍵演算法，似乎有了新的進度。
一般 Scrum team 在 daily Scrum meeting（以下將簡稱為 daily）的時候，最常聽到要遵循的就是 15 分鐘以及三個問題的原則（可參閱《Scrum Primer》），但團隊在實際操作起來經常會被這個教條所綑綁，甚至可能會有團隊成員認為其他成員在 daily 時講述的內容不符規則，而強勢阻止其發言的情況發生。
學習新知和導入新規範時，守破離的「守」固然很重要，但以 Scrum 想要實踐的敏捷文化而言，若為了死守教條而扼殺團隊成員揭露資訊的意願，那反而是本末倒置，也違背了敏捷的精神。
在 coaching 期間的第一次 daily 時，有團隊成員向 91 請益這種狀況，91 秉持的態度是：團隊成員願意發言都是很好的，應持鼓勵態度，只是需要注意時間控管，團隊也要能逐漸意識到哪些事情適合會後詳談，但原則上只要團隊成員有發言意願，仍是好過有話不說。
Do or Don’t：有新需求就加欄位、加表？且慢…
在 daily 後正式開始開發之前，大夥兒就前一天的演算法再做了一番討論，這時候團隊對 91 提出一個問題：「這次的需求，可能是可以透過加資料庫欄位或是資料表就簡單地解決的，但他會選擇這麼做嗎？選擇做或不做的考量又會是什麼？」
會有這個提問是因為團隊在日常開發中，也經常會面臨這樣的兩難抉擇，要嘛就現有的資料進行相對複雜的處理，要嘛另闢新的欄位或資料表作為滿足新需求的新手段。
91 在這方面並沒有特別的偏好，反而是提醒我們思考，加欄位或加表其實就是一種 index 的概念，也就是用空間換取時間，這會提升查詢相關功能的效率，但同時會增加新增、修改動作的成本，當然，維護程式碼和資料庫的成本以及團隊知識傳遞的成本也一併增加了，這個新的欄位或表⋯⋯
- 有沒有可能造成後人的困惑？
- 如果加了額外的欄位或資料表，是不是會需要把現有的多處相關資料寫入、更新的發動點都修改程式碼去寫入額外的資料？這可能會是個風險。
- 這麼做是否可以徹底地滿足新需求所缺乏的重要資訊，或僅是針對個案而未來有其他類似新需求又要繼續往後添加欄位？
- 我們的應用上是查詢的發生頻率較高，或是新增修改的頻率較高？
這個決策問題一樣沒有標準答案，端看團隊所面對的狀況而定。而團隊討論後，認為這次的需求對應的是新增、修改頻率很高的情境，查詢情境中最麻煩的邏輯運算也不太能透過新欄位輕鬆避開，此外當下也沒有較適合的表可以拿來加欄位使用，因此決定還是在應用程式後端對現有可用的資料作處理以完成此需求。
Do：pair programming 真的有比較慢嗎？
來到實際上機開發的階段，團隊與 91 依然採用的是 mob programming 的方式進行，過程中大家會依序輪流當 navigator & driver 以進行 pair programming，其餘人則看著投影幕上的開發內容，任何時候都可以給予建議，並且以 time timer 作為 timebox 的輔助工具，作為換手的提醒。
在 mob 過程中有 navigator 是很不錯的實踐，因為對於 driver 來說，外部的雜音太多了，mob 的群眾經常會情不自禁地給予各種建議，此時有一位 navigator 作為單一指令窗口，可以減少 driver 的認知負擔，這也是未來團隊中實行 mob 可以參考的部分。
不論是單一 pair 或是 mob programming，都會讓人有一種開發速度變慢的感覺，畢竟看起來是 2 個人或是 n 個人做同一份工。這個觀點對，但也不對。
的確，與純開發相比，這麼做是比較慢的，但若考量到「有品質地交付」，在程式碼整合時所有人一起 review、討論更好的設計方案、確保程式碼語意通順、確保沒有技術債（或讓所有人都知道技術債發生了），這不是本來就該付出的時間嗎？
mob programming 只是讓這些時機點在開發的第一時間發生，同時也讓開發過程中討論所產生的知識渲染到整個團隊。長遠來說，這不但不是一種浪費，比起大家各做各的事後再刻意安排時間把人們召集起來進行整合（更常見的是整合時遇到問題才去找當事人，或是「自以為」沒問題），這可能是更健康的作法。
看得還不過癮嗎？coaching 期間值得分享的主題當然不只這些！
豹哥誠心推薦對於技術實踐有興趣的讀者們，看完這篇文章後繼續前往下一篇《大神教練來鈦坦，鈦坦人都耳熟能詳的「coaching」到底在做些什麼？｜Part 2：Dev Do & Don’t（開發篇）》，來一睹 91 在 coaching 期間為團隊成員們帶來了什麼有趣的技術衝擊體驗！
延伸閱讀
📢【鈦坦熱烈徵才中】
在鈦坦沒有Boss，但要有自組織的Guts ❗❗
想要投入 #彈性工時 #自主升遷 #薪資透明 的工作文化 ❓ 還有～～豐富的內外訓教育課程隨你申請、專為敏捷團隊設計的開放式辦公空間、上班隨時前往酒吧暢飲放鬆一下…
🙋♂️ 職缺看這邊～
👉 https://gotica.io/鈦坦職缺/Blog
