3 ms·

This is more about how Jira is configured. For example, there is no reason why each transition in the workflow couldn't simply have a corresponding counter-tra

This is more about how Jira is configured. For example, there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition: "Start development" / "Abort development"; "Move to test" / "Return to development" (not the same as "Test failed"); "Test OK" / "Test again"; "Close" / "Reopen". And the excessive fields almost certainly can be removed from the form, so you could reduce the entire thing to Title + Description + State + Assigned To. You are right that most companies don't do this. That's because in most companies the management decides how Jira should be configured... and their preference is for "more data" because it gives them the illusion of control, and they don't really care how much extra paperwork this means for the developers. Well, we could perhaps blame Jira for having the wrong defaults. But even where Jira has the right defaults, the management often decides to override them. For example, Jira allows to split tasks to subtasks, but by default this functionality is disabled, and the documentation argues strongly against it. (The recommended way to use Jira is that the tasks are atomic, and you have a database of tasks. To relate tasks to each other, use links or tags or epics; all of them optional.) Yet, most managers insist that tasks must be divided to subtasks. And then you get the usual "one subtask per each task" or "analysis, development, and testing are subtasks, instead of steps in workflow", because that's how the management wanted it. Then underlying reason is that developers and managers have different needs. Developers need a database of bugs, and a short list of tasks to be done. Managers want as much information as possible (no matter whether the information makes sense or not, because they don't understand half of it anyway), plus time tracking (to push people to work faster), plus something that would reduce their need to plan and check how the plan progresses... and if they can outsource all this work to developers, that makes their own work more convenient. Which is why the Jira is configured the way it usually is. But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool.

lmm 6y ago
> there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition There isn't, but you have to manually maintain them, and inevitably they get out of sync. > But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool. Bad management insists on tools that let them manage badly, of which Jira is the prime example. It's not a bad tool in the sense of being badly coded, and on some level I can't blame Atlassian for making a tool that micromanagers love - I'm sure there's a huge market for that. But precisely because it's designed to give bad managers what they want first and foremost, it's a red flag in a working environment.

lmm 6y ago

> there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition There isn't, but you have to manually maintain them, and inevitably they get out of sync. > But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool. Bad management insists on tools that let them manage badly, of which Jira is the prime example. It's not a bad tool in the sense of being badly coded, and on some level I can't blame Atlassian for making a tool that micromanagers love - I'm sure there's a huge market for that. But precisely because it's designed to give bad managers what they want first and foremost, it's a red flag in a working environment.