騰訊TAPD合作貨車幫：項(xiàng)目管理實(shí)踐

677次閱讀

(1)客戶介紹

DMS項(xiàng)目是貨車幫的一個(gè)內(nèi)部工具項(xiàng)目，由六人團(tuán)隊(duì)負(fù)責(zé)開發(fā)，包含了產(chǎn)品經(jīng)理(PM)、前端開發(fā)、后端開發(fā)、QA，麻雀雖小，但五臟俱全。DMS項(xiàng)目是為其他研發(fā)團(tuán)隊(duì)的開發(fā)測(cè)試流程提供工具支持，其需求主要來(lái)自各個(gè)研發(fā)團(tuán)隊(duì)，公司所有的程序員，就是我們的客戶。

(2)項(xiàng)目背景

DMS是個(gè)B-S結(jié)構(gòu)的web應(yīng)用，頁(yè)面交互較多，需求比較繁雜。在沒(méi)有使用TAPD前，DMS的開發(fā)組用一套系統(tǒng)來(lái)管理需求、缺陷，測(cè)試組又用另一套系統(tǒng)來(lái)管理測(cè)試任務(wù)、計(jì)劃、報(bào)告。文檔的管理更加混亂，經(jīng)常是郵件和word文檔滿天飛，這給我們的團(tuán)隊(duì)交流帶來(lái)了相當(dāng)多的不便，也容易出現(xiàn)信息的不一致。

(3)解決方案

現(xiàn)在我們使用TAPD來(lái)進(jìn)行項(xiàng)目管理，項(xiàng)目的所有需求(story)、任務(wù)(task)、缺陷(bug)、測(cè)試用例、測(cè)試計(jì)劃，甚至包括項(xiàng)目文檔都放在TAPD上，統(tǒng)一的賬號(hào)及權(quán)限管理，完整的需求/缺陷生命周期，都全部在TAPD上進(jìn)行管理。下面介紹一些我們使用TAPD的經(jīng)驗(yàn)。

工作流設(shè)置

為了將DMS的計(jì)劃、開發(fā)、測(cè)試、評(píng)審等一套完整的工作流在TAPD上管理，我們利用TAPD的"工作流設(shè)置"功能，為story、bug等工單增加了更多的狀態(tài)，以加強(qiáng)內(nèi)部的開發(fā)流程管理。

舉例而言，下面是我們采用的story工作流。團(tuán)隊(duì)約定，story必須和bug一樣經(jīng)過(guò)QA的測(cè)試驗(yàn)證，并由QA標(biāo)注"已驗(yàn)證"。QA驗(yàn)證之后，PM最后還需要再迭代評(píng)審會(huì)議上對(duì)story進(jìn)行review，review通過(guò)了才能正式關(guān)閉story。

undefined

迭代規(guī)劃

PM維護(hù)公司的需求池，DMS小組每?jī)蓚€(gè)星期進(jìn)行一次迭代。PM會(huì)在每次迭代會(huì)議前，規(guī)劃本迭代計(jì)劃的story、task、bug。

undefined

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

undefined

Story被確定后就要拆分子任務(wù)，每個(gè)story及子任務(wù)，都需要明確負(fù)責(zé)人。只要一個(gè)需求需要多人來(lái)完成，就必須拆分子任務(wù)，比如前端需要修改頁(yè)面，同時(shí)后端需要提供API。

undefined

但對(duì)于QA來(lái)說(shuō)，只需要關(guān)注story本身。所以，story的具體描述都是寫在story里，子任務(wù)只需要明確寫自己需要做的事情。

測(cè)試

DMS使用TAPD來(lái)管理測(cè)試用例，并規(guī)劃不同目的測(cè)試活動(dòng)。

對(duì)每一個(gè)story，QA會(huì)針對(duì)需求設(shè)計(jì)測(cè)試用例，并發(fā)給開發(fā)和PM進(jìn)行review。QA每個(gè)迭代會(huì)創(chuàng)建相應(yīng)的測(cè)試計(jì)劃，包含迭代內(nèi)所有story的測(cè)試用例。

undefined

每當(dāng)一個(gè)story由開發(fā)標(biāo)記為"已解決"，QA就開始測(cè)試這個(gè)story的用例。如果QA發(fā)現(xiàn)問(wèn)題，就及時(shí)和開發(fā)及PM溝通，如果PM認(rèn)定是不可接受的bug，就由QA將story"重開"，打回給開發(fā)改。如果PM認(rèn)為可以延后，QA則開bug放到后續(xù)迭代來(lái)計(jì)劃。

除了常規(guī)的迭代測(cè)試外，QA還會(huì)另外通過(guò)TAPD規(guī)劃冒煙測(cè)試、回歸測(cè)試等不同目的的測(cè)試計(jì)劃。

undefined

當(dāng)測(cè)試用例執(zhí)行失敗時(shí)，就能夠直接創(chuàng)建缺陷或者關(guān)聯(lián)已有缺陷。這樣QA執(zhí)行完一輪測(cè)試后，缺陷也都提交完畢，并且和對(duì)應(yīng)的測(cè)試用例及需求關(guān)聯(lián)起來(lái)。這給開發(fā)提供了更多的信息，也節(jié)省了QA的時(shí)間。

消息通知

貨車幫內(nèi)部使用企業(yè)微信進(jìn)行日常工作交流，DMS組利用TAPD的企業(yè)微信和郵件通知功能，將整個(gè)工作流配置了自動(dòng)通知，在工單發(fā)生狀態(tài)和內(nèi)容變化時(shí)，第一時(shí)間通知相關(guān)同事。

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

undefined

然后，再配置打開需要的通知方式。這樣，每當(dāng)一個(gè)story/bug新建、狀態(tài)變化或者內(nèi)容、評(píng)論有更新時(shí)，QA和PM就能及時(shí)收到通知。

以前某些情況下需求發(fā)生了變更，PM可能會(huì)忘記通知相關(guān)地所有人。通過(guò)配置通知，進(jìn)一步加強(qiáng)了團(tuán)隊(duì)的信息交流，需求的變更信息會(huì)第一時(shí)間讓相關(guān)同事都了解到。

undefined

文檔管理

DMS在引入TAPD之后，也利用TAPD帶的Wiki來(lái)管理項(xiàng)目的所有文檔。我們制定了文檔庫(kù)的目錄結(jié)構(gòu)，規(guī)定所有文檔都要通過(guò)wiki管理，包括調(diào)研、架構(gòu)方案、原型設(shè)計(jì)等等。TAPD的Wiki支持富文本模式和markdown模式，有很好的預(yù)覽功能。

undefined