I hope those now remote employees have access to some good issue tracking, repo hosting, and collaboration/documentation tools.
Else they'll be forced to use something like Jira, Confluence, Bit Bucket, and such, which suck...
Else they'll be forced to use something like Jira, Confluence, Bit Bucket, and such, which suck...
The current implementation of jira and confluence I’m using is worse than having _no_ ticket tracking and documentation system.
Because if it didn’t exist there would be the impetus to implement something. But we just kinda barely limp by with what we have.
It’s so barely functional that people actively avoid using it.
I’m fully aware that the company is to blame and not necessarily atlassian though, as we have a number of plugins and random custom fields.
One of the most dangerous things about jira is that it tries to be everything to everyone and people get carried away in the customisation believing they need it. It slows everything to a crawl and leaves you inundated with mandatory fields and a nightmare of matching stories with sprints and estimations in order to bring a bloody task in.
Life was better with rt and mediawiki.
Also the mandatory fields are definitely a per-organization thing. At my org we have I think 3 mandatory fields, which are the project the ticket goes under, the title, and the description. In many cases, "migrating" from JIRA to JIRA but 90% of the features are disabled would probably be an improvement.
... I suppose that might be the main difference between people who hate JIRA and people who find it a little bit clunky but generally acceptable: people who mostly have the baseline stuff happen automatically are fine with it, and people who spend a lot of time interacting with the web frontend in repetitive ways hate it.
I ended up forcing my slack bot to issue POSTs to Jiras API out of frustration.
The two workhorses of my integration are two methods named jira_get and jira_post.
function jira_get {
ENDPOINT="$1"
PAYLOAD="$2"
URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT"
QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')"
curl \
--silent \
--request "GET" \
--header "Content-Type: application/json" \
--user "$JIRA_USER:$JIRA_TOKEN" \
"$URL?$QUERY_STRING";
}
function jira_post {
ENDPOINT="$1"
PAYLOAD="$2"
URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT"
QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')"
curl \
--silent \
--request "POST" \
--user "$JIRA_USER:$JIRA_TOKEN" \
--header "Content-Type: application/json" \
"$URL" \
--data "$PAYLOAD";
}
ISSUE=PRJ-1234
ISSUE_JSON="$(jira_get "issue/$ISSUE/transitions" '{"expand":"transitions.fields"}'
TRANSITION_NAMES="$(echo "$ISSUE_JSON" | jq '.transitions[].name')"
But yeah, a slack bot that issues requests to the JIRA api is a perfectly workable solution, and I think you'd be surprised at how much of a quality of life improvement you'll get by continuing to add capabilities to it that reflect your specific workflow.
The problem is that this anecdote is not even remotely surprising. I've used JIRA and/or Confluence at three employers and all three had wildly different, and awful, configurations. I have never worked with any technical folks who loved either, although I think on the whole Confluence is slightly better than JIRA.
I thought the same thing for a long time - that Atlassian makes decent products that are often implemented poorly - but the problem is, at what point does it become Atlassian's fault for making products that seem so easy to implement so badly that developers will go out of their way to track work in Excel instead of JIRA?
A couple of mandatory fields (department, team, application), that were manageable and that's about it.
They even the JIRA during my tenure there. Made user sessions last for a while instead of being disconnected every 15 minutes.
Feel free to email me if you think your company may be open to using outside help to clean things up.
I'd rather learn a completely new system every 90 days than use JIRA.
On a typical day moving tickets around , reviewing everyone's items and confluence with its WYSIWHG editor only approach is 20% of my day gone.
Just making the UI non blocking for every single action would double my productivity. Their mobile apps are definitely better than web, so it is not like they cannot build decent interface and application, The web app just smells of legacy and debt to me.
Even if its because of customizability they provide, it is really on them, to approve all sorts of plugins and for all straitjacketing they and/or AGILE ( as typically implemented) does to your development in the name of structure, restricting some of this customizability would not have hurt product more.
Ultimately like any other SaaS business they serve the buyer and not the user. They are interested in what sells more, more often than not it does not intersect with what the users need. Customization sells, saying NO doesn't in enterprise.
I guess we should be thankful they are not IBM or Oracle and build your kitchen sink and neighbours too
I am tempted at least once every few months to just build a better interface and frontend which isnt' crap. Management is not going change from JIRA. Developers / users would happily pay out of pocket for a saner interface which helps simply manage their items without fuss, most people don't really care about the backend and the fancy reports, burndown charts for the most part, those who do can use the official app .
I'd rather use a tool that is flexible by default than use a rigid tool that you need to change every six months.
Incidentally that conversation started with the suggestion to bring Jira into our already bloated set of services.
One day I need to have a beer with these people who say Jira is fast. I've seen everything from "unremarkable" to "If we don't reboot the servers on Monday then nobody can work after 10 am on Friday". But never, ever, fast.
I've used it for 6 months - it's garbage. At least, absolutely ZERO times better than Jira as an overall productivity tool.
I can't tell you how many times issues have never loaded (see: blank screen), painstakingly prioritised lists of HUNDREDS of issues that have had their ordering completely scrambled, to name two off the top of my head.
If you hate Jira, think about whether it's the thing you hate that you're used to. Because you're absolutely going to be trading for a NEW thing that you hate, and have to learn to use from scratch.
Then they decided that they wanted to look serious, and reduced the meme size to 32px. That’s when the product fell out of fashion, because it was just like Slack with fewer features.
Thousands of years of linguistic progress out the window...
Atlassian's documentation isn't that good however.
That's the fundamental problem. Jira is sold to PMs and managers, not to developers, and it shows. Jira isn't an issue tracking tool, it's a work-tracking and developer-tracking tool masquerading as an issue tracker. The people who spend the most time with it aren't the customer.
I think this actually might be a fundamental issue that is masquerading as design issues on Jira's side, because when you're doing roadmapping views you want to continually refactor them to reflect better metaphors and realities, whereas when you're doing issue tracking you want issues to stick around and be solid entities linked intimately into the history of the software application. So tools like Portfolio have to juggle both ends.
A non sane place would have 20 obscure mandatory fields per ticket, require the ticket to go through 10 different states that makes no sense, and last but not least, every click would take a full minute to load the page.
When you're working with Python, Jira will render __init__.py as an italicized version of _init_.py even when you put it in monospace with the {{braces}}. If you're talking more abstractly about algorithms, O(n) turns into the letter O followed by the thumbs down emoji.
It's a good thing no one uses Jira for software projects because that'd be really awkward!!!
Collaborating over JIRA on a video conference is PAINFUL AF. A lot of time is spent just waiting for the UI to respond. It is completely unacceptable.
I'm not a PM and I don't really want to get to know the ins and outs of an issue tracker.
Also, looking at my project is a pain since my tickets are outside the sprint and I either need to go into the backlog and scroll a bunch, or use a custom search.