不紙上談兵，所以 Scrum Schedule 怎麼規劃？#新創公司實驗心得 (上)
敏捷的時程規劃規劃可以讓團隊有儀式感，在一個有規律的節奏下穩定進行
世界的運行很奇妙，鼓勵我們跳出框架，但事實是我們一直活在框架中，並且需要它來讓生活運行。
先講一下我的團隊成員：
🙋♂️ 3 位產經裡負責不同產品線
👨💻 15 位前 (ios/android/web) 後端工程師加
👩💻 4 位測試 優化
📂正在跑兩個大專案/小功能優化或 Bug
人打臉說：阿不是敏捷說 5–9 位是最好的嗎？
以一個新創公司剛開始導入，在人力吃緊的情況下我的做法是，先把大專案的人拉出來，剩下的人以及在大專案中比較空閒的人拉出來做功能修復以及小功能的優化，可以參考上圖，優化功能那個顏色比較多的 group (統稱叫日常迭代) 裡面來自四面八方的 request 很多，功能很雜，Bug 很多，其實是最容易讓人感到慌亂沒有重心的，因此更需要設定好框架來約束。
所以這篇會分兩個部分：一是可以在一個月內開發測試上線的小功能，二是全新功能的大專案 (以開發要一個月以上為衡量標準)。
|Hightlight
- 在估時時，必須考慮 Bug，因為修復 Bug 也佔據工程師的時間，應該說只要花時間 (Bug fix/Research…) 的都必須納入本次的 Sprint 中
- 在人力不足的情況可能不行全心投入，可以將 Schedule 設計與其他專案錯開，像是通常人力不足的測試可以先提前寫好專案一的 test case， 再回來測試日常迭代的測試，隨機應變。⭐️並且先跟產品經理或老闆確認好優先級⭐️，比如說如在人力不夠，先保日本鐵路專案，以免壓榨團員的時間，強調我真的不喜歡我的團員加班！
- 業務或是產品經理的需求源源不絕，⭐️先訂立好本次 Sprint 需求確認的時間⭐️，也就是說，你沒趕上這次的需求火車，請坐下一班；但 Agile 的精神就是接受變化，一些緊急需求在經過大家討論後認為必須放在這個 Sprint 發佈也沒關係，挑出相對不這麼重要的任務放到下次做，畢竟即使緊急需求，我們人就是這麼多
|Schedule
- 一個 Sprint 為四週，包含產品經理的需求搜集，很多人的 Sprint 可能只安排了技術人員，遇到的問題是到了開需求評審的時候發現產品經理的需求 2266，所以我的想法是把產品經理的需求整理時間也規劃進去
- 第二個禮拜是產品與工程師討論需求的時間，大家可能會覺得第一個禮拜寫 user story 的時間不就會找工程師討論了嗎？第二個禮拜我覺得算是緩衝期，可能會發生的是產品的需求沒想清楚，需要時間做修改，此次修改又會連動到設計師的圖，設計師在我的 case 中是沒有在 Scrum team 裡面的，所以出圖的速度不是馬上就能拿到，或是媽的工程師上禮拜討論了還是不知道要做什麼，需要花點時間做些 research 等等
相信我加上緩衝時間，做了幾年的 PM 已經讓我練就負黑呼吸
⏰ 重點會議 ⏰
#第二個禮拜的禮拜一上午：需求評審會，產品經理寫好 user story, 在這個會議中如果有不合理的地方需要提出來，確認好哪個 RD 做哪些工作，這麼目的是之後需更細節的討論，產品經理也知道有個窗口 (如果之後 owner 更動，也可以由這位 RD 闡述)
⭐️強烈建議測試要在場⭐️
#第二個禮拜的星期五的下午：排期會，這個會議前從星期一的下午到星期五開會前產品經理跟工程師已確認好需求，準備好所有需求文件/圖/文案/多語言翻譯等等，是可以隨時開發的階段。也必須給工程師的心理建設是，下禮拜會全力發開，到時候才有問題就是你的問題需要被被 review
⭐️強烈建議測試要在場⭐️
這時候會請 RD 估時，⭐️以每天五小時去估⭐️ (所以工程師的工作量為一個禮拜 25 個小時) 原因是我不相信大家八小時都好好在工作 (又在暗黑)，有時發發呆，吃吃飯，打個盹滑手機，或是被同事打擾 (打情罵俏) 都是有可能。一開始可能會估不準，但會越來越準確的，之後可以寫文章分享。
- 第三個禮拜心無旁騖工程師全力開發，一個禮拜的開發時間，這禮拜測試可以開始寫 test case，然後找工程師看一下
⏰ 重點時間 ⏰
# test case 評審：依造 test case 複雜程度，大副份的時間測試寫完 test case 都直接線上或面對面討論一下，反而不需要約一個會
#第三個禮拜的星期五下午：最晚提側時間，禮拜四五的晨會會需要 Scrum master 特別看一下大家的開發狀態，以確保禮拜五可以提測，下一個禮拜一開始測試可以全力測試
- 第四個禮拜測試測試完並上線。可以看到上圖的下方，其實一個 Srpint 沒有結束就開始跑下一個 Sprint 了，所以工程師會是一邊修 Bug，同時在跟產品經理討論下一個 Sprint 的需求
雖然一個 Sprint 是四個禮拜，但以技術團隊的角度實際工作會是兩個禮拜一個週期：
👨💻 工程師：開發 → bug fix/討論新需求 → 開發 → bug fix/討論新需求
👩💻 測試：寫 test case → 測試上線寫 → test case → 測試上線
仍然會遇到很多的問題，大家的問題可以在這個 Sprint 結束後的下一個禮拜一需求品審的時候快速講一下大家遇到的問題並且如何去改善，不過由於我的團隊每次的 Sprint 的人員不一定固定，所以我是選擇每個月一次的月會請團隊成員提出來變紀錄，並在一個月的月會打開上個月紀錄的問題再次 review 看有沒有真的往好的方向進行。
雖然在我的 case 中團隊成員會更動，但留下兩位成員專注在跑日常迭代，這樣整個團隊裡面有比較熟悉的人跑起來會比較流順，並在大的專案結束後，作人員的交替。
大專案的敏捷跑法待下一篇娓娓道來。
|相關文章：
