3 ms·

That is entirely what your company has used Jira to design. Yes it is possible because Jira is that flexible. Jiras standard workflow is literraly Todo-In prog

That is entirely what your company has used Jira to design. Yes it is possible because Jira is that flexible. Jiras standard workflow is literraly Todo-In progress-Done and you can transition from any state to any state and edit any fields you want at any time. Don't blame the tool. You said you needed an axe to chop wood to stay warm. Is it the axe's fault if you go kill your neighbor with it? We use Jira and we have none of the problems you describe. We also have it integrated with a bunch of other tools we use and it gives us a really good overview of where we are at with things, looking up the Why behind a code change etc. FWIW we do use a more elaborate workflow but it works well and parts of it are so that you can see if something it out with customers or not and those transitions are automated and done by our deployment scripts.

lmm 6y ago
> Jiras standard workflow is literraly Todo-In progress-Done and you can transition from any state to any state There may be predefined transitions between all the predefined states. But as soon as you add a new state you do not get any transitions to/from it except those you explicitly define. Any custom step that you define will not be undoable unless you explicitly define a way to undo it, and Jira will give you no help at all in ensuring that your undo transition actually undoes. > Don't blame the tool. You said you needed an axe to chop wood to stay warm. Is it the axe's fault if you go kill your neighbor with it? If the axe keeps slipping in people's hands and they keep chopping off their fingers, that's a problem with the axe. Even if there's one guy who doesn't have that problem and thinks everyone else must've been holding it wrong, it's still a badly designed axe. > We use Jira and we have none of the problems you describe. We also have it integrated with a bunch of other tools we use and it gives us a really good overview of where we are at with things, looking up the Why behind a code change etc. Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards).
- tharkun__ 6y ago
  This again depends entirely on your company. Way back Jira did not have a "allow any state to transition here", but now it does. Now whether that is something that is useful to you depends on how your company uses Jira and its workflow. If you have a huge, overbearing and stringent workflow, then with each combination of workflow steps and required fields and such, everything becomes more and more complex and you easily get into the sort of situation that you describe for various reasons. I wonder how you would have Jira 'help'. If you define a workflow step and set a certain field to a specific value based on post-function from some plugin that actually makes a REST call to some external system. How would Jira help you in determining that if you transition from that step back to one 3 levels before in your (also non-linear) workflow should unset that specific field? I don't envy you and I feel for you. It does not have to be that way but you also can't blame Atlassian for letting those sorts of companies, which let's face it are larger companies with more licenses bought, buy Jira and catering to them. However, Atlassian has kept things very very simple and open enough that you don't have to be a victim of that. > Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards). I do have to give you this, Jira is not great for empowering people to make their own changes to workflows and such, so you _are_ entirely at the mercy of your company. They are sort of changing some of this with at least Jira Cloud and the new issue view (which I hate with a vengeance for the most part) in that you can both "pin" fields yourself on a per project basis (which is bad, because in our case I want the same ones pinned in all projects, as they all share the same issue types and workflows but there's a project per product we have) and you can move fields between the left and right context (or removed from screen) without having to be a Jira admin. It's still lacking in many ways though. Just so you know, I'm not saying Jira is the best tool ever out there and everything is perfect about it. I'm just saying that your company misusing it doesn't mean that the tool isn't valuable and doesn't have some great features. Did you know that Jira since not too long ago allows story points to have floating point values now, because so many people requested it? That is absolute utter BS and not in line with any agile methodology I've ever come across. But I guess this is where I have to refer back to Money, Money, Money ... :) FWIW I've been both at companies where other people were Jira admins and to get something changed you had to go through someone else and where I was the admin. Sometimes the changes requested were denied. In other cases, even within a large (10k+ employees) companies, we just had our own Jira for the project and I was actually (one of the few) Jira admin(s). At my current company I am not but most things are actually configured just as they should be. If you want something changed, you ask for it and it's usually not a problem and the stuff they're putting in is not crazy. Would you rather have a centrally managed IBM Remedy? :) P.S.: And just on the axe, I think it depends. Is it a standard axe with a hickory handle? By default that definitely doesn't slip. Oh you say you oiled it so much that it slips all the time now? Not the axe's fault!

lmm 6y ago

> Jiras standard workflow is literraly Todo-In progress-Done and you can transition from any state to any state There may be predefined transitions between all the predefined states. But as soon as you add a new state you do not get any transitions to/from it except those you explicitly define. Any custom step that you define will not be undoable unless you explicitly define a way to undo it, and Jira will give you no help at all in ensuring that your undo transition actually undoes. > Don't blame the tool. You said you needed an axe to chop wood to stay warm. Is it the axe's fault if you go kill your neighbor with it? If the axe keeps slipping in people's hands and they keep chopping off their fingers, that's a problem with the axe. Even if there's one guy who doesn't have that problem and thinks everyone else must've been holding it wrong, it's still a badly designed axe. > We use Jira and we have none of the problems you describe. We also have it integrated with a bunch of other tools we use and it gives us a really good overview of where we are at with things, looking up the Why behind a code change etc. Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards).

tharkun__ 6y ago
This again depends entirely on your company. Way back Jira did not have a "allow any state to transition here", but now it does. Now whether that is something that is useful to you depends on how your company uses Jira and its workflow. If you have a huge, overbearing and stringent workflow, then with each combination of workflow steps and required fields and such, everything becomes more and more complex and you easily get into the sort of situation that you describe for various reasons. I wonder how you would have Jira 'help'. If you define a workflow step and set a certain field to a specific value based on post-function from some plugin that actually makes a REST call to some external system. How would Jira help you in determining that if you transition from that step back to one 3 levels before in your (also non-linear) workflow should unset that specific field? I don't envy you and I feel for you. It does not have to be that way but you also can't blame Atlassian for letting those sorts of companies, which let's face it are larger companies with more licenses bought, buy Jira and catering to them. However, Atlassian has kept things very very simple and open enough that you don't have to be a victim of that. > Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards). I do have to give you this, Jira is not great for empowering people to make their own changes to workflows and such, so you _are_ entirely at the mercy of your company. They are sort of changing some of this with at least Jira Cloud and the new issue view (which I hate with a vengeance for the most part) in that you can both "pin" fields yourself on a per project basis (which is bad, because in our case I want the same ones pinned in all projects, as they all share the same issue types and workflows but there's a project per product we have) and you can move fields between the left and right context (or removed from screen) without having to be a Jira admin. It's still lacking in many ways though. Just so you know, I'm not saying Jira is the best tool ever out there and everything is perfect about it. I'm just saying that your company misusing it doesn't mean that the tool isn't valuable and doesn't have some great features. Did you know that Jira since not too long ago allows story points to have floating point values now, because so many people requested it? That is absolute utter BS and not in line with any agile methodology I've ever come across. But I guess this is where I have to refer back to Money, Money, Money ... :) FWIW I've been both at companies where other people were Jira admins and to get something changed you had to go through someone else and where I was the admin. Sometimes the changes requested were denied. In other cases, even within a large (10k+ employees) companies, we just had our own Jira for the project and I was actually (one of the few) Jira admin(s). At my current company I am not but most things are actually configured just as they should be. If you want something changed, you ask for it and it's usually not a problem and the stuff they're putting in is not crazy. Would you rather have a centrally managed IBM Remedy? :) P.S.: And just on the axe, I think it depends. Is it a standard axe with a hickory handle? By default that definitely doesn't slip. Oh you say you oiled it so much that it slips all the time now? Not the axe's fault!