Poiché i team SCRUM sono auto-organizzati, sono liberi di scegliere come implementare le attività.
Tuttavia, non c'è il rischio che i team finiscano per decidere di eseguire, ad esempio, una completa riscrittura (anziché un costante refactoring) ogni pochi anni solo perché esiste un nuovo quadro di fantasia che fa le cose in modo leggermente più efficiente , ignorando la prospettiva economica generale?
Se sì, come può essere risolto questo problema in SCRUM?
Il punto di vista economico è in linea di principio sulle spalle di Product Owner (PO) , chi è interessato a massimizzare il valore che viene consegnato, ed è esperto di business . Lo fa predisponendo gli articoli del backlog del prodotto.
Il Team di sviluppo si impegna a fornire software di lavoro e implementare gli elementi del backlog del prodotto negoziati nelle riunioni di pianificazione sprint. Se ciò richiede la riscrittura o il refactoring è una decisione tecnica che appartiene al team. Deve esserci fiducia nel fatto che il team stia facendo la scelta migliore, e non ci possono essere interferenze PO su decisioni tecniche senza il rischio di rompere una dinamica di squadra efficiente.
Ora, se il team decidesse di riscrivere le parti principali con la conseguenza di rallentare la pipeline di consegna per un periodo più lungo, sarebbe certamente non per motivi di fantasia. Potrebbe essere un investimento necessario . Tuttavia, poiché ciò avrebbe un impatto sulla frequenza di burndown e quindi sulla pianificazione dello sprint per un periodo più lungo, questo dovrebbe essere discusso e concordato con l'OP chiarendo la posta in gioco e dando prevedibilità.
Il uso controverso delle storie degli sviluppatori può aiutare a mantenere la visibilità su tali compiti tecnici , ma questi devono essere utilizzati nello sprint backlog e non devono polarizzare il backlog del prodotto, se non apportano valore aggiunto agli utenti.
Potrebbe anche essere che l'adozione di un nuovo framework potrebbe migliorare significativamente (o persino abilitare) storie di utenti esistenti, nel qual caso sarebbe importante anche per l'ordine di acquisto e apparirebbe indirettamente nel backlog del prodotto.
Attenzione : il pensiero che DT possa iniziare a diventare selvaggio e non sia impegnato nella consegna del prodotto comporta il rischio di rompere un trust fondamentale. Ciò potrebbe minare l'efficacia dell'approccio agile e nel peggiore dei casi evolvere in una profezia che si autoavvera (ad es. DT inizia a nascondere questi aspetti tecnici a PO temendo fraintendimenti e l'OP osserva solo una diminuzione misurabile inspiegabile delle prestazioni, creando dubbi e sospetti, che diminuisce la motivazione DT e aumenta il turnover, ecc.)
Questo è sciocco. Per ogni volta che una squadra è andata a riscrivere ogni pochi anni, ci sono letteralmente centinaia di team che sono bloccati in un pasticcio di Dio perché i proprietari dei prodotti richiedono funzionalità che riducono il debito tecnico.
How can this problem be solved?
Come con tutte le cose, il processo non può risolvere i problemi delle persone. E i problemi delle persone sono raramente risolti ...
Alla fine, i tuoi stakeholder tecnici e gli stakeholder aziendali devono effettivamente lavorare insieme per trovare un equilibrio adeguato per fornire il massimo valore al cliente a breve termine e a lungo termine.
Ma praticamente - non lo fai, perché non è un problema. Il problema prevalentemente più comune è la squadra che ha bisogno di fare una riscrittura, ma si sente come se non fosse possibile.
In pratica, questo non è vero. Il team Scrum, non può scrivere gli elementi del backlog e una riscrittura generalmente influisce molto di più sull'ambito di una singola attività.
In secondo luogo, le attività devono essere valutate. Ciò conferisce al Product Owner visibilità sull'impatto economico delle attività. Se il costo della funzione è troppo alto, non verrà inserito nello sprint.
In terzo luogo, ogni giorno il team ha una posizione in cui il Product Owner può partecipare e ascoltare. Presto tutti saranno a conoscenza della riscrittura e la interroga.
Detto questo, lo sviluppo guidato dal CV è una cosa. I proprietari dei prodotti devono essere a conoscenza di approcci alternativi per fornire funzionalità e la motivazione dei membri del team (ad es. Bonus) deve essere allineata con gli obiettivi dei datori di lavoro
Scrum richiede fiducia. Dovresti avere fiducia che i tuoi sviluppatori stiano facendo la cosa giusta.
Sono uno sviluppatore e sono stato a capo di un team alcune volte. Dal mio punto di vista, hai tre opzioni per mantenere un codebase:
Non pagare il debito tecnico è il modo più veloce per perdere buoni sviluppatori. Nessuno vuole passare sei ore a leggere la logica per fare un cambio di una riga. È uno spreco di tempo per tutti.
L'uso dei più recenti framework non riguarda solo la creazione di CV o nuove fantasiose funzionalità. Inoltre, stai rinnovando la finestra del fornitore e il supporto della community per i framework e gli strumenti che utilizzi.
Personalmente ritengo che le riscritture siano decisioni aziendali migliori perché consolidi il lavoro in un periodo di tempo più breve e richiede un numero inferiore di test di regressione.
Data la natura di Scrum, può sembrare che compiti semplici siano stimati molto più del necessario, ma ciò avverrà quando il team di sviluppo sta affrontando il debito tecnico. Dovresti farti l'abitudine.
Scrum funziona meglio quando le parti si fidano l'una dell'altra. Non è possibile chiedere al team di sviluppo di costruire il prodotto e quindi mettere in discussione il modo in cui lo costruiscono. I non sviluppatori spesso non si rendono conto di quanto velocemente un codebase si trasforma in un caos durante una frenesia di miglioramenti delle funzionalità.
Inutile dire che questo non dovrebbe accadere. Le storie per gli sprint dovrebbero essere preparate e selezionate per uno sprint imminente con l'aiuto del PO. Se la trama non ha una priorità sufficientemente alta, non sarebbe nemmeno sufficiente per iniziare.
Questo è tutto presupponendo che una storia sarebbe anche considerata piuttosto che essere respinta inavvertitamente. Sarebbe difficile creare una storia As a ... Voglio ... in modo che ... sia inquadrata dal punto di vista dell'utente quando non vi è alcun vantaggio se non che lo sviluppatore si sente caldo poiché stanno usando la tecnologia all'avanguardia, possono mettere il loro CV.
In definitiva, hai un fallimento del processo qui.
Leggi altre domande sui tag project-management scrum