關於網路那些事...

網路行銷,SEO,網路趨勢,教學文章,網頁設計,生活時事

Git-flow + Scrum

| Comments

對於本文,請記住,在每個sprint結束時,每個story都標記為已完成或未完成。還要記住,每個story都需要被分解成可以提供商業價值的工作塊。

我想,我已經聽過非常多次,沒有人可以確實的落實scrum。

雖然,我不認為scrum 需要嚴格被執行, 嚴謹的落實也不會是成員所希望的,因此必須思考其中的重點還是在於這個框架能夠讓團隊組織,能充分的授權給每一個成員。

我現在所處的團隊,在過去曾經因應當時工作需求,採用了一系列的工作模式,並且非常簡潔,這樣的工作模式大致可稱為 scrummish?或者 scrum-like? 這樣的模式,對於不知情的外人來說,依然可以獲得認可:“他們正在 run scrum"

這些工作方式,很大一部份是基於 Jira 以及許多地方有進行自動化的流程處理(CI/CD)。
當時,當我聽聞到這樣的方式,下意識反應是他們所進行的 gitflow model 事蹟所有流程統一在 master branch 上面執行,我相信這樣的流程是被稱之為 Github Flow。

這時,我以及另外一位新進人員同時說了:“我們必須改變這些流程,這些東西太老舊了”
並且,在想法上都偏向於一句古老諺語:這東西太老舊了,如果他們出事,我們就不修它

下圖是我根據當時所用的流程策略,所畫出來的流程模型:

這些流程非常簡單,並且運作了非常多年仍沒有問題,那為什麼我提出必須要改變它?簡單來說,這流程並不是很完美,沒有考慮流程外的流程,尤其是有修補流程時。

當我來到這裡的第一天,就看到 hotfixes 可以直接透過登入遠端主機直接進行 live coing 的方式進行修改。對於這些,我並不想追究。但是,當某項功能已經通過測試,release出去後,這樣的 hostfixes 容易跳過測試及QA 流程時,就會讓事情變得非常冒險。

下方是我所提出的 git-flow 流程,以及我會說明這些流程如何整合 scrum processes

在這情況下,scrum 與git 之間最大的關鍵會在於,透過 feature 來 run sprint,至 Demo 。

當 story 所涵蓋的 sprint 已經測試及 Demo 確認後,我們會將這些內容merge 並且進到 release candidate,進行更完整的測試及修復及 code review 批准才能發佈,更重要的事,所有 hostfix 都能夠回歸測試。

因此,任何事情必須經過批准才能進到 master ,這是其中的關鍵。並且在這當中,整合了 scrum。

參考:
http://asteriskpound.com/2018/02/11/git-flow-and-scrum.html


聲明,近期發現有平台大量盜用文章內容,若您發現內文非來自關於網路那些事 [https://adon988.logdown.com](https://adon988.logdown.com) ,希望您與我聯繫 [https://www.facebook.com/ThinkingWebsite](https://www.facebook.com/ThinkingWebsite)
(本文章源自"關於網路那些事)

最後,如果你喜歡這篇文章,請幫忙點個讚



最新文章推薦

討論

comments powered by Disqus