1
之所以想写这篇文章,是因为之前自己初次使用JIRA的时候,无法在互联网上找到好资料。好不容易看到一个培训课程,还要收费2K+。我想,这么一个系统,也要收费这么高?等哪天我学会了,我就自己写一个。
上个月,也确实觉得应该写一点了,于是就回到简书,写了20个字,还说明天更新完(牛总是很容易吹)。今天回到简书,竟然还有人来读过。突然,我自己觉得非常惭愧,大家过来了,但是内容没有上。于是,赶紧将使用说明更新上来。
为了方便说明,我在图片上画上了很多箭头和文字。给大家带来的不便,还希望多多谅解。另外,我这里谈的是管理员账号,部分内容普通用户不能使用,譬如版本发布。
考虑到需要保护项目信息,在此我隐去了项目名称和人员信息。若给大家造成了阅读上的不便,还请大家多多原谅~
2
做软件项目的宝宝们,多少都知道JIRA这个项目管理工具。那么,我就直接说怎么用最,尤其是常见的功能。
有管理员账号的话,可以去创建如下内容:
- Project,类似于项目,一个项目中可能有多个项目。
- Board,类似于看板,用来查看项目中某个组成部分的开发进度。
- 开发流程步骤,包括To Do, Blocked, In Dev, In QA, To Review, Done等。也可以根据项目情况自定义,譬如,加上QA(STG),方便测试妹子工作的开展。
- Sprint迭代,我们用的是通常采用的两周。当然,也有一周或四周的。具体的,就不讨论了。
-Story Point,点数,项目团队用来描述完成某项工作所需的时间投入。我们这里,用来描述开发难度。
对于严格执行迭代管理,尤其是开发速度的团队而言,所有迭代工作规划,用户故事创建,点数估算等,都需要在迭代真正开始之前完成。这里,需要为即将开启的迭代设定具体的时间(具体到分钟)。当然,这其中也需要配合需求变更管理,否则执行起来有难度。当然,迭代要在结束之前关闭,否则,就算工作完成了,后台的燃尽图也无法燃尽。这一部分,稍后再讲。
通过产品代办事项,可以创建Ticket,包括任务,bug等。也可以创建发布版本,并设定时间,譬如ISV2.1.0 (12/29/2017),也是为了方便管理。
Ticket创建出错的话,直接点击,通过“Move Issue”进行移动,如:所属Project,Type(任务改成bug)。
同时,还可以对一个Ticket进行Clone(复制),还可以带上其附属的附件,并带上迭代信息。
3
严格执行迭代管理的话,可以用 Burndown Chart燃尽图来监控。当然,这也需要合理管理客户需求变更,否则无法实现。理想情况,Burndown Chart是一根倾斜向下的曲线。但是,如果任务量拆分不是很细,或者工作之间还有依赖的话,曲线就会发生变化,如下所示。
中间灰色的柱状是周末。有了多个Burndown Chart后,就可以估算出开发某项大任务,大概需要多少时间,包括:最乐观时间、最悲观时间、最可能时间,是估算进度的辅助工具。
4
相对而言,JIRA作为项目管理工具,还是非常好用的,尤其是搭上Confluence之后。后面这部分,以后有时间再来写。
希望能帮大家更快上手使用JIRA。