|
What a great comment!
The whole, every change needs a ticket debate is interesting but without context. Some orgs require it and you can just create a ticket and move on. Fundamentally I don't view these tickets as useful, if asked "tell me the latest state of X", or "why was Y done", the tickets rarely help (and if they do, the proper places of commit history or the code itself skimp on these) The tickets can often go on to be "for the devs we like and trust, they can cut tickets", but for the others we require they're prioritized. This creates a lot of chafing, that quick bug fix, is it worth context switching now to create a ticket, again later to explain it to the non-technical prioritizer of tickets, worth the argument of why a "business goal" should be deferred to prioritize this ticket, the tracking overhead to finally say you are selecting ticket X, and that final context switch to actually work on it? All that compared to just fixing it, switching branch and cutting a pull request a minute later I found I liked tickets to identify product work, so maybe 5% of my commits actually reference tickets, the rest are supporting changes that enabled that 5% to be done cleanly or are just things that should be fixed or cleaned.
Coming back to it, tickets have their uses: documentation, discussion, prioritizing. But tickets can quickly turn into "this is how we keep our engineers from cleaning up the code, etc", "this is how we do programming by remote and control exactly what is worked on." Worst, it is the self inflicted burning the midnight oil, "hey, you said this was going to take a week, estimation is a skill of a senior engineer - will this be done as promised, or is your ability to estimate not there yet? Wink, the sprint is over on Monday.." |