使用JIRA进行项目管理的实践探索经验共享

2020-05-08 栏目:行业动态 查看()
本文转发自 老黎即集
 
 
从我们团队建立以来,到现在引入新的项目管理流程,前前后后经历了3次变化。

最开始的时候,采用的是传统的项目管理流程,在公司内部搭建使用 redmine 作为项目管理工具。
但是很快,大家觉得并不那么的好用,可能是某些操作习惯还是不太符合中国人的思维,并且操作繁琐了一点,而且大家都觉得界面比较丑(团队里边还是年轻人居多,大家都对现在新潮的事物比较感兴趣)。
于是,在几经筛选之后,选择了 Worktile 作为新的项目管理工具。

Worktile采用的是 “看板式管理 + 任务式驱动” 的方式进行研发流程管理,根据项目或者组定制不同的看板,让任务在看板之间进行流转。
可视化的看板让每个人的任务状态直观明了,另外Worktile还有些特性也是很不错的,比如关注任务的人可以接收到任务相关的消息,消息也会推送到个人微信等。我们使用的是免费版的Worktile,一直使用了3年左右。
免费版的Worktile现在也要收费了,不然会有人数的限制。再就是现在访问Worktile的网站经常比较慢,当你要更新任务的时候,时不时卡几下,还是很令人捉急的。
单纯的使用看板的方式去做项目管理,任务太松散了,缺乏了一些整体的概念。另外,居于信息保密的需要,使用第三方平台,会存在泄密的风险,先不说需求、任务这些,比如你就不敢上传一些重要的文档、附件等。
有什么办法可以保留现在看板简单方便好用的方式,并且解决掉上面的问题呢?
先是考察了禅道,它是国内开源做得比较好的项目管理系统,但是我试用了下,发现比较难用,并且遇到比较明显的Bug,就放弃了。
无意中看到jira以及它的Scrum敏捷开发实践,我想或许它可以解决我们现有的问题,于是就经过深入的调研与试用后,
决定就使用jira + confluence作为我们的项目管理工具,其中confluence是一套很好的文档管理系统,它可以跟jira很好地集成。
敏捷开发,几年前我就了解过但并不深入,正好这次在实践中做一次尝试。优秀的思想必然有其价值所在,不断去尝试实践才会有所进步。
Scrum敏捷开发网上的资料很多,也有很多专业的培训机构,这里就不多作阐述了。Scrum有一套完善的理论,但是每个团队的情况各有不同,并不能完全照搬理论到实际的情况中。
这一次我们也是在探索中,希望可以在Scrum的指导下,逐渐形成适用于我们的一套项目管理流程。

高效团队

一个项目做得好不好,跟团队有很大关系。从项目管理的角度来看,我认为一个高效的团队必须满足以下3点:
o 清晰的目标
o 明确的职责
o 规范的流程 

清晰的目标

清晰的目标,也即让所有团队成员都清楚团队的目标是什么,项目的目标是什么,长期的目标是什么,短期的目标是什么。
大家清楚了目标,也就有了方向。比如说,公司未来的目标是打造一个开放平台,那好,作为一个技术人员就会去想,现在的系统能不能满足需求呢,
如果要做哪个地方要改呢,需要提前做什么准备呢,架构需要怎么搞等等。作为设计人员就会去想,做成什么风格比较好呢,要准备哪些素材呢等等。
大的目标,如公司的方向、公司未来的规划等,到项目的目标、系统的目标、与第三方合作的目标,甚至到本次需求迭代的目标等等,如果让大家都了解通透,
那么做起事情来会更加的有目的,同时也会让大家跟公司、团队、项目联系更加的紧密,而不是成为纯粹的只是接任务做任务的机器一样。
我以前所在的一些公司,基层员工,甚至中层员工,大部分都不了解也不理解公司的方向。比如说要开发一套系统,绝大部分人都是为了实现功能而实现功能,
至于怎样做才能更好地达成主要的目标,却是没人会去思考得更多。

明确的职责

在一个团队中,最忌的就是团队成员职责不清,这样不仅会让事情做不好,而且可能还会出现模棱两可、相互推诿的情况。
首先,明确人的职责。在团队里边,各个职位的人员各司其职,产品经理、设计师、开发人员、测试人员等。在大型团队里边,
还会有架构师、项目经理等,在小团队里边,并没有设立这么多的岗位。而对于团队管理者来说,又不能事事亲为,那这时候最好就指定谁有更多的一些职责去做一些事情,
并且在团队里边跟大家都明确的,不然有些人就会想,你又不是领导,凭什么来管我的东西,产生这种抗拒的心理。比如谁技术好的,就负责架构,跟进团队的项目代码情况等,谁比较喜欢沟通的,可以让他去跟进项目进度与问题等。
另外,同样一个事情不要有2个负责人,这会让事情的推进不那么容易。当然了,对于成型的成熟的团队,职责划分比较明细,就没这种问题。
再就是,明确大家负责的项目,并且在项目里边的职责。一般项目会划分很多模块,不同的人负责开发不同的模块,那么模块相关的问题都要积极去响应,
出现模糊不清的问题时,需要由谁来梳理跟进。在项目管理系统当中,每个人的职责也明确清楚。比如产品的职责是管理需求,制定版本计划、创建任务等,开发人员处理任务,修复Bug等。
简单地说,就是让每个人都知道自己该做什么,职责是什么,能做什么,不能做什么,要清晰明确。

规范的流程

一个高效的团队,需要有规范的项目开发流程、测试流程、代码管理流程、发布流程、服务器管理流程等,规范的流程,可以让事情执行得更有条理,并且可以避免问题。
大厂与小公司一个比较大的区别就在于流程,就像是正规军与野战军。正规军从前线打仗、到后方支援,都是有组织有规范的,
而野战军则是经常脑袋一拍,我们要干嘛干嘛,所以要想做大,必须要有规范的流程。
规范的流程并不是一下子就能建立起来。在实际的工作中,会不断的出现问题,这时候就要考虑是否制定一些规范去避免掉一些问题。
比如我们与ERP团队在对接的时候,由于是跨部门对接,经常会不明确哪块功能该谁开发,谁来跟谁对接需求,时间进度怎么安排等,
出现问题大家就会扯皮一些责任问题。针对这些问题,两个部门之间制定了一套对接流程,每次都按流程走。如双方进入正式开发对接之前,
先由双方技术负责人、产品经理与业务方召开需求讨论会,明确功能划分,再召开技术对接会,明确对接要点,然后各自估算开发时间并相互通告,
如果需求变动应怎样确定,文档怎样对接等等,整个流程每个节点的结果通过邮件通知双方相关人员,对于一些小的需求,可由双方产品经理直接对接。
可能很多人会觉得,流程太多,会带来一些时间与效率的成本,还不如直接吼几下或者直接QQ微信完事。这就需要做一个权衡,并不是所有事都完全严格规范。
但是我相信绝大多数的事情都需要有流程去规范。
对于项目管理来说,本身就是一个复杂的过程,必然需要一套规范的流程来让它顺畅地执行。在这次新的项目管理过程中,
最重要的部分就是如何去制定一套合理的流程,这也是项目管理的核心所在。

方案实践

在日常的项目开发当中,会有以下一些情况:
o 项目比较多,且都是几个项目并行开发
o 业务线多,业务需求多,且变化快
o 系统模块多,且很复杂,经常一个版本的开发,需要涉及几个项目、几个系统对接开发
o 部分项目版本迭代开发频繁
o 除了版本功能开发以外,经常插入很多需要快速开发上线的功能
针对以上情况,以及以往项目过程中出现的问题,我们把项目管理分为几个过程:
o 需求管理
o 冲刺开发管理
o 非冲刺任务管理
o Bug管理
o 回顾总结

需求管理

我们绝大部分的需求都来自于业务方,这些需求需要经过产品经理的梳理跟进才可以进入项目的开发流程,因而需求就有自己的一套工作流程。
我们创建了需求管理看板来进行需求管理。它使用jira的普通看板模式,并且该看板仅由产品经理进行管理。里边包含了所有的需求,每个需求进展到哪一步,都能清晰地体现出来。
利用jira的功能,还可以很方便地对需求进行筛选。我们利用模块对项目进行业务线定义,在创建需求的时候,指定所属的模块,就通过jira的筛选器定义一些快速搜索的条件。

需求可以分为2类,一类是比较大的需求,比如专题系统开发,它可能需要的周期是2周以上,我们把它叫做史诗级需求或者大型需求,
这类需求会进入冲刺开发流程。另外一类是零散的需求,比如会员注册完成后赠送优惠券,可能也就一两天就能搞定的需求,我们把这类叫小需求或者日常需求,这类需求会进入非冲刺开发流程。
以前我们比较缺乏的就是需求文档,主要还是由于产品经理不大愿意去写文档。这次使用了confluence来存放项目中所有的文档,
它能很好地跟jira进行链接。可以把jira任务链接到一个confluence的需求文档,也可以直接在confluence的需求文档直接创建jira任务。
我们现在都要求产品经理去写一些重要的需求文档,这样任何的任务都可以去查看对于的文档,并且日后回查也是非常有用。

冲刺开发管理

对于史诗级需求(大型需求),我们采用Scrum敏捷开发过程进行管理。产品经理创建好每次的Story,并排好优先级,在需求评审过后,
由项目经理与大家一次创建Sprint,进行时间估算,并对Story进行子任务拆分,分配到对应的开发人员。

在jira中,我们新建了一个Scrum Board,所有的冲刺任务都在这里进行管理。在看板中,以Story作为泳道进行划分,

在每个Story下面都能看到拆分出来的每个人的子任务,以及各个任务的进展情况。开发人员随时更新自己的任务状态,让大家都知道当前的开发进度。

这样,通过这里的冲刺开发管理,我们可以把需求、版本、开发任务、文档关联起来,形成一个整体,解决了以前开发任务松散零乱的状况。

非冲刺任务管理

对于零散的需求,不适宜去走冲刺过程,那么就按照非冲刺任务管理过程去执行。产品经理定好需求后,可以创建子任务,分配给对应的开发人员,或者直接创建一个任务。
所有的非冲刺类型的任务都会在一个单独的看板进行管理。它是一个普通的看板类型,开发人员拖动任务到不同的任务栏下,从而可以更新任务的状态。
对于这种任务来说,需要的是快速的更新流转,可以由任何人去创建任务,被分配到任务的人,需要及时地去更新任务就可以了。项目经理定期去跟踪各人的任务状态是否及其处理即可。

Bug管理

Bug的管理就比较简单了,主要由测试人员来提Bug,分配给对应的开发人员。开发人员处理Bug,并更新Bug到已修复待测试状态,测试人员对这种状态的Bug进行测试验证是否修复,如果已经修复,则更新Bug为修复完成。
Bug要关联到模块、版本,这样在每个发布版本的信息里边,就能看到每个版本Bug的分布情况以及处理情况。还可以根据模块以及经办人来筛选统计Bug的情况。

回顾总结

在每个月的月末,我们会举行一个月度总结会,其中项目经理会对本月的项目开发情况进行一个回顾总结,大家也可以提出问题,讨论解决方案。产品经理也会对下个月要开发的需求进行一个说明。
在这样一个总结过程中,不断地对我们的项目管理流程进行调整,从而使到整个流程更加的通畅。同时也让大家了解项目开发的情况以及未来的计划。

人的力量

为什么要在这里提到人呢?其实在之前我们的项目管理中,大部分都是靠团队成员自我驱动式去进行任务的管理,并没有一个专职的项目经理,
但是实际上人是有惰性的,并且并非人人都具有项目管理相关的意识,而且每个人的任务比较多,经常会忘记去更新自己的任务状态。
这样导致的问题是任务要么是堆积在任务栏没有进行更新,要么就是任务信息并没有在系统中流转。
要解决这种问题,还是少不了项目经理的介入或者施加一些强制的手段。项目经理每天会跟进任务的更新情况,并提醒相关人员。
在Dashboard可以看到每个人的未完成任务数,以及项目的进度情况,如果任务数比较多,或者项目进度缓慢,那就要去跟进原因了。

这里说下jira的仪表板(Dashboard),这是一个很有用的功能,可以添加很多统计信息,如:
o 【分配给我的任务】: 每天各人在这里可以看到所有自己需要处理的任务
o 【7天内没有更新的还没有完成的任务】: 这里能看到所有在过去7天内没有更新过的任务,用以判断任务是否滞留了,或者忘记更新了
o 【修复完成待测试的Bug】:所有等待测试人员去测试的Bug
o 【未完成的Bug列表】: 发现的所有Bug
o 【按经办人统计所有未完成的问题】: 列出所有人要处理的任务数量
o 【所有创建的任务以及已解决的任务曲线图】: 可以看到创建的问题与处理的问题的对比曲线图
通过这样的一些统计信息,让整个项目任务的流转情况,每个人的任务情况都清晰地展示出来。

总结

在引入这套新的项目管理流程之前,我先去尝试了很久,最后才形成现在的一个流程。或许这还不是现在最好最适合我们的流程,只能是在日后的使用过程中不断地去改进完善。
项目管理,是一个很大的领域,我们接触的只是一些皮毛,相比大公司而言,我们也只是小打小闹。比如网易有自己专门的项目管理研究院,
我也听过他们的一些课程,确实专业。希望以后有机会可以学习到更专业的一些理论与实践。
 

关注微信公众号

我们在微信上24小时期待你

解答疑问/技术咨询/运营咨询/技术建议

郑重申明:广州锦高信息科技有限公司以外的任何单位或个人,不得使用该案例作为工作成功展示!