I've worked with JIRA (and Confluence) on a daily basis for the last 6 years. During that time, I have personally spent months of time working on JIRA, to make it do what we wanted. Before that, I worked with JIRA on-and-off for 7 years (with Trac and Rally tagging in here and there).
Which is all to say, I know me some JIRA.
The fundamental thing that this article points out is that JIRA tickets are about work, not software, and as a consequence of wanting to track our software, most users of JIRA spend a considerable amount of time and money approximating the tracking of software.
(No, Confluence isn't for tracking software either. It's for filling in the more flexible pieces of data that JIRA doesn't handle so well.)
This is correct, but I would say calling it an antipattern is going too far. A well-customized JIRA is probably the best system in existence for approximating the tracking of software.
But (probably) it doesn't have to be, which is hopefully where the author was trying to get. Something like Github issues, for example, binds code to "tickets", which at least conceptually is a step in the right direction. But software is quite a bit more than code, which is why our JIRA has tickets related to provisioning infrastructure, deploying, managing data, etc. I'm not aware of any JIRA alternative that considers all these facets of software creation holistically, though it's been a year or two since I looked into it seriously.
there are a lot of ways to develop software, and maybe designing a useful system that encompasses all potential aspects becomes too abstract to actually be efficient.
What I can conceive of is something of a mash up between JIRA and BDD, where desired changes are first described as a new end-state, and then the necessary work to achieve (and automatically validate) that state is broken off in tickets that are linked to that end-state description in some way. The key being that that first description is always your source of truth about the software, with the linked tickets helping organize the work before it is ready, and serving as reference information afterwards.
We are close to approximating something like this with Gitlab, JIRA, and Radish-BDD, but it's a lot of wiring and educating about conventions. I think you could do it in a single piece of software.
Which is all to say, I know me some JIRA.
The fundamental thing that this article points out is that JIRA tickets are about work, not software, and as a consequence of wanting to track our software, most users of JIRA spend a considerable amount of time and money approximating the tracking of software.
(No, Confluence isn't for tracking software either. It's for filling in the more flexible pieces of data that JIRA doesn't handle so well.)
This is correct, but I would say calling it an antipattern is going too far. A well-customized JIRA is probably the best system in existence for approximating the tracking of software.
But (probably) it doesn't have to be, which is hopefully where the author was trying to get. Something like Github issues, for example, binds code to "tickets", which at least conceptually is a step in the right direction. But software is quite a bit more than code, which is why our JIRA has tickets related to provisioning infrastructure, deploying, managing data, etc. I'm not aware of any JIRA alternative that considers all these facets of software creation holistically, though it's been a year or two since I looked into it seriously.
there are a lot of ways to develop software, and maybe designing a useful system that encompasses all potential aspects becomes too abstract to actually be efficient.
What I can conceive of is something of a mash up between JIRA and BDD, where desired changes are first described as a new end-state, and then the necessary work to achieve (and automatically validate) that state is broken off in tickets that are linked to that end-state description in some way. The key being that that first description is always your source of truth about the software, with the linked tickets helping organize the work before it is ready, and serving as reference information afterwards.
We are close to approximating something like this with Gitlab, JIRA, and Radish-BDD, but it's a lot of wiring and educating about conventions. I think you could do it in a single piece of software.