基于TAPD的敏捷实践参考

这篇文章算是对我在上家公司期间使用腾讯TAPD协作平台的一些经验总结,供对TAPD感兴趣的童鞋参考使用。

1 前言

在笔者之前的工作经历中,产研团队使用腾讯的TAPD平台进行协作,经过一段时间的磨合后,效果比较明显,流程日趋规范,迭代的节奏感也把控得很好。今年6月初换了新工作,发现新公司内部也在推广TAPD,故撰写了本文,供领导参考借鉴。

2 团队角色定义

产品:需求收集、定义,原型和PRD制作,版本规划,产品验收,培训等
研发:需求实现
测试:需求测试
运维:系统上线以及日常运维
运营:使用已实现的功能/系统进行业务推广、运营

3 整体协作流程

3.1 创建项目组

公司内部一般都是以项目组为单位,如某个系统/产品,或者某个营销活动。

负责的项目经理(有时候是产品经理兼任,或者是研发经理兼职)以项目组为单位创建一个TAPD项目。

如果是典型的产品研发项目,建议使用功能最全的“敏捷开发全生命周期”模板(企业版TAPD才有这个模板)。

默认情况下,公司申请注册开通TAPD账号后会发现,只能用专业版。如果要使用更为强大的企业版,需要深度使用TAPD半年后才能提出申请升级版本。如果贵司有腾讯前员工,则可以直接提出申请使用企业版。如果你认识腾讯的前员工,对方愿意帮你推荐,那么你也可以直接申请到企业版。这里要特别感谢前公司的某同事,因为他的前企鹅员工身份,我才得以快速帮现在的公司申请到企业版。

3.2 调整项目组成员权限

如果为了限制项目组成员内不同角色成员在本项目内的操作权限,可以考虑对他们进行权限调整。

如:产品经理只能维护需求,不能创建任务;研发只能在需求下创建任务,没有其他模块权限。
先自定义用户组,然后修改项目成员在本项目内的所属用户组。

3.3 需求池的维护

由于产品经理会从市场、渠道、运营、用户等收集到很多改进的意见建议,为了有效管理,一般会维护一个需求池。

在以往,常见的需求维护方式是,用一个Excel管理起来,放到共享盘给大家编辑和查看。这种方式弊端很多,如协作很不方便,无法灵活直观调整需求等。

在TAPD中,产品经理一般是直接在具体项目中的“需求”栏下维护需求池,以故事Story的形式直观呈现。

根据实际需要,可以对需求进行简单分类(放在不同的子目录下),方便管理。

需求池比较关键的是明确好每个需求的优先级。只有高优先级的需求,才会优先进入迭代版本。

如果需求较为复杂,建议使用父子需求的方式来拆分story。使对父子需求的好处是,可对一个大的复杂需求进行集中管理。

需求点的描述没有很严格的规范,产品经理可以根据实际情况而定来撰写。也可以参考以下模板:

  • 需求来源
  • 需求背景
  • 需求描述

如果要统一模板,项目管理员可以在后台配置好本项目默认的需求创建页内容模板。

3.4 规划迭代

根据想要实现的阶段性目标,产品经理从本项目的需求池中,挑选出高优先级的需求点,创建一个TAPD迭代版本(注意,此时的迭代版本内容还没最终定下来,需要与研发讨论评审后才能最终确定要做的功能点)。

一个迭代版本的周期(含测试)一般控制在2~3周。太短的话做不了多少事情,太长的话,容易出现拖延的现象,团队成员没有紧张感。

版本的规划,一般遵循MVP原则,即最小可行化的原则。一个版本只需要包含能跑通核心业务流程的最少功能需求,其他的功能属于锦上添花,一律到第一个版本上线运行后再考虑迭代加上。典型的例子是:某些后台配置功能,可以先用脚本或者配置文件实现,后续再做成可视化的界面配置功能。

MVP的好处是用最少的资源投入、最短的时间来验证需求的可行性。

如果需求非常明确、确认可行、资源充足、上线时间不紧迫,则不必遵循过于严格的MVP,可以考虑把功能细节规划得详细一点。

3.5 需求评审

部分团队会有一个需求初审的环节,即,产品找研发leader或者研发的开发人员,小范围先过一遍需求,主要是可行性的问题。初审的好处?避免浪费大家的时间,尤其是研发和测试的时间,技术人员都不喜欢整天开会,如果需求本身不够完善、可行性有问题,则可以在小范围内做好拦截处理。

如果不是特别复杂、庞大的需求,也可以不用此环节,直接进入正式审批环节。

正式的需求评审环节,研发(含UI设计部门)和测试部门都得参加。

研发有权拒绝做某些需求,如果认为不合理的话。研发也可以要求将某些功能优先级降低,挪到下个版本来实现。

产品根据评审的反馈,对迭代版本做出适当的修改。

评审通过后,迭代版本即确认定稿。

3.6 研发排期和实现

研发部门根据需求的复杂度和现有资源情况,召集研发内部的讨论会(非必须,如不是很复杂的功能版本,也可以在需求评审会结束后当场就快速分配好任务)。

研发内部创建、分配和认领好任务(指定处理人)。

任务的处理人一般需要给出以下信息:

  • 预估工时
  • 预计开始
  • 预计结束

研发leader要检查和协调研发成员的工时分配,避免出现衔接不上的问题。

注意:建议项目经理在 项目设置 > 其他设置 > 可选功能 中修改工时单位为“人日”。

研发leader根据总体的工时估算,给出此迭代版本研发完成的预计日期。

进入研发阶段后,一般不允许修改需求,不过减需求是允许的(只能减不能加)。如果是不涉及到主流程、核心功能实现的小改动,如改个简单的字段,改个图标,一般是允许的(实际上在研发过程中,这类变动也很常见)。特殊情形做特殊处理,只是一般建议需求发生较大改动时,放到下个版本实现,不要影响到当前的迭代版本。如果真的出现重大变动不得不做的,那就需要领导介入来决定。实际上,已经进入研发阶段,需求还出现重大变动,那就是产品经理的责任了。

日常情况下,研发在TAPD的个人工作台就可以看到自己的待办/任务。

研发根据实际情况更新需求/任务的进度,如修改其状态。

3.7 测试用例与测试环节

参加完需求评审会议后,需求已经定稿,则测试部门可以开始安排人员撰写测试用例。

一般来说,测试部门需要在研发实现功能之前完成测试用例准备。

根据研发部门给出的预计完成时间,测试部门需要给出具体的测试排期起始时间。正常来说,研发完成后,测试应该立即投入测试资源,不过也得看测试部门本身的资源安排。

如果使用的是企业版TAPD,则具备测试模块功能,测试人员可以直接在TAPD上记录测试用例、记录bug。

如果使用专业版的TAPD,则只能简单做Bug登记,没有较全的测试用例功能。

典型的TAPD测试管理流程可以参考:
1、编写测试用例,用例关联到需求点
2、创建测试计划,指定待测需求点,加载关联的用例
3、执行测试用例
4、如果用例未通过,则关联记录缺陷,并把缺陷流转给负责的研发
5、研发收到缺陷,修复后,更新缺陷状态并流转给测试进行确认
6、测试人员确认是否修复了缺陷

研发在提测之前,需要进行必要的自测,确保提测代码的质量。如果研发提测的版本有很多问题,如基本的流程都无法跑通,则测试可以直接打回测试申请,让研发修改完善后再次提测。

3.8 测试环境产品验收

测试部门完成所有测试后,产品经理介入,在测试环境进行一次验收,核对是否与原始需求一致。

如果不一致,则让测试提交bug给研发继续修改。如果验收通过,则测试部门发起上线申请。

3.9 上线

如果公司有专职的运维团队,上线一般都是测试发起、运维负责上线。

3.10生产环境产品验收

上线完成后,测试部门和产品经理都要介入,在生产环境验收一遍需求。

如果生产环境验收与预期不一致,则考虑紧急修复再上线一个修复版本,或者是小问题不影响核心业务流程跑通 ,可以放到下个版本一起修复改进。

如果较为紧急,但是又无法短时间内修复,则考虑将生产环境回滚到上一个版本。

3.11运营接收

通知运营部门接收上线的新功能。如有必要,产品经理需要对运营进行培训。

4 常见问题

4.1 上线时间节点问题

一个版本的实现,通常有如下预期的时间节点:

  • 产品想要的上线日期
  • 研发排期能够实现的日期
  • 测试部门答应能够测完的日期

各方需要协商好大家能够接受的日期,安排好资源,并跟好进度。

4.2 资源问题

如果研发和测试能够明确估算出时间,则资源的占用是很清晰的。举个例子,在TAPD上,某个研发人员参与了多个项目,他为每个项目下的需求/任务都填写了预估的工时,则在TAPD上可以直观看出这个研发人员的资源利用率,研发leader可以很方便地知道这个人近期是否还有余力做其他项目,而不是凭感觉安排任务。

“估算工时”有时候是一个玄学问题,真枪实弹做过几个项目的人都知道。例如,研发人员有两种常见的倾向,一种是过于乐观(“这个东西不算太复杂,估计两三天可以弄完”),常见于新手,另一种是喜欢留很多缓冲时间的(“这个东西没那么简单的,估计一周吧,我得研究研究”),一般的老手都喜欢这么干。作为产品或者说项目负责人,如果不能较为准确把控整个项目的所需工时,那他也无法和上级汇报,管理好老板的预期(“说好的两周搞定,你们拖了一个月?”)。虽然敏捷理念里面有一些更高级的估算方法,如用“规模”、“故事点”来评估,不过从我经历过的团队和项目来看,这些都太高大上了,用“工时”还是大家相对能接受的估算方式。

4.3 例会问题

敏捷实践中,一般推崇每日例会,每天早上固定时间,各个部门/项目组限制在15分钟内开一个站立会议,每个人简短发言,总结:

1. 昨天完成了什么任务
2. 今天准备做什么任务
3. 遇到什么困难需要反馈

根据实际项目的体验,每天早会很难坚持,容易流于形式,普遍也有抵触心理。但是,改为一周两次早会,则大家相对不那么抵触(如周一和周四)。而且,加上一些小机制,如迟到的人发红包,可以让早会显得不那么呆板严肃。

早会的意义在于:

1. 发现问题:很多人有问题喜欢默默解决或者直接绕过去,不喜欢提出来讨论,等到隐藏不住了才提出来(如研发遇到技术难题),容易影响到项目进度。
2. 同步进度:项目组内每个人做的事情不一样,有可能会有依赖关系(如前端依赖后端提供接口),如果没有及时同步,会有信息滞后的问题,导致项目延迟

不管你信不信,职场上的问题,大部分都是沟通不善造成的。例如老板对员工预期太高,或者是项目成员捂着问题不上报项目经理。面对面的站会,是一种很好的沟通机制,定期反馈,及时发现问题,确保项目能如期完成。

对于紧急项目,在冲刺阶段,则建议每天必须举行早会,让大家有紧迫感。

早会经营得好的话,会形成一个仪式感,大家知道自己要做什么,目标是什么。

4.4 关于迭代的节奏

一般来说,产品经理的需求要提前一个版本准备好。即,当研发和测试在实现1.0.0时,产品经理需要开始准备1.0.1,当研发完成当前版本后,如果没有太多调试排bug的任务,则可以立即评审1.0.1。控制好迭代节奏后,就不会出现研发资源闲置的问题。

4.5 关于工时估算问题

研发和测试会分别给出自己预计的实现时间,研发leader和测试leader需要检查和监督成员的估算时间,避免有人预估比实际耗时所需多很多的时间。

4.6 需求对接问题

原则上需求都要经过评审(尤其是需要研发leader知晓),产品不能私下找研发直接增加或者大幅度修改需求。

研发只和产品对接,研发不接受业务部门直接提出的改动需求。

4.7 测试排期问题

根据笔者以往的经验来看,如果项目较为紧急,功能较为复杂,更需要注意给测试留出足够的时间,不然上线后会有很多问题。需求评审完成后,测试部门需要充分评估并给出自己的排期。

4.8 迭代的进度条问题

默认情况下,迭代的进度条是基于迭代内所有工作的关闭进度。

4.9 TAPD点击打开新页面问题

可能你也早就发现了,TAPD的大部分链接都是在新页面打开的,这会造成浏览器同时开十几个页面的壮观现象,榨干你的内存。。。如果你用谷歌浏览器的话,建议安装一个叫做Open Self Tab的扩展程序,限制TAPD系统内的链接只能在当前页面打开。

发表评论

电子邮件地址不会被公开。 必填项已用*标注