Sono abituato a trattare l'issue tracker come fonte di verità e memoria organizzativa. Lo uso per registrare qual è il problema e cosa è stato fatto per risolverlo. Considero questo essenziale e fondamentale per una buona ingegneria del software (incluso lo sviluppo agile).
Sono disposto a considerare la possibilità che io abbia torto comunque.
Ora faccio parte di un team di sviluppo diviso su più siti nel mondo, non tutti parlano la stessa lingua (alcuni non condividono l'inglese come lingua comune e possono comunicare solo tramite il mio team leader). Per me questo rende ancora più importante l'uso del tracker dei problemi.
Tuttavia, l'altra squadra (nonostante le mie proteste) aggiunge regolarmente storie di utenti che sono solo una riga. Se sono abbastanza fortunato da avere una descrizione, è piuttosto conciso. Le storie sono in genere chiuse e accettate senza alcun commento aggiunto. A volte ci sono sotto-attività che hanno solo un titolo. Il capo squadra deve accettare i biglietti dopo che lo sviluppatore li ha chiusi (ed è quindi complice). Alcuni di questi sono piccoli problemi, ma altri sono enormi come "valutare i metodi di orchestrazione" che hanno portato all'uso di Kubernetes.
Non sono scoraggiato dall'usare il Ticket Tracker come voglio me stesso, ma non ho visibilità di ciò che fanno gli altri. Certo, non ho spesso bisogno di sapere se non sto lavorando su un problema correlato (il mio punto è un po 'che potrei aver bisogno in futuro). Sembra che preferiscano parlare faccia a faccia o per niente. Si dice che sia "agile". Il issue tracker è solo uno strumento interno non direttamente collegato a incentivi, perversione o altro.
Esiste un mondo o un processo sano in cui ciò ha senso? Una specie di carta ultra sottile, meno test, solo un numero sufficiente di codice, spuntare la casella e spedire il sistema che funziona davvero (o sembra funzionare dal punto di vista della gestione)?
Punti bonus per buoni suggerimenti su come ottenere gli sviluppatori e la gestione a bordo con un processo migliore.