在一個sprint中整個開發過程中大概分為4個階段，啟動、開發、評審、后期處理
每個sprint都是連續的，所以sprint之間的工作會有一些交叉
1. 啟動
- sprint啟動從上一個sprint后期開始，從Sprint Planning Meeting開始，當前sprint已經進入准備階段。
- sprint正式開始是Sprint start meeting的，在這個sprint的第一天。
- sprint正式開始后，第一天、第二天基本上在做sprint的story分析，story拆解為task工作
- 在這三天中需要約定一次Sprint Retrospective Meeting，會議時長約30min~120min
在sprint第三天一定要完成story的分析與拆解，進入正式的編碼階段;
如果在任務分解時有任何問題，可以向SM(需求相關)和TL(技術相關)提出，如果SM和TL無法解決，可以像PO提出或者請求上一級的TL解決;
如果還是沒有結果應請PO評估是否應該放回到product back log中。
理論上不應該出現這樣的問題，這樣的問題出現，說明在Sprint Pre-plan meeting中評估有問題。
2. 開發
- 從sprint第四天開始應該正式進入開發階段，這個開發階段會占用整個sprint的50%~60%的時間
- sprint的周期越長，開發占用的時間越短，最短不應少於50%，最多不應該超過70%，否則后續評審和sprint會無法正常繼續下去
3. 評審
主要是評審會議：Sprint Review Meeting或者叫Sprint Demo Meeting
包含以下內容
- PO對已完成內容的評審，確認是否符合預期標准
- TL對已完成代碼進行評審，確認代碼是否符合代碼規范，也可借助於junit、pmd、checkstyle等工具進行評審
- 如果有測試，則TL和ST需要對測試案例進行評審，確認測試案例是否符合PO的要求。
以上評審需要在開發結束的1~3天內完成
4. 后期處理
前3部分大概占掉了整個sprint的60%~70%
- 處理在評審過程中PO提出的改善建議，注意這里不應該包含需求變更，需求變更需要PO另外建立story
- 處理在評審過程中TL提出的改善建議，這里不會有需求變更，可能包含小型重構，不應包含大量重構，如果確實有必要需要請上一級TL添加tech debt story
- 處理junit和測試過程中發現的異常或bug
- 完善相關文檔或完善story描述，方便后續人員維護