前幾個月剛好是大型功能上線的時間。再接續另外一個專案之前並沒有什麼太大的開發，主要就是修一些小 bug 以及將現有的功能做改善。也因為開發上沒有那麼緊湊，所以這一季有更多的時間可以專注在改善流程上。

背景

先來說說開發時遇到的情況。每個團隊與組織當中遇到的情形不同，因此了解背景與想要改善的問題是相當重要的。這次在開發上明顯造成問題的情況有幾個：

###組織上牽涉到的人員多

我目前參與的是金融相關的開發，目前來說就有 FX（外匯）、股票、投資信託等等產品，比較大型的功能雖然會拆出來另外處理（例如 FX 是額外開發一個 App），但大部分的功能都是實作在同一個網站底下，並交由每個專案負責的開發團隊做處理。這造成了：

• 每次動到共用模組就必須牽扯到多個團隊，心智負擔高。怕改了程式碼之後就壞了，因此偏向 workaround 而非正視問題
• 在多個專案平行開發時容易衝突，例如在專案 A 當中實作了桌機版本，但同時進行的專案 B 當中卻還沒有。這時兩個專案做合併時容易遇到衝突。

團隊無法掌握所有資源

舉例來說，我們在 QA 的時候必須配合所有專案的時程，而 QA 的資源有限，因此有時也會出現明明功能早就做完了，但是要等一個月兩個月才能做 QA 的情形。這個成本是相當高的：

• 開發者在一、兩個月後早就忘記實作細節，需要花時間回想
• 等到 QA 提出問題再修正時，整個迭代的過程就變得相當長。
• 某些 API 或是實作需要等其他團隊做修正，沒辦法掌握對方的時程，進而卡住團隊的開發進度。

QA 環境繁瑣

理想來說，QA 環境應該只有一個才對。

但是在專案平行開發、測試環境有限、新增測試環境成本高（架構限制）的情況下，很有可能 QA 在兩個環境下同時進行。在測試環境不足的情況下，有時開發與 QA 會共用一個環境，這造成了一些問題：

• QA 遇到問題了不知道是因為真的出 bug 還是開發本身在測試新功能。
• QA 環境不足造成的溝通成本非常大。因為團隊大所以要聯絡的 channel 也非常多。
• 測試帳號的準備過程繁瑣，因此各個環境幾乎都有殘缺、無法使用的帳號。

不完整的 Sprint

雖然說目前團隊正在使用 Scrum 進行開發，但我發現自從離開上一個專案之後，Scrum 變得相當不順，推測可能的原因有：

• 團隊內部也有工程師會負責不同專案，Sprint Goal 形同虛設
• 沒有 QA 資源可以調度，無法進行測試。
• 進度的追蹤不夠落實，常常會有優先度是 A 但同事在做 B 的情況發生。
• 沒有明確的目標與迭代。

從以上的情況來看，或許團隊本身並沒有達到一個理想 Sprint 需要的條件。在許多資源都被箝制在其他地方的情況下，或許 Sprint 也並非最佳選擇也說不定。

改善過程

雖然說大部分的問題都不是在開發端能夠完成的，不過開發環境上我認為能夠做一些處理。

在進行改善的時候，必須先思考動機與想要達成的目的。所以第一步我先準備了一份文件，裡頭簡述了目前遇到的問題以及可能的解決方案。

主要的目的如下：

• 開發團隊可以自由切換不同 branch 的程式碼。這點很重要，因為我們的開發團隊負責的專案都不同，同時會有好幾個不同專案進行，因此有時會出現「啊環境先借我測一下，我用完再還你」的情形發生。
• QA 和開發團隊不共用同一個環境。這樣就不會有出現問題無法確認成因的狀況發生。

有了這份文件之後我開始與團隊內進行討論，這個討論主要有幾個目的：

• 確認大家都有類似的問題，確保彼此想像的狀況是相同的。
• 對於同事來說，他們也有不同的考量點，這些考量點是事後改善是否能順利進行的關鍵
• 集思廣益，或許我的想法有缺陷，集結彼此的想法或許有更好的方案。

雖然比起實作，這次更想要著重的是整個改善的過程，不過在這邊還是簡單描述一下我的作法：

• 在前端上因為我們是跑 SPA，所以只要想辦法把 build 好的 JavaScript 上傳後就可以隨意切換不同 branch 的程式碼。這樣一來開發就不需要跟 QA 共用環境，不同開發 team 也可以隨意切換環境。
• 透過 query parameter 來切換不同的環境，但是要一直保持 query parameter 也是一個麻煩事，尤其是 App 當中會有一些 redirect 的邏輯（像是付款後重導頁面）
• 實作類似 deploy preview（Netlify） 的功能，每次提出 PR 後開發團隊可以直接點擊 URL 看 demo。

經過釐清之後，發現這些做法有幾個問題：

• 在部署的時候前端還有另外實作一個 node.js server，當作一個簡單的驗證伺服器還有提供一些 API 方便操作。因此並不是只有純前端而已，用檔案上傳的作法容易造成誤解，並且要改動的 codebase 也比較大，容易造成反彈。
• deploy preview 往往需要動態 DNS 的協助，不過公司內部是使用私有雲，不確定是否有 API 可以達成。另外像登入功能等會轉導到其他頁面做 SSO，實作上有限制 Domain，因此 deploy preview 產生的 domain name 會被拒絕導致登入失敗。雖然對於不需要登入的功能來說確實可行，但效果雞肋不符合成本效益。

在這途中，有另外一位工程師也感受到類似的問題，主動加入了這次的改善流程（原本我以為要孤軍奮戰到底了），開始一起幫忙梳理問題。我首先先解釋了 Deploy Preview 的概念給他，他表示理解之後對於現有的方案提出了新的想法。

「動態調整 DNS 的成本較高，還是我們用 nginx 來做轉導？」

也就是按照目前的部署方式在新建一台機器（透過內部私有雲點幾下就可以了），然後在原有的機器裡的 nginx 加入一個轉導邏輯。

如果帶有某 cookie 值就轉導到開發用到機器，沒有的話就保持原樣。這樣一來，不僅原本的 codebase 不需要動任何一行程式碼（頂多改改 Jenkins 腳本還有修改一下 Ansible 腳本），原有的部署方式也可以複用，大幅減少了開發成本。

就這樣把方案決定好之後，接下來詢問其他團隊的意見，基本上大家也都是正面積極的態度，最後詢問了 SRE team 也沒問題。整個實作也就告一段落了。

改善之後

說真的，只有白紙黑字很難讓人感受到實質的東西，就算看到 Demo 也是。而是真的實際使用了之後才會有感覺。當大家開始使用了新的環境切換機制之後都是一片好評，也算是真的有改善到流程了。

心得

這個改善流程先後總共花了三個多月吧，畢竟涉及的團隊較多，因此花的時間也比較久一些。剛開始一定不能心浮氣躁，不然很容易失去團隊們的理解。這次過程中我也學到蠻多事情的。

1. 先寫文件

寫文件這件事情是建立團隊共識的第一步。在寫文件時不要過度著重在如何實作上，而是要著重於如何解決問題以及可能的解決方案有哪些，進而讓團隊激盪出更好的方案。這麼做還有一個好處是讓團隊覺得這個東西不是只有你一人，而是團隊一起討論出來的。

2. 從全體而非個人出發

這次改善能夠獲得不錯的評價原因之一在於這件事並非只有我個人，而是團隊中許多人都有類似痛點。在做改善時不能只用「因為這樣寫比較舒服」「這個技術我比較熟」之類的原因當出發，而是要想這些改善是否真的帶來效益，這樣才會有人買單，也才會有人站在你這邊。

3. 不要過度執著於技術

老實說這次根本沒用到什麼技術性的東西，就是加個判斷式而已，但是整體帶來的效益卻很高。很多工程師過度執著於技術本身，但往往忽略了要解決的問題。技術本身就是用來服務人類的，如果忽略掉這個事實的話，那麼技術本身也就喪失意義了。

4. 不要害怕其他團隊

這個改善本身需要其他團隊協助，往往會讓人打退堂鼓，畢竟大部分的人都嫌麻煩，不想淌渾水，只要完成自己份內的工作就好。但是只要能夠準確說明問題與解決方案，有打到對方的痛點，很多時候大家都是站在你這邊的，有時對方的考量點聽起來會像是阻饒，但也不需要過度揣測。

5. 找到志同道合的夥伴

我覺得這件事能夠成功還有一個很大的因素是因為當時有一位工程師對這件事也有興趣。剛好他是後端工程師，對架構面比較了解，所以才有後來的 nginx 解決方案。不過志同道合的夥伴可遇不可求，遇到了要好好珍惜。