【心得】软件团队Git工作流及Jira的基本知识和常见问题解释

软件团队使用Jira的基本知识和常见问题解释

前置知识

职位

软件团队中常见的职位

• PM (Project Manager)项目经理
• TL (Technical Lead or Team Lead)技术经理
• PG ( Programmer )程序员
• SE (Software Engineer)软件工程师
• DBA (Database Administrator）数据库管理员
• QA (QUALITY ASSURANCE）测试

在公司交流时一般都以职位简称表达，之后文档我将以职位简称表达身份

以上是我们在软件开发工作中经常打交道的角色,每个公司具体情况不同,称呼可能有出入；其中SE和PG很多公司并不细分，因为软件工程师也是程序员，多数情况下在工作上没什么区别，非要理解的话，那么可以用SE不仅仅上写代码的人而是有追求的有工匠精神，关心的不仅仅是代码还有软件工程中的种种问题。其中QA很多公司也称呼TE
另外注意项目经理和技术经理的区别,项目经理更多上在工作上的人事管理,负责团队的工作安排,考核,甚至工作环境这类的管理.而技术经理是项目在技术上的直接负责人,起技术能力要求非常高,要求在软件从设计、研究、开发、测试、部署整个的流程的所有技术细节皆要求掌握。比如选用什么框架，项目结构要求；在软件公司中这两个职位可能只存在一个而负责原本是两个职位该做的事情，比如说PM同样负责了项目的技术方向

流程

一个软件项目的流程一般如下

1. 提出设想
2. 调研分析
3. 设计
4. 开发
5. 测试
6. 部署
7. 上线运营

普通程序员一般只参与开发、测试流程，越高级的技术或管理涉及的流程越多

新功能流程

在项目设计完成后，就进入开发流程了，每个项目又可以拆分成不同的模块、功能，在团队开发中在把这些模块、功能细分下去交给各个PG开发，这一步由TL或QM负责。每一个功能又按下面的流程进行

Bug修复流程

这里很多人会误解，QA测试如果有bug不是会打回开发重新开发吗？注意！在正经的软件开发流程中，程序员在编写代码时产生的错误不能称之为Bug，这里的bug指的是对于当前项目来说的bug；也就是说，在你开发一个功能时，只要你的代码没有提交到团队的代码仓库，你产生的错误仅仅是你的错误,而不是项目工程的bug，QA难免会出错，在审查你的代码时不能做到面面俱到，当项目仓库的代码或生产环境的代码运行出了错误，那才是我们这里要说的bug。这里讨论的bug一般是QA、TL或者其他PG在拉取了仓库的代码运行时或生存环境发现的错误，将在额外的工作流程中提出并制定PG去解决，一般是负责这个bug代码的PG去修复

bug的修复流程和上面的新功能开发流程类似，就不再列出了

Git

介绍

git相信大家已经了解了，但是在商业项目团队开发中，为了便于管理，同样对Git的使用做了要求

请知悉以下Git常见操作

1. 拉取：从仓库拉取权限允许的分支代码
2. 提交：将本地的修改结果提交到本地仓库
3. 推送：将本地仓库某条分支的内容推送到远程仓库的同名分支上
4. 拉取请求：请求将某条分支（源分支）的代码合并到另一条分支（目标分支）上，将由目标分支的审核者审核是否同意合并

目前主流的Git管理方案是工作流方案，什么是工作流？以上面的功能和bug修复的流程来说，就是一个工作流。一般的软件项目在开发过程中，PG拿到一个任务，一般是功能、bug修复、改进这三项，针对这三项在工作中又有不同的流程细节，涉及到不同的职能分工。所以在Git仓库中，对代码的管理就有了新的要求

git一定要搞清楚，仓库分为本地和云端仓库，云端仓库为团队的公共仓库，有权限的每个人都可以拉取一份代码到自己的本地仓库，在拉取下来之后，可以认为本地仓库内容和云端仓库内容是一直的，你在本地修改的内容和云端没有关系，只要你不推送代码到云端，你就影响不了团队的其他人~

以工作流而设计的分支模型

专业的Git工作流以分支作为管理，在仓库中会存在以下分支

master
develop
release/
feature/*
bugfix/*
hotfix/*

• master

主分支，为保护分支，常驻只有一条，存放从release分支合并过来测试通过的稳定版本代码,作为服务器部署运行的版本，除了TL或其他负责人一般为只读，甚至有些团队把该分支直接设置为不可见

• develop

开发分支，为保护分支，常驻只有一条，一般为仓库的默认分支，除了技术管理层其他人只读，存放最新的各个PG开发完毕初步测试通过合并过来的代码，QA会根据自己的工作安排拉取该分支进行测试找出bug，其他的PG也可以拉取获得最新的版本

• release/*

发布分支，为保护分支，暂驻存在多条，从develop分支创建，比如release/v1.0.3代表项目发布的1.0.3版本。除了技术管理层其他人只读，存放项目准备部署到服务器上线的代码，交给qa进行最高要求的模拟测试，这个分支允许我们做做后的细小更改。通过之后将合并到master分支正式发布，并在master分支上打tag标签（比如：v1.0.3）便于记住这个版本，同样也必须合并回develop分支。最终删除该分支记住：在创建新的release分支准备发布时，该分支可能因为调试会存在一段时间，在此期间，bug的修复可能会合并到该分支而不是develop分支，该分支严格禁止增加新的feature！！

• feature/*

功能分支，暂驻可以存在多条，从develop分支创建，pm划分功能模块交给不同的pg完成，每一个功能都会创建一条feature分支进行开发，比如feature/xxxx，xxxx为该功能在团队内部的编号，pg可以自行创建该分支，拥有读写权限，在pg完成功能自测后，将推送该分支代码到远程仓库，并发起pull request（和并请求）将该分支合并到develop分支，通过后删除该分支

• bugfix/*

bug修复分支，暂驻可以存在多条，从develop分支创建，处理者可以自行创建拥有读写权限，后面带的为bug的编号，交给pg修复，拥有读写权限，修复完毕后和feature分支一样的处理方式。注意在release分支存在时（发布期间），bug的修复应该合并到release分支而不是develop，因为develop存在的bugrelease也有而release是准备发布了！

• hotfix/*

热修复分支（紧急bug修复分支），暂驻可以存在多条，一般从master分支创建，处理者可以自行创建拥有读写权限。代表着线上版本出了问题，一般是非常紧急的，因为master正在运行，是处理优先级最高的分支，修复完毕将合并回master和develop分支，命名规范hotfix/xxxx,xxxx为内部bug编号

分支的写权限表示可以推送到远程仓库

只读意味着项目成员都可以拉取到自己本地仓库，可以查看运行甚至修改,但是无法将自己的修改推送修改到云端，

pull request：拉取请求，其实翻译名不好理解，确切的来说应该叫做合并请求。表示将一个分支的代码请求合并到另一条分支，将有目标分支管理员审核，记住，你可能没有向目标分支发起合并请求的权限！

Jira

jira是一个以项目为核心以问题为驱动的工作流管理平台

我们知道了不同的功能或bug都以一个一个任务交给不同的人去处理，在团队开发中，新功能由研发、客户、领导等目标提出，bug一般由qa提出，那么，在一个团队当中，我们不可能要求每一个提出需求的人当面或用其他方式告诉你：我要你做这个任务，沟通的成本是巨大的，甚至在大团队中还考虑异地、时差、认不认识等问题，而且，在考核工作时，我们又怎么知道：当初是谁提出需求又是交给谁处理了？又是谁审批的？花了都长时间？当时的细节？如果我们要解决上面的问题，难以避免的需要划分大量的人工去记录，还不能保证正确性。那么，jira就是为了记录工作流而存在的

以问题为驱动的工作流程

什么是问题？功能，是一个待解决的问题，bug，也是一个待解决的问题。所有中出现需要人去处理的事情，都是问题，只是名称而已，

一个问题在工作中应该经历这样的最基本流程

考虑到现实的复杂情况，流程可能更复杂

建议好好结合现实情况，上面的流程是不奇怪的，看不懂的同学建议回家放牛 ，你不适合进入职场

我们再思考一下，在上面的每个流程中，由需要不同的人参与进来，不同的人还得在正确时机参与进来，这就是jira需要解决的问题

jira中的基本名词概念

项目角色

现实软件职场中存在不同的职位分工，那么，在jira系统中，同样应该参照现实简历相应的模型，便于不同的用户以不同的角色参与到项目的问题解决流程中

所谓的项目角色一定要记住，角色意味着权限，而这里叫做“项目角色”那么也就意味着这些角色要存在于项目的人员组成中，不是说把张三丢进pm中他就是项目经理了，而是属于把张三先放进某个项目组，再赋予张三为这个项目的PM角色

问题类型

同样现实工作中要解决的问题分为不同的类型，jira已存在以下问题类型

其中软件项目中主要需要关注的问题类型有

• 新功能
• 故障
• 改进

这三种类型的问题几乎全覆盖了我们的工作内容

其中需要注意的类型

• 任务
• 子任务

这两者字面意思很好理解，但是，我们软件工程中的需求（功能，bug）不能称之为任务吗？是可以的的，但是，既然jira设计了既然单独设计了，那么我们就应该换个角度理解，任务应该是开发过程中产生的不可归为新功能 故障 改进 的问题,比如,pm叫pg张三去调试下服务器的环境,这也是属于项目的正常工作内容,但不能归为该三者只能归为任务 。

下面的是什么鬼？

• epic
• 故事

emmmmmm，这只能说又是个文化差异的锅了，epic中文译名“史诗”，表示一个非常大量的工作，包含许多故事（story） ；故事又为最小单位的任务；那这不是和上面的任务类型冲突了吗？，其实，我们应该这样去理解。

epic在软件项目中一般理解为客户提出的一个大的需求，故事是从这个需求拆封出来更细小的需求，比如：张三找到你们团队说：“我要做一个类似淘宝的平台”，那么，张三的“购物平台”就是一个需求（epic），经过细致研讨，拆分出：浏览商品，搜索，购物，付款验证，物流管理....这些小的需求（story）。注意，epic和story更多象征着在纸面上的理想需求，一个团队不仅仅是存在开发人员，还有市场调研，设计，研发等等岗位，这些人不太参与项目代码的具体实现，而他们的工作和讨论更多是围绕在epic和story上面，那么他们一样是在jira系统中存在的，一个软件项目，不仅仅是代码就可以支撑的。回到刚才张三的故事，在团队内部研讨分析后我们决定截马云胡或者捅张三刀子开干，那么就着手建立项目开始写代码，那么这时候，一个个需求就真真变成需要实现的功能，过程中又回产生一个个bug，see？

反正我们程序员更关心前面三种就可以了，当然，不代表需求分析的时候你就不参与，不然的话，被掏屁股的就不仅仅是张三还有你了，不过，普通的码农也未必能参与到设计层的

当然，完全可以在jira创建项目后自定义该项目的问题类型方案，添加自定义问题类型也可以，以上只是jira默认的软件项目问题类型方案

工作流

什么是工作流？你可以回去看看之前提到的几张流程示意图，图中一个问题从开始到完成的过程，就是工作流

jira可以自定义每个不同问题类型的工作流。怎么理解这句话？比如我们的新功能开发，从提出->分配->处理->审核代码->测试->完成;这就是一个工作流,其中有些步骤可能回打回处理,审核又要求有管理权限的人参与,那么,定义这个过程,让jira自动处理这个过程,在不同的阶段可以让正确的人参与进来.这就是我们定义工作流的意义

比如我为不同的4个类型定义了不同的工作流

那么拿新功能类型问题的工作流来说,每一个点代表了当前问题所处的状态

我们在来看从"审查中"到"已解决"这步骤来看

可以发现,我要求必须是项目管理员或PM,TL才可以将问题的状态从“处理中”转换为“已解决”，说人话就是这三个角色才有审核的权限

还可以定制该行为产生的后果

有意思的是我还加了一个触发器，当该问题（新功能）的相关分支被Git同意合并之后，自动执行这一转换

新功能会创建feature分支进行开发，最终pg会请求合并该分支，从某种意义上来说，管理者同意了该分支的合并，也代表着通过了该问题的处理结果了

报告人

问题的提出者

一般是由PM，QA提出，只有一个人，可以被修改，在新建问题是，报告人就是新建问题的人（自己），但是也可以指定为其他人（一般不会，除非这个问题是被人提出而你只是记录者）

经办人

经办人可以理解为问题分配给谁处理

表示问题的工作流中需要参与进来的人，问题的处理者绝对是经办人，审核的领导也是经办人，在提出问题时，可以不指定经办人，因为，问题的提出者可能并不知道问题的会怎么处理，谁来处理，也就是说，在问题的不同状态、阶段，可以指定不同的经办人

jira中的权限

在工作环境中，大家的所作所为都应该在自己的职责范围之内，既不能发生渎职行为也不是出现越权行为，那么，团队所有的成员在jira系统中自然要和现实权限匹配，那么同样需要在jira中搭建相应的权限模型

请记住，jira中以项目为最大标点，也就是说，所有的事情 围绕着项目思考，角色、权限都是如此，好比一个人可能是一个项目的PG，也可能是另一个项目的QA；所有人都以自身的项目为最大目标，围绕项目产生问题，在以每个人在这个项目中的不同角色参与问题的不同阶段

首先项目的参与人员会在项目成员中添加进来并赋予不同的角色，表示他在项目中起到的作用

值得注意的是，一个人可以赋予多个角色，也可以一个用户组为单位进来一起被赋予相同的角色

再给不同的角色在项目中赋予不同的权限

可以这么说，因为jira是以问题为核心驱动，所以，一般权限和问题修改，注意，权限可以赋予给一个或多个角色，也可以直接赋予某些用户（指名道姓）或用户组，一般不这么做，不好管理，毕竟人员是流动的，而身份一直存在于团队

开始使用

创建问题

在开发团队工作中，任何一个任务、问题都需要被记录。这至关重要，在工作环境下团队内的每个人的工作安排都关乎利益，不管是对老板还是员工都希望得到清晰明了公正的记录，jira的问题系统在软件团队中尤其适用

注意，在jira中不是谁都可以创建问题，需要看权限，一般来说，管理发布任务，设计研发发布epic，技术管理发布功能，测试发布bug

以下是jira创建问题的表单

在创建一个问题的时候，一定要先想清楚以下几点

• 问题是针对哪个项目的

• 简短的问题概要

• 问题的类型

• 谁提出的（一般是自己）

• 清晰明了又不拖沓的描述

以上是一个问题必须的最基本信息，在jira中必须填写

在创建问题时，如果需要，以下的点也是需要考虑的

• 问题是向谁提出的
• 问题的优选级(严重性)
• 属于哪个模块
• 属于哪个版本？
• 预计解决这个问题需要多长时间
• 预计解决这个问题还剩余多少时间
• 这个问题什么时候到期
• 还关联哪个问题？
• 和关联的问题是什么关系？
• 关联哪个epic
• 需要附件吗
• 为这个问题打一个自定义的标签

一些字段的解释

经办人

一般情况下，可以理解为处理这个问题的人，可以默认为空，默认值一般为项目负责人。记住，问题的解决是一个流程，在这个流程中问题会经历好几个状态；

比如：开始、处理、审批、完成（关闭），这是一个最常见的基本流程状态，假设张三提出了一个问题，在这个问题提出时他可能并不知道这个问题可能谁来处理。此时问题处于开始状态，经办人为空，李四接手了这个问题，问题进入处理状态，此时经办人为李四，李四完成后提交审批，问题进入审批状态，审批这个处理结果的人是李四的领导王五，那么这个状态下经办人又变成了王五！

当然，有些团队可能没有严格按照要求来，经办人一直是问题的处理者，这不是推荐的做法，另外jira的工作流是可以自定义问题切换状态时切换经办人的，只要定义好各个类型的问题的不同状态的规则即可

模块和版本

这个比较好理解，该问题属于项目的哪个模块？一个bug属于哪个版本？

不过要注意，模块需要jira的项目管理员设置，项目的版本也是

关于问题的时间问题

• 初始预估：解决这个问题从开始到结束的预估时间，可以修改
• 剩余的估算：这个要注意，假设问题预计2天完成，可能jira系统上记录这个问题的时候，问题已经处理过一部分了花了1天时间，那么这个值就是2-1=“1d”；请注意，一般来说，在问题一开始设想的时候将应该在jira系统上创建而不是已经开始处理了在创建，所以，这个值一般和初始预估一致
• 到期日：也很好理解，表示这个问题在哪个日期之前一定要处理完成，虽然假设问题只需要1天完成，但是因为工作安排，可能这个问题会被搁置；那么这个值可能设置在未来的任何一个时间，但一般不会是明天，毕竟你懂得

关联的epic和问题

首先结合上文之前说明

• 史诗链接：epic一般记录的是需求，那么这个问题是属于哪个需求的

以下连个字段要一起理解

• 链接的问题：这个问题可能和其他问题有关系，关系是什么？

• 问题：有关系的问题

关于问题之间个关系

1. blocks：当前问题影响了某个问题或者说当前问题导致了某个问题的产生
2. is blocked by：和上面相反，是某个问题引起了当前问题，或者导致当前问题不能修改
3. clones：某个问题和当前问题性质一样
4. is clones by：：和上面相反 ，当前问题和某个问题性质一样；emmmm，和上面的用哪个都一样的意思
5. duplicates：某个问题和当前问题重复
6. is duplicates by:当前问题和某个问题重复
7. relates to：注意，这个很重要。表示当前问题和某个问题关联，解决了当前问题另一个问题就不存在

问题的标签

没什么意义，一般打标签是便于问题的整理

处理分配给我的问题

根据项目的权限设置和工作流以及问题当前的状态，你能处理的选项各不相同

存在一个未分配的问题？

问题创建出来可以没有经办人字段，表示问题未分配，这种情况下，说明提出问题的人应该不知道这个问题交给谁处理，那么项目的管理者将应该负责分配一下该问题

工作日志

工作日志的记录很重要，不是你在jira点击开始处理就表示你在工作了，团队可能会要求按周期、步骤记录工作日志当做考核标准，这至关重要！

注意！！记录工作日志应该按照周期，比如下班时，或按照完成步骤记录，是在一个阶段内容完成之后记录！！！务必按照团队的日志格式要求记录！！

注释

问题的评论，发布 评论点击备注

改动记录

一般记录了问题的修改记录

活动日志

包含改动记录，还记录了问题的流程记录

问题的状态

当前问题处于工作流的状态

问题的解决结果

问题的解决结果，一般由工作流脚本自动改变