騰訊TAPD合作貨車幫：項目管理實踐

(1)客戶介紹

DMS項目是貨車幫的一個內部工具項目，由六人團隊負責開發，包含了產品經理(PM)、前端開發、后端開發、QA，麻雀雖小，但五臟俱全。DMS項目是為其他研發團隊的開發測試流程提供工具支持，其需求主要來自各個研發團隊，公司所有的程序員，就是我們的客戶。

(2)項目背景

DMS是個B-S結構的web應用，頁面交互較多，需求比較繁雜。在沒有使用TAPD前，DMS的開發組用一套系統來管理需求、缺陷，測試組又用另一套系統來管理測試任務、計劃、報告。文檔的管理更加混亂，經常是郵件和word文檔滿天飛，這給我們的團隊交流帶來了相當多的不便，也容易出現信息的不一致。

(3)解決方案

現在我們使用TAPD來進行項目管理，項目的所有需求(story)、任務(task)、缺陷(bug)、測試用例、測試計劃，甚至包括項目文檔都放在TAPD上，統一的賬號及權限管理，完整的需求/缺陷生命周期，都全部在TAPD上進行管理。下面介紹一些我們使用TAPD的經驗。

工作流設置

為了將DMS的計劃、開發、測試、評審等一套完整的工作流在TAPD上管理，我們利用TAPD的"工作流設置"功能，為story、bug等工單增加了更多的狀態，以加強內部的開發流程管理。

舉例而言，下面是我們采用的story工作流。團隊約定，story必須和bug一樣經過QA的測試驗證，并由QA標注"已驗證"。QA驗證之后，PM最后還需要再迭代評審會議上對story進行review，review通過了才能正式關閉story。

迭代規劃

PM維護公司的需求池，DMS小組每兩個星期進行一次迭代。PM會在每次迭代會議前，規劃本迭代計劃的story、task、bug。 

迭代會上經過討論，條件不滿足的story被放回需求池，明確可行的story才會被本迭代最終選定。PM習慣使用TAPD的迭代規劃功能，方便拖動和編輯 。

Story被確定后就要拆分子任務，每個story及子任務，都需要明確負責人。只要一個需求需要多人來完成，就必須拆分子任務，比如前端需要修改頁面，同時后端需要提供API。 

但對于QA來說，只需要關注story本身。所以，story的具體描述都是寫在story里，子任務只需要明確寫自己需要做的事情 。

測試

DMS使用TAPD來管理測試用例，并規劃不同目的測試活動。

對每一個story，QA會針對需求設計測試用例，并發給開發和PM進行review。QA每個迭代會創建相應的測試計劃，包含迭代內所有story的測試用例。

每當一個story由開發標記為"已解決"，QA就開始測試這個story的用例。如果QA發現問題，就及時和開發及PM溝通，如果PM認定是不可接受的bug，就由QA將story"重開"，打回給開發改。如果PM認為可以延后，QA則開bug放到后續迭代來計劃。 

除了常規的迭代測試外，QA還會另外通過TAPD規劃冒煙測試、回歸測試等不同目的的測試計劃。

當測試用例執行失敗時，就能夠直接創建缺陷或者關聯已有缺陷。這樣QA執行完一輪測試后，缺陷也都提交完畢，并且和對應的測試用例及需求關聯起來。這給開發提供了更多的信息，也節省了QA的時間。

消息通知

貨車幫內部使用企業微信進行日常工作交流，DMS組利用TAPD的企業微信和郵件通知功能，將整個工作流配置了自動通知，在工單發生狀態和內容變化時，第一時間通知相關同事。

比如，配置項目的story模板，將QA和PM加入到缺省"抄送人"列表。

然后，再配置打開需要的通知方式。這樣，每當一個story/bug新建、狀態變化或者內容、評論有更新時，QA和PM就能及時收到通知。

以前某些情況下需求發生了變更，PM可能會忘記通知相關地所有人。通過配置通知，進一步加強了團隊的信息交流，需求的變更信息會第一時間讓相關同事都了解到。

文檔管理

DMS在引入TAPD之后，也利用TAPD帶的Wiki來管理項目的所有文檔。我們制定了文檔庫的目錄結構，規定所有文檔都要通過wiki管理，包括調研、架構方案、原型設計等等。TAPD的Wiki支持富文本模式和markdown模式，有很好的預覽功能。

(4)價值體現

正是在TAPD的幫助下，我們得以對需求、缺陷等進行完整的全周期管理，從而不斷迭代優化DMS產品，為貨車幫其他研發團隊提供更好的支持。期待TAPD未來可以帶給我們更多便利和驚喜。