Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Death to JIRA

techcrunch.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Death to JIRA

#11

Post by fiftyacorn »

crazygringo wrote: post #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 s…

Its a recent trend to skip the documentation and have a sparsely documented JIRA in the belief it encourages agile development. I just groan when i see it

Re: Death to JIRA

#12

Post by alkonaut »

Every large scale software system needs a ticket system if some kind. You might separate the backlog from the bug reports, or omit one part, but you'll have something.

You can't find the reason for a change otherwise, you can't find all the related changes for the feature, you can't catalog incoming bugs and answer whether the last bug report must be tackled or has already been fixed and so on.

This is why - like it or not - there always is an issue management system. It's on a server somewhere, or in an excel sheet, or emails, or on a piece of paper. But it's there.

The usual criticism of Jira is that it's heavyweight compared to e.g GitHubs issue tracker, or whatever post-it moving system is the latest fad.

A fair criticism of Jira is that it makes it too easy for management to encode and expand the formal rules for e.g task workflows, and that these rules invariably end up being too rigid.

An organization should have the least invasive workflow it can, but it should encode and enforce the workflow.

In the end, just like you always have an issue management system, you also have a change workflow. Either it's encoded formally using an issue/PR system or it's ad-hoc via chat and email (which scales very well up to around 2 developers but shows it's weaknesses already at around 3)

Re: Death to JIRA

#13

Post by goalieca »

crazygringo wrote: post #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 s…

A lot of agile shops seem to be doing this.

Re: Death to JIRA

#14

Post by tetraodonpuffer »

fiftyacorn wrote: post #11
crazygringo wrote: post #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 s…

Its a recent trend to skip the documentation and have a sparsely documented JIRA in the belief it encourages agile development. I just groan when i see it

there is also the "let's define everything by user stories" way of doing things (as if having a bunch of stories in whatever agile tool is better than a proper functional spec / design spec)

Re: Death to JIRA

#15

Post by metamicah »

YMMV but one method I like to mitigate the issue the article talks about is keeping documentation in source control, and requiring a change to documentation (or explanation why there should be no documentation change) in association with the resolution of a JIRA ticket.

Re: Death to JIRA

#16

Post by prodigal_erik »

alkonaut wrote: post #12

Every large scale software system needs a ticket system if some kind. You might separate the backlog from the bug reports, or omit one part, but you'll have something . You can't find the reason for a change otherwise, you can't find all the related changes for the feature, you can't catalog incoming bugs and answer whether the last bug report must be tackled or has already been fixed and so on. This is why - like it…

That's the main failure mode I've seen. An over-engineered and role-limited workflow in which the real-life state of the project is considered invalid or nobody is authorized to express it.

Re: Death to JIRA

#18

Post by LKAndrew »

The author clearly doesn't have the experience in agile development necessary to be commenting on this. As a software engineer turned scrum master, I can say that my company is a well oiled machine using JIRA and agile methodologies perfectly well. My engineers don't have these complaints. Clearly he's doing it wrong.

Re: Death to JIRA

#19

Post by kaspiCZ »

firewalkwithme wrote: post #8

JIRA 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

In case it might help you:

For projects where there's possibly only a dev or two and the project/client, we had success with producteev. It's much less complicated than e.g. JIRA.

If you set up rules for tags and priorities you can manage delivery quite well with it.

Highest priority is reserved for blockers.

Sample of our tags: affects customer, bug, feature, change, production, technical debt

Re: Death to JIRA

#20

Post by Suresh_MacApp »

Hackers, Very Well written article, we have been facing this pain point and we went on to create a wonderful system which handles everything for a project in a simple intutive way. I have shared the screenshot here for the hackers. Lot of positive feedback, looking forward to hear your sincere comments and take it forward.

https://pbs.twimg.com/media/CzeajADUUAE87oa.jpg

Post reply on HN