工程團隊如何做專案與程式碼管理 （二）
如何讓專案管理系統上的 User Story 可跟程式碼進度同步 (a.k.a 可驗收）
這當中手續有點複雜，我從幾個原則開始說明。
Ticket branch 使用專案管理系統的票號命名
很多人是使用 gitflow 這個流程去管理程式碼，坦白來說我覺得「不夠用」（a.k.a 很難用）。因為坦白來說：
- 你面對的隊友程度不同，所以 feature 切的 ticket 粒度也不同
- 實務上遇到的狀況是隊友程度不同，狀況緊急也不同，很多時候你無法強求寫 test，一大包的 pull request 混在一起的 branch，沒有辦法做驗收測試 （也就是風險很大，因為就算綠燈，你也還要測使用者介面，然後一個豬 pull request 就會污染大家）
- 喪失決策歷史。不是每個人寫 code 習慣都很好，且懂得寫好的 commit log，或者交代他為什麼要做這個 pull request。
所以我們的作法就是，拉 pull-request 的程度必須到 ticket level 等級，然後用 ticket 號碼為 branch 命名。這麼做的好處有幾個：
- 大家知道這個 branch 為何而開
- 討論決策在 issue tracking 上可以追朔得到
- 該 branch 至少解決了「 1 個明確需要處理的問題」
單支 Ticket branch 要 deliverable
所謂單支 ticket branch 要 deliverable，是指很多時候，我們理想要在一個 branch 裡面解決一個 User Story，但這是不可能做到的。這在設計一整個 workflow，或者是要 Refactor 一整組功能時，最容易發生。
狀況一：Refactor
工程師 refactor 的很開心，測試也綠燈。送上去 deploy，爆得亂七八糟，然後其他人因為這組 pull reqest，被搞得此次 release delay 連連。
而 release manager 要是擋了這組 pull request，又會回退到大家不開心。
我設計的 policy 是這樣，即便是 refactor 一整組功能。也必須要遵守這樣一系列的原則：
- 單支必須要過可以自動測試
- 單支必須要過同事手動使用者測試，而手動測試不能佔到同事 15 分鐘以上的時間，否則就是粒度太大
也就是這隻 pull request 必須要小到直接 hotfix 上去也不能死人。
狀況二：開發複雜的功能
如果是開發複雜的功能，那麼原則，大 ticket 專注在驗收「流程」，小 Ticket 專注在「功能」。假設今天我們要實作一個 Markdown 編輯器，除了要支援 Markdown 語法之外，還要可以拖拉上傳圖片。那麼 Ticket 可以切成這樣
- (1) 產生文章編輯器後台。（純 Text Field 與純 Text Area )
- (2) 把 Ticket Area 掛上 CodeMirror
- (3) 實作後台上傳功能，用 File Field 實作
- (4) 把 File Field 重構成拖拉上傳
- (5) 把拖拉上傳的 Event Listenr 跟 CodeMirror 掛勾
也就是先解決「可完成 workflow」的功能，然後再把每一個小功能當作是 bug，「修復」上去。
如此一來，所有的功能都可以獨立驗收。
工程部分的原則
這當中最重要的原則精神就是，就是一天至少 15 支 pull request，也可以放心的 deploy，不用擔心晚上需要加班救火。
客戶方面的結案建議
在前面一篇我們提到了第一階段要能夠實作 continuous deployment。是因為很多外包的客戶，對於自己外包出去的進度不安心。
用這樣的過程，你可以將驗收階段切成比較無風險的三階段：
- 工程期間，只驗收 workflow 與基本功能
- 驗收階段，驗收細節與 bug 修復
- 美術階段，驗收 UI 細節
這三件事分開驗收，感覺雖然比較麻煩，但是對於雙方信任程度與金錢、法律責任會有相當大的加分。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
