2014 年的 7 月底自掏腰包跑去台北 CLBC 上了知名 Ruby on Rails 開發者 Xdite 的專案管理課程，試圖尋找一種解藥，來平衡我當時白天要上班、晚上要帶小孩、然後還要營運奇步應用的這種忙亂生活。聽完課之後，也果然有了一些想法和具體作為（列在本文最後面的結論裡面）， 無印良品 A5 尺寸的筆記本寫了 3 頁滿載而歸。
我當天搭 9 點的高鐵到台北，是第 1 個踏進上課教室的學員（從現場安排的座位數目來看， 7 月班這個梯次的學員大約 20 人，人數約前兩個梯次的一半）。早到的好處就是可以選擇坐第一排，與講師有最多的問答互動。當天也果然讓我有機會對話了幾次，詢問了 4 、 5 個問題， Xdite 有問必答，而且是經過實務經驗淬鍊而來的答案，聽來格外受用。
整堂課分成 3 段，每段各約 1.5 個小時。第 1 段是早上 10: 30 到 12:00 ，講的是用戶故事（ User Story ，係針對操作情境的描述）；第 2 段是午休後的 13:00 到 14:30 ，講的是專案管理和議題追蹤（ Issue Tracking ）的技巧；第 3 段是吃完點心後的 15:00 到 16:30 ，講的是 Redmine 這套專案管理工具。
目錄大綱（點擊前往→）
Redmine 專案管理工具
也許你並不是真的打算導入 Redmine （基於 Ruby on Rails 的 Open Source 專案，在台灣 Ruby on Rails 社群大概花費新台幣 3,000 元可以找到人從無到有搞定，或者國外也有租賃服務，月租費大約新台幣 700 元），但是在 Redmine 裡面所運用、所延伸的專案管理技巧是放諸四海皆準的，所以仍然有極高的參考價值。
許多公司導入專案管理系統之所以失敗的原因，就在於 RD 根本不知道做某些功能的緣由。所以「 No Story, Only Tickets! 」是不可行的。這裡的 Story 就是 User Story ，而 Ticket 則是專案管理系統中的任務執行單位，所以才會有「開票」（在管理系統上建立一張描述和指派任務的 Ticket ）和「切票」（將大的功能細切成較小的容易描述和執行的 Ticket ）等說法。 PM （產品經理或專案經理）在規劃功能的時候，必須輔以「 User Story 」，以便把功能拆出來。
Issue Tracking 系統還可以用來分享讀書心得的筆記，在 Xdite 公司的 Wiki 上，甚至看得到公司搬家（因為生意興隆，所以辦公室越換越大的緣故）要拜地基主的標準流程。
在 Redmine 的操作上，不一定要使用子母票，切勿因為想要巢狀而巢狀，使得票與票之間的組織架構過於複雜。初期只有母票（樹枝）無妨，之後再慢慢長出子票（樹葉）。此外有技術細節的樹，也應該要有用來測試和驗收的樹，前者可能有 500 張票，而後者則有 100 張票。
User Story 用戶故事的用途
聽到這裡有個空檔，於是我舉手問了第 1 個問題：「是否會將 User Story 作為合約的一部分，或者單純只是作為開票的輔助？」 Xdite 回覆說：「兩者皆是。」大型接案公司都這是這麼做的，也就是 User Story 既是合約的一部分，也是專案管理工具開票的依據。關於專案報價和時程的估算，以矽谷知名軟體接案公司 Pivotal Labs 的模式為例，他們會先切 User Story ，接著評估實作時間，最後才報價。這個過程中首先派去和 Product Owner （敏捷開發中的「客戶」角色）進行需求訪談的是 PM ，然後才是資深工程師。
有趣的是， Pivotal Labs 在合約上不會保證在交付日（ Delivery Day ）之前要完成哪些功能，只保證會集中火力盡量去做（根據講好的優先順序來完成功能項目）。形同租用員工給客戶，簽的是「時數約」。台灣鮮少有這樣的公司，除非公司夠強，不過 Xdite 的公司向來就是這樣簽約的。
另外如果到了 Xdite 出馬但是談了 2 次還無法簽約的客戶，她就會選擇放掉，因為有時候客戶只是藉此機會進行比價而已。
在簽約技巧方面，複雜的、非主要的、需要花時間 Survey （研究）的功能，不要簽入主約，放在附約就好。
User Story 用戶故事撰寫心法
關於 User Story 的撰寫，基本上是以「角色」為導向的，由角色的觀點出發，寫出有價值的功能和需求。其句型是：誰需要什麼來完成什麼。例如：老闆要能夠透過後端網頁看到訂單數量、客戶要能夠使用信用卡結帳。
User Story 通常要發展到第 7 或第 8 版左右才算是最終的版本。每則 User Story 的時程大約 1 個禮拜（ 5 天，每天 5 個小時），包含實作、套版、測試，由整個團隊共同執行，團隊裡面包含 Senior 和 Junior 工程師。當然票還是有分簡單和複雜的，所以通常是 Junior 分配到 3 張簡單的，然後 Senior 分配到 3 張複雜的。
課程現場有做 15 分鐘的習作， Xdite 要求學員將一個第 3 版左右的「線上商店」 User Story 拆分發展到第 6 版左右，票瞬間多了 3 倍的量。舉例而言，光是「身為消費者，要能找到商品並結帳」這項需求就至少可以拆分成「消費者要能搜尋商品」、「消費者要能產生訂單」、「消費者要能用信用卡結帳」等比較細的票了。
切記一點，不要讓 Product Owner 用仿真畫面來討論，因為會沒完沒了。 User Story 加低保真草圖（ Low Fidelity Prototype ）才是王道！初期不應該被 PhotoShop 繪製的設計圖來引導，那是套版階段的事情。 Xdite 說她不接這種客戶，因為太危險了。
User Story 用戶故事實務
另一方面， RD 若要避免被賣掉，應該主動參與 User Story 討論。
User Story 有所謂的 SMART （ Specific 明確、 Measurable 可量測、 Achievable 可實現、 Relevant 切題、 Time-boxed 時效性）撰寫原則。課程當中舉了幾個例子，像「 User-friendly 」這樣的字眼就太過主觀了，不符合 Specific 和 Measurable 原則，而「 要像 Google 一樣」也有同樣的問題，其實 Product Owner 想講的應該是「搜尋功能要有一邊輸入、一邊補完的 Auto-complete 功能」之類的。
除此之外， User Story 本來就應該邀請（甚至強迫） Product Owner 進來一起討論，一起使用專案管理工具（例如 Redmine ）。但是這麼做又怕太過於透明，所以不想給 Product Owner 看到的東西，就開別的版去討論。原則上大部分的東西都可以讓 Product Owner 看，除了技術細節、人力分配、金錢、工時之外。
題外話， Xdite 在回答學員問題時透露，在她的公司，所有員工都是一起吃午餐的，這樣可以凝聚向心力，而老闆也可以知道大家的近況。
另一方面，票與票之間難免有前後順序或者可以同時進行的關聯性，為了避免卡關，也為了讓後續的相關功能得以完成，可以先做一些不實作商業邏輯的假按鈕，例如「以信用卡付款」按鈕按了之後會產生訂單但是並沒有真的進行結帳動作。
關於 Xdite
基於對頂尖講師（她曾在多場國際 RubyConf 研討會開講）和頂尖開發者（也曾榮獲 Facebook 2012 World Hack 全球首獎）的好奇，我稍微觀察了一下 Xdite 。她戴著超厚的眼鏡，頭腦思路清晰、回答問題的速度超快，投影片沒有標題、只有白底黑字，也沒有使用控制上下頁的簡報筆，穿著 T 恤、短褲、便鞋，一個人就搞定整天的課程和 Q&A 了。
吃完下午茶點心之後，進入本堂課的最大賣點，也就是 Xdite 分享參加 Facebook World Hack 2012 並獲得首獎的經驗，故事高潮迭起而且可以學到很多實用技巧，鼓勵大家去上她的課，在此就不贅述了。關於這次獲獎的報導，可以參考 Mr. Jamie 、 Inside 和 T 客邦的文章。
立刻行動
最後再回過頭來看一下課程名稱《 Deliver Project on Time 》，到底 User Story 對於專案準時上線有什麼幫助呢？因為好的 User Story 可以幫助開出準確的票、分配準確的人力和時間等資源，進而估算出準確的時程。而時程知道了，專案自然準時上線。 Xdite 說他最高記錄是一次（還是一天，我忘記了）要管理 150 張票，哇賽！
上完這堂課之後，我決定：
- 把與客戶討論出來的東西寫成 User Story 當作合約附件，同時也當作驗收的標準。
- 儘管奇步應用目前只有兩人微型規模，但是還是要想辦法導入專案管理工具。