Quello che non si vuole sentire è che queste situazioni di solito vengono gestite non consentendo loro di crescere così in grande. Ma temo che sia così.
I programmatori pragmatici ci consigliano Don't live with broken windows. Il punto è che se lasciamo qualcosa di rotto invece di sistemarlo, resteranno altre cose e prima che ce ne rendiamo conto abbiamo 480 elementi nella nostra lista TODO. Inoltre, c'è il pericolo che parte della nostra applicazione si baserà sul comportamento "rotto", quindi quando indirizziamo l'articolo TODO abbiamo anche la correzione del.
Non tutti possono essere all'altezza degli elevati standard dei programmatori Pragmatic.Un approccio alternativo consiste nell'avere un elenco di cose su cui è necessario lavorare (talvolta noto come Kaizen list). Le persone che sono bloccate sul lavoro assegnato possono prendere una di quelle attività.
Per quanto riguarda la vostra situazione attuale ....
Ho una regola empirica in cui si afferma che nulla può essere fatto in meno di mezza giornata: non una volta si include il controllo di origine, la documentazione, discutendo la cambiare con Bob, ecc. Naturalmente, la mia regola empirica non si applica a compiti veramente banali, ma se questi compiti fossero veramente banali essi sarebbero stati sistemati sul posto, non contrassegnati come TODO, giusto?
Quindi stai guardando il barile di 240 giorni di sforzi. Se molte di queste attività possono essere combinate in un'unica correzione, è possibile ridurre l'overhead per attività. Ma prima hai un pezzo di lavoro solo per vagliare i compiti, categorizzarli e dare priorità a loro. Questo è il motivo per cui lo chiamiamo "debito tecnico": più a lungo lo lasciamo e più costa riparare, e ha il tasso di interesse composto del prestito a domicilio medio.
A meno che non si dispone di una comprensione molto responsabile del progetto/cliente pagante penso che si dovrà accettare il fatto che non si ha intenzione di essere in grado di cancellare tutti questi elementi. Quindi è necessario una breve triaging esercizio: assegnare ogni TODO in una delle tre categorie:
- Roba che è intollerabile e deve essere risolto in questo momento
- Roba che dovrebbe essere fissato come e quando c'è un'opportunità
- roba che si sta solo andando ad avere vivere con
Buona fortuna!
Grazie per informazioni dettagliate. In effetti mi sono piaciute seguirne alcune !! – GustyWind
Questo non risolve veramente la domanda, è un buon consiglio ma non è davvero una risposta. Sono venuto qui in cerca di evidenziazione dell'attività perché sto usando REFATTORE: tag per tenere traccia del codice che sto commentando o cambiando che deve essere ripulito prima della fine dello sprint corrente (non più di 2 settimane) quindi sto marcando 'finestre rotte'. Una cosa così flessibile come l'evidenziazione dei tag task non impone necessariamente cattive pratiche. –
@AdamTolley - una bandiera TODO o REFATTORE è un'ammissione di debito tecnico, una cambiale di pagamento per lavori futuri. Non è automaticamente una cattiva pratica, a condizione che li risolviamo più o meno immediatamente. Diventa una cattiva pratica quando rimandiamo la compensazione a favore di altri problemi più urgenti. Questa sembra essere la situazione in cui si trovava l'OP. YMMV – APC