XDite 的行事風格與課程有些爭議，總之採購前做好評估就是。
上週五去上了 XDite 開的 Deliver Project On-Time 敏捷專案管理食物實務，當初會決定去上這個課有一部分是因為課程簡介中提到會講些使用 Redmine 的技巧，雖然我已經有開始試著用，不過感覺自己摸索用的沒有很好。
整體來說，課程大概分三個部分:
- User Story
- Project Management Tool
- Q & A
這次課程看到的 User Story 樣板是 "As a (role), need (some feature) to done (some business value)." 形式的，之前有看過一個形式有包含驗證也必須描述。
之前在整理 User Story 比較傷腦筋的是到底要切多細，這點 XDite 的建議是在估價時期大概切到一週到三天的工作量，至於切到什麼程度大概是一週到三天就要靠經驗了。
幾個關鍵重點:
- 大量跟客戶與工程團隊溝通，儘量把隱藏的功能、場景、流程都先找出來，這些都是工時暴增的潛在風險。
- 把時間成本或風險高的項目儘量提早抓出來先排進工作規劃，比如要申請介接之類花時間但沒有的話某個功能就不能完成的事。
- 針對「想解決的問題」去討論，避免被「畫面安排細節」或「操作流程」分心。
有些太雞肋的東西，可以試著連問客戶 5 個 Why 也許就可以把該項目丟棄或是放到最低優先權佇列上。我想，要用這招反應可能要很快，免得客戶覺得在硬找理由 XD
到了實作時期，切到最後的 User Story (其實就是 Task 了) 應符合 SMART 原則:
- Specific
- 明確的
- Measurable
- 可衡量的
- Achievable
- 可實作出來、可達到的
- Relevant
- 與使用者需求有關聯
- Time-boxed
- 有時限的，萬一實際上使用的時間比估算的長，要開始採取行動
切割 Story 時可以大概分成幾個層次:
- 1 週 ~ 3 天:
- 第一版粗切，估算成本用
- 1 天:
- 進行雙週級的工作排程規劃
- 半天 ~ 1 小時:
- 單日的工作排程規劃
另外有瓶頸的工作也應該想辦法分割，才不會浪費時間卡住。
工具部分，從 Trello, Basecamp 到 Redmine 很快的簡介了一輪，自己簡單試用過後，要能切 sub-ticket 還是要用 Redmine 才有。
使用 Redmine 的部分得到了幾個之前沒想過的做法:
- 可以分成內部 (開發團隊用) 跟外部 (給客戶使用) 兩個分離的 Project 然後利用 related issue 來在兩者間作關聯。
- 不一定要是一棵大樹，可以是幾個小子樹，中間一樣利用 related issue 關聯。
- 最上層可以分 Story 與各項技術細節等幾個樹根，一樣在 Story 與實作的 ticket 間利用 related issue 進行關聯。
Milestone 是不錯的功能，現在改叫做 Version 了的樣子，看起來應該是一樣的東西。之前搞不太懂怎麼用比較好，開始嘗試使用中。
可以儘量開 ticket 來記錄做了些什麼事情，除了可以整理解決問題的脈絡，還可以做記錄，之後可以在整理到 Wiki 上。不過忙一忙我都會忘記要去把 ticket 撈出來整理，請同事整理又請不太動，有點囧... 大家都很忙 (攤手)
另外就是畫面 mock-up 的部分，雖然有些工具可以使用，不過還是建議使用紙筆討論之後再拍照上傳，免得陷入討論細節的狀況。
問答時間會聽到其他人碰到的狀況，很有趣。
帶新人: 目標是在一個月後可以解 minor ticket 並且不會拖到原有的團隊戰力 (可以自己解決大部份的問題)
- 第 1 週:
- Rails 101
- 第 2 ~ 4 週:
- 撰寫 User Story 並做程式撰寫規劃
- 第 5 週起:
- 算是 on job training 吧！
時間分配: 早上做規劃，下午寫程式到五點，五點之後 code review 到大約六點，七點前準時下班。
講時間分配時有段很有趣，大概是這樣說的: 「我非常討厭其他人遲交，他遲交我什麼時間做 code review ? 晚上加班嗎？晚上是我打電動的時間耶！我如果加班 review 就得要熬夜打電動，這樣我隔天精神就不好沒辦法好好帶專案，這樣專案就很可能會失敗！」
真的是這樣！
