Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…
Why Jira Sucks
201–210 of 530 posts
Re: Why Jira Sucks
#202Earlier quoted context omitted.
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eye…
It depends on your organisation size and structure, but probably you want to run the bug fix through some triage first (meh management overhead, but needed if you have many bugs to make sure the "important" ones are fixed), then code review (well, that doesn't happen in jira, but probably should be (automatically) reflected there to have one place to look later) and after fixing probably should be routed to the docum…
Re: Why Jira Sucks
#203Atlassian is basically the centre of the so-called "Agile" industry these days. Jira is just a reflection of it.
Re: Why Jira Sucks
#204Earlier quoted context omitted.
> If devs aren't working on priority items Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.
>and what happens when JIRA does not reflect the actual priority as observed by devs? Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.
I do not believe that, of course it is collaborative. Some things are emergent, some are not. Some can be neatly broken down into fixed length tasks, some cannot. Some are planned, some are not. Some are top-down, some are bottom up. Some are obvious business function items, some are leftfield ideas.
I'm just feeding back that attempting to mediate and regulate that collaboration via JIRA is a bad idea. A common, and bad idea.
Re: Why Jira Sucks
#205Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…
Re: Why Jira Sucks
#206To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…
When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it.
Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason)
When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.
Re: Why Jira Sucks
#207I disagree. What makes JIRA a pain is that it has too much. It tries to be a solution for every possible workflow and ends up being a slow, clunky, and confusing solution for all of them.
I personally think the best thing Atlassian could do is spin of JIRA into multiple apps which all use the same core, but have different interfaces designed for different workflows. Of course, that's much easier said than done with such a ubiquitous monolith as JIRA.
Re: Why Jira Sucks
#208Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…
Opening a jira issue to document a change that everyone should be aware of can take me literally one minute, and I've even assigned it to the sprint and version.
"Developers don't like JIRA, they love GitHub": these are some generalizations that can often be true. However, you can also automate JIRA using your VCS of choice. You somehow make the assumption that only GitHub git + GitHub issues can be automated.
Re: Why Jira Sucks
#209Earlier quoted context omitted.
I was looking at the homepage reading text that explained the Picture Gallery ("when users can reuse images... more likely to...") and then the whole page refreshed with a completely different design. I was on the page for probably about 30 to 60 seconds. Firefox 84 on Kubuntu Linux, no relevant addons.
Hi! That’s just a video playing on a loop taking you through the various screens. The “image gallery” is just showing our work item screen and then it jumps to some other screens. Thanks for the feedback though! It may be that this isn’t clear enough
Re: Why Jira Sucks
#210Earlier quoted context omitted.
> Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".
Exactly. What's going on is commits and merges. They live in GitLab. There is also tickets in GitLab, which all developers are happy to use. There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites! But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is…
Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.