almost 8 years ago

寫完創業團隊如何做專案管理。下一篇我要來寫的主題是工程團隊如何做專案與程式碼管理。以前我寫過很多調度專案的文章,但是執行細節我都沒有寫(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

這是我以前的切票示範。

系列文章

← 創業公司 Startup 如何做專案管理(總結) 工程團隊如何做專案與程式碼管理 (二) →
 
comments powered by Disqus