4 ms·

>If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think tha

by jmcqk6 9y ago

>If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot. If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.

sz4kerto 9y ago
You seem to be talking about JIRA reports. JIRA != Trello + fancy reports. The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA. (Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )
- ravitation 9y ago
  > The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA. This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason... And you're also stuck carrying around all the features you don't use...
  - gregmac 9y ago
    You can also build flexible, low-overhead workflows using JIRA. The key is to keep managers out of the admin section, make sure the dev team is in full control, and tend towards saying "no" whenever anyone asks for changes to the workflow.
    - blattimwind 9y ago
      > The key is to keep managers out of the admin section Works as a general rule, too.
    - ravitation 9y ago
      I think anecdotally that may work, but I'm not convinced that dev teams are that much better than "managers" are at creating or managing process (nor are they often very interested in doing it)... But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
      - sdoering 9y ago
        Just anecdotally I can confirm that different development and product teams work good with JIRA and Confluence in conjunction. The agency I work at uses these tools together with ovur clients, as well as internally on different levels. We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...
tyingq 9y ago
There are places where the incoming work is pretty high volume...so you need a "ticket" system just to make sure it's all accounted for. Jira isn't perfect, but I can't tell if you just generally object to tracking work, or if the particular environment you're in just doesn't need that sort of thing. And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not. I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.
deleted 9y ago
[deleted]
arafalov 9y ago
Apache uses them: https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all https://issues.apache.org/jira/secure/BrowseProjects.jspa?se... I am not sure who the 'management' would be in their case.
- brodock 9y ago
  the companies that pay the foundation bills.
pgt 9y ago
I shall steal the quote, "Rorschach number generators for management" xD

by jmcqk6 9y ago

sz4kerto 9y ago

You seem to be talking about JIRA reports. JIRA != Trello + fancy reports. The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA. (Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )

ravitation 9y ago
> The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA. This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason... And you're also stuck carrying around all the features you don't use...
- gregmac 9y ago
  You can also build flexible, low-overhead workflows using JIRA. The key is to keep managers out of the admin section, make sure the dev team is in full control, and tend towards saying "no" whenever anyone asks for changes to the workflow.
  - blattimwind 9y ago
    > The key is to keep managers out of the admin section Works as a general rule, too.
  - ravitation 9y ago
    I think anecdotally that may work, but I'm not convinced that dev teams are that much better than "managers" are at creating or managing process (nor are they often very interested in doing it)... But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
    - sdoering 9y ago
      Just anecdotally I can confirm that different development and product teams work good with JIRA and Confluence in conjunction. The agency I work at uses these tools together with ovur clients, as well as internally on different levels. We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...

tyingq 9y ago

There are places where the incoming work is pretty high volume...so you need a "ticket" system just to make sure it's all accounted for. Jira isn't perfect, but I can't tell if you just generally object to tracking work, or if the particular environment you're in just doesn't need that sort of thing. And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not. I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.

deleted 9y ago

[deleted]

arafalov 9y ago

Apache uses them: https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all https://issues.apache.org/jira/secure/BrowseProjects.jspa?se... I am not sure who the 'management' would be in their case.

brodock 9y ago
the companies that pay the foundation bills.

pgt 9y ago

I shall steal the quote, "Rorschach number generators for management" xD