Durante la revisione dello sprint, il proprietario del prodotto potrebbe dire che una determinata storia è incompleta o che il team stesso potrebbe non aver completato alcune attività impegnate.
In quali situazioni lasci il codice nella compilazione? Se il codice viene lasciato nella build, è una decisione consapevole presa durante la revisione? In altre parole, discuti di questo problema durante la revisione?
Esistono casi specifici in cui il codice deve essere rimosso?
Una funzionalità incompleta dovrebbe uscire. Ma se questo può essere fatto senza rimuovere il codice (flag di funzionalità, rimuovendo solo il cablaggio, ecc.) Allora va bene - preferibile, in effetti. Perché? Perché limita le modifiche a un prodotto che è già ampiamente testato.
Suggerirei che, se una storia è a rischio medio-alto, gli sviluppatori dovrebbero sempre codificare con la sua possibile rimozione e assicurarsi che l'attività sia il più sicura possibile.
Fai ciò che ha senso.
Se il codice non causerà alcun problema (diciamo che è una funzione che non può essere chiamata), e / o se hai intenzione di finire la storia dopo lo sprint, allora portarlo fuori è solo un po 'perdere tempo tirando per rimetterlo in posto.
Se, d'altra parte, il codice sta destabilizzando qualcos'altro, o è visibile all'utente in un modo che non funziona, o ha il potenziale per rompere le cose, e non si sta tornando alla storia subito, quindi rimuoverlo è probabilmente la cosa giusta da fare.
Se il codice che è già presente ha una copertura di test sufficiente (test unitari, ecc.), puoi mantenerlo così come sarà ancora testato. Se non hai molti test automatici in corso, dovresti probabilmente rimuoverlo quando il codice inutilizzato marcirà e lo stato di esso sarà conosciuto solo più tardi quando verrà nuovamente utilizzato. Il codice non utilizzato e non testato è principalmente rumore.
Il codice morto, codice che non viene usato, dovrebbe sempre essere rimosso a meno che non venga usato nel prossimo futuro.
Storie incomplete
Solo perché una storia è incompleta non significa che non ci sia valore nel far funzionare ciò che hai. Se non c'è alcun valore in esso, penso che si qualifica come codice morto.
Il codice per quella funzione non dovrebbe mai essere entrato nel codebase pronto per la release in primo luogo. Questo era abbastanza duro con il controllo della versione basato su server (es. SVN) se non fossi usando la ramificazione delle funzionalità. Oggigiorno con il controllo della versione distribuita (ad esempio Mercurial, git) è una cosa facile da fare.
Oltre agli strumenti, potrebbe essere necessario apportare modifiche al processo. Ad esempio, richiedendo che il codice venga esaminato prima di essere unito, assicurandosi che la revisione con il product manager avvenga abbastanza presto nell'iterazione, in modo che le cose incomplete possano essere corrette e testate.
La linea di fondo è che non puoi guadagnare valore su una storia parzialmente completata. Inoltre, se non è terminato, il cliente può cambiare rotta con la successiva iterazione, nel qual caso ora hai causato un gonfio con una funzione semilavorata.