敏捷開發的Traceability

Apr. 25 12:21~13:35

 

一個多月前有一位長期接政府機關專案的鄉民甲問Teddy：「在敏捷開發中要如何做到traceability（追溯性）？」聽到這個問題Teddy內心的第一個想法就是：「這個人可能是搞CMMI或是具有軍方背景」。

最近應邀到竹科某公司介紹單元測試與分散式持續整合的經驗，演講結束之後有一位鄉民乙問了類似的問題：「我在網路上看到可以結合SVN（版控系統）、Jenkins（持續整合系統）、Redmine（議題追蹤系統）的文章，當持續整合失敗之後，可以直接在Redmine中新增一筆issue。你有沒有這方面的經驗可以分享？」

Teddy將這個問題翻譯成「鄉民乙想做traceability」，將整合失敗透過新增一個issue，與story、task、source code，甚至是撰寫source code的開發人員連結起來，以便日後的追蹤與管理。

***

先請大家思考幾個問題：traceability重不重要？如果重要，在敏捷開發中要如何管理traceability？

有讀過軟體工程相關書籍的鄉民應該都會知道軟體工程很重視traceability，因為使用者的需求被分解之後，交由若干個類別與函數來實作。如果不知道這種垂直性的關係，就不容易評估修改需求所造成的影響與成本。另外還有一種traceability叫做水平追溯性，管理功能與功能之間的相依性。例如，銷售產品功能與結帳功能彼此相依。

被軟體工程，特別是CMMI給「荼毒 教育」過的鄉民，來到敏捷開發的世界，也會想要管理traceability，所以自然而然就想到透過在source code貼tag的方法，再加上一些script，配合issue tracking system，來做到自動化的追溯性管理。

如果Teddy說在敏捷開發中不需要做traceability，應該會被很多鄉民打死。當然不是不需要做，而是該用哪種方式來做？首先，Teddy覺得敏捷開發中管理traceability的主要手段應該是透過自動化的測試案例來達成。要知道垂直追溯性，那就幫story寫一個（或若干個）驗收測試。要知道水平追溯性，可以寫串起多個story的系統測試。如果這一點已經做到，發現還是需要更細部的追溯性管理，再來思考要求開發人員在source code貼tag以及後續自動化建立traceability關係圖的必要性。

***

Teddy曾經協助某個團隊導入Scrum，該團隊在Teddy涉入之前，就已經採用電子化工作看板、持續整合系統、議題追蹤系統、版控系統，也要求開發人員在程式中貼tag，建立起source code和task以及story的相依性關係。就Teddy的觀察，該團隊會這麼做的目的，主要是讓主管可以透過電子化工作看板追蹤開發人員認領工作（task）的進度，以及在「有空的時候」可以幫開發人員做code review（所以要求開發人員commit code的時候要加上 task ID與story ID）。

聽起來很棒，不是嗎？反正要求開發人員在commit code的時候加上task ID與story ID，也花不了什麼時間，有些系統與開發環境甚至會自動幫開發人員在commit code的時候加上task ID與story ID。有了這種traceability，主管就可以在「任何時候」，來管理開發人員的工作。

看到這種作法，當時Teddy問了幾個問題….

Teddy：如果覺得code review很重要，為什麼要把責任綁在主管身上，不讓開發人員互相review，或是用pair programming的方式來開發？

主管：因為開發人員的經驗不夠啊，而且大家「不習慣」pair programming。有了系統之後，我就可以在有空的時候隨時連上系統review開發人員所寫的程式。

Teddy：那你有經常去review code嗎？

主管：其實沒有，因為我太忙了，很多會議要開。

***

建立鉅細靡遺的traceability在「理論上」的確可以做到很多事情，但制定規範的重點不是「追求理論上帶來的好處」，而應該先考慮「實際上可以做到哪裡」。否則很多人會以為團隊已經獲得「理論上的好處」，而忽略了實際上的現況。

不是不需要做詳細的traceability，而是「等到真正需要的時候」再做。至於什麼時候才是「真正需要的時候」，就需要鄉民們用智慧去判斷了。

***

友藏內心獨白：不必要的traceability，也是一種浪費。