Gestione del lavoro "correlato" all'interno di un singolo oggetto di lavoro agile

10

Sono in un team di progetto di 4 sviluppatori, incluso me stesso. Abbiamo avuto una lunga discussione su come gestire il lavoro extra che si presenta nel corso di un singolo elemento di lavoro.

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

  • refactoring del codice modificato dall'elemento di lavoro
  • codice di refactoring adiacente al codice modificato dall'elemento
  • re-architecting l'area di codice più grande intorno al biglietto. Ad esempio se un articolo ha cambiato una singola funzione, ti rendi conto che ora l'intera classe potrebbe essere rifatta per meglio adattarla a questo cambiamento.
  • miglioramento dell'interfaccia utente in un modulo che hai appena modificato

Quando questo lavoro extra è piccolo, non importa. Il problema è quando questo lavoro extra causa un'estensione sostanziale dell'elemento oltre la stima del punto caratteristica originale. A volte un elemento di 5 punti richiede effettivamente 13 punti di tempo. In un caso abbiamo avuto un elemento di 13 punti che in retrospettiva avrebbe potuto essere 80 punti o più.

Nella nostra discussione ci sono due opzioni su come gestirlo.

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

    • Prevediamo "padding" alla fine dello sprint per tenere conto di questo genere di cose.
    • Lascia sempre il codice in una forma migliore di come l'hai trovato. Non effettuare il check-in di lavoro a metà assaggiato.
    • Se lasciamo il refactoring per dopo, è difficile programmare e potrebbe non essere mai eseguito.
    • Sei nel miglior "contesto" mentale per gestire questo lavoro ora, dato che sei già nel profondo del codice. Meglio togliersi di mezzo ora ed essere più efficiente di perdere quel contesto quando torni più tardi.
  2. Disegniamo una linea per l'oggetto di lavoro corrente e diciamo che il lavoro aggiuntivo 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 siano realmente le cose, o dover ammettere che tutte le nostre stime sono terribili.
    • Lo sprint "padding" è pensato per sfide tecniche impreviste che sono ostacoli diretti al completamento dei requisiti del ticket. Non è inteso per gli elementi laterali che sono solo "simpatici".
    • Se vuoi programmare il refactoring, basta metterlo in cima al backlog.
    • Non c'è modo per noi di rendere correttamente conto di queste cose in una stima, dal momento che sembra alquanto arbitrario quando si presenta. Un revisore del codice potrebbe dire "quei controlli dell'interfaccia utente (che in realtà non sono stati modificati in questo elemento di lavoro) sono un po 'confusi, puoi aggiustarlo anche tu?" che è come un'ora, ma potrebbero dire "Bene se questo controllo ora eredita dalla stessa classe base degli altri, perché non spostate tutto questo (centinaia di linee di) codice nella base e ricollegate tutte queste cose , i cambiamenti a cascata, ecc? " E ciò richiede una settimana.
    • "Contamina la scena del crimine" aggiungendo lavoro non correlato nel ticket, rendendo inutili le nostre stime di punti originali.
    • In alcuni casi, il lavoro extra posticipa il check-in, causando il blocco tra gli sviluppatori.

Alcuni di noi ora stanno dicendo che dovremmo decidere un po 'di interruzione, come se il materiale aggiuntivo fosse inferiore a 2 FP, va nello stesso biglietto, se è di più, crea un nuovo ticket.

Poiché impieghiamo solo pochi mesi per utilizzare Agile, qual è l'opinione di tutti i veterani Agile più esperti qui intorno su come gestirlo?

    
posta Tesserex 27.03.2012 - 20:23
fonte

4 risposte

5

La pianificazione e le user story agili sono incentrate sulla fornitura di 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 declassare l'importanza delle buone linee guida architettoniche, della gestione della progettazione, delle buone pratiche di sviluppo e del mantenimento del debito tecnico.

Agile non fa bene quest'ultimo perché non era inteso come una risposta a questi problemi e problemi per lo più tecnici.

Sapendo che non sono d'accordo sul fatto che le attività di refactoring, la gestione tecnica del debito e il lavoro di progettazione dovrebbero tenere conto di storie utente separate in uno sprint specifico. Questi sono solo compiti che uno sviluppatore potrebbe intraprendere per contribuire a soddisfare la user story per lo sprint.

Ricorda che un'attività è una qualsiasi unità di lavoro assegnabile che aiuta a portare a termine una determinata user story all'interno delle linee guida architetturali e a mantenere le buone pratiche di progettazione e sviluppo del software nel suo complesso.

Ecco perché la stima delle ore dovrebbe essere su attività e non su user story. Questo è anche il motivo per cui alcune attività sono fondamentali per il completamento di più storie di utenti.

    
risposta data 27.03.2012 - 21:48
fonte
3

Rosso, Verde, Refactor. Questo è lo scopo di un singolo oggetto di lavoro. Scrivere una suite di test in errore che copra lo scopo del cambiamento, codificare l'importo minimo richiesto per superare il test, quindi eseguire il refactoring per soddisfare gli standard di codifica durante il superamento dei test. Sono necessari tutti e tre questi passaggi; non puoi codificare la soluzione finché non hai definito il problema, se ti rifatti mentre scrivi la riga di codice invariabilmente violi YAGNI, ma se non entri dietro a te e refactor dopo aver superato i test, per definizione incorrerai in un debito tecnico che alla fine dovrai ripagare.

Data questa definizione, e che è stata seguita, un 5-pointer che risulta essere un 13-pointer era una stima errata. Quello che prenderebbe in considerazione il lavoro di refactoring era probabilmente più simile alla ristrutturazione; bisognava riorganizzare un'area piuttosto significativa del codebase in modo che la nuova funzionalità fosse inclusa in un modo comprensibile e gestibile. Questo di solito indica un fallimento del team nel comprendere il percorso futuro generale di sviluppo, portando a qualcosa che è stato implementato molto semplicemente in una precedente iterazione quando alla fine sarebbe stato necessario essere molto SOLIDO. Una migliore comunicazione tra BA e PM, che sanno cosa c'è di più in basso nel backlog, e il team di sviluppo che sono generalmente concentrati sullo sprint attuale, possono mitigarlo. In alternativa, questa storia ha esposto una grande quantità di debiti tecnici sostenuti in precedenti sviluppi, e ha semplicemente raggiunto il team. 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 occorrenze.

Una cosa da tenere a mente è che il refactoring è un lavoro "non ideale". In Agile SCRUM, le attività sono stimate in "ore ideali"; cioè, il numero di ore trascorse a testa in giù scrivendo un codice nuovo di zecca che non è mai esistito e promuove la funzione base del progetto. Un giorno 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 la squadra canticchia davvero. Refactoring, o tornare indietro e apportare modifiche che non influiscono sulla funzionalità del progetto ma che migliorano il codebase in altri modi, è un lavoro non ideale, come la pianificazione, la progettazione, la comunicazione, la revisione, le interruzioni o il downtime tecnico. Oltre al downtime tecnico, il lavoro non ideale è importante, ma non fa progressi agli occhi del proprietario del prodotto.

Quindi, a condizione che il refactoring non raddoppi le ore effettivamente spese, ci si può aspettare una certa quantità di lavori di refactoring quando si stimano le ore ideali. Diciamo, perché non so esattamente come è calibrata la scala dei punti del tuo team, che un 5-pointer è equivalente a una settimana di sviluppo ideale, o circa 25 ore ideali. Quel 5, che è diventato un 13 (più di due settimane di sviluppo dalla stessa scala), è causa di una certa retrospezione su ciò che ha causato la complessità di balloon. Forse il codebase non aveva bisogno di tanto refactoring come era stato fatto, forse una grande quantità di debito tecnico si era accumulata all'insaputa della squadra che doveva essere risolta per far funzionare le nuove funzionalità, o forse si trattava di un'onesta stima sbagliata della quantità di nuovo lavoro richiesto (forse il team pensava che estendere una parte esistente del dominio sarebbe stato sufficiente, quando in realtà erano necessarie diverse nuove classi di dominio e le relative modifiche dello schema).

In un universo alternativo, immaginiamo che un 5 come stimato in ore ideali diventi un 7 (~ 35 ore) in base alle ore effettive, perché hai bisogno di 10 ore di ulteriore refactoring per inserire il nuovo codice e alcuni bit precedenti in un architettura di design opportunamente modellata. In tal caso, l'extra si trova all'interno del "gap" tra ore ideali e totali durante il numero di giorni di sviluppo che la storia avrebbe dovuto prendere. Quindi, come project manager, chiamerei un 5 che diventava un 7 una stima ragionevole e andare avanti.

    
risposta data 27.03.2012 - 22:03
fonte
1

I punti storia sono una stima della relativa complessità di una determinata user story. Sembra che tu stia usando i punti storia per dire che ci vorranno X giorni uomo / ore. Invece, cerca due obiettivi

  1. Analizza le storie finché non 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 linea di base per la velocità. Ogni storia a 5 punti non impiega lo stesso tempo degli altri, ma la velocità media per sprint (quanti punti della storia il team può completare) sarà coerente.

Preoccuparsi di quanto tempo impiegherà una determinata storia è controproducente. Le stime effettuano solo la media su storie di dimensioni coerenti in termini di volume (un puntatore 1 EE potrebbe richiedere un po 'più di tempo a causa del refactoring ma si raccolgono i benefici di tale sforzo su uno correlato).

    
risposta data 27.03.2012 - 22:23
fonte
0

Ci dovrebbe essere un limite relativo di quanto è all'interno dell'elemento di lavoro originale e quanto è qualcos'altro. Le storie degli utenti sono punti di partenza per discussioni e quindi ci possono essere tutti i tipi di elementi di ambito da inchiodare durante uno sprint mentre si lavora su una storia.

Ci possono essere momenti in cui in uno sprint la pianificazione di una storia può aggiungere ulteriori criteri ad essa aggiunti nel tentativo di evitare "scope creep" che può accadere dove un utente vuole un nuovo form e quindi 101 cambia in quella forma che non è t realistico da fare in 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 refactoring che potrebbero essere fatti, ma quanti benefici ci sono per chiunque per tutto quel lavoro? Questo è dove ci devono essere alcune linee guida per aiutare a far funzionare bene la squadra, ma non perdersi nel tentativo di rendere il codice perfetto.

    
risposta data 27.03.2012 - 23:10
fonte

Leggi altre domande sui tag