4 ms·

Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures: way too many non-devs and non-qa people looking to

Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures: way too many non-devs and non-qa people looking to get data from it and cramming their stuff into it. Every month it seems like there's another couple of fields that I have to fill out so that some random group can track some metric, or the security team can pretend like we're doing a security audit on all of the code, or whatever. My favorite is the checkbox the QA team has to click to confirm that they've done security checks on new endpoints. They don't have the first clue on how to do that, but they all just check the box because they have to check the box to continue. Whether or not this is Atlassian's fault is debatable of course. I feel like they were more opinionated back when I started using it ~10 years ago (with the Greenhopper plugin). It was a much, much more pleasant thing to use. Probably because it was only under the control of the teams who were actually doing dev work.

taftster 10y ago
Goodness yes. JIRA has become way too many things to way too many people. It's got a feature for everything, which means it's good at nothing. I'd rather just go back to bugzilla at this point. The agile stuff in particular feels like a bolt-on. Its obvious that JIRA grew up from a simple bug tracker to a complete software development workflow engine. The pain points of its growth and add-ons are frustratingly obvious. It really needs a reboot. I feel like Atlassian products are vulnerable to be picked off. There's going to be something that kicks it off its pedestal soon. Good riddance.
- kschrader 10y ago
  Agreed. It feels like Atlasssian never met a feature request that they didn't say "no" to. Unfortunately, most of the tools out there don't scale well, so most teams reach the point where Jira is the only reasonable choice. (Full disclosure, building https://clubhouse.io https://clubhouse.io address this problem.)
  - jaxb 10y ago
    They only say "no" to something you (think you) really need at this moment :) Say, https://jira.atlassian.com/browse/JRA-4446 https://jira.atlassian.com/browse/JRA-4446 "Sub-issues should be able to contain their own sub-issues" -- #6 on the list of top voted for.
    - kschrader 10y ago
      To be fair, they did say "no" to this. (After 11 years. :-) )
    - merb 10y ago
      Actually Stash issue's were handled badly. Some issue's were delayed for better "integration" with jira. unfortunatly these issue's were way more important.
  - itomato 10y ago
    Baloney. There are at least 5,000 for JIRA alone: https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%20JRA%20AND%20type%20in%20(Suggestion%2C%20Enhancement)%20and%20status%20not%20in%20(Resolved%2C%20Closed)%20order%20by%20created%20ASC https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%...
    - kschrader 10y ago
      Perhaps you confused "it feels like" (implying that it feels bloated with many esoteric and/or generally useless features) with the statement "there's literally never been a feature that they've said no to" which is something else entirely and what you seem to be disproving here.
      - itomato 10y ago
        In that case, does it really feel like they've said no to any enhancement request that's come through? From my experience, and those who have watched issues for ten-odd years, I'd say the opposite is true, but I'm not working on a competing product.
virgil_disgr4ce 10y ago
Exactly why I described it as the "Salesforce of project management." shudder
jschumacher 10y ago
Disclaimer: I work on JIRA Software "Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures" JIRA didn't try to be a universal tool for all processes and procedures, but it happened to spread from the development team into other parts of organisations due to it's flexibility. Of course that flexibility comes at a cost the experience to the end-user is controlled by the administrators. What is the alternative? A more opinionated tool could potentially get a specific task done better. The problem is that you will need 2, 3 or more separate, more opinionated tools to cater for the specific use-cases. These tools will have to be maintained and probably won't integrate very well, making collaboration between different departments a lot more difficult. That's exactly what JIRA tries to solve, help your teams collaborate. Could Atlassian be more opinionated. Absolutely. Being opinionated doesn't necessarily mean that we need to limit the flexibility of JIRA. We can do a much better job at optimising for specific use-cases and guiding people towards best practices, while still allowing customisations where desired. We've started this effort last year by introducing JIRA products aimed at specific use-cases. Take JIRA Software for example, it's aimed at Software teams and has specific features like Scrum, Kanban boards, sprints and releases that are specific to software teams. If you aren't a software team, you can just use JIRA Core and you don't need to worry about what Scrum even means. There is a lot more we can do to make the simple things simpler, and it's a big focus area for us. We won't enforce limits on the number of fields you can add, but we are looking at giving project administrators a lot more autonomy around how their projects are configured. We can't stop the QA checkbox from appearing if somebody really wants it there, but we can provide the guidance and tools to make the experience better for everyone. Happy to answer any questions you may have.
ryandrake 10y ago
Just a counter-point: The non-dev, non-qa people have to get their data from somewhere. Why not consider the issue tracker the "source of truth" for information about the issues that affect the project? The alternatives are: 1. maintain parallel excel (or whatever) sheets and have all these different managers manually bugging the developers and qa people constantly to keep it up-to-date, or 2. stand up parallel systems to track each of these things with varying levels of integration, and as a developer you now need to remember to both close the issue in your bug tracker AND update this project management dashboard AND update the security status tracker AND add a ticket to another system to get the end user documentation updated AND on and on... When you've worked with that kind of system, you start to long for the simplicity of another field in the issue tracker.

taftster 10y ago

Goodness yes. JIRA has become way too many things to way too many people. It's got a feature for everything, which means it's good at nothing. I'd rather just go back to bugzilla at this point. The agile stuff in particular feels like a bolt-on. Its obvious that JIRA grew up from a simple bug tracker to a complete software development workflow engine. The pain points of its growth and add-ons are frustratingly obvious. It really needs a reboot. I feel like Atlassian products are vulnerable to be picked off. There's going to be something that kicks it off its pedestal soon. Good riddance.

kschrader 10y ago
Agreed. It feels like Atlasssian never met a feature request that they didn't say "no" to. Unfortunately, most of the tools out there don't scale well, so most teams reach the point where Jira is the only reasonable choice. (Full disclosure, building https://clubhouse.io https://clubhouse.io address this problem.)
- jaxb 10y ago
  They only say "no" to something you (think you) really need at this moment :) Say, https://jira.atlassian.com/browse/JRA-4446 https://jira.atlassian.com/browse/JRA-4446 "Sub-issues should be able to contain their own sub-issues" -- #6 on the list of top voted for.
  - kschrader 10y ago
    To be fair, they did say "no" to this. (After 11 years. :-) )
  - merb 10y ago
    Actually Stash issue's were handled badly. Some issue's were delayed for better "integration" with jira. unfortunatly these issue's were way more important.
- itomato 10y ago
  Baloney. There are at least 5,000 for JIRA alone: https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%20JRA%20AND%20type%20in%20(Suggestion%2C%20Enhancement)%20and%20status%20not%20in%20(Resolved%2C%20Closed)%20order%20by%20created%20ASC https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%...
  - kschrader 10y ago
    Perhaps you confused "it feels like" (implying that it feels bloated with many esoteric and/or generally useless features) with the statement "there's literally never been a feature that they've said no to" which is something else entirely and what you seem to be disproving here.
    - itomato 10y ago
      In that case, does it really feel like they've said no to any enhancement request that's come through? From my experience, and those who have watched issues for ten-odd years, I'd say the opposite is true, but I'm not working on a competing product.

virgil_disgr4ce 10y ago

Exactly why I described it as the "Salesforce of project management." shudder

jschumacher 10y ago

Disclaimer: I work on JIRA Software "Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures" JIRA didn't try to be a universal tool for all processes and procedures, but it happened to spread from the development team into other parts of organisations due to it's flexibility. Of course that flexibility comes at a cost the experience to the end-user is controlled by the administrators. What is the alternative? A more opinionated tool could potentially get a specific task done better. The problem is that you will need 2, 3 or more separate, more opinionated tools to cater for the specific use-cases. These tools will have to be maintained and probably won't integrate very well, making collaboration between different departments a lot more difficult. That's exactly what JIRA tries to solve, help your teams collaborate. Could Atlassian be more opinionated. Absolutely. Being opinionated doesn't necessarily mean that we need to limit the flexibility of JIRA. We can do a much better job at optimising for specific use-cases and guiding people towards best practices, while still allowing customisations where desired. We've started this effort last year by introducing JIRA products aimed at specific use-cases. Take JIRA Software for example, it's aimed at Software teams and has specific features like Scrum, Kanban boards, sprints and releases that are specific to software teams. If you aren't a software team, you can just use JIRA Core and you don't need to worry about what Scrum even means. There is a lot more we can do to make the simple things simpler, and it's a big focus area for us. We won't enforce limits on the number of fields you can add, but we are looking at giving project administrators a lot more autonomy around how their projects are configured. We can't stop the QA checkbox from appearing if somebody really wants it there, but we can provide the guidance and tools to make the experience better for everyone. Happy to answer any questions you may have.

ryandrake 10y ago

Just a counter-point: The non-dev, non-qa people have to get their data from somewhere. Why not consider the issue tracker the "source of truth" for information about the issues that affect the project? The alternatives are: 1. maintain parallel excel (or whatever) sheets and have all these different managers manually bugging the developers and qa people constantly to keep it up-to-date, or 2. stand up parallel systems to track each of these things with varying levels of integration, and as a developer you now need to remember to both close the issue in your bug tracker AND update this project management dashboard AND update the security status tracker AND add a ticket to another system to get the end user documentation updated AND on and on... When you've worked with that kind of system, you start to long for the simplicity of another field in the issue tracker.