當團隊各自開發的程式沒有及早整合，需求認知差異或不相容的行為，可能延遲到後期才被發現；即使程式已經完成，其他人也可能因為整合與驗證尚未完成，無法直接使用，依賴這些程式的任務也會因此延後。

團隊需要讓程式及早整合並分享，同時確認既有功能正常，維持可發布的狀態。

以下透過 Nathan 團隊的假想情境，說明這些問題具體在日常協作中是怎麼呈現的。裡面有很多對話，有可能就是平常大家的內心話。

團隊的開發流程

自從 2022 年以來，Nathan 領導 Kevin 和 Mandy 一路開發強大的演算法與機器學習模型。團隊好不容易打入市場，為多數重要產品提供關鍵的 AI 服務。Nathan 心中還有更大的目標想實現，因此邀請了其他多位開發者一同加入團隊，參與新的開發計劃。

好景不常，Nathan 原本預期，新成員加入後能夠分擔部分開發任務，讓計劃可以如期或提早完成。但經過了幾個月，整體的開發效率反而變慢了。他發現，任務所需的時間開始估不準，成員也多次在站立會議上回報，有臨時問題需要處理，導致原本的任務延後。甚至連 Kevin 和 Mandy 執行的任務，似乎也受到影響而跟著變慢。

Nathan 還不清楚問題出在哪裡，只知道原本的開發步調還算順，成員變多後卻開始出現這些問題。自己悶著頭想也不是辦法，因此他決定召集團隊成員，一起集思廣益。

團隊採用 GitHub Flow，以 main 作為主要分支。成員從 main 建立功能分支，透過拉取請求（Pull Request，簡稱 PR）討論與審查修改內容，完成必要驗證後，再將程式合併回 main。

共用模組的修改與整合

Kevin 是團隊的元老之一，前端工程師，平常喜歡自己烘咖啡豆。Kevin 先說明自己的情況：

「我的任務要修改好幾個前端模組。剛好 Phoebe 的介面調整也改到其中一個共用模組。我還在開發的時候，她已經完成並合併到 main。等我準備合併自己的程式，才發現有些地方對不起來，只能找她一起看。」

Phoebe 是新加入的前端工程師，過去在設計領域有豐富經驗，近年轉做前端開發。她接著說：

「我們要處理的需求不同，對共用模組的修改也不同。有些地方不能直接選我的或他的，要先確認兩邊需要什麼行為，再決定怎麼調整。」

為了釐清雙方對共用模組的需求，Phoebe 先前曾暫停手上的任務，回頭與 Kevin 一起討論。

Kevin 接著說明，雙方已經處理好衝突，但整合後的驗證還沒完成：

「因為調整到共用模組，我要再確認原本的功能和這次新增的功能，放在一起是不是都正常。衝突處理好了，但驗證還在做。」

他接著要驗證的，是納入 Phoebe 的提交、加上雙方協調後調整的版本。原本各自在分支上通過的測試，不能直接證明這個新組合也符合預期。

下圖以 Kevin 將 main 合併到自己分支的做法，示意這段整合過程。

Phoebe 的提交已經進入 main；Kevin 分支末端則是雙方協調、處理衝突後的版本。虛線框表示這個版本的驗證尚未完成，也還沒合併回 main。

取用尚未整合的程式

另一位新加入的前端工程師 Elvina，平常熱愛爬山，只是偶爾會迷路。她的任務也需要 Kevin 修改的另一個共用模組：

「我的任務需要 Kevin 改好的另一個前端共用模組。main 裡還沒有，但他的分支上已經有了。我不想自己重做一次，之後又要處理兩份程式，所以跟他討論後，就先把他的分支合併到我的分支。」

她取得的是 Kevin 解衝突之前的版本。除了需要的模組，也帶入整條分支裡尚未與 Phoebe 的提交完成整合的其他程式。

Nathan 問：「那妳的功能現在完成了嗎？」

「前端部分在我的分支上可以動了，但還不能合併回去。因為裡面包含 Kevin 的程式，我還要等他把整合結果確認好，再處理我這邊的差異。」

Elvina 已經確認自己的前端程式能在當時的版本上運作。但 Kevin 與 Phoebe 已經調整了共用模組，Elvina 還需要把這些調整納入自己的分支，重新驗證。她雖然只需要一個模組，仍得等待整條分支完成整合。

下圖示意分支的建立、Elvina 已取用的版本與後續等待的調整；實線表示已發生的過程，虛線表示尚末完成的步驟。

此時 main 已包含 Phoebe 的提交，但還沒有 Elvina 需要的模組；Kevin 與 Elvina 的版本仍未合併回去。

前後端的整合驗證

Mandy 是另一位團隊的元老，後端工程師，興趣是收藏漫畫，並自己手刻 App 來為自己的漫畫做書櫃日記。

Mandy 負責 Elvina 這項功能需要的後端介面。聽完前面的情況後，她也說明自己的進度：

「後端部分已經按照我們約好的請求與回傳格式做完測試，也合併到 main 了。我原本安排等 Elvina 的前端程式合併後，再一起確認從介面操作到後端處理的完整流程，但現在還沒做到這一步。」

Mandy 的後端介面已經完成測試並合併，但她與 Elvina 原本安排的完整流程驗證仍未完成。因此，即使後端部分已經準備好，這項功能仍有需要兩人一起確認的部分。

下圖呈現兩人原本的驗證安排；虛線表示尚待完成的步驟。

專家的提點

Brent 是從加拿大回國的資深 SRE，經手過多個跨國產品。聽完大家的情況後，他從整合與驗證的安排提出看法：

「Kevin 跟 Phoebe 太晚一起確認共用模組的需求。另一個問題是，Elvina 需要的模組已經寫好了，卻跟 Kevin 的其他修改綁在一起，還不能分開提供。現在連前後端一起驗證也跟著延後了。」

「我們可以在修改共用模組之前，就找會用到的人一起討論。已經完成的部分，也請你們一起確認是否能先整理好，分開驗證並放回共同版本，讓需要的人取得。前後端已經能配合的部分，也可以先安排驗證，逐步確認。」

假如 Elvina 需要的模組，必須搭配 Kevin 另一個還沒完成的模組才能運作，就不能只把幾個檔案挑出來合併。Kevin 與 Elvina 需要先確認它依賴哪些行為、會影響哪些呼叫端，再判斷是否能拆開。

團隊雖然已有共同的 main 分支，但共用模組的需求何時確認、哪些程式要一起合併，以及何時安排驗證，仍會影響其他人何時能取得並使用這些程式。Brent 提出的做法，就是從這些協作安排著手調整。

下圖以 Elvina 需要的模組為例，整理 Brent 建議的拆分與整合方向。

對新做法的疑慮

Sharon 過去是招募資安人才的獵頭，後來透過與專家交流及自己的努力，成為資安專家。這時她也加入討論，提出對使用者的擔心：

「如果新功能還沒完成就一起上線，使用者會不會看到做一半的介面？原本能用的功能會不會受到影響？」

Brent 回答：

「合併程式不等於立刻開放新功能。要確認程式放進共同版本後，原本的功能仍然能用，並完成必要驗證。發布時如果新功能還不能開放，就得控制它不要啟用，不能讓使用者進入還沒完成的流程。」

小結

從這次討論可以看出，需求差異到了準備合併時才被發現，讓 Kevin 與 Phoebe 必須回頭協調；Elvina 取用的分支又包含這些尚待確認的程式，連帶延後 Mandy 與 Elvina 的完整流程驗證。

因此，評估任務何時能完成時，除了撰寫程式，也需要考慮需求協調、等待其他人的程式，以及整合驗證所需的時間。

後面會進一步說明，團隊如何透過共同主幹安排整合與驗證，讓其他成員能夠更早取得可使用的程式。

參考資料

• GitHub Docs：GitHub flow