上一篇先把：
Git
GitHub
Azure DevOps
三個東西分清楚了。
以前寫 React 時，我比較熟悉的是：
VS Code
↓
Git
↓
GitHub
進公司後則變成：
Visual Studio
↓
Git
↓
Azure DevOps
但真的打開 Azure DevOps 之後，第一個問題其實不是：
我要怎麼 Push？
而是：
蛤？
我的工作到底在哪裡？
因為左邊會看到：
Boards
Repos
Pipelines
點進 Boards 又有：
Work Items
Boards
Backlogs
Sprints
工作單裡又會看到不同類型：
Feature
Product Backlog Item
Task
一開始全部看起來都很像：
反正都是一張單？
後來實際開始跟著公司的流程做，才慢慢理解：
Azure DevOps 不只是放程式碼。
在開始寫程式以前，
工作本身其實就已經在 Azure DevOps 裡被整理好了。
所以這篇先不碰 Branch，也先不碰 Commit。
先弄懂一件事：
我進 Azure DevOps 之後，到底要去哪裡找到自己這次要做的工作？
上一篇有提到，Azure DevOps 是一套團隊開發協作平台。
裡面常見的功能有：
Boards
Repos
Pipelines
Test Plans
Artifacts
但目前最先要看的其實是：
Boards
因為：
Repos
比較接近「程式碼在哪裡」
Boards
比較接近「現在到底要做什麼」
在公司裡，一個需求通常不會只是有人走過來說：
欸，這邊幫我加一顆按鈕。
然後工程師就直接開始改。
實際上通常還需要：
需求紀錄
工作項目
負責人
預計開發時間
工作狀態
這些資訊。
Azure Boards 就是在管理這些工作的地方。
公司裡可能不只有一個系統，也可能不只有一個 Azure DevOps Project。
進入 Azure DevOps 後，第一件事情就是：
先確認自己現在進的是哪個 Project
因為不同 Project 裡可能有不同的：
Boards
Work Items
Repository
Pipeline
團隊成員
如果 Project 進錯，後面可能連工作單都找不到。
所以我現在會先確認：
Organization
↓
Project
↓
Boards
再開始找自己的工作。
進入：
Boards
後，常會看到：
Work Items
Boards
Backlogs
Sprints
一開始我真的很容易把它們混在一起。
後來我會先這樣記：
Work Items
↓
看工作項目
Boards
↓
用看板方式看工作狀態
Backlogs
↓
看還有哪些工作等待安排
Sprints
↓
看這個開發週期正在處理哪些工作
先不用把每個功能學得很深。
只要先知道：
它們不是四種不同的工作單
而是用不同角度
查看同一批工作資料
這樣就比較容易理解。
我最先接觸的是：
Boards
↓
Work Items
Work Item 可以先理解成：
Azure DevOps 裡用來記錄一件工作的基本單位。
例如可能是：
一個大需求
也可能是：
某個功能
或：
某個工程師真正要執行的工作
實際要看它是哪一種類型。
在 Work Items 裡，可以看到很多工作項目。
不一定只會看到：
現在 Assigned 給我的工作
也可能看到其他團隊成員或其他狀態的項目。
所以我會先把：
Work Items
理解成：
工作項目的查詢與管理入口
而不是：
我的待辦清單
點進一張工作項目後，可能會看到：
ID
Title
Assigned To
State
Iteration
Description
Parent / Child
Links
Discussion
不同公司可能會再加自己的欄位。
例如：
類型
系統別
預估工時
需求單號
版本
等等。
但核心概念差不多：
這件事情是什麼？
誰負責？
現在做到哪裡？
它跟哪些其他工作有關？
所以 Work Item 不只是：
一個標題
而是在保存整件工作的資訊。
接下來是我一開始最容易亂掉的地方。
我們的工作不是只有：
一張單
而是會再往下拆。
我自己一開始是用：
阿公
爸爸媽媽
小孩
來記 XD
大概就是：
Feature
↓
Product Backlog Item
↓
Task
也就是：
大需求
↓
需求裡要完成的項目
↓
工程師真正執行的工作
在我們目前的流程裡，最上層會看到：
Feature
我自己筆記會把它叫：
紫單
因為畫面上的類型顏色比較容易辨認。
Feature 可以先理解成：
一個比較大的需求或功能範圍。
例如假設有一個需求：
建立員工資料查詢功能
這件事情可能不是改一行程式就完成。
裡面可能包含：
建立查詢頁面
建立 API
增加權限判斷
增加查詢條件
所以 Feature 比較像：
上層需求
而不是工程師真正拿來寫程式的最小工作。
在我們公司的實際流程裡，這層也可能對應到原本的需求來源或需求單。
這是公司的工作項目設計，不代表所有 Azure DevOps 團隊都一定使用完全相同的層級。
Feature 下面可能再建立：
Product Backlog Item
簡稱常會看到：
PBI
我自己的工作筆記把它記成：
藍單
可以先把它理解成：
從較大的 Feature 裡，再拆出一個比較具體、可以安排進開發週期的需求項目。
例如：
Feature
員工資料查詢功能
下面可能拆成：
PBI
建立員工查詢畫面
以及：
PBI
建立員工資料 API
或者其他團隊實際需要的工作內容。
所以可以理解成：
Feature
比較大
↓
PBI
比較具體
PBI 再往下，可能會看到：
Task
我自己的筆記會叫：
黃單
Task 就更接近：
某個工程師實際要完成的一件工作。
例如：
Feature
員工資料查詢功能
↓
PBI
建立員工查詢頁面
↓
Task
完成查詢條件 UI
或者：
Task
串接員工查詢 API
所以整體可以先畫成：
Feature
大需求
↓
Product Backlog Item
較具體的需求項目
↓
Task
真正要執行的工作
這樣我才開始理解：
不是每張單都拿來直接寫程式。
有些是在管理：
需求範圍
有些是在管理：
開發項目
有些才是：
這次我真正要做什麼
如果正式名稱還不熟，我會先這樣記：
Feature
紫單
阿公
↓
Product Backlog Item
藍單
父母
↓
Task
黃單
小孩
不是 Azure DevOps 官方叫法。
只是我自己拿來理解階層。
因為一看到：
Parent
Child
就比較容易知道：
誰包誰
例如：
Feature
├─ PBI A
│ ├─ Task A-1
│ └─ Task A-2
│
└─ PBI B
├─ Task B-1
└─ Task B-2
這樣就比只看到：
一堆 ID
清楚很多。
Azure DevOps 工作項目之間可以建立關聯。
其中很常看到：
Parent
Child
例如：
Feature
是：
PBI 的 Parent
而：
PBI
則是：
Feature 的 Child
同樣：
PBI
可以是：
Task 的 Parent
所以：
Feature
↓
PBI
↓
Task
其實不是三張互不相關的單。
而是：
有階層關係的一組工作
這也讓團隊可以從大需求一路往下看：
這個需求到底拆出了哪些工作？
假設今天要建立：
Feature
不能只是：
New Work Item
↓
隨便選 Task
因為 Work Item Type 不同，代表用途也不同。
例如我們目前流程可能會看到：
Feature
再新增 Child：
Product Backlog Item
再往下新增：
Task
所以我建立之前會先確認：
這張單是大需求？
還是需求裡的項目？
還是我要實際執行的 Task？
再選對類型。
接著是：
Boards
這裡比較不像 Work Items 那樣：
一列一列看清單
而是用：
Kanban Board
看板
方式呈現。
可能會看到：
New
Active
Resolved
Closed
或其他狀態。
實際欄位名稱要看團隊怎麼設定。
概念就是：
待處理
↓
處理中
↓
完成
讓大家不用點進每一張單，也能大概知道：
哪些事情還沒做？
哪些正在做？
哪些已經完成？
所以：
Work Items
比較像工作項目清單
Boards
比較像工作狀態看板
接著：
Backlogs
Backlog 可以先理解成：
還在需求池裡、等待安排或持續管理的工作。
例如團隊目前可能有：
20 個需求
但這個 Sprint 不可能 20 個全部做完。
所以有些會被安排到：
目前 Sprint
有些可能還留在：
Backlog
等之後再安排。
我現在會簡單記：
Backlog
↓
還有哪些事情在排隊
接著就是很常聽到的：
Sprint
Sprint 可以先理解成：
團隊設定的一個開發週期，在這段時間內安排要完成哪些工作。
例如：
Sprint 1
8/1 ～ 8/14
可能安排：
Task A
Task B
Task C
下一個：
Sprint 2
8/15 ～ 8/28
再處理其他工作。
實際一個 Sprint 多久，是團隊自己決定。
不是 Azure DevOps 規定一定：
兩週
只是 Scrum 團隊很常會看到固定週期的做法。
進到：
Boards
↓
Sprints
會比較聚焦在：
目前這個 Sprint
被安排進來的工作。
例如可能看到：
To Do
In Progress
Done
假設我的：
Task
被安排進目前 Sprint。
就可以在 Sprint 裡看到它。
所以我自己的簡化記法是：
Work Items
全部工作項目
Sprints
這個開發週期正在處理的工作
這樣就不容易搞混。
在 Work Item 裡還可能看到：
Iteration
這個就是跟：
Sprint / 開發週期
有關。
例如：
Iteration Path
Project\Sprint 2026-08
代表這張工作被安排到：
某一個 Sprint
所以如果一張 Task：
明明存在
但在目前 Sprint 找不到。
我現在就會開始檢查：
它的 Iteration 是哪一個？
如果被移到別的 Iteration：
目前 Sprint 畫面
當然就可能看不到。
但它沒有被刪掉。
還是可以在：
Work Items
找到。
這也是剛開始很容易嚇到的地方。
假設我在目前 Sprint 有一張：
Task #1234
結果把它：
Move to iteration
移到另一個開發週期。
下一秒：
目前 Sprint 看不到了
第一反應很可能是：
蛤？
我把單刪掉了？
其實沒有。
只是它：
不屬於目前這個 Sprint
了。
所以可以到：
Work Items
找它。
或切到：
對應的 Iteration / Sprint
就會重新看到。
我目前最簡單會這樣分：
Work Items
我想找：
某一張工作單到底在哪？
Sprints
我想看：
目前這個開發週期大家正在做什麼？
例如：
找不到某一張 Task
我比較會先去：
Work Items
如果想知道：
這個 Sprint 我有哪些工作？
再去：
Sprints
假設今天有一個需求：
員工詳細資料頁新增部門資訊
為了理解，可以假設它被整理成：
Feature
員工資料功能調整
↓
Product Backlog Item
員工詳細資料頁調整
↓
Task
新增部門資訊顯示
然後 Task 被安排到：
Sprint 2026-08
這時工程師真正開始工作時，會看到：
Task
新增部門資訊顯示
而不是只看到最上層那句：
員工資料功能調整
這就是為什麼需求要拆層級。
因為：
需求管理
和：
工程師真正執行的工作
粒度不一樣。
工作項目不只是自己存在。
後面還會慢慢看到它可以跟：
Branch
Commit
Pull Request
建立關聯。
例如：
Task #1234
可以綁：
feature branch
這樣之後看到這張 Task，就能知道：
這張工作是在哪支 Branch 開發？
反過來看 Branch，也可以知道：
這支 Branch 是為了哪張工作單？
這就是 Day 28 要開始做的事情。
如果公司同時有：
很多需求
很多工程師
很多 Branch
Branch 只叫：
test
或：
new
過幾天真的會不知道：
這支到底幹嘛的？
如果 Branch 可以跟：
Task
關聯。
之後就比較容易追：
需求
↓
Task
↓
Branch
↓
Commit
↓
Pull Request
這也是 Azure DevOps 跟單純：
我自己把程式 Push 到 GitHub
感受很不一樣的地方。
開始有：
整套工作流程
被串起來。
不是。
這點很重要。
Azure DevOps 可以依照團隊使用的 Process，看到不同類型的 Work Item。
所以：
Feature
Product Backlog Item
Task
是常見的一種組合，但不同團隊的：
層級
欄位
命名
流程狀態
都可能不同。
而像我筆記裡的：
紫單
藍單
黃單
更是公司內部方便辨識的說法。
所以這篇是在記錄：
我目前工作的流程怎麼使用 Azure DevOps
不是說：
所有公司的 Azure DevOps 都一定長這樣。
現在如果要開始一件工作，我不會打開 Azure DevOps 後到處亂點。
大概會先確認：
第一步
Project 對不對？
↓
第二步
Boards
↓
第三步
Work Items / Sprints
↓
第四步
找到自己要處理的工作
↓
第五步
確認 Work Item Type
Feature？
PBI？
Task？
↓
第六步
確認 Assigned To
↓
第七步
確認 Iteration / Sprint
↓
第八步
看 Parent / Child 關係
↓
第九步
確認自己真正要做的是哪張 Task
到了這一步：
我才知道這次到底要做什麼。
第一次進 Azure DevOps，我最容易犯的錯就是：
一看到一堆工作單
就覺得全部都是一樣的東西。
其實不是。
先分兩件事。
第一個是：
我要用什麼方式看工作？
Work Items
↓
找工作項目
Boards
↓
看工作狀態
Backlogs
↓
看待安排的工作
Sprints
↓
看目前開發週期的工作
第二個是：
這張工作項目是哪一層？
我們目前的流程可以先理解成：
Feature
紫單
大需求
↓
Product Backlog Item
藍單
較具體的需求項目
↓
Task
黃單
實際執行的工作
所以整體其實是：
需求
↓
拆工作
↓
安排 Sprint
↓
工程師取得 Task
而不是：
收到需求
↓
馬上打開 Visual Studio 改程式
到這裡，我終於找到：
這次真正要做的 Task
但還有下一個問題：
好，我知道我要改什麼了。
那我是不是直接打開 main 開始改？
還是要先建立自己的 Branch？
Azure DevOps 上建完 Branch，
為什麼 Visual Studio 又找不到？
Clone、Fetch、Pull、Checkout 又是什麼？
下一篇就接著處理：
工作單怎麼變成我的 Branch？從 Azure DevOps 建分支到 Visual Studio Checkout。
iThome鐵人賽
看影片追技術