- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
To be fair, it at least used to be the case that the diagram could be unspaghettified manually, resolving at least the display issue. That does not solve the problem of "PM putting in an absurd workflow that nobody understands", which leads to circumvention and lack of actionable data.
Admin
I think you mean "sluiten" instead of "gesloten". (sluiten = to close; gesloten = closed)
Admin
This friendly flowchart will help you in every business situation. It's worth being printed in A0 format to enlighten the whole office. But beware of the automatic sprint bug of Klaar. Now sit.
Admin
That is less a flow-chart and more a chaos-chart. If someone handed me that, I'd have to suspect either a prank or the creator needs help, possibly of the psychiatric variety…
Admin
I would root for 3 states. Open -> In progress -> Deployed
All other states can be collapsed to those 3. And rather focus on the lean principles,
Admin
TRWTF is “nobody has actually make a version that's any good.” Has anyone really been far even as decided to use even go want to do look more like?
Admin
"Developing software can't simply be done with a text editor and a compiler"
Yes, it can. Whether it's easy to do it this way is a different questions, but there were decades of development where a text editor and compiler were all that was available.
I'd even ague that for a lot of simple projects it's probably the best / easiest way to do so.
Admin
The question is, is the team's actual workflow—the way they really do the work—equally complex?
I've used Jira for a few decades now. When used properly, it's a great ticketing system. But "properly" starts with "the workflow matches the way the team actually works." The very first thing one should do before adopting Jira is make a flowchart of how your team actually processes work. Then you can build statuses and transitions that match that flowchart, and your team will find Jira comfortable because it works the way they do.
This may mean that you wind up with a whole bunch of ticket types and projects to wrangle different workflows, but guess what? That's your own processes that are "inefficient," not Jira. And maybe they're not "inefficient" so much as "necessary given the circumstances"...
When I see people that despise Jira, it's usually because their employer decided that everyone must use The One True Workflow that matches absolutely nobody's way of working, and so everyone's interaction with Jira is a bunch of manual workarounds and kludges to try and make The One True Workflow match what they do. That's TRWTF.
Admin
Jira reminds me so much of Lotus Notes.
I was in a place that used Notes for email once upon a time, in the early 90s. It was slow. Glitchy. Impenetrable.
The problem was that Notes/Domino wasn't really an email platform, it was a client/server programming system for text and data sharing. The primary application built on it was a bad email system.
Among other problems, the hardware of the day couldn't keep up with the software's demands.
Admin
Many, many software teams don't really have a single workflow, because often the ad-hoc problems they solve don't all fit in the same envelope.
Admin
Youecategories have a few holes(like if a ticket is rejected, or the requester changes their mind).
Therefore I suggest 3 different broad categories:
Needs Work - for anything no one is working on that needs work In Progress- for anything someone is working on Closed - for anything that needs no more work
Although honestly every company I've worked at has had the same basic flow once it hits dev: Planning(breaking down work and adding estimates) -> backlog -> approved for sprint -> in progress -> PR review -> awaiting deploy -> ready for test -> test passed -> done
If I was to make a ticketing system I'd start with this and make sections skippable with alternative options available, but the core will generally be similar to this flow so why not make it the default flow?
Admin
The real WTF is having a diagram like that not being rendered by any decent tool, such as mermaid or graphviz. Funny how there is at least one decade of difference between the ages of graphviz, Jira, and mermaid (in this order).
Admin
s/text editor/IBM 026 keypunch/
Admin
I only dispise Jira because it's slow and unreliable, and every month some basic element changes its UI for no good reason.
Admin
Clearly, Klinsten has uncovered several WTFs:
The worst one, IMHO, is the lack of automation behind the state mechanism. In this day and age, with the software development, QA and deployment processes tightly wrapped in the levels of automation they are, why is this ticketing state management still a manual thing? The ticket management software should know exactly which conditions have been (or not been) met, and be able to make the state change on its own. There should be no reason for Klinsten to manually determine which new state the ticket needs to be in.
But, then again, I'm an old fart, long retired from software development, and unused to the modern ways to fsck things up.
Admin
I once worked at a small company that spent MONTHS building a "process" for gathering requirements, scheduling enhancements, QA, getting user feedback, documentation, etc. In the end, there were more steps in the process than there were employees in the company!
To my knowledge, the process was NEVER used a single time. After all that work to build "the perfect process", it was so cumbersome that everyone simply worked around it.
Admin
Too bad JIRA doesn't have a "Allow any status to transition to this one" checkbox. Oh wait, it does. Yet another garbage-in, garbage-out problem.
Admin
As a systems engineering specialist, who specializes in process development and management, the only question that I have left is this, "Is the process like this to fix incompetency for multiple reviews, or is this actually how people work there?" A lot of processes get convoluted like this due to sign-off requirements, where a lot of "red-tape" is involved, or there has been enough errors that each Corrective Action adds another layer of policing to the process rather than looking at personnel, resources, time constraints, etc. The diagram itself with how Jira shows it, is entirely different matter in and of itself with rendering.
Be very careful with AI generation of flow diagrams, even using mermaid, as I've yet to have a successful one generated automatically. It tends to spit out things very similar in nature to what's been in this post, and then it drops connections and arrows.
Admin
Ah yes, I once spent a month building a GUI workflow editor for a enterprise app, just to find out afterwards there are only ever three steps, and only ever one workflow....
Admin
You definately can develop software with a text editor and a compiler. And depending on what language you choose, you might not even need the compiler.
JIRA isn't about developing software, JIRA is about managing team's workflows. You can apply it to building software but you can also apply it to building houses, organising a large bakery or transactional legal processes. And unfortunately it can be applied very, very badly. :(
Admin
Jira has its issues, but if you'd "put Jira as one of the not goodest of all", you clearly don't have much experience of some of the alternatives... we used to use ClearQuest years ago (along with ClearCase for source control), and that was an abomination. And that was still better than some of the in-house solutions I've seen.
Really, the main problem with Jira is that they kept adding features long after they'd run out of useful features to add. They had a good product once, but it got lost among all the new stuff that's been added, and all constant UI changes.
Admin
Call me old fashioned but I prefer my ticketing systems dumb. A ticketing system should have as few options as possible. Just give me the ability to write text on a piece of digital sticky note and a board to hang it up on.
Admin
While it's fun to dump on Jira (and it deserves quite a bit of it), I'm more interested in exploring better options. Does the collective here know of better (even if it isn't quite good) options? Ideally, something that can be run on your own server without having monthly charges per user?
Admin
You absolutely can develop software with a text editor and a compiler. This is how I did it at University. Admittedly, I developed only small projects at University quite slowly and I wouldn't dream of not using at least a source code control system now, for even the simplest of projects.
Jira is perfectly fine as long as you use one of the simple built in models. I use it all the time for my personal projects and it's fine. The last big commercial project I used it on had a fairly simple out of the box Kanban board. It was perfectly adequate.
I think people make the mistake of thinking Jira should be used to enforce their processes, not just track them. That's what managers are for.
Admin
Honestly I don't think it matters. Jira is kind of like windows or git in that respect. It's the standard that everyone uses. Even if there was a thousand other pieces of software that were infinitely better they just would not be relevant because the odds of finding them in an actual workplace are zero.
Admin
I did support Lotus cc:Mail which was run in parallel to Lotus Notes in 1995. Once we switched from Windows 3.1 to Windows NT4, cc:Mail had gone and everybody had migrated to Notes. Luckily at that time I had left my first level support job and had gone back to proper engineering :-)
Admin
Mixing Dutch and English is very common in the Netherlands, especially when it comes to computer technology. It doesn't help, but for Dutch people it probably won't hinder, either.