- 工程團隊如何做專案與程式碼管理 （一） User Story 如何上專案管理系統
- 工程團隊如何做專案與程式碼管理 （二） 程式碼如何與專案管理系統整合
- 工程團隊如何做專案與程式碼管理 （三） 如何保持高速的 development & deploy 步調
這三篇裡面我嘗試回答了幾個許多團隊都會遇到的問題，也是我過去七年的技術經驗累積：
- 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. 保持自動化
容易人為造成的高風險部分，應該盡量利用工具自動化。
＝＝＝
很多時候，信任、透明、進度展示、公德心，我認為才是「敏捷」的重點，而不是那些框架與方法。