分享：透過 Azure Devops Server 瀏覽團隊工作狀況 (Part2)-團隊活動的運作
在前一篇文章中，我們探討了團隊活動管理的核心 — — 需求的生命週期管理，以及在團隊工作過程中持續迭代的項目，例如工作流程的改善，或是系統的補強等。這些元素不僅值得被詳細記錄，也應該被安排在未來的版本中進一步的優化。
透過這種持續的反思和改進，團隊能夠不斷提升工作效率，同時確保每一項需求都能以最合適的方式被處理和實施。在接下來的內容中，將介紹我們在各種活動的執行細節與理念。
專案的起始 — Planning
我們期許除了說明功能需求以及所帶來的價值之外，更能讓不同團隊的角度來看待同一件事情，從而激盪出不同的火花，為此，我們將區分成三個階段：
PH1 : 功能需求的多角度探討
在這一階段，主要是由產品負責人（PO）詳細介紹即將在下一個版本中業務的各項需求。目的是引導各團隊成員從多個角度審視需求，從而能夠提出各自專業領域中的見解和建議。
前置 :
1. 確保PO團隊已經收整於該版本的所有需求，並提出工單。
2. 確定該版本的Release時間。
工作分配
- 產品負責人（PO） 會前數日，提供業務需求說明文件，文件中描述需求的背景、涉及到的利害關係人、周邊相關的系統甚至是業務規則等。
- 開發團隊（RD） 從技術角度評估該功能與現有系統的整合性，並提出可行的技術解決方案，並初估時程是否有疑慮。
- 測試團隊（QA） 從測試的角度探討該功能在實際操作中是否能夠滿足業務需求，同時考慮操作過程中可能出現的異常情況，是否有導致例外的特定場景。
- 維護團隊（RD(Maintain)） 以系統維護的視角，分析當功能出現問題，用戶提出投訴或甚至系統不可用時，可能的應對措施。這包括考慮業務行為與相關系統間的連動反應，並對假設中可能存在的處理漏洞提出問題，同時，對於緊急情況下需要其他子系統配合的場景，也確定了聯絡窗口與溝通方式。
產出 :
1. 需求團隊的工單、需求文件。
2. 針對需求工單開出問題類型工單，待後續追蹤。
PH2 : 系統實作的細節與討論
在這一階段，重點放在對系統實作細節的深入探討與交流。各團隊將基於系統負責人（資深RD）提供的資料 — — 包括系統規格、流程和關鍵程式碼片段進行提問和討論，以確保所有參與者都能對系統設計有充分的理解。
前置 :
1. 確保PO TEAM 所有的工單問題都已確認完畢。
2. 確保開發/維護組的Backlog工單與需求組的所有工單已經拉上關聯。
工作分配
- 系統負責人（資深RD）會前數日，根據Backlog的開發範圍，提供系統的詳細規格和相關資料，以促進與會人員的理解和準備。
- 產品負責人（PO）關注系統設計是否滿足基本的業務需求，並考量系統是否具有隨需求變化進行調整的靈活性。此外，還需評估系統在面對緊急情況（如系統短暫中斷、大流量請求或關鍵資料丟失/錯誤）時的補救機制。
- 測試團隊（QA）從系統設計的細節著手，識別可能的異常測試流程和資料細節之間的對應關係，例如列舉值0=未退貨、1=已退貨、2=退貨失敗。探究在特定業務規則下，應將資料寫入哪一個欄位，以及應該帶入什麼值？此外，測試團隊也會檢查在更複雜的情境下，這些規則是否存在遺漏的情況。總之，這些準備工作將為編寫測試計劃提供必要的前置條件。
- 維護團隊（RD(Maintain)）：這個團隊的職責在於深入理解系統實作的細節，並在出現問題時快速進行修復。因此，他們將提出更為細緻和專業的問題，以檢驗系統的健壯性和可維護性。
產出 :
1. 開發團隊Backlog工單、系統文件。
2. 針對Backlog工單開出問題類型工單，待後續追蹤。
PH3：人員配置與工作準備
在進行實際開發之前，需要進行細致的前置準備，以確保所有準備工作都已就緒。這一階段的目標是確保人員與任務的有效對接，並對開工計畫做出最後確認。
前置 ：
1. 所有工單應無任何格式或內容上的變更，以保持需求的穩定性。
2. 所有Backlog中的問題都應獲得解決，確保開發工作能夠順利進行。
3. 確保測試團隊的測試計畫工單已經和開發/維護組的Backlog工單已經拉上關聯。
工作分配
- 開發版本負責人（資深RD）根據專業能力分配負責Backlog開發的RD。該RD將負責建立WorkItem，並設定預計的開始與結束日期。
- 測試團隊（QA）基於需求和開發提供的文件，測試團隊將撰寫測試計劃並開立對應的工單，為測試工作做好準備。
- 績效評估：資深RD和主管將共同確定每個工單的功能點，這些功能點將作為績效評估的一部分。
產出 ：
確保開發、維護、測試團隊的Backlog和WorkItem都是具體可執行的任務，並且每個工單都有明確的開始和結束日期。
通過這一階段的細致準備，團隊可以確保進入開發階段時，所有必要的前置條件都已得到滿足，從而為項目的順利進行打下堅實的基礎。
專案的進行 — 開發/測試
正如前文所述，整體工單的關聯情況大致如下圖所示。
在此階段中，我們需要確保所有提及的工作項目都能夠按照計畫準確且及時完成和解決。
我們使用Azure Devops 中的 Sprints Board 作為工單追蹤的工具，細節設定將於下個章節提到。
基本介紹 ：
PO Board
- 需求單
- 優化需求 ：對現有功能進行的改變或調整，不具急迫性。這類需求我們通常會規劃在未來的版本中進行優化。
- 障礙修復需求 ：對於現有功能出現的問題進行修復。除非是重大缺陷或有時間限制，否則我們可能會選擇在後續版本中處理這些問題。
- 新功能需求 ：按照上述的標準工作流程進行新功能的開發。 - 工作項目
- 文件撰寫 ：通常是為需求單撰寫說明文件 (ex: 系統說明書,外部串接系統規格書… etc)。
- 問題回饋 ：對於其他夥伴對於該需求的提問進行回饋，如上述的Planning PH1會議。
Dev Board
- 需求單拆解
- 功能主項目 ：將需求單細分為主要功能列表，例如：使用者操作的基本CRUD，這可能會進一步細分為API和前端開發兩大類。 - 工作項目
- 功能子項目 ：基於功能主項目，進一步拆分為小且具體可執行的子項目，我們通常建議夥伴將任務細分為0.5～1天的工作量。
- ReleaseMemo ：根據功能主項目，開發與測試完畢後，會先準備好即將更新的資料，例如：更新用的SQL腳本、Config等，待到版本更新當天進行更新操作。
- 問題回饋 ：對於其他夥伴對於該功能的提問進行回饋，如上述的Planning PH2會議。
Maintenance Board
維護看板與開發小組的看板在結構上相似，主要的差異在於功能主項目的性質或來源上的不同，例如優化或障礙修復等。此外，基於跨團隊合作的精神，開發與維護小組中的開發夥伴有時會互相提供支持，以促進項目的高效進行和問題的及時解決。
QA Board
在開發進行階段，測試團隊將負責撰寫結合測試計畫和測試案例。這些測試案例不僅關注於業務流程的操作行為和合理性，也包括驗證系統資料流的準確性以及系統規則等多方面。在此階段，測試團隊與開發、維護及業務團隊進行密切的協作，以核對和確認測試內容的完整性和準確性。
專案的日常 — 晨會
我們主要使用 Azure Dashboard，投影在大螢幕上，並且於晨會時大家會在螢幕前對焦重要事項 ：
Dashboard 細節設定將於最後一個章節提到。
我們主要將Dashboard 分為幾個部分 ：
共通項目
- 團隊行事曆：
- 版本行事曆：
通常，由於團隊的版本是併行的情況居多，因此可能在會議當天，有一部分專案人員正在忙於版本的開發，其他則忙著上版前的準備。
因此在晨會時，會由版本負責人進行整體情況的理解，確認關鍵人員都在這場會議中，以進行後續的討論。
- 排班人員：
營運的過程或是版本剛Release之後，難免會遭遇到緊急的狀況需要修復與對應，這種情況也有可能發生在非上班時間，因此我們會特別注意可能近期發生的障礙清單，以及相關排班人員的到班狀況。
- 其他重要事項
至於其他非版本功能的新增或是調整，可能都會需要進行對應，如：周邊系統的故障、基於資安的OS Patch更新等，也都會納入到版本行事曆，這樣做是為了確保團隊成員能夠充分意識到他們當前工作內容中與這些項目中可能存在的重疊部分，確保項目進度不會因為未預期的外部因素而受到影響。 - 便貼
在版本進行的過程中，鼓勵團隊成員進行正面的互動和分享是非常重要的。我們使用Miro進行便貼，提供了一個管道讓夥伴們可以表達感謝、分享成就或者傳遞正能量。 - 待討論項目
接下來，焦點會回到當前版本的討論議題上。在這一討論階段，我們將專注於開發/測試過程中提出的問題類型工單，進行深入分析與明確界定。此外，我們在會議記錄中詳細註記討論過程和最終確認的結果，以確保所有團隊成員對於問題的理解和解決方案達成一致。
開發階段
- 功能項目
負責Backlog的RD夥伴將對每一個功能的主要項目進行進度報告。如果在開發過程中遇到任何問題，那麼具體負責該功能細項的團隊成員將提供更詳細的說明。必要時，他們可能會向團隊的其他成員尋求支援。
測試階段
- 測試項目
負責Backlog的測試夥伴，將會對於每個流程的測試進度進行說明，在測試的過程當中，對於比較複雜的測試情境，可能也需要RD進行協助，如測試資料的建立，或是虛擬環境的部署等。
在這個階段，摘出障礙或是可能發生例外的潛在問題，會逐一與RD團隊進行確認並開立障礙單。
專案的尾聲— 部署
當開發和測試階段進入尾聲，負責Backlog的團隊成員將進行發佈前的重要準備工作。這包括詳細盤點在發佈過程中需要特別注意的事項，以及當天必須完成的任務。隨後，他們會創建相關的部署工單以便管理這些任務。在部署前數日，他們將與主管和版本負責的產品負責人（PO）進行最終確認，以確保版本更新當天一切能夠順利運作。
在部署後，將統整當天所遇到任何的突發狀況。如：部屬的Instance IP 訊號未寫入Grafana Monitor 、也有可能是部署流程上疏忽了某個步驟等等。並找到團隊中各領域的專家進一步討論解決方案，開立優化類型工單，會排定在未來版本進行優化。
邁向下一步 — 回顧
進入此階段，團隊成員們無疑都會感到一絲鬆懈。在經歷了上一版本的運作後，我們認為既有的優秀做法值得保留，同時也發現了需要改善的地方需要調整。無論如何，大家都持著積極的態度，對這系列過程的變化抱以開放的心胸。
在回顧活動中，夥伴們通常會採取較為輕鬆的方式表達自己的看法與建議，並透過工單整理，將這些內容回饋到各版本的執行項目內，這樣的迭代確保團隊將從每一次的過程當中，能夠變得更加強大。
補充資訊：Miro Azure Card
總結
這篇文章主要專注在說明團隊活動的運作流程與基本工單與各團隊之關聯，從計劃階段，透過各團隊的協作，為專案接下來的進行奠定了紮實的基礎。開發/測試階段，透過晨會的Dashboard，讓整個版本的運作更加的透明，讓夥伴的問題提早被發現、被解決。
整個流程延續到最重要的部署階段，可視化的呈現讓團隊各個角色可以意識到版本更新後，接下來要注意的事項以及異動的系統範圍。
最後，透過回顧會議，把整個專案的經驗往下一個版本持續迭代，從而實現持續改進和優化。
下一篇文章將提到工單與職責之間的關係，以及較詳細的設定部分。
