前篇
前言
自從開始與新團隊合作後, 產品也即將 GA release.
GA 之後又會有新的不同的挑戰. 在新挑戰之前, 是時候紀錄一下這段時間發生的事情.
挑戰
- 產品本身
- 由於架構改變加上優化, 整個 backend 幾乎全部改寫, 而且加上支援 HA. 有大量還沒經過 QA 驗證的程式(全部改寫, 都只有 unit test, 所以算是全部都還沒驗證過 :P).
- 這個產品開發需要了解另一個產品才可以整合
- 人員改變
- 原本的核心團員一人
- 新外包團隊五個人加入, 四個工程師與一個 QA.
- Functional QA 與 Performance QA
- 同時間 (同個禮拜加入)
- 需要帶領新團隊五人從無到有了解產品並加以貢獻
- Functional QA 開始列 functional testcase 測試, 這是公司內經驗老到的 QA
- Scaling QA 開始列 performance criteria & testcase 開始測試效能, 這也是公司內經驗老到的 QA
- 時程
- 由於來支援的 QA 手上還有其他重要的事情, 所以我們不該耽誤他們太久
- 因此不論 scaling QA or functional QA 的時間都非常寶貴 (大家的時間本來就都非常寶貴)
- 必須特別注意不可以有 blocking issue, 有 blocking issue 就需要立馬解決
接受挑戰
規劃
Thread 1-1: 新團隊成員
- 協助裝機, 介紹開發環境
- 講解原理, 提供文件
- 拍影片, 介紹產品基礎設定與整合測試方法
- 下載程式後, 介紹程式架構, 依照 use case 介紹程式位子
Thread 1-2: Functional QA
- 介紹產品背景與 trade-off
- 解釋功能, 提供文件
- 討論 testcase 以及測試的範圍
Thread 1-3: Scaling QA
- 介紹產品背景與 trade-off
- 解釋功能, 提供文件
- 討論需要的 capacity 以及效能測試的方法
Thread 2-1: 新團隊成員
- 確認基本操作完成後, 開始安排 Functional QA 開的 bug中比較單純的部分交給新成員處理
- 由於每個人開始透過不同的 bug 來熟悉系統, 為了快速掌握進度, 開始進行 daily meeting
- 透過由淺入深的 bug, 來觀察還有甚麼地方不懂, 就一次講解給所有人聽, 期望盡早把知識都散布出去
Thread 2-2: Scaling QA
- 一開始 Scaling QA 遇到的問題最棘手, 因為效能大多就是測 critical path
- scaling test 的特性是: 一旦遇到一個量上不去, 測試幾乎就卡住了, 需要立即處理
- 力求每天 Scaling QA 遇到新瓶頸, 當天或隔天就可以有新的 release 可以繼續測試
- 由於新團隊成員掌握度還不高, 因此這類問題都要先讓原本的隊員與我來處理
Thread 2-3: Functional QA
- Functional QA 開的 issue 很多, 需要盡早判斷是屬於新團隊成員可以練習的, 還是需要與原本的隊員一起先解決的
- 新隊員摸索時期大多是從 NodeJS or Angular 起頭去看 application logic, 因此就先都安排在 NodeJS 或 UI 上可以看到程式的 issue 給新成員
- 如果跟 Linux system call 或是 IPv6 或是 Java/Groovy 做的比較偏系統操作的 bug, 就由我與原始隊員先排除
- 初期雖然大部分時間都在與 Scaling QA 合作, 但隨時要注意 Functional QA 有沒有遇到 blocking issue
Thread 3-1: 新團隊成員逐漸上手
- 上手後能協助的問題就變多了
- 定調 release 的節奏為每週一次, 簡化流程
- 開始把一些比較系統面的工作也指派出去
- 當遇到問題的時候就一起看
- 有經驗的人與我一樣先挑比較麻煩的 bug, 讓新團隊可以先熟悉 application code.
- 慢慢有些麻煩的 issue 試著交給新團員後, 有問題就分享平常解決問題的方式
- 阻止外部的人催促新團隊成員時程, 爭取按步就班上手的時間
Thread 3-2: Scaling QA
- Scaling test 尾聲, 與 Scaling QA 討論測試的上限
- 完成測試
Thread 3-3: Functional QA
- 持續把新成員有能力處理的 issue 指派過去
- 持續自行處理棘手的 bug
成就
終於, 在經歷了一百多個大大小小的 bug 後, 得到 GA candidate
- 通過 Scaling QA 安排的測試
- 通過 Functional QA test pass rate over 96%
過程中
- 原本的隊員與我在過程中一度需要去支援別的案子, 當下壓力頗大.
- 秉持著 "培養新團員就有 capacity 來處理更多 issue" 的精神, 繼續投資時間在與新團隊的溝通與分享上
- 最終果然有的新成員逐漸上手, 可以把更多事情安排出去, 討論的內容也愈來愈進階
- 時程快到之前, 每天都看著 scrum board 沙盤推演誰的 issue 做完之後可以提升 pass rate
- 直到有天 pass rate 超過了 96%
插曲
- 原本新團隊的隊長, 突然要離開公司, 搬回馬來西亞
- 新團隊的 QA 節奏有點跟不上, 協助幾次之後, 在與新團隊成員討論之後, 提出了 PIP, 最終我們好聚好散
- 新隊長會再找人補上空缺
後續
- 為了要 GA, 新團隊還沒有接觸較底層的東西
- 新團隊即將成為產品的下個版本的主力開發人員, 需要盡早掌握所有部份的技術
- 新上任的隊長還沒有帶隊經驗, 因此還需要協助建立新的 working model
- 也要協助新隊長理解新產品需求, 並規劃好 milestones. 讓團隊每個人都能 on the same page.
心得
時間一樣短短的 (2-3個月), 想不到列下來發生這麼多事情.
有人支援是很好的事情, 可是也需要注意釋放出來的知識需要按部就班規劃.
同時間要頂住壓力, 避免 QA 的 issue 壓太多給新隊員導致消化不良, 又要避免卡住 QA 浪費時間.
讓每個人都能處在剛好可以提出貢獻, 又有一點挑戰的狀態就很重要.
為了做到這點, 需要不停地從他人的角度來看待, 持續溝通, 想辦法讓人 on the same page.
很感謝不論是 QA, 原核心成員與新團員都很給力, 在許多混亂的資訊攤在檯面上的時候,
依然能一起持續討論, 找出有意義的目標與問題加以克服.
之後還有很新挑戰, 又是一輪新的動態搭配.
沒有留言:
張貼留言