計劃趕不上變化 變化靠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上實現呢?
敬請期待~