Story 對應一個服務開發的最小單位。多個 Story 可以構成一個 Epic。

在 Kubernetes、Docker Swarm、... 日益成熟後，分散式的系統架構因應高併發的服務已經非常普遍了。
基本上只要把 Story 當成一個微服務，而多個微服務可以構成一個分散式系統也就是 Epic。
名詞解釋完畢。
如果沒有導入任何管理工具的話，這時候會議室的白板應該長成這樣 :

四期衝刺活動(sprint)的燃盡圖(Burndown Chart)結果以及每一期所完成的「Task 卡片」。

使用 Planner 的話，開發結束後則如下圖 :

值得一提的是，「Story 卡片」必定是最後一張該被設定成已完成的卡片。因為它要四期所有的「Task 卡片」都確定已完成之後，才代表實質上的已完成。

不過，在去年疫情歷經在家工作的經驗後，還是建議要導入 Scrum 開發模式，該買的管理工具還是不該省。

所以開發任務交付給業務部了。接下來呢 ?
即使產品開發部有自信的立下一個 Flag :

一定沒人相信這種鬼話。該排查、監控、解決問題的項目還是要有。

明天開始適當的調整進入運營時，Scrum 開發的策略吧 !