3 ms·
I'm not sure if Jira is inherently bad or if Jira is destroyed by project managers that force developers to use it as a reporting/management tool and not as a b
by Rexxar 11y ago
I'm not sure if Jira is inherently bad or if Jira is destroyed by project managers that force developers to use it as a reporting/management tool and not as a bug-tracking tool.
- mgkimsal 11y agoI'm diving in to a new project right now - third one with Jira/Confluence, and working with a freelance PM on it. The one issue she's got with it is trying to generate "good reports" with it for the 'biz folks' on the project. :) That said, we're still going with it, partially because the other tools we've tried all... don't work together very well. Documenting things in Confluence and tying tickets to those documents directly does wonders for bridging the gap between tech/dev and the other parts of a project that think in English. There are no doubt better 'bug trackers' out there, and there are no doubt better 'document collaboration' tools, and better 'planning' tools, but I've not found any that play nice together. Open to suggestions...
- oneJob 11y agoMy experience also suggests that this is the real issue. Someone has to make a decision on which solution to use for their "agile" development workflow, but this someone doesn't understand that they are actually purchasing a product with a constrained, predefined version of agile. Even though it is somewhat flexible it doesn't perfectly map onto this person's version of agile and so, since they've already paid the licensing fees and gone through the office politics of getting buy in or stuffing it down the users throats, they don't want to admit that either their version of agile could be tweaked or that they should have licensed different software. So then, the mess begins. At every turn square pegs are forced into round holes and workflows are misused with consequences that are not immediately evident. A year down the road and everyone is frustrated. You'd be better off using an excel workbook. Now you have to explain to everyone you onboard why your version of agile is so much better than other versions and warranted creating this monstrosity which they must figure out how to use without documentation (which is useless at this point) and without frustrating their new coworkers with too many questions about the arbitrary nature of their system, which they hate and had shoved down their throats.