# Scrum流程
###### tags:`體育聊天室`
:::spoiler 目錄
> [TOC]
:::
## Redmine(每天下班前，或code review時)
- 在站會開始之前，需開出以下幾則task：
- 昨天完成的項目
- 昨天未完成的項目
- 今天接續要做的項目
- 今天開始要做的項目
- 調整百分比
- 調整狀態
- 完成時，請將百分比調整至100%
- 狀態在開完早會時，改成“完成”
- 開新的Task，請將父議題狀態從“待排程”->"開發中"
## Refinement(星期四早上10:30-11:30)
- 再開會之前，請團隊先提供，現階段技術上因該有哪些項目(優先級需先討論過)
- 開會結束後，必須定出下禮拜須交付的項目
- 參與人員：江江、冠智、sean
## Demo(星期五早上)
- 這週sprint項目的展示
- 參與人員：all
## Retro(星期五下午2:00-3:00)
- 感謝卡(好好告白吧！):
- 在這週，我覺得應該謝謝“牠”(人)，在我忙著找bug(物)，找的抓狂時(事)，“牠”的一句話幫我突破重圍(唔，有種寫情書的感覺，這就對了！！！)
- 許願池(談自己的心):
- 根據這週，有什麼是覺得特別有成就感的事，希望被長存的!？
- 根據這週，有什麼是覺得特別不開心、不順心、鬱卒的事？
- 拜包公(事事不順想開口說)：
- 在 Sprint 進展良好的是什麼？
- 在 Sprint 可以改善的地方？
- 在下一個 Sprint 團隊可以嘗試改善的是什麼？
- 參與人員：all，但不含sean(不是排擠他，是他太忙了)
## 下週Planning討論(星期五下午3:00-4:00)
- 團隊針對每個項目，提出相對應的task
- 撰寫Task，簡單來說就是「拆解工作步驟」，把工作任務拆解小至0.5~2小時的單位（依據職業特性可能有所差異，但千萬別超過5小時）。而撰寫的大方向是：
- 「當把這些Task完成後，就可以達到Story所寫的Criteria與目標。」
- 在寫task最好加入更多的「動作」與「細節」
- 後端將程式碼撰寫好
- 並將API文件完成，通知前端
- 前端需接撰寫好的API
- 並進行測試，確定後端能接收到資料
- 簡單來說，就是寫完的TASK要感覺它會動一樣。不要怕把Task寫得太細，因為寫得細，代表你對Story的掌握度很高。
- 寫出動態感還有另一個好處，就是當工作足夠小、足夠多、足夠明確，團隊就有互助的可能(因為別人可以很清楚知道，哪一部分可以順手幫忙)
- 在事後回顧檢討時，也可以辨認出究竟是哪一個細節，使得Story遲遲無法完成。
- 3個問題，進行最後檢驗
- 1.為什麼這樣做，可以達到Criteria？
- 2.為什麼這樣做，是否與目標一致？
- 3.有沒有更快、更省、效果更好的方式？
- 參與人員：all
## Daliy(每天早上10:00-10:10)
- Scrum立會精髓是即時地「掌握現況」、「彈性調整」、「相互幫助」，而每日立會就是為了做到這三件事而生的。
- 它的原則是：要在每天的固定的時間（例如：10:00am）只花15分鐘、用相同的方式進行會議。
- 3個目的
這場會議十分重要，因為它就是為了Scrum的3個目的而生的，為了
- 讓PO可以「彈性調整」任務，決定是否繼續執行，或新增任務
- 讓團隊「掌握現況」並讓夥伴「相互幫助」
- 確保當前執行的任務「和目標保持一致」
- 3件事情
為了達到這三個目的，Scrum立會被設計由所有團隊成員，每天花15分鐘站在一起，輪口頭報告三件事：
- 昨天我完成了哪些leangoo上的事
- 今天我打算做哪些leangoo上的事
- 昨天或今天，發生了哪些會阻礙團隊、個人執行任務的事
- 4種情境
但這場立會比較特別的是，所有人都是積極回應的一方，任何人在報告時，都可能會產生以下4種狀況：
- 團隊成員對問題報告內容不清楚，會立刻提問
- 團隊成員聽到某個問題，而他有能力解決，會馬上說「我可以幫忙，等等我們來討論」
- PO、SM發現有人做錯了、不在軌道時，會即時說明、調整任務
- 如果有問題被留下，SM會負責記錄下來
- Scrum立會主要的功用在於「資訊交流」，是單純的發出訊息、吸收訊息而已。
- 既然Scrum立會主要的功用在於「資訊交流」，「解決問題」當然就不會出現在立會。但並不代表團隊不該相互幫助，立會上比較好的幫助方式是說：
- 「好，這個問題我可以解決，我們等等處理」
- 「這個問題好像有點難，立會後詳細跟我說明一下好嗎？」
- 每個人都該在立會前，充足地準備要報告的內容，並在會議進行時，專心理解他人目前的狀況、發生什麼樣的問題，並盡其所能提出解答。