# 計劃趕不上變化 變化靠GitLab Issue具體化(下)
上篇以日常開發的角度分享團隊成員在單一平台協作的價值，本篇將會以更高層次的企業目標來說明，若身為Team leader 掌握了組織的預算，或是Product Owner需要進行公司產品藍圖的規劃，我們可以如何在GitLab上實現呢？讓我們繼續看下去吧！
## 好的開始是成功的一半
在帶領你的團隊進入GitLab之前，先在GitLab上根據你的團隊性質或目標建立完整的組織架構，能夠讓日後專案管理事半功倍，而GitLab提供的組織架構圖如下：
* __Group__：建立主Grorp，以部門或單位為主

* __Sub Group__：若部門規模較大，可以再拆分出Sub Group，例如R&D部門下還有Frontend與Backend...等小組，就可以將其設定為Sub Group，以利拆分專案
* __Project__：接著就可以開始建立團隊的專案

* __Issue__：在專案裡就可以開立不同的Issue，Issue內會有詳細資訊如下：
* *Comments：團隊成員對於此Issue的開發方式與測試結果的說明*
* *Participants：Issue的參與者*
* *Assignment：受指派處理此Issue的人員*

有關Issue的使用方式與詳細說明可以參考[上篇](https://www.gaia.net/tc/news_detail/2/181/gitlab-gcp-1)的介紹。

而我們公司在GitLab上的組織架構如下：

我們其實透過不同的架構，建立了幾個GitLab的服務，遵循GitLab發展微服務的腳步，最後我們選擇用微服務的方式搭建GitLab，搭建在K8s之上，目前使用的是Google Cloud的GKE。
我們將開發團隊設定為主要的Group，在開發團隊內有兩個小組，分別為 Development Team與 DevOps Team，分別設為Sub Group。
接著開立各自的Project，舉例來說，目前Develop Team正在開發的專案為雲端帳務系統，我們為前後端開立了各自的Project，DevOps Team會負責雲端帳務系統環境的建立以及其他Presales的相關業務，所以在其底下開立了其所屬的兩個project，接著將帳務系統內的各個功能拆分為Epic，Epic可以跨Project共用，接著開立工作項-Issue，Issue彼此之間可以進行關聯。
若一開始進入GitLab就規劃好組織架構，日後在GitLab上進行專案的管理與開發之路才能一帆風順，開始動手規劃屬於你的組織架構吧！
## Epic是什麼好東西
看完了上節分享蓋亞在GitLab上建置的架構，或許你會疑惑，怎麼會突然出現Epic，那是什麼？

Epic是GitLab提供給升級至 __Premium__ 以上用戶的服務，我們可以將Epic視為Business Scope，可能是公司的產品或是系統上的功能。
而Epic與上篇提到的Milestone功能都可以關聯Issue，兩者又有什麼區別呢？這邊為大家整理如下圖：

* __Epic__：Business Scope像是目標、產品或功能
* __Sub Epic (升級至Ultimate的用戶)__ ：雖然Epics 和 Issues 搭配使用，已為長期目標計劃提供靈活性。這樣的設計仍然僅限於提供兩層的結構，若升級至Ultimate，您可以創建多層的工作分解結構，可以將更長期的戰略計劃或組織目標表示為主Epic，然後在這些Epic之下建立多個Sub Epic，將它們分解為更具體的可交付成果，提升開發效率。

* __Label__：可以為Epic設定Label，例如：此Business Scope是目前組織的主要目標，則設定為Urgent
* __Comment__：在Epic內有Comment功能，可以看到Team leader或Product Owner針對此Business Scope的看法或期待
* __Participants__：公司可能同時有好幾個目標或產品在開發，可以為不同的Epic設定不同的團隊成員

* __Milestone__：Time Box可以依專案需求設定短期或長期的區間
* __Burndown Chart__： 可以看到在Milestone內Issue開立與執行的進度
* __Link to merge requests__：可以在Milestone內直接連結到該區間內Merge的Request

介紹完Epic與Milestone的功能後，在GitLab的kanban中，我們可以以更高層次搭配兩者使用：


以上圖為例，左邊的圖是以Epic Roadmap的角度，可以清楚的看到Epic 關聯的每一個 Issue，清楚的呈現了 Issue 的層次結構，幫助我們將重點放在未來產品的規劃和戰略方向。
而右邊則是以 Milestone Kanban 清楚展示Issue的進度，幫助我們掌握開發的狀況。
對於企業而言，Epic 和 Milestone 都是不可缺少的兩個功能，Epic 是基於客戶的解決方案，模擬客戶實際使用系統的功能，幫助企業去規劃整個產品藍圖，而 Milestone 可以衡量工作項目的實際進度，快速交付產品，所以在整個軟體研發過程中，兩者相輔相成，缺一不可。

## 權限控管做得好 開發才能沒煩惱

在專案管理的過程，常常會花費許多時間在接收並非我們必須知道的資訊，可能會造成專案效率的降低或是對資訊產生其他的誤解。舉例來說，身為PM主要關心的會是Issue的開發進度與上版的狀況，而對於開發人員寫的程式碼細節相對了解程度較低。
透過GitLab多層次的權限管控，除了提升專案安全度，還能根據團隊成員身份設定不同角色及功能。

GitLab提供的權限如下：


* 第一層權限控管：User 的 Access Level 
1. 一般使用者（Regular users）：只能存取自己建立的 Group 與 Project
2. 外部使用者（External users）：只能存取被設定為公開的 Project
3. 管理人員（Admin）：能夠存取所有的 Group 及 Project，並且有權限操作 Admin 的功能，如新增專案成員與設定權限..等
* 第二層權限控管：Visibility Level 與 Member 
主要判斷登入者的身份是否已經註冊為 GitLab 用戶，以及被加入在哪個 Group 或 Project 來控制權限。這邊要注意的是Project 本身會受制於 Group 的 Visibility Level，例如： 當Group 被設定為 private，則該Group內開立的Project 的 Visibility Level也只能設定為 private。
* 第三層權限控管：Member Permissions
主要用來設定使用者在 Project 內到底能使用哪些功能和執行哪些動作，例如：使用者被設定為Developer，則能夠建立 branch ; 若被設定為Maintainer，則可以進行code review...等。
有關更詳細的權限設定可以查看GitLab的[官方文件](https://docs.gitlab.com/ee/user/project/members/)。

## 使用GitLab 一切都Hub
在上篇以日常開發的角度分享團隊成員在GitLab協作的價值，本篇以更高層次的企業目標來說明如何透過權限控管與 Epic / Milestone 的功能，在GitLab上實現組織目標與產品藍圖的規劃。

GitLab已不再只是自建Server或是CICD的工具，更不只是開發人員或DevOps的專屬名詞。在GitLab上，以團隊中小的任務需求單位開始管理(Issue)，將所有任務集結起來成為專案並能隨時掌握進度(Project)，多個專案統整後達成整個企業的願景(Sub Epic)與最終的目標(Epic)，帶領企業與組織內部朝向同方向前進。完善的軟體開發工作流程可以為專案團隊帶來新的里程碑，小至每日進度，大至年度目標，都能一手掌握！

還在挑選適合你的專案管理工具嗎？心動不如馬上行動～