經過前幾天的進度，我們假想情境中的團隊已經有了基本的 CI/CD 環境可以使用，現在開發工作已持續推進，團隊的 Developer 正在解 Issue/Feature，撰寫程式碼。

To-DO List

團隊的 Developer 準備開工，首先他登入 GitLab，點擊右上角的 To-Do List，查看目前有哪些還沒處理的工作。

每個 User 都有自己的 To-Do List，可以快速查看目前有哪些工作是分配給自己，或者哪個 Comment 有提及（mentioned）自己，必須盡快查看資訊了解狀況。

透過 To-Do List，Developer 很快發現 Senior Developer 在一個新的 Issue 中提到了自己，於是前往查看這項 Issue 的內容。

（To-Do List 會顯示 Issue 的基本資訊，以及為何該項 Issue 會被列於 User 的 To-Do List 之中。）

點擊進入 Issue，Developer 透過 Issue 異動的歷史資訊得知這是 PM 新開立的一張 Issue，並且同樣被規劃在 Milestone - Sprint 1 的工作範圍內。原本是 Assignee 給 Senior Developer，但現在則被分配給自己處理，看來這個 Sprint 無緣無故的被增加工作量了，等下先留個 Comment 抗議一下，晚點再上 Mattermost 詢問一下確切的詳細狀況。

（Issue 的詳細資訊頁面會顯示所有的重要資訊，並且 User 可以在此透過 Comment 進行討論。Comment 支援 Markdown 格式，並可以直接插入檔案、圖片等資源。）

在 Issue 詳細資訊的頁面分為左右兩欄。左欄會是 User 所撰寫 Issue 的內容與討論，還有異動的歷史紀錄；右欄會顯示基本資訊，像是被分派（Assignee）給誰、截止日期（Due date）、Labels⋯⋯等。GitLab CE 一次只能 Assignee 給一個 User 但 EE 或 gitlab.com 在付費升級後，則可以一次 Assignee 給多人。

（可針對 Issue 透過 Comment 進行討論，亦可針對單一 comment 往下深入討論。）

Developer 回覆了 Comment，消除此項 To-DO，接著決定優先處理這個 Sprint 原本已安排好的工作。

（只要 User 有針對 Issue 回覆 Comment，GitLab 會自動將其狀態改為 Done。特別要說明 Done 並不代表該 Issue 已經 Close，Done 代表 User 已針對該項「工作」做出應對，若有人再次 mentioned User，則該項「工作」又會再次回到 To-Do 中。）

Milestones

Developer 改從 Milestones 的角度切入，查看當前 Sprint 自己需要優先完成的工作項目。

（GitLab 針對 Project 有提供 Milestones 功能，可以檢視每個階段的工作量與工作進展。）

他發現這個 Sprint 共 5 項 Issue，其中 2 項自己正在處理中，有 1 項則是剛剛才正在抗議臨時被分配的 Issue，看來要先加緊腳步把 doing 的 Issue 解完才行。

（Milestone 頁面會列出該項 Milestone 的眾多資訊，方便管理者查看工作執行狀況。）

Milestone 頁面會列出有哪些 Issues 被分配在此，並且顯示此 Milestone 的資訊，像是 Start date 與 Due date。不過在上圖中，GitLab 也提醒 Milestone 頁面內的 Issue tabs 功能在未來將會取消，建議使用者可以用 Issue boards 或 Issue tracker 功能取代。

（要查看當前 Milestone 有哪些 Issue 需要處理，也可利用 Issue List 頁面的 Filter，進行篩選。）

（Issue List 頁面的 Filter，可以針對不同的條件進行篩選。）

（Filter 可以同時篩選多個條件。）

小結

今天我們透過 Developer 的角度使用 GitLab，GitLab 提供了方便使用的 To-Do List 幫助使用者能快速查看自己當前有哪些「工作」需要進行。Issue Tracker 使用起來也十分便捷，除了先前提過的可以用 Issue Boards 一覽全貌，也可以用 List 搭配 Filter 幫助使用者篩選 Issue。

針對專案管理，GitLab 也提供 Milestones 的功能，不管是採用傳統瀑布式或敏捷開發進行專案管理，Milestones 都會是專案管理者的好幫手。Milestones 除了可以針對 Project 設置，也能針對 Group 設置，因此如果團隊開發的產品包含數個 Project，例如前後端各自一個 Project 的時候，即可考慮設置 Group 層級的 Milestone。

如果你覺得 GitLab CE 的功能還不夠，希望能針對同一個 Milestone 之下的 Issue 作出優先順序的排列，那麼你也可以考慮付費升級 EE 或 gitlab.com 取得 Issue weight 的功能。有了 Issue weight 你就可以自己訂立一套優先順序的標準，像是 1~5，5 是最重要，或者 1~10，10 是最重要，都隨你自由訂定。

（圖片來自 GitLab 官方文件。）

今天的內容就先到這裡，明天我們會繼續跟著 Developer，看著他解完 Issue 送出 merge request，然後等著看 Senior Developer 會怎麼接招。

鐵人賽，我們明天見～

參考資料

• https://docs.gitlab.com/ee/workflow/todos.html
• https://docs.gitlab.com/ee/user/project/milestones/
• https://docs.gitlab.com/ee//workflow/issue_weight.html