腾讯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未来可以带给我们更多便利和惊喜。