計劃趕不上變化 變化靠GitLab Issue具體化(上)
提到GitLab，可能許多人認為只是自建 Git Server 或是執行 CICD 的其中一種工具，但其實GitLab的功能無論從專案管理面，或從開發維運面，都能滿足軟體開發至部署的各階段需求，團隊成員能夠在單一平台上協作，PM更能及時掌握開發狀況。
本篇將以PM角度介紹GitLab如何幫助團隊降低開發成本，同時提高開發人員的生產力，讓我們繼續看下去~
你以為的專案管理？
很多時候我們可能會認為，做了一個好的專案管理計畫，裡面針對需求進行了縝密的分析，並根據需求分析了完整的範疇，接著做了適當的人力資源安排，然後搭配完美的專案時程，一切計畫還在公司的預算內！天啊，這個計畫太完美了！肯定萬無一失！
但是…
我們可能會因為老闆的一句話，整個專案計畫就必須重來…
可能因為隔壁的同事，隔天突然就不來上班了，找不到人可以交接，專案進度將大延遲…
也可能因為公司突然宣布預算考量，整個專案必須立即停止！
這些風險無時無刻都在發生，實際上的專案管理是如此波濤洶湧、暗藏危機。
或許你會想，如果有工具可以幫助我們即時掌握這些風險，是不是能減少一些專案管理路上的風風雨雨呢？
那何不試試GitLab呢？
GitLab Issue太神啦
在介紹GitLab Issue有多神之前，我們可以先將Issue視為開發團隊成員各自的工作項，而整個Issue的生命週期分為六個階段：
- Create Issue : Issue建立
- Review Issue : Issue確認及開發
- Approve Issue : 執行同意
- Merge Issue : 合併程式碼
- Test Issue : 執行測試
- Close Issue : Issue關閉
在生命週期的過程中，GitLab提供讓所有團隊成員能夠在單一平台上進行協作，掌握彼此開發進度。
舉例來說：
- UIUX同仁開立了一筆UI效果調整的Issue，我們可以在GitLab的Issue畫面上看到Issue的位置/狀態/開立人員/內容，如下圖：
若有其他相關連的Issue，也可以進行連結，以利掌握功能開發進度，並提供其他團隊成員參考：
Issue的內容也可以根據團隊的需求來制定範本，可以避免團隊成員撰寫內容的習慣不同而導致理解錯誤，若剛開始製定團隊的Issue Template，建議可以使用3W1H來描述Issue的內容，或許你會說，不是5W1H應該更詳細嗎？因為GitLab很貼心的把When與Where都幫我們準備好了。
如下圖，我們可以在Issue內清楚的看到這個Issue是在哪個Epic(Where)內執行，以及是開立在哪個Milestone(When)內。
所以在Issue的內容我們僅需說明：
- What：描述Issue的內容
- Why：執行此Issue的原因
- Who：需求的來源
- How：執行此Issue的做法
當然，你可以根據產品的性質或團隊的習慣設定各種不同的範本，更詳細的設定的方式可以參考GitLab官方文件Description templates。設定完成後，團隊成員在開立Issue的時候只要根據Issue的類型選擇對應的範本，如下圖：
-
接著由PM及UIUX進行Review，PM會Review Issue開立的內容是否符合需求，UIUX則會Review Issue的開發是否符合UI的設計，當然，團隊的Leader可以隨時Review Issue，掌握團隊的開發進度。
-
開發完成後，前端同仁可以指派UIUX進行Approve，除了通知UIUX同人已開發完成，也可以再次確保開發符合UIUX設計。
-
按下Approve後，前端同仁就可以進行Branch的Merge，我們可以在Issue下方看到目前Merge的狀況，以及是由哪幾位團隊成員進行Approve的，日後如果要吵架，就有證據了(誤)
-
完成Merge後PM與UIUX即可在測試環境進行測試，確認此功能是否開發完成以及有無bug，並將測試計畫與結果記錄在Issue下方。
根據以上的例子，我們可以看到團隊的成員能夠在Issue的不同階段進行參與，並且只需要透過單一平台-GitLab，就可以完成開發的流程。
有別於以往專案團隊成員可能各自使用其熟悉的工具，而PM需要透過不同的方式掌握進度，還必須保持資訊即時性與正確性，團隊成員各自努力，卻因為工具的不相容，而降低了工作效率，這些問題GitLab都幫我們解決了，是不是迫不及待的想為你的團隊升級專案管理工具了呢？
Kanban一打開 敏捷好簡單
介紹完了團隊成員在GitLab共同協作的價值，或許你還會說，可是我的團隊正在執行敏捷開發，Gitlab也可以協助我嗎？
當然，GitLab幫你準備好了Issue kanban，只要先根據你的需求設定好Sprint的區間-Milestone，可以根據產品預設的開發時程設定Milestone的起訖日，也可以將整年度依固定單位劃分Milestone，更詳細的介紹可以參考官方文件Milestone。
設定完Milestone後，不論你是執行Daily Review或是Sprint Review，只要在Issue Kanban上設定相對應的條件，都可以輕鬆掌握開發狀況(如下圖)。有關Issue Kanban還有各種彈性的使用方式，可以參考官方文件Issue boards。
本篇以日常開發的角度分享團隊成員在單一平台協作的價值，下篇將會以更高層次的企業目標來說明，若掌握了組織的預算，或是需要進行公司產品藍圖的規劃，我們可以如何在GitLab上實現呢？
敬請期待～
計劃趕不上變化 變化靠GitLab Issue具體化(上)
提到GitLab，可能許多人認為只是自建 Git Server 或是執行 CICD 的其中一種工具，但其實GitLab的功能無論從專案管理面，或從開發維運面，都能滿足軟體開發至部署的各階段需求，團隊成員能夠在單一平台上協作，PM更能及時掌握開發狀況。
本篇將以PM角度介紹GitLab如何幫助團隊降低開發成本，同時提高開發人員的生產力，讓我們繼續看下去~
你以為的專案管理？
很多時候我們可能會認為，做了一個好的專案管理計畫，裡面針對需求進行了縝密的分析，並根據需求分析了完整的範疇，接著做了適當的人力資源安排，然後搭配完美的專案時程，一切計畫還在公司的預算內！天啊，這個計畫太完美了！肯定萬無一失！
但是…
我們可能會因為老闆的一句話，整個專案計畫就必須重來…
可能因為隔壁的同事，隔天突然就不來上班了，找不到人可以交接，專案進度將大延遲…
也可能因為公司突然宣布預算考量，整個專案必須立即停止！
這些風險無時無刻都在發生，實際上的專案管理是如此波濤洶湧、暗藏危機。
或許你會想，如果有工具可以幫助我們即時掌握這些風險，是不是能減少一些專案管理路上的風風雨雨呢？
那何不試試GitLab呢？
GitLab Issue太神啦
在介紹GitLab Issue有多神之前，我們可以先將Issue視為開發團隊成員各自的工作項，而整個Issue的生命週期分為六個階段：
在生命週期的過程中，GitLab提供讓所有團隊成員能夠在單一平台上進行協作，掌握彼此開發進度。
舉例來說：
若有其他相關連的Issue，也可以進行連結，以利掌握功能開發進度，並提供其他團隊成員參考：
Issue的內容也可以根據團隊的需求來制定範本，可以避免團隊成員撰寫內容的習慣不同而導致理解錯誤，若剛開始製定團隊的Issue Template，建議可以使用3W1H來描述Issue的內容，或許你會說，不是5W1H應該更詳細嗎？因為GitLab很貼心的把When與Where都幫我們準備好了。
如下圖，我們可以在Issue內清楚的看到這個Issue是在哪個Epic(Where)內執行，以及是開立在哪個Milestone(When)內。
所以在Issue的內容我們僅需說明：
當然，你可以根據產品的性質或團隊的習慣設定各種不同的範本，更詳細的設定的方式可以參考GitLab官方文件Description templates。設定完成後，團隊成員在開立Issue的時候只要根據Issue的類型選擇對應的範本，如下圖：
接著由PM及UIUX進行Review，PM會Review Issue開立的內容是否符合需求，UIUX則會Review Issue的開發是否符合UI的設計，當然，團隊的Leader可以隨時Review Issue，掌握團隊的開發進度。
開發完成後，前端同仁可以指派UIUX進行Approve，除了通知UIUX同人已開發完成，也可以再次確保開發符合UIUX設計。
按下Approve後，前端同仁就可以進行Branch的Merge，我們可以在Issue下方看到目前Merge的狀況，以及是由哪幾位團隊成員進行Approve的，日後如果要吵架，就有證據了(誤)
完成Merge後PM與UIUX即可在測試環境進行測試，確認此功能是否開發完成以及有無bug，並將測試計畫與結果記錄在Issue下方。
根據以上的例子，我們可以看到團隊的成員能夠在Issue的不同階段進行參與，並且只需要透過單一平台-GitLab，就可以完成開發的流程。
有別於以往專案團隊成員可能各自使用其熟悉的工具，而PM需要透過不同的方式掌握進度，還必須保持資訊即時性與正確性，團隊成員各自努力，卻因為工具的不相容，而降低了工作效率，這些問題GitLab都幫我們解決了，是不是迫不及待的想為你的團隊升級專案管理工具了呢？
Kanban一打開 敏捷好簡單
介紹完了團隊成員在GitLab共同協作的價值，或許你還會說，可是我的團隊正在執行敏捷開發，Gitlab也可以協助我嗎？
當然，GitLab幫你準備好了Issue kanban，只要先根據你的需求設定好Sprint的區間-Milestone，可以根據產品預設的開發時程設定Milestone的起訖日，也可以將整年度依固定單位劃分Milestone，更詳細的介紹可以參考官方文件Milestone。
設定完Milestone後，不論你是執行Daily Review或是Sprint Review，只要在Issue Kanban上設定相對應的條件，都可以輕鬆掌握開發狀況(如下圖)。有關Issue Kanban還有各種彈性的使用方式，可以參考官方文件Issue boards。
本篇以日常開發的角度分享團隊成員在單一平台協作的價值，下篇將會以更高層次的企業目標來說明，若掌握了組織的預算，或是需要進行公司產品藍圖的規劃，我們可以如何在GitLab上實現呢？
敬請期待～