寫完創業團隊如何做專案管理。下一篇我要來寫的主題是工程團隊如何做專案與程式碼管理。以前我寫過很多調度專案的文章，但是執行細節我都沒有寫(a.k.a 不想寫 XD）。這一系列我希望解答一些常見的主要實作問題。
Q: 上 Issue Tracking 的 User Story 第一版粒度要切到多細?
這要分兩個層面來說。跟客戶簽約的 User Story 或者是工程團隊的 User Story。基本上是以 Interaction 粒度來切。
跟客戶簽約的 User Story
跟客戶簽合約的 User Story 的最小 Interaction 是 1-3 天。也就是 User Story 的粒度是切到剛好到 billable（在收費程度上無爭議）。（更細反而有爭議）
工程團隊內部時做的 User Story
假設這個專案只是內部的專案的話，那麼 User Story 的粒度是要切到 0.5 - 1 天左右，也就是要切到能
- 粗抓大概工程時間線
- 細抓到你可以找到工程 Risk 結點
大致上的專案規模
所以一個要做 2 個月的中型專案，大約上 issue tracking 之前
- 與客戶簽約的 User Story 版本大概是 60-100 條左右
- 自己內部開發的 User Story 版本大概是 100-200 條左右
結案大概會是 350 條 User Story 左右（含驗收）
Q: 收到 User Story 後要如何排定 Milestone?
我會用 Deadline-Driven + MoSCow method 的方式去排 Milestone。
- 先將 1/3 的工期，預留給 deploy 收尾的 story （或者稱 epic，就是技術細節）
- 再將 2/3 的工期，切成 3 段。
第一段：前期基礎
第一小段，做前期準備，比如說做
- Continous Deployment 架構。讓之後隨時的工期都會有可驗收的進度
- 找出高風險的 User Story，比如說信用卡刷卡需要先書面申請，先委託給其他單位去跑行政作業
- 找出有多少頁需要進行畫面設計
第二段：主要工程開發
實作主線架構。這時候的重點在於
- 完成主要功能
- 無法完成主要功能的話，至少要能完成主要功能「User Story」的 workflow
這個階段的目的是，邊做邊盤點團隊有多少資源。同時藉由 workflow 的拓展，把下一步未知的風險出來。
這時候就可以透過 MoSCow Method 去對所有的 User Story 去做 Milestone優先權升降。
MosCow Method 將資源分成
- Must have
- Should have
- Could have
- Won't have
這階段應該專注於把 must have 的功能或者是 workflow 做完
第三階段：次要工程開發
完成了第二階段後，若有時間的話，接下來在這階段可以實作 should have。
然後把 could have 的優先權，拉到驗收階段。然後誠實跟你的 Product Owner ( PM 或者是客戶）告白，won't have 就是 won't have 了。
驗收階段
因為我們留了一大段驗收階段的時間，這時候就可以心無旁騖的實作 could have。
甚至是最後 finalize 的效能調校與 bug 修正。
Template
這是我以前的切票示範。
系列文章
- 工程團隊如何做專案與程式碼管理 （一） ← You Are Here
- 工程團隊如何做專案與程式碼管理 （二）
- 工程團隊如何做專案與程式碼管理 （三）