Gestire il lavoro "correlato" all'interno di un singolo oggetto di lavoro agile

Faccio parte di un team di progetto composto da 4 sviluppatori, me compreso. Abbiamo discusso a lungo su come gestire il lavoro extra che si presenta nel corso di un singolo oggetto di lavoro.

Questo lavoro extra di solito è qualcosa che è leggermente correlato all'attività, ma non è sempre necessario per raggiungere l'obiettivo dell'oggetto (che può essere un'opinione). Gli esempi includono ma non sono limitati a:

• refactoring del codice modificato dall'elemento di lavoro
• codice di refactoring vicino al codice modificato dall'elemento
• riprogettare l'area di codice più ampia attorno al ticket. Ad esempio, se un elemento ti sta modificando una singola funzione, ti rendi conto che l'intera classe ora potrebbe essere rifatta per adattarsi meglio a questa modifica.
• migliorare l'interfaccia utente su un modulo appena modificato

Quando questo lavoro extra è piccolo non ci dispiace. Il problema è quando questo lavoro extra provoca un'estensione sostanziale dell'articolo oltre la stima del punto di funzionalità originale. A volte un oggetto a 5 punti impiegherà effettivamente 13 punti di tempo. In un caso avevamo un oggetto di 13 punti che in retrospettiva avrebbe potuto essere di 80 punti o più.

Ci sono due opzioni in giro nella nostra discussione su come gestirlo.

1. Possiamo accettare il lavoro extra nello stesso oggetto di lavoro e scriverlo come una stima errata. Gli argomenti per questo hanno incluso:

   • Abbiamo in programma "imbottitura" alla fine dello sprint per tenere conto di questo genere di cose.
   • Lascia sempre il codice in una forma migliore di quello che hai trovato. Non fare il check in a metà lavoro.
   • Se lasciamo il refactoring per dopo, è difficile da pianificare e potrebbe non essere mai fatto.
   • Sei nel miglior "contesto" mentale per gestire questo lavoro adesso, poiché sei già nel profondo del codice. Meglio toglierlo di mezzo ora ed essere più efficienti che perdere quel contesto quando torni più tardi.

2. Tracciamo una linea per l'oggetto di lavoro corrente e diciamo che il lavoro extra va in un biglietto separato. Gli argomenti includono:

   • Avere un biglietto separato consente una nuova stima, quindi non stiamo mentendo a noi stessi su quanti punti sono realmente le cose, o dobbiamo ammettere che tutte le nostre stime sono terribili.
   • La "imbottitura" sprint è pensata per sfide tecniche inaspettate che sono barriere dirette al completamento dei requisiti del biglietto. Non è destinato agli oggetti secondari che sono solo "simpatici".
   • Se si desidera pianificare il refactoring, basta inserirlo nella parte superiore del backlog.
   • Non c'è modo per noi di spiegare correttamente queste cose in una stima, dal momento che sembra un po 'arbitrario quando si presenta. Un revisore del codice potrebbe dire "quei controlli dell'interfaccia utente (che in realtà non hai modificato in questo oggetto di lavoro) sono un po 'confusi, puoi risolvere anche questo?" che è come un'ora, ma potrebbero dire "Bene, se questo controllo ora eredita dalla stessa classe base degli altri, perché non spostare tutto questo (centinaia di righe di) codice nella base e ricablare tutta questa roba , i cambiamenti a cascata, ecc.? " E ci vuole una settimana.
   • "Contamina la scena del crimine" aggiungendo lavoro non correlato al ticket, rendendo insignificanti le stime dei nostri punti di funzionalità originali.
   • In alcuni casi, il lavoro extra rimanda un check-in, causando il blocco tra gli sviluppatori.

Alcuni di noi stanno ora dicendo che dovremmo decidere di tagliarli, come se la roba aggiuntiva sia inferiore a 2 FP, va nello stesso biglietto, se è di più, lo rende un nuovo biglietto.

Dato che impieghiamo solo pochi mesi ad usare Agile, qual è l'opinione di tutti i veterani Agile più esperti qui su come gestirlo?

La pianificazione agile e le storie degli utenti sono focalizzate sul fornire valore e trasparenza agli stakeholder del progetto e agli utenti del software. Questa è una buona cosa, ma non deve e non deve sostituire, includere o sminuire l'importanza di buone linee guida architettoniche, gestione del design, buone pratiche di sviluppo e mantenimento del debito tecnico.

Agile non fa bene quest'ultimo perché non è stato inteso come una risposta a questi problemi e problemi principalmente tecnici.

Sapendo che non sono assolutamente d'accordo sul fatto che le attività di refactoring, la gestione tecnica del debito e il lavoro di progettazione debbano tenere conto di storie utente separate in un dato sprint. Questi sono semplicemente compiti che uno sviluppatore potrebbe intraprendere per aiutare a soddisfare la user story per quello sprint.

Ricorda che un'attività è qualsiasi unità di lavoro assegnabile che aiuta a portare una data storia utente al completamento all'interno delle linee guida sull'architettura e a mantenere le buone pratiche di progettazione e sviluppo del software nel suo insieme.

Questo è il motivo per cui la stima delle ore dovrebbe riguardare le attività e non le storie degli utenti. Questo è anche il motivo per cui alcune attività sono fondamentali per il completamento di più user story.

Rosso, verde, refattore. Questo è lo scopo di un singolo oggetto di lavoro. Scrivi una suite di test non riuscita che copre l'ambito del cambiamento, codifica la quantità minima richiesta per superare il test, quindi esegui il refactoring per soddisfare gli standard di codifica pur superando i test. Sono richiesti tutti e tre questi passaggi; non puoi codificare la soluzione fino a quando non hai definito il problema, se rifletti mentre scrivi la riga di codice, invariabilmente violerai YAGNI, ma se non entri dietro te stesso e rifletti dopo aver superato i test, per definizione incorri in un debito tecnico che dovrai eventualmente rimborsare.

Data questa definizione, e che è stata seguita, un 5-pointer che risulta essere un 13-pointer era una stima errata. Quello che considereresti il ​​lavoro di refactoring era probabilmente più simile alla ristrutturazione; hai dovuto riorganizzare un'area abbastanza significativa della base di codice per includere le nuove funzionalità in modo comprensibile e mantenibile. Ciò di solito indica che il team non è in grado di comprendere il futuro percorso di sviluppo generale, portando a qualcosa di implementato in modo molto semplice in una precedente iterazione, quando alla fine sarebbe necessario essere molto SOLIDO. Una migliore comunicazione tra BA e PM, che sanno cosa c'è di più arretrato nel backlog, e il team di sviluppo che sono generalmente concentrati sullo sprint corrente, possono mitigare questo. In alternativa, questa storia ha rivelato una grande quantità di debito tecnico dovuto allo sviluppo passato, e ha semplicemente raggiunto la squadra. Migliori processi di revisione del codice, oltre a una migliore conoscenza concettuale dei modelli di progettazione e del percorso generale futuro del progetto, possono aiutare a ridurre tali eventi.

Una cosa da tenere a mente è che il refactoring è un lavoro "non ideale". In Agile SCRUM, le attività sono stimate in "ore ideali"; vale a dire, il numero di ore trascorse a testa in giù nella scrittura di un codice nuovo di zecca che non è mai esistito e favorisce la base delle caratteristiche del progetto. Una giornata di sviluppo di 8 ore potrebbe realisticamente avere solo 5 ore ideali; a volte puoi contare su 6, specialmente nel "tratto" di un progetto in cui il team sta davvero canticchiando. Rifattorizzare o tornare indietro e apportare modifiche che non influiscono sulla funzionalità del progetto ma che migliorano la base di codice in altri modi, è un lavoro non ideale, come pianificazione, progettazione, comunicazione, revisione, interruzioni o tempi di inattività tecnici. Oltre ai tempi di fermo tecnici, un lavoro non ideale è importante, ma non fa progressi agli occhi del proprietario del prodotto.

Pertanto, a condizione che il refactoring non raddoppi le ore effettive impiegate, è necessario prevedere una certa quantità di lavoro di refactoring quando si stima nelle ore ideali. Diciamo, perché non so esattamente come è calibrata la scala dei punti del tuo team, che un 5 puntatore equivale a una settimana di sviluppo ideale, o circa 25 ore ideali. Quel 5, che si è trasformato in 13 (più di due settimane di sviluppo con la stessa scala), è causa di alcune retrospezioni su ciò che ha causato il palloncino della complessità. Forse la base di codice non aveva bisogno del refactoring tanto quanto era stato effettivamente fatto, forse una grande quantità di debito tecnico si era accumulata all'insaputa del team che doveva essere risolto per far funzionare le nuove funzionalità,

In un universo alternativo, immaginiamo che un 5, stimato nelle ore ideali, diventasse un 7 (~ 35 ore) basato sulle ore effettive, perché erano necessarie 10 ore di refactoring aggiuntivo per inserire il nuovo codice e alcuni bit precedenti in un modello corretto architettura di design. In tal caso, il supplemento si trova nel "divario" tra le ore ideali e quelle totali durante il numero di giorni di sviluppo che la storia avrebbe dovuto prendere. Quindi, come project manager, chiamerei un 5 che è diventato un 7 una stima ragionevole e andiamo avanti.

I punti storia sono una stima della complessità relativa di una determinata storia utente. Sembra che tu stia usando i punti della storia per dire che ci vorranno X man giorni / ore. Cerca invece di raggiungere due obiettivi

1. Analizza le storie fino a quando si trovano in un intervallo coerente (3, 5 o 8 punti)
2. Supponiamo che la storia includa qualsiasi refactoring necessario

Nel tempo questo ti darà una base per la velocità. Ogni storia a 5 punti non richiederà lo stesso tempo degli altri, ma la velocità media per sprint (quanti punti trama la squadra può completare) sarà coerente.

Preoccuparsi di quanto tempo impiegherà una storia specifica è controproducente. Le stime si basano solo su storie di dimensioni coerenti in volume (IE un puntatore 5 potrebbe richiedere un po 'più di tempo a causa del refactoring, ma raccogli i benefici di quello sforzo su uno correlato).

Dovrebbe esserci un taglio relativo di quanto è presente nell'elemento di lavoro originale e di quanto altro. Le storie degli utenti sono punti di partenza per le discussioni e quindi potrebbero esserci tutti i tipi di elementi di ambito da inchiodare durante uno sprint mentre si lavora su una storia.

Ci possono essere momenti in cui nella pianificazione di uno sprint una storia può ottenere criteri aggiuntivi aggiunti ad essa nel tentativo di evitare "creep scope" che può accadere in cui un utente desidera un nuovo modulo e quindi 101 modifiche a quel modulo che non è realistico per fare uno sprint di 2 settimane a volte.

Un rovescio della medaglia da tenere a mente è quanto valore si sta guadagnando da questo lavoro extra. Potrebbero esserci tonnellate di possibili rifatturazioni che potrebbero essere fatte, ma quanti benefici c'è per chiunque per tutto quel lavoro? È qui che ci devono essere alcune linee guida per aiutare il team a lavorare bene ma non perdersi nel tentativo di rendere perfetto il codice.