研发管理(四)可用报表及项目管理

上一篇文章,我们从实际使用出发,优化了在jira使用过程中的各种问题,到这里大家已经可以较为便捷的使用jira来进行项目任务的创建、状态改变,项目管理者也可以很好的进行每个冲刺的开始结束等工作,但是我们如何在项目结束或项目进行中,及时掌控项目进展状况并发现问题呢,这里我们就需要使用到jira自带的报表以及我们可以使用的第三方插件来帮助我们解决这些问题了。

本篇文章将包含如下三个部分:

  1. jira自带报表

  2. jira项目管理相关插件介绍

  3. 我对项目管理、研发效能的理解

jira自带报表

首先我们来介绍几个基于前面我们使用jira过程中比较好用的报表:

版本工作量报告

一般情况,我们开始一个冲刺之前,需要所有的研发同学在jira上完成工作任务卡片的创建和各项工作量的评估,所以在开始冲刺的阶段,我们需要有一个整体的工作量汇总,来查看每个人以及全局工作量具体有多少,从而来帮我们在项目开始前就发现研发资源及瓶颈可能在哪里,从而做出对应的调整,如下是工作量报告的查看方式:

我们选择对应版本后,设置包括子任务,因为我们所有的工作时间都是统计在子任务上了,设置后点下一步如下:

进入后我们就可以看到当前版本一共有哪些开发参与,每个人的耗时是多久,点击每个人,我们还可以查看其详细在每个子任务上耗费的时间:

所以我们就能够很方便的看到这个版本的主要开发工作在哪一块,来决策人员安排是否合理,以及做出迅速的调整,将阻塞时间将为最低。

燃耗图

项目进入开发过程中,如果一个版本的周期较长,我们如何来确保当前的开发进度是否在按照预期执行呢,这个时候我们就要用到燃耗图了,使用然后图的基础是大家每天都在按时准确的拖动卡片及登记工作时间,这也是上一篇文章我们所解决的问题。

燃耗图分为好几类,首先我们来看剩余预估时间燃耗图:

首先看下这个图如何看,红色的线代表的是剩余的时间,绿色的线代表的是消耗的时间,灰色的线代表的是预期时间消耗的走势,灰色的竖条代表那两天是周末。红色的线越接近或者拟合灰色的线代表整个项目进度越可控,如果红色线出现在灰色线上方说明项目进展较慢,在下方代表很可能会提前结束。这个图会实时根据大家的工作日志登记更新。

当然上图的灰色线是后加上去的,下面说下这个图反应的几个问题:

  1. Sprint冲刺打开过早,大家的时间还没评估完就开启了,导致预期的灰色线显示的不对。

  2. 可以看见项目前期,前两周前后端开发的进度还是很快的,比预期还要快,但是到了第三周测试介入后明显红色线下降的速度就变慢了,说明测试环节存在问题。

  3. 红色线没有消耗完,说明研发效率还是比较高的,能够在预估时间内完成开发。

  4. 周六还在加班

上面说到了剩余时间的燃耗图,我们再从问题数量的燃耗图来看下:

这也是燃耗图的一种体现,其更能反应整个研发边开发边交付的效率,我们可以看到这个版本问题的规模在140个左右,灰色线是预期的问题数量下降曲线,这张图我们能够看出如下的问题:

  1. 开始Spring冲刺后还在继续增加问题数量,也就是前期对于需求的评估不够充分,在第一周的中间基本上任务都完成创建。

  2. 第二周第三周开始陆续有问题测试完成,第四周明显出现问题,没有一个故事完成测试,实际情况是,这一周有重大的需求变更。

  3. 在项目后期可以看到仍有需求加入,大部分问题都完成了,剩余少量的几个问题还在开发及测试中,导致整个冲刺无法结束。

  4. 用户故事规模太大,整个研发周期太长,是不太适合进行冲刺形式的敏捷开发模式。

能够看出真个研发团队的高效产出,是离不开高质量的产品设计,清晰的需求描述和开发测试团队紧密的配合的。

同时燃耗图问题记数还有一种被解决问题向上增长趋近的形式,这里就不详细介绍:

累积流量图

上面讲完燃耗图,可以让我们知到当前项目整体是否按照预期的时间或者问题数量在趋近,我们可以了解大体的偏差,但是我们如何能知道整个项目在个阶段同时进行的数量来发现整个团队对问题的吞吐量呢,这里累积流量图就可以帮助我们:

累积流量图 横轴是时间,纵轴是问题个数,同一时间,不同颜色的高度代表不同状态任务的数量,这里包含了子任务(由于上篇文章,主任务可以自动的更新状态,所有上图的数据是可用的),我们可以看到前期任务数量增长很快,大部分都是待办,到中间时待办逐渐减少,集成中逐渐增多,开发完成和测试完成的高度基本相同,说明前期测试可以很好的处理掉开发完成的任务,反而集成中的减少的较慢,应该是有任务关联导致等待。从累积流量图中我们可以基本看出当前开发阶段,以及团队,开发、集成、测试的分工效率是否合理。

项目管理插件

接下来介绍几个对项目管理比较友好的插件

Tests

Test Management 是Jira内部可扩展的高性能测试管理解决方案,具有高级测试计划、报告和可重用性功能,可以很好的帮助我摸嗯对测试用例进行管理,编写测试步骤,同时关联到开发任务卡片。

我们可以通过创建文件夹针对不同的业务不同的版本进行测试用例管理。

在测试用例编辑页面,基本的编辑选项都有提供,可以很好的管理优先级和模块。

尤其是在TestScript模块,可以很好的一步一步进行测试用例执行步骤及期望结果的编写。

同时该插件还可以帮助我们生成测试报告,具体使用请查看上面的链接,非常推荐测试的小伙伴去尝试使用。

Git

git插件对于开发的同学来说非常好用,可以在 Jira 中集成 Git 提交、分支、标签和拉取请求。连接 git 服务器 GitHub、GitLab,将代码提交和项目管理进行集成。这里大家就直接参考官方的介绍:

  1. 在 Jira 中查看您的 Git 提交。快速查看提交评论、更改的文件和作者。

  2. 自动化jira工作流程,据提交、分支和拉取请求配置 DevOps 触发器,以通过Automation for Jira简化团队的 Jira 工作流程。

  3. 在jira中创建分支和拉取请求。

Worklogs

这个插件所做的事情就是统计大家每天研发登记的工作时间,最开始领到希望看到每个人每天都做了哪些事情,花了多长时间,可能会觉得有些人是在摸鱼的,于是就整出这么一个插件。

很明显大家是很反感这种方式的,而且其实很多事情是不能够很好的在jira上进行体现,例如各种需求评审,技术方案设计、测试用例会议,解决临时线上问题等,而且会导致大家为了凑够一天8小时而去凑够一天8小时,个人觉得这种方式真的是为了统计而统计,研发的产出价值并不只是通过时间来进行统计的,这样达不到太多有益且正向的目的,反而会带来大家的反感和厌恶。

Plans

那如何真多中小型团队进行较好的工作计划和开发任务管理呢,这里jira推荐我们使用Roadmap,在jira上也叫plans,我们可以针对不同的项目创建不同的plan,这里介绍两个我自己觉得比较常用的plan。

1.以人的维度来安排自己的开发任务顺序,如下图:

具体设置这里直接参考官方教程,来说下上面的图,Hierarchy只显示子任务,横向通过经办人的维度来进行分组,这样我们就可以看到分配给自己的所有任务,我们首先可以根据任务的优先级上下拖动进行排序,优先级高的先处理,然后根据我们创建卡片的时候预估的时长,及第一个任务的开始时间来进行时间拖动,规划每个任务的起始时间,这样我们就可以看到上图的内容,黄色竖线为当前时间点,红色圆圈为当前冲刺的结束时间点,这样大家就能够很好的对自己的任务进行排序,以及了解当前的开发进度是否正常。

2.以用户故事的维度来安排针对每个用户故事的调试及测试交付顺序,如下图:

这个视图就是将一个故事的所有子任务聚合在一起显示,我们可以看到一个故事下不同开发人员的子任务及其开始结束时间,一般情况下,当前后端开发完成其开发调试时间评估后,测试同学根据最后的开发时间,就能够知道当前故事能够开始测试的时间,从而明确整个故事交付的时间。

同时当遇到开发阻塞时,在Plans中我们可以方便的标记阻塞内容:

所有的阻塞我们的可以在Dependencies report中绘制出阻塞关系图

这样我们就能够很清晰的查看及安排项目的计划。

我对项目管理的理解

上面这张图是整个研发过程,其实我觉得,一个公司的效率我们更应该关注需求完整的生命周期,也就是产品+研发+测试其心协力的输出效率和交付质量,往往在开发过程中我们会发现,当需求等待、需求评审、需求变更这几个环节处理的比较好的团队,往往在研发环节可以省去很多不必要的沟通,同时研发能力强的团队同时也可以弥补一些产品设计不到位所到之的问题,提升研发效能应该是全流程的,且是大家每个齐心协力的结果。

同时然间研发效能并不光光是指单独的交付效率提升,交付效率、交付质量、交付能力三方面缺一不可,具体的分析我们可以参考 Infoq研发效能启示录 系列文章中的分析。

研发管理自己的理解就是需要更多的吸取行业上先进的管理方式,同时结合团队自身的情况来进行量体裁衣,只有大家都积极配合,且管理者能够不断的优化流程,实际的解决大家在研发中与到的问题,才能更好的形成一个集体,功能提升研发效率和质量。

到这里整个基于jira的研发管理就结束了,这个系列的文章主要是想记录下过去几个月中对于研发管理的实践及自己的思考,欢迎大家结合自己的工作,说说自己的心得。