Refactoring nello sviluppo Agile
In un progetto di sviluppo di app, l'intero ambito del progetto non è stato considerato nella progettazione dell'app. Pertanto, il frequente refactoring dei codici per accogliere le modifiche ha un impatto negativo sulla tempistica di consegna del progetto, che si è resa necessaria durante uno sprint. Qual è il modo migliore per controllarlo per ridurre al minimo il rischio di superare la data concordata di consegna del progetto, dal momento che le parti interessate non sono disposte a scendere a compromessi?
Risposte
TL; DR
Parte di qualsiasi framework di gestione del progetto, ma soprattutto framework agili come Scrum, è la necessità di gestire continuamente le aspettative degli stakeholder. Le persone vogliono quello che vogliono quando lo vogliono, ma una parte importante della gestione del progetto sta spiegando alle persone cosa possono effettivamente avere all'interno dei vari vincoli che impattano sul progetto. Man mano che il progetto si evolve, così dovrebbe la comprensione di ciò che è attualmente fattibile entro i vincoli attuali, soprattutto quando ciò che è fattibile diverge da ciò che era stato originariamente pianificato.
È prevista una rilavorazione
Il refactoring modifica l'implementazione senza modificare il comportamento esterno. Con ogni probabilità, non stai realmente effettuando il refactoring; stai ripagando il debito tecnico o eseguendo rilavorazioni e integrazione, che non sono intrinsecamente le stesse cose.
Framework come Scrum trattano vari tipi di lavoro (inclusi refactoring e rilavorazione) come un compromesso accettabile per il controllo empirico e la progettazione. Questo viene gestito nel processo di stima e (correttamente) si presenta come un freno alla velocità con l'aumentare del debito tecnologico, della complessità o del ritmo del cambiamento. Questo è sia previsto che auspicabile in un framework iterativo, perché ogni ciclo di ispezione e adattamento offre un'opportunità per cambiare ambito, priorità o approccio.
La rilavorazione è il costo del controllo empirico. Non puoi davvero evitarlo in progetti complessi come lo sviluppo di software. Scrum rende visibile la rielaborazione al team e agli stakeholder come il costo per apportare modifiche necessarie o auspicabili.
Risolto: tutto non è possibile
Il "triangolo di ferro" postula che puoi adattare un progetto controllando il budget, l'ambito o la pianificazione, con la qualità una quarta dimensione implicita influenzata dagli altri tre cursori. Il grafico seguente lo illustra.
I framework agili come Scrum generalmente trattano l'ambito, e in particolare l' ambito del progetto , come il cursore principale chiedendo:
Quanto ambito possiamo inserire nel time box di un singolo Sprint o rientrare nel nostro piano di rilascio agile ?
Attualmente, il tuo progetto sta tentando di correggere sia l'ambito che la pianificazione. Ciò lascia solo il budget come dispositivo di scorrimento disponibile. Se tenti di bloccare anche questo, il tuo progetto fallirà o la qualità ne risentirà, o entrambe le cose. Semplicemente non puoi fare in modo affidabile prezzo fisso, ambito fisso e programma fisso in qualsiasi struttura di progetto mantenendo la qualità; Scrum lo rende semplicemente più ovvio e rende i compromessi più visibili.
Lo scopo di Scrum non è quello di far sparire magicamente il triangolo di ferro. Invece, costringe il progetto (così come gli stakeholder e gli sponsor) a fare i conti con i compromessi intrinseci. Scrum consente agli stakeholder di determinare se qualcosa è "abbastanza buono" da essere spedito alla fine di ogni Sprint, e il Product Owner ha l'opportunità di aggiustare l'ambito e la priorità durante il Raffinamento del Backlog e lo Sprint Planning. Gli stakeholder devono sfruttare questi eventi per assicurarsi di ottenere il massimo valore possibile all'interno del piano di rilascio; non è mai una garanzia di rimborso che il progetto sarà completo al 100% o adatto allo scopo al termine di una serie fissa di Sprint.
Riduci i costi irrecuperabili
Un altro aspetto dello sviluppo agile è l'opportunità di "fallire presto". Quando è probabile che un progetto fallisca per qualsiasi motivo, framework agili come Scrum danno al Product Owner l'opportunità di risparmiare denaro annullando uno Sprint e pianificandone uno nuovo in base alle aspettative modificate, o consentendo agli stakeholder di annullare il resto del progetto se lo non servirà ai loro scopi. Quest'ultimo non farà funzionare il progetto, ma ridurrà i costi irrecuperabili associati al progetto.
Nessuno può garantire che un progetto abbia successo. Il meglio che puoi fare è controllarlo e uccidere un progetto condannato il prima possibile quando il successo non è più un'opzione.
Cosa puoi fare adesso
Per prima cosa, ammetti di essere sulla strada per una marcia della morte. Se non affronterai questa verità, nient'altro che farai avrà importanza.
Quindi, scopri se il problema è il design, il debito tecnologico, le aspettative irragionevoli o qualcos'altro. Non importa quale sia la causa principale o le cause; devi solo renderli visibili in modo che il team e le parti interessate possano affrontarli in modo collaborativo .
Infine, comunica chiaramente lo stato attuale. Se sei pronto per una versione completa di pochi cicli dopo la data di consegna originariamente prevista, discuti se il progetto può regolare il vertice "temporale". Se non puoi o non vuoi modificare la pianificazione, puoi comunque rispettare la scadenza fissata aumentando i costi o riducendo l'ambito. Le parti interessate scambierebbero la consegna puntuale per ridurre un po 'di funzionalità che richiede tempo? Non lo saprai se non chiedi.
Se il progetto non può o non vuole fare nessuna delle cose di cui sopra, allora preparati al fallimento. Rispolvera il tuo curriculum e spera di aver appreso lezioni preziose che puoi utilizzare nel tuo prossimo progetto o prossimo lavoro. Soprattutto, spero che abbiate imparato a comunicare presto e spesso su ipotesi, sfide, requisiti del quadro e compromessi e interiorizzato l'importanza di una gestione continua delle aspettative degli stakeholder.
Stai producendo un incremento di prodotto distribuibile ad ogni sprint? Se è così, le date di consegna concordate sono già state rispettate e questo è il modo migliore per ridurre al minimo i rischi e dare al cliente la fiducia in ciò che stai facendo. Gli stakeholder (tramite il proprietario del prodotto) dovrebbero decidere quali cose vogliono e quando, quindi la cosa più importante è che continuino a vederti fornire valore e che tu riceva il loro feedback sui miglioramenti, le modifiche e le correzioni necessarie al prodotto. Ottenere il loro feedback è fondamentale qui. I clienti potrebbero essere interessati comprensibilmente se la timeline si estende senza nuova gamma di funzioni, ma non appena si inizia inclusi gli ultimi miglioramenti che essi vedono come priorità che sarà più probabile ad apprezzare il bisogno di flessibilità.