分享：透過 Azure Devops Server 瀏覽團隊工作狀況 (Part3)-Kanban與工作職責
在前一篇文章中，我們探討了團隊合作及工單之間的密切關聯，並強調了從計畫、執行、部署到回顧各階段的完整記錄重要性。確保了任務的透明度和可追蹤性，也促進了團隊間的協作。
接下來，我們將深入討論如何有效將工單分配給具有相對應職責的團隊成員，以及如何將這些任務的完成情況與個人績效連結起來。
流程說明
下圖是一個評定績效流程的概述，我們從幾個階段說明：
1.主管會將未來的部門或是單位整體目標條列出來，這個階段的內容並沒有那麼明確，舉個例子，可能就類似像是單位營收需要達到某個數字、或是基於障礙的數量需要減少等。
2. 這時候小組負責人會去思考該如何滿足這些目標，會與主管進行幾次的討論，確保接下來擬定出的具體方向，能夠在對的基礎上落實。
討論完畢後，這些具體的方向將會由各Team進行認領並規劃出團隊目標。
3. 以RD Team為例，將由Team Leader與夥伴進行面談，討論出夥伴期許在未來希望的發展方向，如接觸更多雲端的基礎建設、參與UI/UX的訪談等，我們會搜集這些願望清單，需要時會跨小組進行工作上的協調與安排，讓夥伴能夠往期許的工作內容進一步嘗試。
4. 最後，會將具體的工作項目與夥伴的願望清單進行連結，也因為工單的性質包含著不同的面向，因此我們將參照夥伴目前的職級與工單內容進行適當的評分。
5. 滿足上述流程，也確保夥伴對於未來的工作項目有較為具體的理解，接下來每一個版本的迭代，將遵照這樣的規則進行安排。
6. 最終，工單的統計與彙整，我們透過工具產出績效報告，作為評核的標準。
相信讀者到這邊會有幾個疑問 ：
工單得分越高是否就代表績效越好？
答案並不是絕對的。在績效結算時，我們將工單得分視為一項參考因素。真正重要的是評估該員工是否完成了與團隊和個人目標相符的項目。如果一位資深的開發人員完全專注於程式編寫，卻忽略了團隊間的溝通，導致版本Release遇到障礙，那麼即便得分很高，從結果來看，這仍是一種不符合標準職能的表現。
工單項目就緒，也進行了派工，但夥伴執行的狀況不如預期，該怎麼辦？
這時候可能會有幾種情況：
- 工單輪調：在這種情況下，工單會被轉交給其他人員處理。由於職責不同，工單的計分也將進行重新評估。這樣的做法可以確保工單能夠繼續向前推進，並且由擁有相對應技能的人員來完成。
- 品質不如預期：當開發完畢，但遭遇到像是障礙摘出數過多、CodeReview太多次仍無法改善等，這時候會由Team Leader 與版本負責人確認狀況，若無特別原因，則會斟酌扣分。
- 需求異動：當開發過程中，如不可預期因素導致正在開發中的功能強迫停止，或是要調整成其他方案，這時候的情況可能如下：
- 評估調整範圍：Team Leader和版本負責人將會共同評估因應異動所需調整的範圍。這包括確定新的目標、調整既有的計畫以及重新分配資源等，以確保項目能夠順利繼續進行。
- 重新評估計分：隨著需求的變更，原先對工作項目的計分也需要重新評估。這意味著，根據調整後的工作範圍和難度，以及團隊成員的貢獻程度，重新確定每項工作的分值。
- 需求停止時的處理：如果某個需求被決定中止，則會根據到目前為止的開發進度來給予相應的分數，為了公平反映團隊成員在該項目上的努力和貢獻。
協調夥伴目標的過程當中，是不是有可能大家會挑工作，苦差事兒沒人做？
當然，這種現象很普遍，並且確實可以說是一個關乎人性的問題。在這種情況下，重要的是要傳達一個核心觀念給團隊成員：為了團隊的整體利益，有時需要作出個人利益的犧牲。這意味著在工作分配上，應該以達成團隊的整體目標為首要。
相對來說，可能對於身為領導者的你需要注意幾點，
- 盡可能公平的分配工作：避免特定夥伴工作負擔過重，因此妥善分散掉工作內容是很重要的。
- 激勵與肯定 ：當夥伴完成相對複雜的工作時，應適度給予激勵。
- 團隊精神的渲染 ：當然，團隊文化建立後，也將帶給其他團隊，甚至是新進夥伴。
- 取得信任：經歷過幾個版本的迭代，也陪著一起面臨到很多不同的挑戰，最終，取得夥伴對你的信任。
實際操作
嘗試在 Sprint Board 進行設定，需要先認識幾個基本的核心單元，介紹如下：
專案(Project)
- 代表一個整體的開發工作，並且包括了進行該項目所需的所有要件，如：Git Repository、CI/CD Pipeline等等。
小組(Team)
- 每個Project可以包含一個或多個Team，每個Team負責專案中的特定部分或功能，小組可以有自己的工作項目、Spints Board和DashBoard等，以支持團隊的日常工作和溝通。
衝刺(Sprint)
- 為規劃和追蹤工作進度的關鍵週期，所有團隊的工作框架均與版本同步，每個版本對應一個Sprint週期，通常持續四到六週。在此期間，各團隊致力於完成於該版本既定的工作項目，最終讓功能順利上線。
區域(Area)
- 用於分類工作項目，以利追蹤與管理。在我們的團隊當中，並沒有太特殊的分類，層級主要是 {專案}/{小組}/{版本}
接著，有了基本的Board框架後，我們會定義工作項目的類型與階段，基本介紹如下：
泳道(Swimlanes)
用於Sprint Board 上用於分類和工作項目的水平分段。它們可以按照不同的標準進行設置，如按照工作項目或負責人進行彙整呈現等，從而幫助團隊成員快速識別工作項目的分類，並根據這些分類來管理和追蹤進度。
狀態欄(Column)
狀態列在Sprint Board上則是垂直分段，用以標示工作項目的不同階段，例如新增、進行中、測試中..等。在版本進度的同步會議中，團隊成員會逐一審查每個工作項目，確保每個工作項目的進度狀態符合預期，使項目按時推進。
補充說明：這邊指的版本進度同步會議，是由負責這個版本的資深RD與其版本參與者進行同步，通常會在晨會之前結束，這樣在晨會時，對於主管或是不參與該版本開發成員的提問，能夠清楚地回應。
工單(WorkItem)
工單是代表團隊在 Sprint 中需要完成的具體工作項目，每個工單包含了完成該任務所需的所有相關信息，如任務描述、負責人、預計完成時間以及任務的當前狀態等。
Azure Devops 提供幾個種類的模板，可以讓使用者直接套用於Project，我們選擇 Agile ，詳細內容可以參照這裡。
如果需要客制化的欄位或是工單類型，可以至組織設定>處理序，選擇處理序後，會出現工單類型的清單，這時候你可以選擇新增，或是對於特定類型內的欄位進行編輯。
在欄位的設計上，除了基本的內容，像是負責人、開始與結束時間外，可能要考慮到未來要分析時，會拿來進行彙整統計的欄位，如：平台名稱、業務別甚至專案別等，在下個章節中會提到。
總結
這篇文章著重於介紹如何將團隊目標與夥伴期望整合成工單評分標準的流程。闡述了在確定版本需求之後，如何有效地安排Sprints Board，以及如何設定工單的基礎要素。
接下來的文章將從管理層面出發，探討如何對這些資訊進行有效整理，以便快速釐清多個版本並行進展的整體情況，並進一步識別出表現優異的團隊成員。
