網頁

2021年3月31日 星期三

敏捷深夜食堂:什麼是 Long Live Team

最近有朋友問我 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 🙈

{\__/}

( • - •)/つ 🍷 乾了這一杯 ~讓我們下回見

沒有留言:

張貼留言