每年過新年前夕就會看到一堆人在討論專案管理工具或方法 XDD
大概是這時候各 Manager / Lead 現在才有喘息的時間可以來 Survey 工具。然後趁這個過年大 break 一口氣改掉專案進行方法。上一次寫這方面的懶人整理包已經是三年前。我也來整理新版的心得。
有興趣的可以配我之前的文章看
網站程式上線前需要準備的事 ( 2012/3 撰）
專案管理之道在「協調」
在談如何挑專案管理工具或方法之前。有一個中心原則很重要，我覺得必須要寫：
「這世界上沒有一套大一統的管理術，還有神奇專案追蹤工具。不會讓你裝了之後大家就變成超級賽亞人，人人練成通靈術。」
而專案管理也不是大家想的那樣，學了以後「命令」「指揮」大家做事比較有效率，專案管理是「協調」大家「一起做事」的技巧。
「協調」，「協調」，「協調」！
很重要所以要講三遍！！
瀑布與敏捷
專案進行方法有幾種，瀑布式，敏捷式（還有分 Scrum, Kanban, Scrum + Kanban ...) ，到底哪種比較好？
我的看法這幾種方法是因運組織以及組成人事有關。
有很多人講敏捷就要先幹瀑布式一下。抱怨只是做個簡單的東西結果 spec 被不專業的人花上很多時間寫了一堆廢物，拖了一堆時間結果 delay，實際實作時卻脫離現實。
我個人認為這其實跟組織運作有關。通常一個組織會出現「瀑布式做法」，通常已經代表這個組織太大或太冗了或者缺乏合作情感。頭無法控制到腳，或者 pm 根本無法跟實作團隊建立互信，或者根本是與不熟的外部團隊（外包）合作，為了避免產生糾紛才會有這種做法。
Spec 與 Story
寫 spec 跟 story 也是不一樣的東西。
spec 是很精確定義要做什麼，細節要做到怎麼樣的程度，不容修改。這適合你已經知道要做什麼了，你這次要做第二遍第三遍，所以只是重複上一次要做的東西，然後加上局部修改。
而 story 是你有一個使用情境，但你不知道確切成品會長成什麼樣，所以我們需要有一個 story「讓參與專案的人反覆討論改進」。
讓「讓參與專案的人反覆討論改進」
「讓參與專案的人反覆討論改進」「讓參與專案的人反覆討論改進」「讓參與專案的人反覆討論改進」
這件事超重要。所以也要講三遍！
我相信大部份的軟體開發與情境，都是不知道確切成品會演化成什麼樣。所以比較適合的是「敏捷式」與寫 Story 。
這也是本文要接續寫下去的方向。
Scrum or Kanban ?
好了。屁了這麼多廢話，到底要選哪一種？
好。先講結論：不要選 Scrum XDDDDDDD （那些靠教 Scrum 賺錢的不要揍我）
沒有啦。其實我沒有想要擋人財路。Scrum 很好，但是我會勸你去學 Scrum 但不要「導入」Scrum。（好吧看起來還是很欠揍，有人可能又會跟我吵那是因為 Scrum 學不到位才會講這種妖魔鬼怪的言論）
OKOK。我承認我不是什麼敏捷高手，只是低手。我只是在寫我的想法，理性勿戰 XDDDD
我個人對 Scrum 的看法，是 Scrum 是是一整套「工具集」。它是提升效率的一套「敏捷」「Framework」（這也是 Scrum 開宗明義講的）。每一個組織都有每一個組織各自的問題，一次全導 Framework 進去未必會幫到自己的組織，可能還會搞到非死即傷。
Scrum
有些讀者可能對 Scrum 沒那麼熟悉，我大概講一下這套工具箱裡面有什麼：
- User Story （敘述我們要解決什麼問題，以及相關的使用者情境）
- Story point （每一個 User story 的權重）
- Scrum Master, Stakeholder, Team member ( 裡面成員扮演的角色）
- Sprint （衝刺週期）
- Standup （站立會議，成員每天報告之前做了什麼，今天做了什麼，未來要做什麼，今天遇到什麼難題希望 Team Member 幫忙解）
- Retrospective meeting （回顧會議，在這個會議檢討我們這個 sprint 的部分有什麼需要改進的）
團隊難以導入 Scrum 的原因
為什麼很難全導呢？
- Story point 要怎樣分（爛票要優先做嗎？可以裝死嗎？政治問題與能力問題）
- Team member role （Scrum master 誰當？角色重疊會不會有後遺症。政治問題與能力問題）
- Sprint （啊我們一個 Team 同時在做多個 project ，哪有辦法精確估計守備範圍和速度？ ）
- Scrum 重視 Story，大家都在拼 Story point。那 Epic （不在 Story 上的技術問題，但很重要，比如 Refactor 或者是 Performance Tuning ）怎辦？
etc.etc.
這些都是導入 Scrum 會面臨到的問題。導入開始產生一堆問題，接著 Team member 就會產生一堆疑惑，大家開始質疑，一個弄的不好大家就覺得比之前複雜超多好累不想弄喔，就 GG 了。
但這表示 Scrum 不值得導入嗎？
不不不。你應該看你有什麼樣的問題要解決，拆進去用，逐一導入。
我在前面的部分就說了：Scrum 是一套工具集，裡面的工具是是真的很不錯。
Scrum 細細說
User story 與 Story Point
User story 的誕生是為了解決在專案過程中，因為負責專案管理的人過於描述細節而把原始目的破壞殆盡的狀況。很多時候，專案經理為了求好心切，甚至過於精確描述實作細節
- 不僅花費了不必要的時間（講的方案不好
- 還造成負責實作者的困擾 ( RD 或者 Design 覺得不切實際
- 甚至 RD 做完了，stakeholder 才講這不是他要的。（因為精確描述時作方法，會造成實作者實作時缺乏上下文，想像錯誤 ）
- 只描述了一部份的細節（比如說只講商店要怎麼結賬，卻忘記講後台也要有後台可以管理訂單）
但做專案重要的是
- 中間經手的人通通都理解要解決什麼問題。在什麼時限之前。
- 我們手上有多少資源
- 我們可以在第一版做到什麼程度
- 能不能讓實作者在第一版就解決最真切的問題
- 能從不同使用者角度審視這個軟體
- 第一版我們要做哪一些功能。哪一些馬上就要做，哪一些可以之後再做。哪一些給 Senior 做，哪一些給 Junior 練手用。
Sprint / Standup / Retrospective Meeting
Sprint
做軟體不能沒有遙遙無期沒有 Release date。也不能「只有一個 Release date」。這會造成花了大把時間卻做歪掉。
或者是 14 天內只要 a,b,c 功能，但實作者卻因為想一口氣做完 a,b,d,e,f, 功能，一口氣報了 30 天才能「通通完成」，結果第三十天才發現 c 沒做。
這就是為什麼必須要有 Sprint。規劃一個短時程，把值得先實做的部分衝刺，邊改邊做小 release。
Standup
而 Standup 的用意不是為了監視 Team member 有沒有做事。而是為了保證每個人「做對事」。軟體開發者不是通靈者，沒辦法 100% 辦法精確 implement。
為了避免劇烈的 misunderstanding 發生，standup 是在每天一個固定時間讓大家交流實作狀控使用。報告現在的狀況，當發生無法實作或者需要改優先權，甚至改實作者（有些 junior 做不出來）的時候馬上可以調整。
可以讓大家常常保持在 same page，對專案有一個清晰的了解，保持士氣。
Retrospective Meeting
同時，為了團體的成長，在 Sprint 結束後，也會有一個回顧會議，去檢討在這個週期中，我們各自或甚至公司有什麼地方可以做得更好的地方。大家一起改進。而非一直忍耐某人某鳥事忍到受不了然後離職。
Scrum 要解決的事
看完這些，你知道 Scrum 要解決的是哪些事了嗎？
- 對專案目標的理解程度
- 對專案時程的透明程度
- 進步，溝通，協調
導入者要先知道自己組織有哪些問題，然後去調整去用工具才有意義。
Kanban 要解決的事
同樣的 Kanban 也是類似的想法。Kanban 沒那麼複雜的工具集。核心就是三個故事版：
- 未實做
- 實做中
- 已實做
目的是為了讓專案所有成員了解現在的實作狀態。從而自己發展各式各樣的輔助方式協助時程內完成一定的目標。
敏捷是怎麼回事？
所以看下來，敏捷是怎麼回事？
- on time
- on budget ( resource )
- deliver correct result
- communication / collaboration
如果專案管理者只是想要「命令」實作者「通靈」。說真的我覺得導什麼敏捷方法都沒用。
最有效的方式是「擲筊」。
我怎麼做專案管理以及用什麼工具？
具體一些細節可以看三年前的系列的文章。就不重複講裡面的內容了。這一段主要是描述現在我怎麼樣做專案的
- 要做某功能前請某 pm 在 Hackpad 起草 User Story
- 要開始實作實，用 Redmine 開一串巢狀式的實作票 ( Story, Design, RD frontend , RD backend, RD mobile, QA )
- Redmine 與 Hipchat / Slack 整合，team member 都可以在 #techlog 上看到全部的票的更新狀況
- RD 依照 ticket 號碼開實作 ticket branch, Senior 根據 branch code review, PM 根據 branch 跑驗收, devops 針對 ticket branch merge 并 deploy.
- Admin backend 不寫測試，API 與 Service Object 一律要寫測試。code reviewer 不 review 任何 紅燈 branch.
- deploy 是使用 samson 整合 CI 做 deploy
- 內部 mobile release 是使用 crashlytics
- CI 是使用 solanolabs
- 難以敘述的部分使用 screenshot 與 google hangout 直接講
- Tech / Design / Mobile team 會用 Hackpad 一有 release 會寫 updates 寄給全公司。
我們現在開發團隊的狀況是：美國，台灣都有 RD。靠這些工具, weekly pm meeting, company tech touch base, engineering demo 與 retrospective meeting 確保公司上下想要的東西是一致的。
平均我們 redmine 一周會產生100-150 張 ticket, rails 的主 branch 一個月 2000 commit，一周大約會 release 5-7 個 major feature。code climate 現在 3.08 分。test coverage 大約 60%，API 的部分應該有 90-95%。
我們怎用 Hackpad?
用 Hackpad 有兩個地方。
1. 寫 User Story。
User story 寫
- 要完成什麼商業目標
- 希望出貨的時間
- 會動用到的 Team
- 主要的使用者角色以及相關場景
- 必要 Must / 有時間再做就可以 Nice to have
這時候會起一個 Redmine 的主票，在 slack cc 相關人等上去評論
2. 寫 Product Updates
因為我們 Tech team 開發速度和能量太驚人。非 Tech 的人常常會被新冒出的功能驚嚇到，或者已經上線的功能他們不知道還跑來催。
所以當我們 Deploy 或者要 release build 時，會寫 Tech Updates 寄給全公司。讓大家對我們這一兩天做了什麼有基本的了解。或者做好應有的應對衝擊。
以免產生要馬覺得 Tech 都亂作亂 deploy 功能，或者是 Tech 都 delay 功能的誤會。
我們怎用 Redmine ?
會用 Redmine 是因為試到一個功能其他專案管理軟體「都沒有」。就是「無限的巢狀票」。（我不是說其他套軟體不好。每一套有它適合的專案複雜度）
我們會用巢狀票去切細切碎 Story。Redmine 對於需要跨多 team 合作的專案非常適合。特別是我們幾乎所有的專案都需要 backend, front, design, 還要 release 到三個 client 上。
同時，切碎 Story 也有助於 RD 專精在功能的思考與任務分配上。其他專案管理最大的缺點就是通常只有兩層 Task。不太夠用。
就算是寫一個中型功能，RD 有時候也會遇到 nice to have, tricky bug, edge case, complex implementation, 不拆票很容易就鬼打牆。junior 更是不拆票就當場死，而且還死在非常前面。redmine 可以幫助 RD 有自我 task management 的習慣。
redmine 還有 related ticket 可以用。大家可以用 related 串來串去，related to / block by 之類的。
我們通常會這樣切票,
master 票，下有
- story 票
- design 票
- backend 票
- fnd 票
- ios 票
- android 票 implementation 做完會關掉開 QA 票。
然後因為我們公司有太多線 project 還有軟體有太多 phase release 要管了。所以我們還有一個 basecamp 去管這些 release。不然會管到爆炸..
Take away
所以結論是什麼？ XDDDDD
結論不是我告訴你哪一套軟體或哪一套流程比較好。然後你回家照著用結果處處踢鐵板。
反省團隊的根本效率問題是什麼
而是要認真去檢視你到底要解決團隊裡面的什麼問題，一次解一個問題，遇到問題再去翻書逛 blog。
很多時候不是某某書上沒寫什麼，或者是某個作者對某方法或某軟體有強烈的偏見。而是你再找解法時，沒有認真先去 identify 你的問題到底是什麼。（「效率不彰」本身不是一個「詳細的問題」）
就連我自己寫不同專案在不同場景時也會用不同工具 Set 了。有時候我自己寫 side project 根本沒有 user story 也沒有 project management，甚至連 branch 都不切，Test 也不寫，但這樣慢嗎？無敵快的勒 XDDDDDD 但這卻不是一個專案合作上的好方法。
我這一篇文章主要是在介紹我現在管專案所使用的 General Method 與 General Tool，相信裡面大部分也是一般團隊常遇見的問題。
我自己認為，專案執行上有問題不脫是幾點問題
- 對目標迷失
- 時間觀念迷失
- 外行領導內行
- 缺乏溝通
- 專案不透明
朝著這幾點改善才能大幅改善團隊裡面的效率。去挑選工具與方法也才顯得有意義。
幾本書推薦
這三本書是我覺得講敏捷觀念與方法比較根本的三本書，也許讀者可以從這三本書入門
這三本都有簡體中文版。露天上找得到。
歡迎各位業界朋友在本文留言討論專案執行經驗。