JIRA使用十年间变换的四种模式

系统、模块、需求、缺陷、用例、版本、迭代，开发、测试、运维，如何保证大家有一个公共的交流界面？

模式1- 项目制的JIRA Project

在引入JIRA的早期，公司的研发管理主要是围绕着年度项目来进行的。每次专项交付的启动，就会新建一个JIRA Project来承接这个项目组的日常管理工作。而到了项目的末期，随着版本上线，项目进入结束和退出阶段，还需要对该Project进行归档。在研发人员转移到新的项目上，新的Project会被新建出来以满足新的需求。

一般各团队会为常规性的研发需求建立一个各自单独的JIRA project,而为某些大型专项，如新一代、新产品上市等建立额外的Project。而大部分项目是在一年的时间范围内完成的，极少有项目是跨多年。除了频繁地在进行项目切换带来的配置管理成本之外，另外一个则是某个系统可能在不同的项目中进行修改。在满足项目管理的需求之外的组织级需求，例如某个系统当前有什么需求，有多少缺陷或者测试用例，则需要从各个项目中来整理，现实则是很难梳理出来，因为各个项目中的表示这个系统所是使用的系统名字、JIRA属性都可能各不相同。 总之就是，缺乏了从系统视角出发的应用生命周期管理ALM的思路。

模式2- 单角色团队的JIRA Project

在某个测试团队建立的初期，由于开发团队尚未使用JIRA，测试团队便自行使用JIRA来管理测试需求、测试任务和缺陷，久而久之，就形成了团队的工作惯性。当开发团队也转用JIRA时，双方于是便使用不同的JIRA Project来进行日常工作的管理。后来者由于加入团队时就是这样的现状，也就引以为循例，竖井就这样愈来愈坚固了，最后就形成了各自在各自JIRA Project里面工作，极少在对方的project里面进行互动的局面。

类似的案例还有将某个JIRA Project当做缺陷库使用。某个团队将利用某个JIRA Project来管理线上缺陷，由于元数据的缺失，很难将其有效地进行管理，开发、测试人员的工作界面就与之分离了，最终也就只能发挥该团队自身内部管理的作用，原先设立时担当的组织级缺陷库的职能就难以为继了。

模式3- 按照部门来设置JIRA Project

随着公司的发展和规模的扩大，在模式1之后，公司逐步从项目制转变成为根据主要业务部门来划分设置对口的开发部门。每个开发部门也归口负责若干个系统，当然也有部门负责多达几十个系统。相应的，JIRA的使用上也逐步转变成了每个部门设置一个或者有限几个JIRA项目，用于管理归属本部门的各个系统的开发工作。这样，在一个JIRA项目中管理了少则几个，多则几十个系统。这种情况首先是将每个系统的管理固定在了对应的某个系统中，实现了单一信源的问题。不过，紧接着就会发现，在系统、组件、版本等元数据的管理上，由于单个JIRA项目立管理了多个系统， 原生的component、version等字段就显得非常拥挤了。

模式4- 一个系统一个JIRA Project

在公司开始实施DevOps并着手开始效能平台的研发时，小组邀请各部门的接口人对研发模型进行了多轮次的探讨，逐步确定了产品化思维，在原先项目视角的基础上，更强调产品视角，以应用生命周期管理ALM为主线，确定了产品中心模块，并提出了一个系统对应一个JIRA Project，该系统相关的需求、用例、缺陷、线上缺陷、组件、版本等数据均在该项目中纳入管理，成为该系统相关的产品、开发、测试、运维人员的共同的工作界面。当然，考虑到公司有上百个系统，这样打散之后，对于原先管理几十个系统的部门来说，工作模式的转变是比较大的。运维和测试部门也有类似的感受。因此，通过DevOps平台和JIRA之间的联动，管理好系统相关的元数据，实现两个平台间的数据联动，提高易用性。

那么，如果你们在用JIRA和类似的平台的话，是那种模式呢？