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.
-
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.
-
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?