Serious question, why does anyone still use Jira. It's a huge pita and everywhere people are essentially forced to use it, they hate it.
It's become clear case of too many knobs.
Jira, is like linux. If you don't like Jira, it's either slow (will address this next), or its really that you don't like the organization processes of the team or organization you are a part of. Because properly configured, Jira reflects the working decisions you have made as a team.
As to being slow. I only had this issue once with a small dev shop self hosting in a closet. At a large enterprise with over 10,000 engineers using Jira, not including the non-engineers using it, it was always lightning fast for the self hosted version.
People didn't like Jira and started using Trello. So Jira made a Trello style view. People moved to Asana. Jira made an Asana view. Jira is everything, and if you don't like it, it either doesn't fit your use case ( yes its expensive and can take a lot of thought or time to set up properly ), but its likely more that you don't like your Jira that you are being _forced_ to use.
(On the other hand, I have many bones to pick with confluence).
Contra-point: I use Jira for <1,000 users, it's hosted on a single instance (128G mem 64vCPUs), with a seperate database server and it takes 30s to load my backlog. (And I'm not exaggerating, truly, each page load takes 1-30 seconds, direct ticket views to to kanban board).
I looked at running multiple servers, but it seems like our license doesn't allow that. Which is another issue with Jira, it's licensed on the server level.
Nope. Fuck jira. Let’s not talk about the hell that is Confluence. If you must use it then don’t self host it, let them deal with managing their garbage product.
Also, I don't intend to defend JIRA from a cost or infrastructure perspective, just as a tool.
If you are shopping around for a ticketing system might I offer this generic minimum spec sheet: * Items should all have a unique identifier that can be used in the developers workflow * Any item should be able to be a sub-item of another item. * It should be fast enough to not waste development time (time spent in tool).
If your ticketing/work/bug system doesn't allow those (and I believe GitHub issues might not), then you are doing your team a disservice.
The reason I usually turn to JIRA, is that somehow it manages to be everything to everyone. I was managing a small team at a startup, and the developers only looked at the detail view and the kanban view. Almost any "update" to JIRA happened via including a ticket number in a git commit, branch, etc. However, the QA team, had some crazy pipeline that happened after the engineers deemed it done, and those two workflows didn't affect each other, and worked seamlessly. Product, had an entirely different workflow before engineers even saw a ticket. Then after grooming, and sprint planning, the team set a goal of how which tickets would be done and in what order. Engineers would go back to their desk, and just use JIRA for viewing the details and commenting on things usually for product/design. Also, if I wanted to cut a release of something (at the time we did weekly deploys, even though master was always considered deployable at any time), and I could click a button in JIRA to make a release that automatically knew what had changed from git. All of those tickets got updated to `released` automatically from the deploy.
You may not need JIRA. But a lot of engineers have put a lot of hours into a marvel of software that does way too many things. Its an amazing tool. But you may not need a multi-tool such as JIRA. You might just need a hammer.
(Lastly out of curiosity, have you contacted their support about optimizing your performance? I am curious before I choose self-hosting in the future.)
As per wine and dine: 1. I have never interacted with a human being from Atlassian ever. 2. I don't think this is as effective for selling software anymore. This has been replaced by user conferences. Most people who can buy things that involve being wined and dined have can expense a nice meal when traveling for work. Many times a sales person may wine and dine you so they can wine and dine themselves.
I couldn't imagine doing the process I use at work in something less complex (github issues, trello, ...). We tried that in a simpler system and it is a web of hacks, manual steps, emails...
If the complex you need is complex, then a complex and configurable system might be the easiest way of managing it. Everyone should of course first consider whether a complex process is actually needed - but for the sake of discussion, let's say it is (No one who has a simple process would be considering Jira, and contrary to popular belief I don't think complex systems breed complex processes. I think complex organizations do).
Do you have multiple teams, with people switching between teams. Do teams have different processes in different teams? Do you have hierarchical planning where a management team plans on a higher level what features go in what major version and different product teams break it down into managable chunks? Do you have managers that need to report statistics to various stakeholders? All of that can be emulated in any system. But if you start emulating it in a simple system, then all that's missing instead you need to add to the system with emails, a wiki describing which email to send to what person after generating the monthly report or whatever.
I think the mistake that is often made is that these systems are seen as tools for a development team of 4-8 people who would otherwise use a whiteboard. They aren't. In fact, I'd recommend that any team use a simpler tool to manage their progress if they want to. Why not post-its on a whiteboard if you are colocated? All that's left after you complete an iteration (sprint, release, whatever) is to fill in the issues from the whiteboard back into a system and be done. These systems aren't supposed to get in the way of developers. If they do, don't use them. But you need a central source of truth for questions like "what was the cause of that bug 9 years ago?". I use info like that daily. It's not going to be found in the trashcan under the post-it whiteboard.
There are a bunch of oddities in the UI that don’t help it much (like having 4 different interaction patterns for sorting list items), but the biggest issue by far is needless complexity and foot guns added by the org/admins. For this, I wouldn’t blame Jira/Atlassian.
I’ve managed Jira workflows for 3/4-digit users on even larger instances and I run my own self-hosted Jira as a private task manager (If you’re already concerned about waste of resources and bloat in Electron apps, better not try this at home). When configured properly, I prefer Jira over all the other tools* in it’s domain that I administered at some point in time.
* Bugzilla, Gitlab, Github, OTRS
I can't comment on the cloud offering, but I agree that the performance and resource consumption of the self hosted Jira is not great either.
To me it is not quite slow enough to negatively offset its usefulness. Perhaps I am also too used to working with even slower web applications to really take note of anything < 1s ;)
Again, to double down on my previous point: where it can get very slow very fast, is for ill configured systems... i.e. when running unnecessary permission checks on very large groups.
Back when I used pine it just loaded instantly! No spinner, no splash screen, no progress bar needed.
And don't give me that "oh but it's in the cloud" crap -- the cloud isn't an excuse to be slow when I have a 300mbps downlink with sub-10ms ping times to headquarters and datacenters of these companies.
Creating a bug report with Jira can be as simple as filling in a summary and a (optional) description, then click submit. If you use issue collectors, you may not even need an account in the system or directly access the Jira application to report the issue.
GitHub issues and Trello have more or less just abandoned the idea of being able to do any useful analytics or reporting, tools like Pivotal Tracker have some but require that you work in exactly the process they dictate, and the other big ones that have reporting generally are even worse than JIRA.
This reporting gets useful once you have a stable team and you want to identify issues in your process and back your theories up with data.
Let’s say you struggle to meet expected delivery dates (based off estimates), have a look at a chart of your cycle times. Do they take longer than a week, with a wide variance in when they get delivered? Maybe you’re not breaking down work enough, or you’re getting blocked (committed too early).
Check a chart of the number of tickets in each status every day, that might tell you that things get backed up waiting for review or deployment, so discuss that.
Simpler tools don’t really provide this information. Is it always necessary? On greenfield work with a smaller company, almost certainly not, but as your product and company gets more complex, having access to this, and presenting it to your team, gets more valuable.
I went from MSProject and ClearCase to Jira in the mid 00s and thought it was so much better. I’ve gradually changed to hate it, but can’t find a better tool.
The alternatives I’ve tried have been way worse in terms of complication, cost, and specialized training required. I work with people who use MSTeams and it makes me yearn for Jira. I’ve used GitLab, but it’s cost is too high for non software projects.
It’s weird how this seems so simple that there would be a clear default tool that just captures user stories, routes them among people, and gives reports.
What do you mean by this? As far as I can tell, stock MS Teams and stock Jira are designed for very different goals—they don't fall in the same category.
I hated JIRA until our company switched to a competitor. Now I wish I was on JIRA.
and then under the guise of “agile” they develop the same exact thing
JIRA is just a SAP for software development, with exactly the same forces making it a slow, complicated mess, that people keep using
Jira is an extremely powerful tool when used correctly by an organization and the entire Atlassian suite as a whole is pretty awesome.
If you essentially write all your organizational processes into Jira workflows it’s a whole other universe all of a sudden everything is behind a single paint of glass and all technical and non-technical processes are in a single place in a single a coherent workflow.
We have everything from the first steps of the project through its entire lifecycle in Jira it’s not just a place for bug reports.
My previous serious exposure has been MantisBT and Bugzilla. Out of those I vastly prefer Jira.
So what's with the Jira hate? Seems clear we're not doing something a lot of other people are with our Jira.
The latter tends to be horrifically slow from what I understand.