當一個需求，經過規畫系統的一連串洗禮後，就準備進入開發。對團隊而言，工程實踐方法，只有最適合，沒有最好。因此，在本篇中，我不探討程式架構、雲端架構或是 CI/CD 這些根據應用場景不同，就可能有不同的實踐方式的技術細節。我們來聊聊，在 Scrum 的日常開發中，團隊協作上可能會導至系統性問題的坑點。

冗長的站立會議

我曾經在前公司看過最誇張的站立會議，開了快一小時。我相信，大家絕對不是站在原地閒聊，而是很認真的在討論問題。值得思考的題目是，問題的範圍，是否需要整個團隊一起討論？如果是，表示 Refinement 沒做到位；如果不是，表示有些成員的時間被浪費了。

站立會議的內容，依據團隊不同，可以自由演化，但我認為，再大的團隊，站立會議，都不該超過 15 分鐘。更重要的是，成員必須要主動的提出需要團隊支援的問題，在站立會議上，找到正確的資源，在會後進行「跟進討論」(Follow-up Discussion)。

避免過度依賴規則

某次檢討會議 ( Retrospective )，大家熱烈的討論一個狀況：前端因為不知道後端的 API 何時可以準備好，所以無法準時交付。經過一輪熱烈且秏時的討論，團隊表決出一個結論：日後後端 API 必須在 Sprint 開始後的第 x 天，將 API 交給前端，如果發生 xx 情況，則要做 xx 調整。事後我看到這個結論，很顯然，大家努力錯了方向。

我提醒大家：「有什麼比轉身過去問一下夥伴更敏捷呢？站立會議中提出來迅速交換情報，不會比記一堆規則簡單嗎？」

「腦力密集人才的管理之道」（Peopleware) 中提到，太多的 SOP，會讓系統失去自我修復的能力。團隊系統也是同樣的道理，停止訂規則，開始對話吧。

過度依賴 QA

在有 QA 編制的團隊，偶爾會觀察到一個現像：大家把品質議題全權委託給 QA。交付符合驗收標準的的程式，是工程師的責任；QA 應該負責的對象，是產品，是消費者。 RD 該吐掉奶嘴，自己為自己的程式把關。對自己的創作都無法負責的成員，主管應該好好思考，是否合適留在團隊中。

主管變成保姆

有些新手主管覺得要充份掌握成員的狀況才有安全感，但這樣成員會過度依賴主管的關心。相信自己的團隊，把狀況、進度回報的責任交回給成員。當責與習慣的養成需要時間，不必過度擔心是否會有打混摸魚的情況，海水總有退的一天，沒穿褲子的人總就會被發現。

本篇介紹了在開發過程中，團隊系統應該關注的原則。一個 Sprint 的生命週期：Planning - 開發 - 檢討。明天，來聊聊我認為最難開但也最有價值的-回顧會議 (Retrospective)。