分享:透過 Azure Devops Server 瀏覽團隊工作狀況 (Part1)

Anthony Chen
Feb 10, 2024

--

前言

在當前的資訊科技產業中,作為一名管理中小型團隊的領導者,常常需要扮演多重角色 — — 從技術決策制定、系統設計、項目開發進度規劃到親自參與Coding…等。面對這種角色多樣化且需同時兼顧的狀況下,如何有效地整合並同步團隊成員的工作,以及將其成效量化為具體的績效指標,是一項艱鉅的挑戰。

每間公司組織的人文背景不同,不能以一概全,但希望以下的想法可以幫助到各位看倌。

進入正題

團隊配置與實質挑戰

PO <-> RD<-> QA
basic workflow

PO TEAM

對每個版本進行項目的安排,這些項目範圍不一,從小型調整(例如新的Logger格式到Grafana analytics)到關鍵大功能(例如帳務計算方式的調整)。他們根據不同的功能需求和客戶期望,將這些項目安排到各個版本中進行開發。在實際情境中,通常不會僅有單一版本的開發,而是多版本並行開發的情況更為常見。

RD TEAM

根據每個版本的需求來配置開發人員。如果用k8s來比喻開發團隊的調度方式,每個node(RD Group)都被指派給一個版本。對於開發範圍較大的版本,則會配置更多的pod(RD)在這個版本上進行開發。整體上,開發人員的分配是根據項目需求和實際情況靈活制定的。

QA TEAM

由於團隊性質的差異,QA團隊的作業方式通常是按照版本順序進行測試,較少出現並行測試的情況。然而,在實際時程上,由於不同的開發和測試流程,有時可能需要進行協調以確保順暢進行。

技術團隊的隱性挑戰

有一種忙,是RD認為的忙

成員經常在跨版本的調度中忙碌轉換,這種切換不僅增加了額外的開銷,也使得團隊成員承受時程壓力。這種忙碌常常是非生產性的,因為它來自於頻繁的上下文切換以及對多個任務同時進行跟蹤和管理的需求,也有可能是在工作上並未制定完善的流程,如(UnitTest、CodeReview、Coding Style..),甚至是對需求不明確的狀況下貿然進行開發,而導致不必要的重工。與版本的壓力交互作用下導致倦怠,進而影響團隊成員的工作成效。

有一種慢,是主管認為的慢

從主管的角度看,項目進展的緩慢往往是因為缺乏對團隊當前工作狀態的深入了解。缺少這種透明度讓主管難以準確評估項目時程和資源分配,進而可能對團隊的工作速度有錯誤的期望。這種誤解不僅影響了主管與團隊成員之間的關係,也可能導致不切實際的壓力和目標設定。

鄙視鏈

技術團隊內部的分工往往涵蓋了廣泛的專業領域,從基礎設施建設到程式開發,再到測試和文檔編寫。這種多樣性雖然是團隊力量的來源,但也可能導致價值觀的碰撞和衝突。當團隊成員從各自的專業角度出發,忽略了其他角色的貢獻和挑戰時,就會形成所謂的「鄙視鏈」。這不僅削弱了團隊合作的精神,也影響了工作氛圍和團隊成員之間的相互尊重。

對於具有管理經驗的專業人士,以下問題可能會引起共鳴:

  • 如何有效協調項目時程?
  • 如何估算RD團隊間調度的成本(尤其是領域知識的掌握程度)?
  • QA的工作Loading是否可能成為開發過程的瓶頸?

等等問題。

從上述討論中,我們識別到的核心問題是如何確保各團隊間的運作資訊能夠有效同步。透過建立透明的溝通管道,我們能夠:

  • 提前規劃專案進程:對近期版本進行深入分析,識別任何可能導致開發延遲的障礙。這樣做可以幫助我們在未來的版本安排中更加謹慎地評估功能範圍,並考慮人力資源的最佳分配策略。
  • 跨團隊的調度:不僅僅著重於工作分配,也鼓勵跨團隊的合作,如:RD團隊成員支援QA的測試工作。這樣的安排不僅促進了技術知識的共享,也提供了一個機會,讓開發者能從最終使用者的視角出發,深入理解系統的操作流程。這種從使用者角度出發的理解,能夠有效地提升產品的可用性和用戶體驗,同時增強團隊成員之間的溝通和協作。
  • 濃縮工作範圍:這不意味著刪減工作內容,而是專注於將當前工作範圍縮減到滿足核心需求的最小可行產品。這類似於QA團隊進行回歸測試的過程,即在版本範圍確認無需調整的情況下,優先測試關鍵功能。

啟發例子

以電影《絕地救援》為例,當面臨火星上太空人生存危機時,各領域的專家迅速匯聚,通過創新的解決方案和緊密合作,其中一幕是為了要遙控接駁小艇升空,為了在有限條件下減少重量,把推進火箭的鼻錐、窗戶、控制台、座椅等等拆掉,僅剩下一張椅子和船殼。最終成功制定出救援計畫。這一過程不僅展示了跨領域協作的力量,也強調了在壓力之下通過集體智慧找到解決方案的重要性。

接著我會開始詳細說明使用一些工具/方法來滿足資訊透明化的目標。

1.團隊活動的運作

團隊活動的核心圍繞著需求的生命週期管理,從提出需求到最終的部署上線。這一過程不僅記錄了系統層面的變更,也促使團隊運作方式的進化。通過明確劃分各階段的責任和任務,整個團隊能更高效地協同工作,確保每一步驟都能順利完成。

2.kanban / 工作職責說明

需求被細分為一系列具體的系統工作內容,形成許許多多的工單(tickets)。這一階段,我們關注工單的生命週期及如何與跨團隊成員的聯繫,從而揭示了工單質量與團隊職責分配之間的直接關係。明確的職責分配不僅提高了工作效率,還確保了工作質量的標準,最終連結績效。

3.dashboard / PowerBI

通過Dashboard和PowerBI工具,我們對工單數據進行可視化展示,從不同維度出發,如版本角度、個人貢獻,以及跨版本的總覽,提供了一個全面的數據視角。這種數據呈現方式不僅讓團隊成員能夠實時掌握項目進度和個人貢獻,也為管理層提供了基於數據的決策支持,進一步增強了團隊的透明度和協作效率。

總結

通過實施這些工具和方法,我們可以提升團隊之間的資訊透明度,從而促進更有效的溝通和協作。Kanban板和清晰的工作職責劃分幫助團隊成員理解自己的角色和任務,而Dashboard和PowerBI則提供了分析支援,讓團隊基於實際數據做出更快、更準確的決策。總之,這些策略共同交互作用下,不僅提升了團隊的工作效率,也建立了透明的工作環境。

--

--