「PM World -工具類」小團隊跑敏捷,實務上這樣用 Trello!

專案管理有許多可以探討的議題,隨著新創風氣在許多育成單位協助後蓬勃發展,但不盡然都是資訊呈現為主的網站,在工具上更是雨後春筍般不斷有針對特定流程、特定目的、特定對象產生的第三方服務,那這些到底該怎麼選擇?用了這些工具就能做到他所說的效果嗎?其實並不其然。
 

目標先決比工具先決重要

相信許多 PM/管理者 一定都有過該遵循哪種管理方式比較好?專案管理服務幾十種該怎挑選?該怎麼樣確保上線的品質?該怎確保工程師成就感?等等的心中小劇場。筆者也經歷過這樣的過程,甚至試用了 10 幾套專案管理工具,最終才發現,這些服務、心法還是管理方法,終究只是達到我們管理目標的一個工具/方式,還是要問問自己,想要打造怎麼樣工作模式與氣氛的產品開發團隊。

 

當時在尋找工具前,希望管理方式能做到三大目標:

  1. 工程師能有不斷完成工作的成就感,團隊也能有一個時間區間的共同成就

  2. 一旦規格訂好討論好後,減少開發過程間的溝通

  3. 開發內容與討論過程都能公開透明並保留記錄

工具的挑選


現在專案管理服務非常的多,像是 JIRA, Trello, Asana, Redmine, Notion, Basecamp, Phabricator 等等,筆者都有實際上去測試且將某功能的 issues 搬上去玩玩。但形式非常的多,有適合敏捷的、Scrum、待辦事項的、指派工作為主的,甚至有連文件管理跟 CI/CD 統包的服務。蘇格拉底說:「我唯一知道的就是我一無所知」,這句話的奧妙就在我們生活隨處都在遇到,知道太多時就像無頭蒼蠅,不知道該往何處去。

目標先決重要就在於莫望初衷,我們想要的就如 Scrum 的模式,一開始大量溝通與規劃,每日隨時的校正,最後不斷透過每個 Sprint 檢核團隊成果,並檢討與改進,獲取不斷往前的成就感累積。但,小團隊與創業剛起步時,有的是許多的想法....就是沒有人、沒有錢、沒有客戶。這時需要的是快速的演進,根據客戶與市場需求不斷快速的開發,是產品 0-20 分很重要的過程。

最終,我們則是選擇了 Trello 作為管理工具,簡單、有彈性、有標籤、有篩選器、有指派功能,還有許多 browser extensions 能夠擴展功能,更重要的是,免費。

(後記:若有使用github 作為主要管理程式碼的服務,可以試試看Waffle.io,基本功能與 trello 一樣,差異最大在於他的每張卡等同於 github issue,且有做同步的整合),基本功能與 trello 一樣,差異最大在於他的每張卡等同於 github issue,且有做同步的整合)



先簡單定義一下 Trello 功能搭配專案管理上的連結關係:(參照範例圖)

  1. board(看板):代表一個專案

  2. list(列表):代表開發流程中的一個步驟
  3. card(卡片):俗稱的票(issue)。

這定義尤其重要的是 board,過去在使用 trello 上因忽略背後設計理念,以 board 為團隊,將所有專案的票都開在一起,最後沒了流程性,每張票的流程與進度都得進去看內容才知道;每個 list 也因爲各專案的工作很多,整合在一起時便多到讓人嫑嫑的,導致整個管理失敗。在吸取過去與其他團隊的經驗下,我們有了幾個原則:
 

  1. 各自為政,一同努力
  2. 每一個 board 代表一個專案,有多個專案就需要開多個 board,讓各個負責人專心瞭解他們該做的工作就好。
  3. 另外,若同專案有不同目的也應拆成兩個 board,像我們有個 A 產品開發版,以及 A 產品規劃版,讓 PM 規劃每個功能也有流程可以跑供大家檢視。
  4. 列表只用作為流程的步驟使用
  5. 分工合作,逐步完成
  6. 每張卡片盡可能切細,最多半天能處理完的大小
  7. 卡片在切分時盡可能降低耦合、增加內聚力,讓每張卡的相依性降低(這很難我知道,所以盡可能)
  8. 透明公開,彼此瞭解
  9. 以卡片在 trello 的 url slug 作為 git branch name(例如:https://trello.com/c/wIdo3qXx/732-system-should-apply-only-one-automatic-coupon-when-checkout,就會以最後粗體字處作為分支名稱,甚至在分支切換時也可透過前面的數字做到 auto complete)
  10. 每張卡片完成後,都需要在 github 上開 pull request(後簡稱 PR),並且將連結貼回至卡片中,讓 code review 以及其他對此工作有興趣的夥伴,都能直接連結過去。

(範例圖)


在這樣的原則下,我們的 lists 大致為:(參照流程圖)

  1. Sprint to do:每個 Sprint 團隊要一起完成的工作。

  2. Blocked by:若有張票開發到卡住,則丟進此處並標記被卡住的卡片連結,相對該卡片也應標記此張卡片,以便未來完成後可再持續解決這張卡。

  3. Developing:當工程師要開始開發時,則將卡片移動,作為一個開始動作,同時也可讓大家知道目前每個人正在開發什麼內容。

  4. To revise:開發流程最後一定都會需要有他人進行 review,不論是 coding style, architecture 或是 user flow,有需修正的地方,我們都會在 PR 中註記,並將此卡片丟至此處。

  5. Done:已完成開發的卡片,等待後續 review。

  6. To Deploy:代表 review 完成沒問題,並已完成 merge 等待最後確認(e.g. staging, CI auto testing)上線。

  7. Deployed:功能正式上線後,卡片就會丟到此處算流程完整跑完,大家也能在此看到已上線哪些功能。


(流程圖)


成效如何?

在新流程導入後,工程師都反饋比起過往在執行每個卡片時,需煩惱 branch name 如何命名,以及在想瞭解過往夥伴執行的工作時都還得打斷對方做詢問等狀況,在簡單一個統一的 branch naming rule 下,讓整個團隊運作的彼此瞭解,能透過工程師的共同語言:「程式碼」做溝通,減少許多不必要的溝通。

實際開發上,因為卡片的大小有一定規範,獲得兩個顯著的收穫。第一個是,每天工程師都能有完成些什麼的成就感,作為不斷持續的動力;code review 上也因為卡片的大小限制,讓進入成本(時間成本、心理成本)大幅降低,可以將可用資源最大利用的將功能完成測試上線。對於 PM 與管理人員來說,能更確實在功能上線前都一定會經過檢核,還能明確掌握每一位成員手中在執行的任務,協助每個成員對準團隊目標。

實際上在跑有遇到幾個比較特別的狀況,假設真的這個功能較大很難拆出每張可以獨自被 merge 到 master 的票,可以在卡片中溝通哪幾張票都應該 merge 到某一個 branch,等到最後完成時再一次回到 master;前端與設計該怎進入此流程?一樣將設計與切版都開票,走一樣的流程;若需要其他後端協助,再將後端拉進票中一同幫忙。

 

小結

我們團隊(後端*2、設計/前端*2、Tech lead/PM)依照這樣流程跑了超過半年,平均每週能上版超過10個大大小小版本。在聽過中國大公司其中一個小組分享他們一年上版150-200個版本,相比之下 10+/週算是很不錯的一個成績。

 

產品開發管理就這樣嗎?

此篇著重在從規劃完成後,票的建立到完成上線如何有效的被實踐。其他像是 standup meeting(我們用 jell 各自紀錄同步 slack 取代)、程式碼品質檢驗(code climate)、自動化測試、持續性發佈(CD)等等;非工程面,像是像是怎麼訂版本號、如何根據市場設定戰略目標、如何製作商業模式的營運報表等,又是另外一門學問了,讓我們下次見。

若有更多好奇的細節或是議題,歡迎來信或填以下問卷與我們討論。

問卷裡有神祕的Trello聚會活動喔~