---
# System prepended metadata

title: 計劃趕不上變化 變化靠GitLab Issue具體化(上)

---

# 計劃趕不上變化 變化靠GitLab Issue具體化(上)
提到GitLab，可能許多人認為只是自建 Git Server 或是執行 CICD 的其中一種工具，但其實GitLab的功能無論從專案管理面，或從開發維運面，都能滿足軟體開發至部署的各階段需求，團隊成員能夠在單一平台上協作，PM更能及時掌握開發狀況。
本篇將以PM角度介紹GitLab如何幫助團隊降低開發成本，同時提高開發人員的生產力，讓我們繼續看下去~

## 你以為的專案管理？
很多時候我們可能會認為，做了一個好的專案管理計畫，裡面針對需求進行了縝密的分析，並根據需求分析了完整的範疇，接著做了適當的人力資源安排，然後搭配完美的專案時程，一切計畫還在公司的預算內！天啊，這個計畫太完美了！肯定萬無一失！
![](https://i.imgur.com/XEOe2Ug.png =400x)



但是....
![](https://i.imgur.com/Pog74b7.png =200x)


我們可能會因為老闆的一句話，整個專案計畫就必須重來...

可能因為隔壁的同事，隔天突然就不來上班了，找不到人可以交接，專案進度將大延遲...

也可能因為公司突然宣布預算考量，整個專案必須立即停止！

這些風險無時無刻都在發生，實際上的專案管理是如此波濤洶湧、暗藏危機。
![](https://i.imgur.com/n9FCkMj.png =400x)


或許你會想，如果有工具可以幫助我們即時掌握這些風險，是不是能減少一些專案管理路上的風風雨雨呢？

那何不試試GitLab呢？

## GitLab Issue太神啦
在介紹GitLab Issue有多神之前，我們可以先將Issue視為開發團隊成員各自的工作項，而整個Issue的生命週期分為六個階段：

![](https://i.imgur.com/q4uw5jc.png =600x)

1. Create Issue : Issue建立
2. Review Issue : Issue確認及開發
3. Approve Issue : 執行同意
4. Merge Issue : 合併程式碼
5. Test Issue : 執行測試
6. Close Issue : Issue關閉

在生命週期的過程中，GitLab提供讓所有團隊成員能夠在單一平台上進行協作，掌握彼此開發進度。
舉例來說：
1. UIUX同仁開立了一筆UI效果調整的Issue，我們可以在GitLab的Issue畫面上看到Issue的位置/狀態/開立人員/內容，如下圖：
![](https://i.imgur.com/PkOTtyV.jpg =500x)


若有其他相關連的Issue，也可以進行連結，以利掌握功能開發進度，並提供其他團隊成員參考：
![](https://i.imgur.com/HuiVxxA.png =600x)

Issue的內容也可以根據團隊的需求來制定範本，可以避免團隊成員撰寫內容的習慣不同而導致理解錯誤，若剛開始製定團隊的Issue Template，建議可以使用3W1H來描述Issue的內容，或許你會說，不是5W1H應該更詳細嗎？因為GitLab很貼心的把When與Where都幫我們準備好了。
如下圖，我們可以在Issue內清楚的看到這個Issue是在哪個Epic(Where)內執行，以及是開立在哪個Milestone(When)內。
![](https://i.imgur.com/dwSBYIO.png =200x)
所以在Issue的內容我們僅需說明：
* What：描述Issue的內容
* Why：執行此Issue的原因
* Who：需求的來源
* How：執行此Issue的做法

當然，你可以根據產品的性質或團隊的習慣設定各種不同的範本，更詳細的設定的方式可以參考GitLab官方文件[Description templates](https://docs.gitlab.com/ee/user/project/description_templates.html)。設定完成後，團隊成員在開立Issue的時候只要根據Issue的類型選擇對應的範本，如下圖：
![](https://i.imgur.com/EoZT0xA.png =250x)


2. 接著由PM及UIUX進行Review，PM會Review Issue開立的內容是否符合需求，UIUX則會Review Issue的開發是否符合UI的設計，當然，團隊的Leader可以隨時Review Issue，掌握團隊的開發進度。
![](https://i.imgur.com/aFbGyIS.png =600x)
3. 開發完成後，前端同仁可以指派UIUX進行Approve，除了通知UIUX同人已開發完成，也可以再次確保開發符合UIUX設計。
![](https://i.imgur.com/brHmk3c.png)

4. 按下Approve後，前端同仁就可以進行Branch的Merge，我們可以在Issue下方看到目前Merge的狀況，以及是由哪幾位團隊成員進行Approve的，日後如果要吵架，就有證據了(誤)
![](https://i.imgur.com/MOxiCVc.png)

5. 完成Merge後PM與UIUX即可在測試環境進行測試，確認此功能是否開發完成以及有無bug，並將測試計畫與結果記錄在Issue下方。
![](https://i.imgur.com/DaDfe3H.png)

根據以上的例子，我們可以看到團隊的成員能夠在Issue的不同階段進行參與，並且只需要透過單一平台-GitLab，就可以完成開發的流程。
有別於以往專案團隊成員可能各自使用其熟悉的工具，而PM需要透過不同的方式掌握進度，還必須保持資訊即時性與正確性，團隊成員各自努力，卻因為工具的不相容，而降低了工作效率，這些問題GitLab都幫我們解決了，是不是迫不及待的想為你的團隊升級專案管理工具了呢？
## Kanban一打開 敏捷好簡單
介紹完了團隊成員在GitLab共同協作的價值，或許你還會說，可是我的團隊正在執行敏捷開發，Gitlab也可以協助我嗎？
當然，GitLab幫你準備好了Issue kanban，只要先根據你的需求設定好Sprint的區間-Milestone，可以根據產品預設的開發時程設定Milestone的起訖日，也可以將整年度依固定單位劃分Milestone，更詳細的介紹可以參考官方文件[Milestone](https://docs.gitlab.com/ee/user/project/milestones/#milestones)。
![](https://i.imgur.com/Eh7FsSb.png)
設定完Milestone後，不論你是執行Daily  Review或是Sprint Review，只要在Issue Kanban上設定相對應的條件，都可以輕鬆掌握開發狀況(如下圖)。有關Issue Kanban還有各種彈性的使用方式，可以參考官方文件[Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards)。
![](https://i.imgur.com/WUszq2o.png)


本篇以日常開發的角度分享團隊成員在單一平台協作的價值，下篇將會以更高層次的企業目標來說明，若掌握了組織的預算，或是需要進行公司產品藍圖的規劃，我們可以如何在GitLab上實現呢？
敬請期待～

