- 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
"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.
Edit 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.
Edit 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.
Edit 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/
Edit Admin
I only dispise Jira because it's slow and unreliable, and every month some basic element changes its UI for no good reason.
Edit 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.
Edit 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.