• atheken@programming.dev
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    1 year ago

    We used JIRA effectively at my last job, the things that made it work for us:

    • stop adding shitloads of required fields. Title, description, branch, priority (defaulted), status (defaulted), type (bug/feature). We might have had some others, but that was all I remember being required.
    • stop writing shitty descriptions: spend more time writing something that your co-worker can use. Respect their time enough to try to include enough detail for them to actually use the ticket. Be available to answer questions when they are assigned a ticket you wrote.
    • you don’t need extremely granular statuses: the functional role of the assignee is enough to determine what “state” it’s in, trying to codify a unidirectional flow of tickets is maddening and overly complicated. Work is messy, it flows back and forth, you do not need a “rejected by qa” status. Just leave it open and reassign to the developer with a comment. Managers find out when individuals are submitting half-assed work on a regular basis, you don’t need JIRA for that (unless you need metrics to fire them… different problem).

    I agree with the premise of the article, JIRA is a communication tool, not a management tool.