almost 8 years ago

這三篇裡面我嘗試回答了幾個許多團隊都會遇到的問題,也是我過去七年的技術經驗累積:

  • User Story 的粒度怎麼切到夠上 issue tracking
  • 如何根據 User Story 精確的驗收 milestone 與控制開發速度與優先權
  • 如何讓專案管理與程式碼開發進度緊密結合
  • 如何讓客戶對你的專案管理,隨時能夠保持安心狀態
  • 如何 release 大的功能與大的 refactor
  • 如何設計出一個可以每天 15-20 支 pull-request 的 release 流程
  • 如何保持整個團隊的技術產品 release 訊息同步

過去我分享的敏捷專案管理,多半是屬於「規劃方面」的分享。這一個系列,我專注寫的方向是「如何具體執行」。

很多技術圈的朋友嚮往敏捷,但事實上敏捷非常吃隊友程度。而且實務上,總有很多理想是「這樣」、實際協作上卻是「那樣」的人際衝突。

總結:

關於工程執行以及協作,我可以歸納幾個「無關隊友程度」的原則給各位參考:

1. 清楚溝通,別通靈

User Story 講清楚,風險問題不要扭捏閃避。用 standup 時間釐清風險與優先權。

2. 克制貪心

Must have 與 Should Have 才是最重要的部分。不要讓太多 Could have 的貪心把未來緩衝時間用掉。

去掉 PM 本身的規劃疏失,專案 delay 很多時候都是 RD 的悶頭不溝通與 could have (炫耀)的貪心心態在作祟。

3. 有公德心

想想自己是負責 merge 與 deploy 的人時,你想要收到的 pull-request 是什麼粒度與格式。然後依據這種心態,好好的撰寫 pull-request 的說明。

一個壞的 pull-request,壞的不是 reviewer 的時間,而是技術團隊所有人的時間。

4. 進度公開透明,提早整合測試

很多專案的紛爭,都是因為「技術團隊寫了,還沒上線」,「技術團隊上線了,整個功能還沒有測試」。對於不懂技術的人,沒有上線進度就是 0,不是 50 分。盡量保持每一個進度「有可驗收成果」,信任程度才會高。

隨時讓技術團隊外的人,知道今天發生了什麼事。技術團隊的效率進度流速往往是其他團隊的 10 倍。
但是若技術團隊沒有可以展示的進度,外界對技術團隊的觀感就是 1/10 倍。

5. 保持自動化

容易人為造成的高風險部分,應該盡量利用工具自動化。

===

很多時候,信任、透明、進度展示、公德心,我認為才是「敏捷」的重點,而不是那些框架與方法。

← 工程團隊如何做專案與程式碼管理 (三) 2016 亞洲區最棒的 Rails 年會 RailsPacific 回來了 (5/20) →
 
comments powered by Disqus