敏捷突擊隊是台灣敏捷社群所舉辦的活動, 點子來自對岸, 這活動會提供企業一次免費問題診斷的諮詢服務. 之前在 Agile Summit 2018 時有舉辦過.
那時候我們幫了一些企業回答了他們的難題, 下面是我們的成果:
A. 敏捷突擊隊 — 松江站
B. 敏捷突擊隊日誌: 如何切分 tasks
C. 敏捷突擊隊 — 台中站
這次敏捷突擊隊在 Trend Micro 內, 遇到一個剛開始實施敏捷不到 3 個月的團隊, RD: QA 應該是 3:1 以上吧. 他們提到了以下幾個問題：
(1) git feature branch 的 lock 問題
苦主提到每個 feature team 在開發時, 會長出一個 branch 出來, 開發完後會要 merge 回 master. 在 merge 的時候會會 lock master 大約 1-2 小時, 有時候遇到測試有問題, lock 時間還會做更久.
老實說, 如果要改成其他運作方式, 要養成新的習慣可能會花更多時間. 因此先確認他們為什麼會花這麼久的時間 merge.
苦主說因為 branch 和 merge 差很大, 所以即使在 branch 測完後, merge 回 master 又發現有問題.
因此, 我只先很簡單建議每天做 merge: 從 master 拉到 branch 合併, 讓 branch 盡可能和 master 差不多. 這樣在 branch 測試後, 不至於到 master 後差很大. 另外這樣的解法不會和原先他們的做法差很大, 團隊成員比較能接受.
其實 agile 很多原理都是一樣, 利用小批次, 快速回饋, 及時修改. 不只開發功能是如此, code merge 也是要這樣.
另外, 我也給他一些參考資料, 看看別人的優點, 是否能整合進來.
Version Control for Multiple Agile Teams - InfoQ
多個敏捷團隊之間的版本控制
(2) 大家還是比較習慣過去 waterfall 的方式, 即使 sprint 也像是 mini waterfall, 要鼓勵 RD shift testing left 還需要持續溝通. 另外 review 時間 變長, 要怎麼處理?
目前團隊角色分工明顯, 有開發人員和測試人員, 在無法改變組織人員結構下, 在跑 sprint 勢必會像 mini waterfall, 測試人員一定在開發人員完成後才測試, 我建議可以先嘗試以下事情
a. 小批次: RD 不要做完一堆 story, 才給 QA 測試.
b. 讓 RD 開始寫測試自動化, 這樣 QA 才會有更多時間去做更複雜的測試 (因為它們 RD 人數遠大於 QA 人數)
c. QA 要從 需求討論階段開始加入討論, 越早知道需求和設計, 他們能越早知道怎麼測試, 並且建議 RD/PO 一些測試時要考量的事情
讓所有資訊從頭到尾都所有成員的是透明的, 流通的. 讓不同角色很早就知道其他人在做什麼, 減少交棒所帶來的問題.
苦主提到有一堆東西要大家一起 review, 像是畫面設計, 架構設計, 和 測試個案等等, 會花大家很多時間. 個人覺得這是一定的, 溝通是要花時間的, 不可能大家不交談, 只靠看文件就會清楚. 如果文件要能寫的這麼清楚, 我想寫文件的時間應該也是高得嚇人. 並且這個時候不花, 到時候晚期才發現有問題, 團隊就會沒有時間去反應.
這部分是要麻煩他們多去溝通.
但是, 另外一件事可以改進的, 是他們會不會在開一個沒有效率的會. 例如: 因為很多事情不知道怎麼處理, 大家在那邊瞎忙瞎討論, 導致時間一直拉長.
因此我建議這些人一定要到場
a. 能夠回答需求的人: 要有人可以決定要做什麼. 或者遇到某些錯誤/狀況時, 系統該反應什麼.
b. 能夠做技術決策的人: 遇到技術難題, 或是不知選擇哪種解法, 要有人可以給建議, 或者做出判斷.
有了這些人會讓會議有效很多. 有時候不是團隊想開這麼久, 而是他們不知道怎麼辦.
(3) junior member 相對易接受新的做法，senior member 感覺比較不易接受.
可以先了解他們是習慣問題, 還是不知道怎麼做. 如果是後者, 這是我們可以立即處理的.
例如他們可能不知功能怎麼拆解, 或者怎麼做規劃工作, 可以請其他 feature team 的人分享他們的經驗, 同個產品線的分享會比較有說服力, 大家討論交流完後, 相信大多的問題可以解決, 畢竟同一個產品不至於開發做法無法套用.
接下來再跟這些資深成員, 確認是否有地方還不知道怎麼做, 讓他們在可行性上面是沒有問題的. 接下來才去處理時間不夠, 或是比較燙手的心態問題.
(4) 你們standup meeting 怎麼做? 會用 Jira 嗎?
不管是實體看板或是電子看板, 我建議都是要在看板面前進行. 否則因為沒有資訊的呈現, 很容易空口說白話.
如果真的很多人參加, 是可以採用 Jira 進行. 因為人數一多, 不管是那種看板都會密密麻麻的, 但是 Jira 可以設定一些 filter, 我們可以針對某個 epic, 或是某個成員的內容去看, 讓我們有專注性, 東西少大家也比較不會想放棄看.
(5) retrospective 久了大家沒有新鮮感, 可以怎樣改進?
可以先跟團隊成員確認一下, 大家覺得無聊的地方在哪? 是說要改沒有改善? 還是要改的東西不是重點? 還是已經沒有太多東西可以改了. 或者是團隊成員的心態上比較是屬於 fixed mindset?
先暸解後比較好對正下藥. 目前我只能就流程上提出改善方式:
a. 可以考慮換不同人進行, 例如不同 feature team 的 SM 可以交換主持.
b. 可以改成針對某個問題改善, 而非全面性檢討
c. 確定 retrospective 提出的問題有被處理或解決. 如果會議有效, 大家可以忍耐無聊.
嗯, 敏捷突擊隊真的不容易, 在不改對方做事的大架構下, 提出一些建議, 真的需要不少修練.
全站熱搜
留言列表
