Death to JIRA
techcrunch.com
Death to JIRA
1–10 of 20 posts
Re: Death to JIRA
#2> I promised a better way... a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets.
I'm mystified... everywhere I've ever worked used design documents to some extent -- not for simple features, but more for things that are truly "complicated systems" with nuances.
Are there really places that attempt to do project design solely with tickets? I almost can't believe it.
(Although in terms of effort estimation, breaking the design doc down afterwards into tickets, and then estimating those individually, is a very useful exercise -- a design doc describes the outcome, the tickets describe how to get there, which is what you're really estimating.)
Re: Death to JIRA
#3tl;dr Blame the tools.
Re: Death to JIRA
#4It seems like most organizations that use JIRA start off with good intentions, but it eventually devolves into a huge mess that users dread. Maybe it's because the system tries to do too much or, more likely, it's a user problem and orgs demand more and more features. Whatever the cause, it's leading to a death by 1000 cuts.
Re: Death to JIRA
#5For me, JIRA is addressing a fundamentally difficult problem: how to separate work on a monolith between several people. At some point the separation into tickets, tasks, requirements or whatever one wants to call them is necessary.
Re: Death to JIRA
#6For me, JIRA is addressing a fundamentally difficult problem: how to separate work on a monolith between several people. At some point the separation into tickets, tasks, requirements or whatever one wants to call them is necessary.
Re: Death to JIRA
#7> And so JIRA ticketing subtly but powerfully tends to push developers to work on one ticket at a time, instead, which is often both less efficient and more prone to drastic late-in-the-game failure.
Technical debt is measured in net present value.
As a QA engineer myself, it is more valuable to explicitly account for when and why a given software change is made then it is to rush things out, because when a later change inevitably breaks an older one, the engineer can immediately know when and why it happened, and what to fix.
Relying solely on design documents means that if something goes wrong in a sufficiently complex system, it can take a very long time to isolate and fix the issue. (no, TDD does not alleviate this)
Re: Death to JIRA
#8JIRA is a fantastic tool if management know how to use it, and how to limit themselves. Having used 2 other horrible alternatives I really miss JIRA
Re: Death to JIRA
#9> I promised a better way... a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets. I'm mystified... everywhere I've ever worked used design documents to some extent -- not for simple features, but more for things that are truly "complicated systems" with nuances. Are there really places that attempt to do project design s…
Atlassian themselves even has a tool for this: Confluence. Then then integrate with JIRA for individual tickets. https://confluence.atlassian.com/doc/develop-technical-docum...
Re: Death to JIRA
#10From the article:
> I stress that it’s not specifically JIRA itself which is guilty of this. All of the above is implicit in the notion of reducing software architecture and development to a set of “tickets.” JIRA’s great sin is only that of being the most successful and widespread ticketing system. The notion of specifying a software project with a set of tickets is itself the enemy.
Hope that saves ppl from this terrible clickbait