Story 對應一個服務開發的最小單位。多個 Story 可以構成一個 Epic。
在 Kubernetes、Docker Swarm、... 日益成熟後,分散式的系統架構因應高併發的服務已經非常普遍了。
基本上只要把 Story 當成一個微服務
,而多個微服務可以構成一個分散式系統也就是 Epic
。
名詞解釋完畢。
如果沒有導入任何管理工具的話,這時候會議室的白板應該長成這樣 :
四期衝刺活動(sprint)
的燃盡圖(Burndown Chart)
結果以及每一期所完成的「Task 卡片」。
使用 Planner 的話,開發結束後則如下圖 :
值得一提的是,「Story 卡片」必定是最後一張該被設定成已完成
的卡片。因為它要四期所有的「Task 卡片」都確定已完成
之後,才代表實質上的已完成
。
不過,在去年疫情歷經在家工作的經驗後,還是建議要導入 Scrum 開發模式,該買的管理工具還是不該省。
所以開發任務交付給業務部了。接下來呢 ?
即使產品開發部有自信的立下一個 Flag :
一定沒人相信這種鬼話。該排查、監控、解決問題的項目還是要有。
明天開始適當的調整進入運營時,Scrum 開發的策略吧 !