新團隊快速貢獻

前篇

分工不設限

前言

自從開始與新團隊合作後, 產品也即將 GA release.

GA 之後又會有新的不同的挑戰. 在新挑戰之前, 是時候紀錄一下這段時間發生的事情.

挑戰

1. 產品本身
1. 由於架構改變加上優化, 整個 backend 幾乎全部改寫, 而且加上支援 HA. 有大量還沒經過 QA 驗證的程式
   (全部改寫, 都只有 unit test, 所以算是全部都還沒驗證過 :P).
2. 這個產品開發需要了解另一個產品才可以整合
2. 人員改變
1. 原本的核心團員一人
2. 新外包團隊五個人加入, 四個工程師與一個 QA.
3. Functional QA 與 Performance QA
3. 同時間 (同個禮拜加入)
1. 需要帶領新團隊五人從無到有了解產品並加以貢獻
2. Functional QA 開始列 functional testcase 測試, 這是公司內經驗老到的 QA
3. Scaling QA 開始列 performance criteria & testcase 開始測試效能, 這也是公司內經驗老到的 QA
4. 時程
1. 由於來支援的 QA 手上還有其他重要的事情, 所以我們不該耽誤他們太久
2. 因此不論 scaling QA or functional QA 的時間都非常寶貴 (大家的時間本來就都非常寶貴)
3. 必須特別注意不可以有 blocking issue, 有 blocking issue 就需要立馬解決

接受挑戰

規劃

Thread 1-1: 新團隊成員

1. 協助裝機, 介紹開發環境
2. 講解原理, 提供文件
3. 拍影片, 介紹產品基礎設定與整合測試方法
4. 下載程式後, 介紹程式架構, 依照 use case 介紹程式位子

Thread 1-2: Functional QA

1. 介紹產品背景與 trade-off
2. 解釋功能, 提供文件
3. 討論 testcase 以及測試的範圍

Thread 1-3: Scaling QA

1. 介紹產品背景與 trade-off
2. 解釋功能, 提供文件
3. 討論需要的 capacity 以及效能測試的方法

Thread 2-1: 新團隊成員

1. 確認基本操作完成後, 開始安排 Functional QA 開的 bug中比較單純的部分交給新成員處理
2. 由於每個人開始透過不同的 bug 來熟悉系統, 為了快速掌握進度, 開始進行 daily meeting
3. 透過由淺入深的 bug, 來觀察還有甚麼地方不懂, 就一次講解給所有人聽, 期望盡早把知識都散布出去

Thread 2-2: Scaling QA

1. 一開始 Scaling QA 遇到的問題最棘手, 因為效能大多就是測 critical path
2. scaling test 的特性是: 一旦遇到一個量上不去, 測試幾乎就卡住了, 需要立即處理
3. 力求每天 Scaling QA 遇到新瓶頸, 當天或隔天就可以有新的 release 可以繼續測試
4. 由於新團隊成員掌握度還不高, 因此這類問題都要先讓原本的隊員與我來處理

Thread 2-3: Functional QA

1. Functional QA 開的 issue 很多, 需要盡早判斷是屬於新團隊成員可以練習的, 還是需要與原本的隊員一起先解決的
2. 新隊員摸索時期大多是從 NodeJS or Angular 起頭去看 application logic, 因此就先都安排在 NodeJS 或 UI 上可以看到程式的 issue 給新成員
3. 如果跟 Linux system call 或是 IPv6 或是 Java/Groovy 做的比較偏系統操作的 bug, 就由我與原始隊員先排除
4. 初期雖然大部分時間都在與 Scaling QA 合作, 但隨時要注意 Functional QA 有沒有遇到 blocking issue

Thread 3-1: 新團隊成員逐漸上手

1. 上手後能協助的問題就變多了
2. 定調 release 的節奏為每週一次, 簡化流程
3. 開始把一些比較系統面的工作也指派出去
4. 當遇到問題的時候就一起看
5. 有經驗的人與我一樣先挑比較麻煩的 bug, 讓新團隊可以先熟悉 application code.
6. 慢慢有些麻煩的 issue 試著交給新團員後, 有問題就分享平常解決問題的方式
7. 阻止外部的人催促新團隊成員時程, 爭取按步就班上手的時間

Thread 3-2: Scaling QA

1. Scaling test 尾聲, 與 Scaling QA 討論測試的上限
2. 完成測試

Thread 3-3: Functional QA

1. 持續把新成員有能力處理的 issue 指派過去
2. 持續自行處理棘手的 bug

成就

終於, 在經歷了一百多個大大小小的 bug 後, 得到 GA candidate

1. 通過 Scaling QA 安排的測試
2. 通過 Functional QA test pass rate over 96%

過程中

1. 原本的隊員與我在過程中一度需要去支援別的案子, 當下壓力頗大.
2. 秉持著 "培養新團員就有 capacity 來處理更多 issue" 的精神, 繼續投資時間在與新團隊的溝通與分享上
3. 最終果然有的新成員逐漸上手, 可以把更多事情安排出去, 討論的內容也愈來愈進階
4. 時程快到之前, 每天都看著 scrum board 沙盤推演誰的 issue 做完之後可以提升 pass rate
5. 直到有天 pass rate 超過了 96%

插曲

1. 原本新團隊的隊長, 突然要離開公司, 搬回馬來西亞
2. 新團隊的 QA 節奏有點跟不上, 協助幾次之後, 在與新團隊成員討論之後, 提出了 PIP, 最終我們好聚好散
3. 新隊長會再找人補上空缺

後續

1. 為了要 GA, 新團隊還沒有接觸較底層的東西
2. 新團隊即將成為產品的下個版本的主力開發人員, 需要盡早掌握所有部份的技術
3. 新上任的隊長還沒有帶隊經驗, 因此還需要協助建立新的 working model
4. 也要協助新隊長理解新產品需求, 並規劃好 milestones. 讓團隊每個人都能 on the same page.

心得

時間一樣短短的 (2-3個月), 想不到列下來發生這麼多事情.

有人支援是很好的事情, 可是也需要注意釋放出來的知識需要按部就班規劃.

同時間要頂住壓力, 避免 QA 的 issue 壓太多給新隊員導致消化不良, 又要避免卡住 QA 浪費時間.

讓每個人都能處在剛好可以提出貢獻, 又有一點挑戰的狀態就很重要.

為了做到這點, 需要不停地從他人的角度來看待, 持續溝通, 想辦法讓人 on the same page.

很感謝不論是 QA, 原核心成員與新團員都很給力, 在許多混亂的資訊攤在檯面上的時候,

依然能一起持續討論, 找出有意義的目標與問題加以克服.

之後還有很新挑戰, 又是一輪新的動態搭配.

分工不設限

 

前言

去年一些巧合, 跟團隊幾個人接手一個案子, 這個案子原本算是服務客戶特定需求的 POC, 但由於客戶愈來愈依賴這個工具, 因此交到我們手上.

PS. 在我加入之前, 已經有人辛苦耕耘了好一陣子. 不過也因緣際會離開這個案子. 一個案子要成功, 從來不是誰可以獨立勝任. 享受合作的當下, 同時也要記得這是很多默默付出的人辛勞的結果, 而非甚麼簡單的水到渠成.. 

挑戰

1. 技術背景不同
1. 案子用到的技術是 NodeJS, Angular, MongoDB
2. 成員技術背景是 Java, Cassandra
2. 需求大: 要把 MongoDB 換成 PostgreSQL
3. 技術債: 由於是個 POC 的案子, 所以程式結構沒有特別維護, 整組就是典型的 callback hell, 經常性的 callback 到第四第五層
4. 沒有統一的 build flow: 原本交付的方式就是從某個工程師的電腦打包出一個 image 給客戶安裝, 在 POC 也還合理, 但要產品化就無法接受了
5. 概括承受 bug, 當前客戶在用的系統如果遇到問題, 就需要與 technical support, customer support 一起討論與解決問題

接受挑戰

初期

1. Study: 由於技術不熟悉, 所以大家還是花時間學一下 NodeJS, Angular, MongoDB.
2. List features: 一起把功能使用一番, 列出來

規劃

Thread-1-1: 換資料庫

1. 一開始我們把所有的 table 列出來, 想要"縱切"來分開發方式. 也就是一個 table 一個 table 的把程式從面對 MongoDB 改為面對 PostgreSQL
2. 做一段時間後, 深感部分 Data Access layer 面對 MongoDB, 部分面對 PostgreSQL, 常常碰到一些因為資料不一致出現的錯誤.
   這種錯誤讓人無法確認現在的開發是好了沒有, 所以我就決定開始衝刺把所有的 Data Access Layer 通通轉成面對 PostgreSQL, 而不理會功能是否損毀.
3. 同時間, 另一個成員深受 callback hell 的困擾, 因此在討論後, 開始大幅度的將 callback hell 改為 controller -> service -> dao 這樣的三層式架構

Thread-1-2: build script

團隊內的大神基於興趣, 接手了 build flow 的規劃. 將原本由工程師在自己電腦上 build image 的方式, 轉為

1. 準備 docker 環境
2. 在 docker 內準備好 CentOS, PostgreSQL, NodeJS, Angular 的環境
3. 安裝好後 build 出客戶需要的 vmware image
4. 準備 CLI 讓客戶裝好 image 後, console 上能跳出 setup 的 CLI.
5. 支援 join 第二台 PostgreSQL
6. 在 Jenkins 上執行 build script

Thread-1-3: nginx

1. 專案原本用 openresty 在 nginx 寫程式 access MongoDB
2. 我們認為這設計導致不容易管理資料庫由誰存取
3. 因此規劃改寫 openresty 從直接存取資料庫, 改為存取 API 來存取資料.

Thread-2-1: data migration

在 Data Access Layer 改為面向 PostgreSQL 之後, 接下來需要處理怎麼從 MongoDB 轉移過來, 因此規劃了

1. 把 MongoDB 資料轉出
2. 建構 PostgreSQL 的 migration script, 包含建立 schema 的 DDL
3. 提供 user import MongoDB data 的功能

Thread-2-2: licensing

原本的案子沒有 license 的功能, 因此也照公司其他產品的方式規劃了 license

Thread-3-1: documentation

慢慢功能都快補好了, 開始需要與 document team 溝通與準備需要的文件

Thread-3-2: unit test

過去缺乏 unit test, 因此大量地補上

成就與心得

1. 像這樣分很多個 thread 做了非常多的事情, 一切只發生在大概五個月內, 而且我們成員就五個人, 且大多都還有其他在進行的專案.
2. 通常一個案子在進行的時候, 很多人可能會想要把要做的事情都規範好, 希望能夠營造一個 "我都規畫好了, 你照做就沒問題"
3. 但我們的作法則是: "目標就這些, 一起來看怎麼處理"
4. 在執行過程中, 每個人都在貢獻自己能做的事情, 而且當遇到覺得有問題的地方, 提出來後大家就能一起討論做決定, 接著繼續分頭進行
5. 由於能夠參與決定, 大家就更有 ownership, 就會提出非常多很好的意見
6. 我自己就很開心能享受到架構與流程的改善, 而且完全是大家自發性的改變, 回想這一段時間, 很短, 但很充實愉快

後記

這個案子, 因為一些因素, 人員變動, 在我們做完之後暫時告一段落.

大家繼續各自去忙不同的案子.

後來公司找了外包團隊.

所以接下來我還會一次與公司突然開始加入的外包團隊, functional QA & performance QA 一起合作.

正在如火如荼, 再次經歷一段美好的團隊合作經驗.