最近有朋友問我 Scrum 裡有一條 Long live team 的定義，到底要把一群人放在一起多久才算 Long live team ? 一週？一個月？一季？一年？ 還是就是說不清楚反正 As long as possible？我們來公司又不是來交朋友的，當『階段性』任務完成就應該重新調整，讓公司資源分配最有效率最大化啊？我的認知是用多長的時間來衡量 Long Live Team 是一個假命題，重點這一群人是否一起『走過完整產品生命周期』
軟體生命週期
就像玩股票沒有完整走過牛熊週期，你不能稱上一位資深的投資人，一個開發 team 沒有完整走過開發到上線維運，甚至上線後還有在空中換引擎的完整週期也不能稱之為 Long live team 。
就像這篇文章『 Why do you need long-lived teams? 』所列舉的
1. 團隊的磨合度
做任何事都都事需要花費溝通成本，當團隊培養到一定的默契，就能大大降低溝通成本，可以互相背靠背的支持對方，只靠一個眼神就知道對方想表達什麼，code review 只需要提點一下馬上就知道要怎麼改比較好。另外一個好處就是估算時間和點數也都有共同的基準和默契，根據過去合作經驗與預估，PO 就能很容易判斷這些 feature 團隊何時能交付上線。
2. 服務客戶所累積的 know-how
團隊成員真的累積足夠的知識了解客戶的痛點在哪裡嗎？以及客戶最常用和最不喜歡的功能是哪些嗎？可以提出讓客戶掏錢要你解決的問題嗎？
3. 累積足夠的 domain knowledge
工程師要的不是成為碼農，每天只負責照著 Spec 打字，年復一年重複寫出一堆 CRUD 的 code ，而是要能累積解決這個領域問題的能力深度。舉例來說到底 DRM 造成不能播放是哪個環節出問題，機器大量轉檔卡住了或是甚麼原因造成的，這就需要對團隊的 code ，系統架構都要有足夠的瞭解和認識，最近彼此互相改了什麼？東西可能放在哪裡？過去是不是有哪些 known issue？這個 workaround 是為了解決什麼商業上的問題？
4. 了解該找誰幫忙
Scrum team 也不是要大家都變成全才，每個人都還是有他的專長，大家都知道誰對什麼最了解，如果發生那方面的問題應該要找誰請教，誰之前處理過類似的問題？而不是遇到問題大家都徬徨無助或焦頭爛額的到處尋找問題所在，這時後老司機就有他的價值...
上面講這些都是為了要減少 context switch 的成本，因為每一次切換產品和領域就是一次的 reset ，再怎麼資深和有經驗的人都需要暖機時間，任何的轉換也都應該跟當事人溝通，人不是零件和螺絲。
Ownership
最後最重要的就是增加 Ownership ，大家都知道 Ownership 很重要，那到底該怎麼培養呢？一個你從頭到尾打造維運的系統，你的熟悉程度和責任感就會像照顧你的小孩一樣，你知道他的毛在哪裡，該怎麼教訓他 🤣 。
此外如果你還要維運，你就會痛，痛過就會知道，就知道要 code 要寫好，品質要好一點，workaround 要少一點，要更容易 debug 和維運....
如果常常被調來調去，或是到處當救火隊，最後就會變成我達達的馬蹄是美麗的錯誤我不是歸人，是個過客...
揮揮衣袖，不帶走一片雲彩，卻留下一堆 bug 🙈
{\__/}
( • - •)/つ 🍷 乾了這一杯 ~讓我們下回見
沒有留言:
張貼留言