Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

Post reply on HN
Print view View original

501–510 of 530 posts

Re: Why Jira Sucks

#501

Post by HelloNurse »

josephg wrote: post #375
orzig wrote: post #249

Earlier quoted context omitted.

My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.

That would be great. On a client project a few years ago I effectively bullied the product owner into doing that. We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and…

Playing the devil's advocate, maybe detailed reporting to the boss is useful and worth doing. Probably the product owner's job and not yours, but not necessarily a bad (or, specifically, not agile enough) way to work.

I'm familiar with using Jira for enough customer support requests to require a full time ticket wrangler position, and closing tickets timely with accurate reports is often more important than the requested fix or support intervention: looking good with the IT managers that are, for all practical purposes, our customers has a higher priority, for everybody, than helping a random end user with a noncritical problem.

Re: Why Jira Sucks

#502

Post by specialist »

p2t2p wrote: post #299
specialist wrote: post #280

Earlier quoted context omitted.

> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.

Atlassian whole point is team centricity. The team decides the process, the team decides the metrics, the team decides what to deliver and how fast. The team decides what are the QA rituals. Yes, there checks to fix a disfunctional team but I have never seen those applied. So there are as many processes as teams in Atlassian.

Been chewing on your replies. Thanks for pushing back.

Atlassian really should be bragging about their internal processes, cultures. Popularize your Agile equivalent of Toyota's Production System. Seed an ecology of people spreading your techniques.

Embed some ethnographers and anthropologists in some random teams. Keep the cameras rolling. Show the good and the bad. Model how orgs should and could become learning orgs.

Re: Why Jira Sucks

#503

Post by [deleted] »

Karunamon wrote: post #221
Lazare wrote: post #119

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning…

[deleted]

Re: Why Jira Sucks

#504

Post by tharkun__ »

pm90 wrote: post #330
Kwpolska wrote: post #295

Earlier quoted context omitted.

Let’s face it, most git logs have one-liner commit messages that may or may not describe the issue at a very high level. Even if you have long commit messages, they still are less likely to contain extended discussions about the issue (which can be useful many months later), and cannot be edited. In many places, commits are expected to have the Jira/bugtracker ticket number in the commit message, so that if I find th…

Except when the linked ticket is just a title with no content. However, I would argue that even some of that metadata is better than no metadata. At least the ticket can provide some clues for anyone who is investigating a change. I feel like GitHub issues are good enough for this purpose; unfortunately GitHub charges a per user license fee meaning that most non engineers don’t get access by default reducing its usef…

Which means that the creator of the ticket does not understand the value of the ticket and is just forced to do it by process and so does the minimum required for Jira and his other tools to let him work.

Github issues are basically what a Jira ticket is. Just with less of the other stuff around it feature wise that Jira has. How your company uses Jira is not what makes Jira good or bad. Jira can either be used in an appropriate way or it can be customized into a big rigid process machine that we'd all hate. Been there done both. I like being in the Scrum Master/team lead position to try and influence things into a "less process" world. Ultimately I'm probably still 'hated' by the Devs because there's 'too much process and Jira' and the higher ups don't like it either because they don't 'have enough control' (actually illusion thereof).

Re: Why Jira Sucks

#505

Post by timka »

joegahona wrote: post #252
kjd1231 wrote: post #190

Earlier quoted context omitted.

What bothers me is if I use JIRA, why do I have a meeting every single day telling you what I'm working on. If you care, look at JIRA.

To discuss blockers and what you'll be working on that day. Also many engineers aren't good about updating tickets, ruining it for everyone.

That's the problem. You have to actually use Jira to get any value out of it. And better use it properly. That is do it accordingly with your process or the lack of it.

Re: Why Jira Sucks

#506

Post by j45 »

mnd999 wrote: post #433
j45 wrote: post #166

Earlier quoted context omitted.

We can say laptops are bad because they let people create bad software too. Jira is far from perfect but there isn’t much that solves what it can in an integrated manner. Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?

Permits and encourages are quite different things though.

I'd say less encourages.. And more easily enables.

You know the saying that money doesn't change people.. It reveals what already there...

Same ca be said to let people make the mess they already probably make.

A disciplined workflow in any technology takes effort and thought. I don't feel like I've ever stopped trying to improve it. Sometimes with jira, other times in spite of it.

Re: Why Jira Sucks

#507

Post by josephg »

signal11 wrote: post #472
josephg wrote: post #375

Earlier quoted context omitted.

That would be great. On a client project a few years ago I effectively bullied the product owner into doing that. We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and…

Great story, but re the “killed respect for Agile” bit: Agile done right is all about less process. It’s right there on the Agile Manifesto: > Individuals and interactions over processes and tools I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the…

Oh, I’ve read all that. But I feel like there’s two agile methodologies - one that the authors intended, a lightweight adaptive attitude where you ground out your process based on what works with your team. And then there’s Agile: The Process as prescribed by agile consultants who go to agile seminars. This agile insists on daily standup, point based estimation, velocity tracking, jira (for some reason), etc. Otherwise you are Doing Agile Wrong, and you will be cast off the holy mountain.

I get the sense the authors of agile used words like “scrum” because they imagine software development like a full contact sport; where everyone is fully engaged with all their senses to truly be aware of what’s happening, what’s needed and what is the most important thing to work on. The cargo culting agile consultant approach always feels like an attempt to make software into a repeatable assembly line, and make software engineers into factory workers.

Re: Why Jira Sucks

#508

Post by IshKebab »

yakubin wrote: post #115
IshKebab wrote: post #113

Earlier quoted context omitted.

Phabricator is pretty good except it has pretty much zero CI integration. Kind of annoying. You also have to pay to even comment on issues. I think that's a pretty great way of getting companies to pay for support but it's also annoying if you want to work with other freeloaders on issues. Also it's written in PHP which means you aren't ever going to want to read or modify the code. No different to GitHub, or probabl…

> You also have to pay to even comment on issues. OP mentioned "non-cloud", so I assumed they wanted it self-hosted. You don't have to pay anyone for commenting in Phabricator when you're self-hosting it.

Err, I think you misunderstood. You have to pay to comment on issues about Phabricator. On their official bug tracker. Like, if you find a bug, or a solution for a known bug, you can't tell them without paying.

Doesn't have anything to do with cloud hosting our self-hosting.

Re: Why Jira Sucks

#509

Post by josephg »

HelloNurse wrote: post #501
josephg wrote: post #375

Earlier quoted context omitted.

That would be great. On a client project a few years ago I effectively bullied the product owner into doing that. We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and…

Playing the devil's advocate, maybe detailed reporting to the boss is useful and worth doing. Probably the product owner's job and not yours, but not necessarily a bad (or, specifically, not agile enough) way to work. I'm familiar with using Jira for enough customer support requests to require a full time ticket wrangler position, and closing tickets timely with accurate reports is often more important than the reque…

I disagree. We were a product team. Our primary responsibility to the company was to ship working code, not open and close jira tickets. Would management have forgiven poor reporting in the scramble leading up to an on time / on budget launch? Yes. Would management have preferred a delayed release in exchange for more tickets visible in jira? No. I’m sure my manager could pass it off and say he did his job (look at the velocity graph!). But we would be failing our responsibility to the company.

Re: Why Jira Sucks

#510

Post by wpietri »

namdnay wrote: post #487
wpietri wrote: post #429

Earlier quoted context omitted.

Startups compete in the enterprise space all the time, [1], so I don't think your characterization is correct. I agree that client relations is important, but that's something that happens in many businesses. Like the comment I replied to, you assert that a managerial apparatus is necessary for that. I don't think that's the case. It's true that managerialist-dominated companies often prefer to work with other compan…

No again you’re mixing two markets. Just because a SaaS startup sells solutions to big companies, doesn’t make that the same thing as custom IT projects Enteprise but Startupy: MS Teams Not startupy: BMW need a solution to track how many defective gearboxes are detected every month, sorted by supplier, model and assembly site, data fed in from the various factory control networks, verified weekly by each quality resp…

I would be interested to see your data for that 90%.

Even if correct, I also don't think your point invalidates mine. I have done contract work for small companies that build "second type" code for large companies. One doesn't need Jira for that. As I said, one needs good client relations, but that can certainly be accomplished without a lot of top-down mangerialist claptrap. Indeed, it's my experience that things are better that way. They don't need metrics. They need their problems solved. Those two sometimes go together, but they're quite often opposed.

Post reply on HN