And yet, "Creating a JIRA task is like going to the fucking DMV."
If you have more stuff to fill out, that's an issue with your local configuration. Blame your Jira master, not Jira or Atlassian :D
My work flow is exactly the same as yours, yet it still feels clunky, and is quite correctly, a total dog.
Much like, you know, going to the DMV.
The 2 fields workflow doesn't feel too clunky, but the interface certainly is, and the speed, oh dear lord, the speed. Its just sooo slow.
It is
> they're probably being cheap and giving it as little resources as possible and
Almost certainly
> it not being on-prem probably contributes to the feeling of slowness.
Sure, all of 150ms of it really adds up.
If its failed for 1 user, its a shit product. If its a success for 1 user, it's a great product.
It's GOOD for a user to say they find it easy and why.
It's GOOD for a user to say they find it hard and why.
1 helps the user give a product a second chance by learning of his pitfalls.
1 helps the company improve their product to make it easier for more users.
My point is that apologists shouldn't come in here and blame users for a shitty product.
That is a dangerous over-generalization.
Let's say -ferinstance- you have kick-ass, seriously best-at-what-it-does software that's only localized in Japanese, and a uniglot USian attempts to use it. They're gonna have a hard time. The software will very likely fail them, because they will be unable to understand anything they're being told by the software.
Does that make the software shit? No. No, it does not. The software is great, it "just" needs to be localized in order to be great for a wider swath of humanity.
From the perspective of the user, if the product fails for that user, its a shit product.
I don't mean the product itself is actually shit.
Like I say:
If its works well for a user. It's a great product. If its fails for a user. It's a shit product.
From the perspective of that user.
But we can learn from both the users who like it, and the users who hate it. But we cannot blame the problems the user has, solely on the user.
Honestly, even this is a hazardous over-generalization.
I've looked at gobs of software that failed to do what I needed it to do. Much of that software was good-to-great at what it was written to do, but it -like a lot of software- wasn't written to do what I needed it to do.
That doesn't make the software shit, that makes it unsuited for my needs. I am -and many others are- clever enough to distinguish between the two categories. :)
Yet Jira is a wildly successful product.
In my experience there are only people that tolerate JIRA on one side of the spectrum and a bunch of people that hate JIRA on the other side.
With just a little tweaking (30 minutes or so on a fresh install), I can have it perfectly configured to match my ideal workflow.
* Setting up several statuses (more than in the default) to reflect backlog, selected, in progress, testing, deployed
* Creating an appropriate board which splits everything into columns by status and rows by user
* Setting up a few quick filters to find things like anything which has been in the backlog for more than 6 weeks or bugs which haven't seen activity in the last 48 hours
* Integrating GitHub. Being able to kick a ticket over to QA from your commit message is awesome.
Beyond that, I mostly focus on stripping out default things to make the workflow simpler. I don't need my software to enforce that I can't move a ticket to deployed straight from in progress, and stripping out those extra rules makes it easier to deal with.
As a result, all issue trackers have more detractors than promotors, with the vast majority of users being neutral.
That said, I've used RT (holy shit no), Pivotal Tracker (drinks too heavily from the dynamic DOM/JS koolaid, sucking up all RAM and CPU in the known universe), and JIRA. I'd take JIRA over the others.
JIRA is the best bug tracking software I've used since I left Microsoft, which was over a decade ago. Sometimes I still miss Raid, particularly it's ability to build complex queries, but also the ability to connect to any team's project. At the time, it was supposedly the only internal tool used throughout the entire company.