5 ms·

Jira tries to solve everyone’s problem. It tries to incorporate everyone’s idea of how and what’s needed to be tracked. I can just say from my own experience t

by he0001 3y ago

Jira tries to solve everyone’s problem. It tries to incorporate everyone’s idea of how and what’s needed to be tracked. I can just say from my own experience that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer or anything near a software project, and yet enforces all this garbage for their illusion of control. And yet they have none. Just because they are higher up in the hierarchy than the people that works with the actual product. And then there is all these managers that think that everything should be a ticket and all changes can absolutely map to a ticket. Or that everything is actually done by the guy on the ticket. I bet when I die and go to hell, my punishment will be to fill out Jira tickets and push them through the workflow. Edit: formatting and spelling

robertlagrant 3y ago
Lots of things can be a ticket, though.
dingnuts 3y ago
> that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss... I thought it was JIRA, but it was the org..
submain 3y ago
I share the sentiment and frustration of having to fill useless boxes. However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped. I hate overly complicated processes, but tracking things is essential.
- deleted 3y ago
  [deleted]
- jdmoreira 3y ago
  Your developers must be children then. (Maybe because you treat them like children). The source of truth is their changelog not your Jira tickets
  - submain 3y ago
    Quite the opposite actually. My developers barely touch their tickets. Most of the updates are done rather informally. They mostly interact with git and I make sure things are tracked. You’ve used quite strong words there.
- occz 3y ago
  Seems like the kind of thing that Git is really good for, right?
- TheCoelacanth 3y ago
  Continuous deployment is the solution to that. You always know what is in a release because it's the one thing that you were trying to change when you clicked merge. Overly complicated processes are just patches to try to cover up for immature engineering practices.
- _dain_ 3y ago
  >tracking what's being changed and by whom git >You won't know what's included in your release release notes >nor if it was tested properly. CI
  - vundercind 3y ago
    Resistance to simply reading data we already fucking have is so very weird to me in “agile” (and much of non-agile, to be fair). Part of the trouble is using things like Jira and moving tracking-what’s-happening and chatting-about-features farther from the code than it needs to be.
- 3y ago
bigmattystyles 3y ago
The problem is when your instance has too many masters - all fields are global, then their visibility is controlled at the project level. In a big company with one instance, holy sh!t. There are so many duplicated fields, unused fields. When you go to the bulk change option, it shows you all of these and it goes for days. It works well if you keep it under control, but word to the wise to any company. Create a governance board that's not afraid to tell a VP to fuck off with their requests for yet another ill-conceived field. That's from the user / web viewpoint. Don't get me started on their API. v2, v3 changes - the stuff you can't filter out that bloat responses, etc.... But otherwise, if well controlled, it is good. Or at least one of the least bad systems.

by he0001 3y ago

robertlagrant 3y ago

Lots of things can be a ticket, though.

dingnuts 3y ago

> that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss... I thought it was JIRA, but it was the org..

submain 3y ago

I share the sentiment and frustration of having to fill useless boxes. However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped. I hate overly complicated processes, but tracking things is essential.

deleted 3y ago
[deleted]
jdmoreira 3y ago
Your developers must be children then. (Maybe because you treat them like children). The source of truth is their changelog not your Jira tickets
- submain 3y ago
  Quite the opposite actually. My developers barely touch their tickets. Most of the updates are done rather informally. They mostly interact with git and I make sure things are tracked. You’ve used quite strong words there.
occz 3y ago
Seems like the kind of thing that Git is really good for, right?
TheCoelacanth 3y ago
Continuous deployment is the solution to that. You always know what is in a release because it's the one thing that you were trying to change when you clicked merge. Overly complicated processes are just patches to try to cover up for immature engineering practices.
_dain_ 3y ago
>tracking what's being changed and by whom git >You won't know what's included in your release release notes >nor if it was tested properly. CI
- vundercind 3y ago
  Resistance to simply reading data we already fucking have is so very weird to me in “agile” (and much of non-agile, to be fair). Part of the trouble is using things like Jira and moving tracking-what’s-happening and chatting-about-features farther from the code than it needs to be.
3y ago

bigmattystyles 3y ago

The problem is when your instance has too many masters - all fields are global, then their visibility is controlled at the project level. In a big company with one instance, holy sh!t. There are so many duplicated fields, unused fields. When you go to the bulk change option, it shows you all of these and it goes for days. It works well if you keep it under control, but word to the wise to any company. Create a governance board that's not afraid to tell a VP to fuck off with their requests for yet another ill-conceived field. That's from the user / web viewpoint. Don't get me started on their API. v2, v3 changes - the stuff you can't filter out that bloat responses, etc.... But otherwise, if well controlled, it is good. Or at least one of the least bad systems.