Git-flow + Scrum

對於本文，請記住，在每個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。