不是沒前後端，只是我們要練全端：小團隊的生存與成長法則

前後端技術已經確定，接下來我們來討論分工，先破題【全端工程師團隊的養成計畫】，這也揭示了組織策略與文化：資源有限，團隊必須兼顧前端與後端開發業務，即便專案開發時期同時參與的開發人數較多，未來系統上線後仍可能回到「一個系統、一人扛」的維運模式。此外，雖然技術架構已選擇可前後端分離，開發工作仍以單一功能切割：開發者接到需求時，需自行完成前端畫面以及後端 API 對接。聽起來雖然辛苦，但這正好符合我們練功的目標之一，當團隊熟悉了前後端特性，若組織未來有其他類似系統，也會以相同的專案小組模式進行翻修，也能順利打下基礎。

以 ADO 為核心的開發管理實驗

確認好任務切割方式回到以單一功能為主，接下來則可以進行需求如何管理的討論，去年公司內部引進 Azure DevOps (ADO) 的平台，但還沒實作於自行開發與多人協作的場景，因此本次也將以 ADO 作為多人協作開發與專案管理的主要平台，在 ADO 上 Feature 可再細分為 User Story，並可往下延伸 Task、Issue、Bug、Test Case 等 Work Item，我們利用此延伸性，將單一功能視為一個 User Story 進行管理。

初期當然需要 PM 兼 SA 的專案成員 美薇進行全面性站台功能的盤點，確認翻修功能清單，並依照功能模組的分類建立無數的 User Story，而多個 User Story 可往上 Group 為一個大項的 Feature。您也可以把它想像成系統的模組，層層往上後，就可獲得一份驚人的 Product Backlog (PBI)。

這樣一來美薇便可以依照這份 PBI 開始派工，因此開發進度的追蹤也是基於完成 User Story 的數量進行估算。當然這裡僅是粗略的估算，並無法精細計算實際專案的整體進度，因為功能的切割可大可小，且本次的開發交付採用迭代 & 瀑布式 Hybrid 模式，雖未採用 Scrum Sprint & 故事的點數，雖無法精準推算開發進度與燃盡圖，但仍可以約略點出各個階段進程。

圖3-1 : 校長兼任敲鐘的美薇分析專案待翻修功能清單產出的 PBI

圖3-2：展開後可以詳盡知道模組下有哪些待開發的 User story

當然，上方這些指純開發的功能，上線前後仍然有許非開發其他作業，那麼一樣可以透過類似的方式建立「Feature」進行分類，往下逐一建立 User Story，或是直接建立 Task，派個專職的負責窗口，也可以透過 ADO Board 確認各功能完工狀態，這次的專案中對於一個 User Story 完工的定義，包含需求確認、開發、交付測試環境、IT 測試、使用者驗測、修復、優化、驗證完成、使用者驗收完成，完成這些階段後，才可 Close 該功能故事卡片。

圖3-3 : 使用 ADO Board 追蹤各 User Story 完工狀態

圖3-4 : 每個故事卡中可以清楚看到目前的狀態，負責的窗口，任務工項、Bug 修復、測試完成度

Ending Remarks

這次專案看似是在練習如何運用 Azure DevOps 管理開發流程，實際上卻更像是一場「團隊肌肉」的鍛鍊。前後端全能的磨合、單一功能的切割、任務的分派與追蹤，這些都不是短期的專案技巧，而是日後團隊能否在有限資源下持續翻修、維運甚至再擴張的基礎。
ADO 只是工具，真正的價值在於讓團隊逐步養成紀律、默契與共同語言。當下一個系統翻修案來臨時，我們不僅擁有更清晰的管理方法，也已經有了一群能夠快速協作、彼此接招的夥伴。