Live data from Hacker News

GitHub and Jira Software Integration

blog.github.com

131–140 of 222 posts

Re: GitHub and Jira Software Integration

#131
post #92

Earlier quoted context omitted.

all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.

I agree. One of my previous companies used Jira and it was absolutely fantastic because one project manager had a clear vision for it and implemented it and the other PMs planned sprints inside it.

Yep! I switched to Jira from an older in-house solution early this year, and have found it to be excellent so far. There's a little learning curve on the admin side, but the actual experience of using it for feature / issue tracking has been real positive.

A lotta folks I talk to have had bad experiences with Jira in a big-company setting -- say in particular, Amazon --- but most of those problems I've heard boil down to poor practices on the management / admin end, rather than problems with the software itself.

p.s. I've also used Asana and a few other less-costly solutions, but their limitations ended up getting frustrating.

Re: GitHub and Jira Software Integration

#132
post #111

To wade in on the JIRA wars going on, I was once a JIRA consultant (among other things). I ended up telling people I worked on business process design because once you see 100 different ways people are using a tool you learn most of the wrong ways to do it. The primary issue with any task tracking or workflow tool is that the people implementing it have never learnt what is effective and what isn't. Worse, what is ef…

> Every time you add a gate to a task (this person must accept this before it progresses … This seems to be the standard failure mode. When a ticket is wrong, I try to fix it only to find I'm not allowed to , because the workflow presumes the actual state of the project today can't happen.

The solution of course it to just allow people to do what they want.

Every now and then it’s useful to everyone to stop some things from happening - it’s easier to have the gate than to not.

The fact that that exemption exists is what drives the pain most people have with systems like this.

My trick was to say “while we’re building this let’s just leave it as open as possible, we can lock it down once we’re sure the process works how we need it” - and then never lock it down (or just lock down the bits that people use to shoot themselves in the foot).

Re: GitHub and Jira Software Integration

#133
post #84
post #11

I see a lot of people complaining about JIRA in this thread, so here's my take: - I've used Trello, GitHub Projects/Issues, and other Project Management software; - While JIRA has a steep learning curve and is generally unpleasant to use, it is far and away the most customizable and powerful PM software I have used; - Despite JIRA's poor design choices and UX clunkiness, it is so powerful that I wouldn't use anything…

Can you give some examples of its power and customizability? What does JIRA do that for example Trac can't? (Trac can often be customized with 10 lines of simple Python (or CSS, HTML, JS) dropped as a single file into the plugin folder and you're done. It's the hacker's bug tracker. And it's fast and quite easy to use. I wonder why it's not more popular anymore.)

I've never used Trac for tickets. My first introduction to Jira was replacing 5 different in-house ticketing systems covering systems, desktop support, to software development. Here are some of the things I've noticed that I haven't seen other ticketing systems do as well; each department's tickets had their own fields that were unique to them, you could pass a ticket department-to-department with a clear interface to map and update fields, a clear history was preserved when going from department to department, you could have a simplified interface for users (with additional, more intimidating fields for people working the tickets), you could update tickets by replying to emails (seems obvious/trivial, but that feature is often missing), search was very good. This was close to 10 years ago.

Fiddling with Trac tickets right now it seems like something I would love if I spent the time to learn. For example, search is just a text field. I imagine if I learned the syntax it'd be very powerful. I remember Jira, at the time, had a "simple search" with separate auto-completing fields for things like opened-by, assigned-to, open-date, and "complex search" that used a text-based syntax.

Not that Jira was amazing, but UI makes a big difference. A coworker showed me a different frontend someone had built in front of BugZilla and it looked 100x more approachable.

After working at places that didn't use Jira (well, almost all of them evaluated it but deemed it too expensive and too large of a project to migrate) my current job uses Jira, again. Man is it slow (I've heard this is growing pains of converting a codebase designed to run on a single server and making "services" out of it to scale) and there's way more confusing integration. I've been trying to use it as little as possible.

Re: GitHub and Jira Software Integration

#135
post #92

Earlier quoted context omitted.

JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories: - conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new product…

all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.

Agreed that the problem isn't directly Jira, but (anecdotally maybe) there seems a clear correlation between Jira and unhappy developers who feel their tracker has way too much process. Jira doesn't cause the root problem, but Atlassian are profiting from it existing, and so maybe people are encouraged to use it in those ways. I'm not letting it off the hook so easily.

Re: GitHub and Jira Software Integration

#136
post #5

Earlier quoted context omitted.

Yeah I've had nothing but a bad time with Jira, it's slow / high latency and high impact to use - combining that with GitHubs poor UX and I guess they're made for each other :/

Admittedly I havn't used Jira for about 6 years, but I don't recall it being particularly slow, at least if you give it decent hardware to run on (this is on-prem, so not sure how the Cloud editions go). If you're talking about process aspects, well.. that's also a business process thing, as to how much information PMs/etc want.

I used it 6-8 years ago on-prem. I remember hearing it needed a rather beefy server and I don't remember it behaving particularly fast but it wasn't particularly slow, either. My jobs in-between didn't use Jira, but my most recent one uses the hosted version--it's very, very slow. What's annoying is it doesn't seem to cache either, so a second reload or navigating around is also slow.

I only read this in passing, but I heard it's the growing pains of changing a codebase intended to run on a single-server and trying to rebuild it into "services" that scale.

Re: GitHub and Jira Software Integration

#137
post #92

Earlier quoted context omitted.

JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories: - conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new product…

all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.

> Jira gets the flac, because but the problems isn't Jira.

I recently had somebody come up and tell me: "I can't get a grasp of the status of the sprint because of Jira."

The issue, in stead was that people were creating epics all over the place and nobody ever updated their stories. So there was no clear structure and the burndown never burned down. I've worked with Jira for a long time and I can, almost, always adapt it to fit a process. However, when nobody knows that the process is, it's impossible to create a good version in Jira, but Jira ends up getting the blame.

Re: GitHub and Jira Software Integration

#138
post #62
post #52

Earlier quoted context omitted.

I work in a shop that had effectively no project management. When jira was introduced it was a godsend. Obviously email and slack requests aren't better, so what is the alternative system that has people hating on jira? Honest question.

How long has your company been using JIRA for? JIRA has a tendency to.... decay. New ticket types are created with custom fields that aren't ever kept up to date. Everyone starts to choose random entries because they have no choice, and no way to add new ones. Once that starts, things fall into chaos because nobody knows the "right" way to file tickets. Tickets soon become immeasurably immeasurable. Projects become c…

> JIRA has a tendency to.... decay.

Is there any enterprise scale tool that doesn't, when it isn't managed correctly? It needs management just like any other tool that's being used on an enterprise scale. People just want to be able to set and forget, but then it doesn't adapt well to individual departments and teams. Then people either start messing with it, or if they can't, they start hating it.

The benefit of a smaller tool is then, that teams can just get their own instance and mess that up without impacting the organization.

Re: GitHub and Jira Software Integration

#139
post #59
post #40

Earlier quoted context omitted.

It's because many of us have worked at companies that use JIRA extensively. It's a tool that marks the sign that a company cares more about the management of staff as units, instead of caring about employees as breathing and creative forces. It makes management's job easier, but it does nothing for the managed, except lead to frustration and hundreds of emails that have to be waded through for that 5% chance of relev…

What are some alternatives you (or others) would suggest to Jira? I don't mean that to come across snarky at all; I'm honestly curious what people are using and enjoy.

I learned about clubhouse.io last week. Testing it now, but it seems very nice. Just enough configuration and structure.

(We are coming from Trello which just doesn't deal well with a large number of tickets as you have only one view on them.)

Re: GitHub and Jira Software Integration

#140
post #92

Earlier quoted context omitted.

JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories: - conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new product…

all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.

JIRA makes it dangerously easy to implement overly bureaucratic processes. A certain kind of organization is drawn to it for that reason. Even a healthy organization switching to JIRA can get carried away with the tools now at its disposal.

JIRA is a software product but also a social institution, an organizational philosophy. Sure, you can have the software without the attitude or vice versa, but use of JIRA is still a (weak) negative signal about the quality of an employer.

Turns out that the main thing protecting employee autonomy is the logistical difficulty of micromanagement. JIRA "solves" that problem.

Post reply on HN