Operazioni completate e non completate

Da Ken Schwaber e David Starr, Scrum.org

Gennaio 2012

La consegna di un incremento eseguito è un'operazione importante per avere successo con Agile Software Development. Utilizzando esempi realistici e teorici, gli autori spiegano la differenza tra la percezione di "risultato" e la realtà di "risultato" e come questo influisce sul successo di un progetto. Attraverso questi esempi, gli autori continuano a illustrare gli strumenti e le strategie che consentono ai team di trovare una definizione sensata di "risultato" e i metodi che consentono ai team di comunicare le dipendenze, lo stato e il significato di "risultato".

Si applica a

Application Lifecycle Management; Team Foundation Server

In questo articolo:

• Introduzione

• Il problema della perdita di trasparenza nella società di Anna

  • Ciò che le persone pensavano si fosse verificato

  • Ciò che si è appena verificato

  • Lezione

• Debito tecnico presso Nanomedtronics AZ

  • Ciò che le persone pensavano si fosse verificato

  • Ciò che si è appena verificato

  • Lezione

• Debito tecnico si amplifica con più team

• Il piano di rilascio alla Datum Corporation

  • Ciò che le persone pensavano si fosse verificato

  • Ciò che si è appena verificato

  • Lezione

• Tecniche su vasta scala per il completamento

  • Scrum di scrum

  • Integrazione continuata

• Conclusione

Scrum è un framework Agile iterativo e incrementale. I team la utilizzano per produrre rapidamente incrementi "completati" o funzionalità software potenzialmente utilizzabile, ogni iterazione o sprint.

"Eseguito" è una parola semplice ma spesso mal interpretata. Per me significa terminato, finalizzato e completato. Eseguito indica che non c'è più nulla da fare. La parola Eseguito è semplice da definire, la consegna di un Incremento eseguito resta uno dei requisiti fondamentali e più elusivi dello Scrum e dell'agilità.

L'agilità richiede per ogni Sprint l'esecuzione della consegna, gli incrementi pronti per l'utilizzo del software funzionante. Eppure la maggior parte dei team scrum e Agile generano incrementi incompleti, parzialmente completati. Quando a un team scrum viene chiesto il motivo per cui non sono stati completati i requisiti del backlog del prodotto in uno Sprint, i membri del team spesso rispondono di non aver avuto tempo sufficiente.

In questo documento vengono esaminati i problemi correlati agli incrementi eseguiti attraverso l'esempio di casi di studio reali a partire dai primi giorni di utilizzo di Scrum. I nomi e le posizioni delle persone in questione sono stati modificati e sicuramente i singoli riconosceranno se stessi e il loro duro lavoro. In questo articolo tutti gli Sprint sono un'iterazione mensile, salvo quando diversamente indicato.

Il problema della perdita di trasparenza nella società di Anna

Anna aveva la necessità di automatizzare la ricezione del suo reparto delle modifiche al titolo di proprietà. La società per cui ha lavorato ha costruito e gestito gasdotti attraverso la maggior parte del Nord America. Il reparto ha elaborato e pagato i diritti d'autore ai proprietari della terra che attraversano. Le informazioni sul titolo ricevute dal reparto di Anna erano stampati o documenti sulle modifiche delle proprietà. Il volume stava diventando eccessivo, pertanto Anna desiderava automatizzare il processo di pagamento dei diritti e i feed.

Il team di sviluppo ha proposto che sviluppassimo il sistema di royalty per Anna che utilizza scrum. In questo modo, Anna avrebbe avuto una parte di software utilizzabile da controllare ogni mese. Aveva anche il diritto di cambiare idea ogni mese su ciò che avrebbe fatto il team in seguito.

Per la fine del terzo sprint, si dispone di un feed da una delle province e viene integrato con dati più obsoleti. Lo abbiamo dimostrato utilizzando una semplice soluzione SQL. Anna era contentissima, perché la maggior parte del backlog prodotto del personale proveniva da questa provincia.

Desiderava che insegnassimo SQL al suo staff, in modo che potessero iniziare immediatamente a utilizzare il software consegnato del team di sviluppo.

Che cosa intendeva dicendo che voleva utilizzarla? Certamente non ha capito che aver completato uno sprint è come avere completato il software!

Lo abbiamo detto ad Anna nel modo più cauto possibile. Era estremamente contrariata. “Cosa si intende per non eseguito? Ho visto il primo Increment, il secondo Increment e ora desidero iniziare a utilizzarlo. Esegui la distribuzione e insegnaci SQL in modo da poterlo utilizzarle".

C'è stato un momento di disagio. Abbiamo detto ad Anna che effettivamente era stato completato. Ma non era completamente eseguito. È stato fatto per mostrarlo a lei, ma vi sono problemi che richiedono una risoluzione prima che il software possa essere utilizzato:

• Alcuni record in ingresso potrebbero non essere elaborati. È necessario disporre di una struttura in cui archiviarli e gestirli per non gettarli via.

• Diversi campi nei record in ingresso sembravano essere utilizzati per scopi diversi da quanto documentato. Come li si poteva utilizzare?

• I campi del database esistente contenevano puntatori o informazioni che sembravano informazioni di riferimento. È tutto quello che si sapeva del database.

• Mentre stavamo eseguendo feed in ingresso e le query sul database, il sistema si è arrestato in modo anomalo più volte. Apparentemente i dati sono stati danneggiati durante questi arresti anomali.

Anna ha chiesto quanto tempo sarebbe passato prima che il suo tipo di eseguito sarebbe potuto diventare utilizzabile. È stato stimato che erano necessari altri due Sprint per rendere gli incrementi utilizzabili. Ci ha detto di precedere e predisporlo per l'utilizzo del reparto. Mi ha quindi "chiesto" una riunione per la mattina dopo.

La mattina dopo sono arrivati Anna, il suo superiore e il capo dello sviluppo. Hanno espresso il loro disappunto sul fatto che non c'era la trasparenza che avevo caldeggiato. Ritenevano che avrei dovuto gestire i problemi irrisolti in modo differente anziché limitarmi a registrarli come bug. Erano irritati perché il progresso illustrato nei rapporti burn-down distribuiti a tutti non erano corretti.

Dopo la riunione, gli ordini di marcia sono:

1. Analizzare e correggere i quattro bug.

2. Terminare e distribuire i primi tre incrementi in modo che il reparto di Anna può iniziare a utilizzarli.

3. Migliorare le nostre competenze di progettazione e l'automazione dei test in modo che la nostra definizione di risultato fosse la stessa di Anna (immediatamente utilizzabile dall'azienda).

4. Modificare la modalità con cui sono stati registrati gli errori in modo che il requisito non sia considerato eseguito a meno che non sia stata apportata una correzione.

   Ci è stato detto che questa sarebbe stata un'ottima opportunità di apprendimento se tutti avessimo imparato la lezione.

Ciò che le persone pensavano si fosse verificato

Quando abbiamo sviluppato un piano di base per il sistema, rappresentava ciò che le parti interessate e Anna pensavano che sarebbe accaduto. Il team di sviluppo ha restituito lo stato di avanzamento che è apparso come se fosse la versione al passo e le persone è associata del rapporto.

Il team di sviluppo dispone effettivamente di prodotto che venissero utilizzando l'operazione corretta visualizzazione del lavoro per l'esecuzione come stabilito nel piano.

Ciò che si è appena verificato

La velocità è la misura e il record cronologico della produttività del team di sviluppo per lo Sprint. La velocità è calcolata ad ogni sprint e serve a definire i modelli di produttività.

Il team di sviluppo ha richiesto una velocità continua di 8 unità complete di lavoro per ogni sprint per rispondere alle esigenze del piano. Quando un evento ha minacciato di rallentare la velocità al di sotto di 8 unità, non è stato completato tutto il lavoro su quegli elementi.

Il risultato funzionava abbastanza bene ma non era sufficientemente completo per poter essere utilizzato per la compilazione. Era nostra intenzione migliorarlo in un secondo momento. Quando abbiamo stimato di nuovo il lavoro non svolto, si erano aggiunte altre 14 unità di lavoro.

Una volta specificata la difficoltà dei feed del titolo iniziali, è stato rielaborato l'intero piano affinché riflettesse una probabile pianificazione a 20 mesi. Il reparto di Anna ha rilasciato incrementa circa ogni due mesi, abilitando nuovi feed. I nuovi feed automatizzati hanno ridotto talmente tanto il lavoro manuale complessivo che si è rimasti delusi quando il sistema è stato pronto in ventidue mesi.

Lezione

La vera trasparenza richiede una visione e una comprensione comuni a tutti coloro che si occupano dell'incremento. L'analisi trasparente dell'incremento avrebbe dovuto consentire ad Anna di gestire i rischi e di prevedere facilmente le fasi successive del lavoro. Tuttavia, poiché l'incremento non era trasparente, non è stata in grado di pianificarlo in modo efficiente.

All'inizio del progetto, Anna ha definito un obiettivo del rilascio. Dopo Sprint 1, ha valutato lo stato di avanzamento verso l'obiettivo analizzata ciò che pensava essere un incremento utilizzabile. Ha preso una decisione su cosa fare nello Sprint 2 in base allo stato di avanzamento incrementale verso l'obiettivo. Se avesse ritenuto che il nostro stato di avanzamento era inadeguato, avrebbe potuto annullare il progetto.

Alla fine dello Sprint 3, Anna ha creduto che i 3/10 del totale fosse completato, ma questa presupposizione era errata.

Avevamo lavorato solo quanto bastava per una dimostrazione dell'incremento. Il lavoro annullato ha reso gli incrementi inutilizzabili per il reparto di Anna e poco chiari a un esame.

L'opacità quando si controlla un incremento è come coprire un termostato con un con un panno freddo e bagnato. Il termostato non riconosce la temperatura ambiente effettiva e attiva erroneamente il riscaldamento quando invece dovrebbe attivare il condizionamento.

Senza gli incrementi trasparenti, le parti interessate non hanno una conoscenza corretta di ciò che sta accadendo e possono agire erroneamente.

In breve, senza trasparenza completa la capacità di controllo e adattamento efficace del team viene persa.

Debito tecnico presso Nanomedtronics AZ

Debito tecnico è il lavoro posticipato che deve essere completato prima che il software sia considerato completato. Debito tecnico utilizza molte forme come progettazione scarsa, duplicazione di codice e funzionalità non testate. Nell'esempio seguente vengono mostrati la causa e l'effetto sul debito tecnico del lavoro annullato nel corso di un progetto.

Nanomedtronics AZ è una nuova piccola società di software. Un team scrum lavorava a una nuova release del suo prodotto di punta, un software utilizzato da robot nani per liberare le arterie ostruite di pazienti soggetti a ipertensione.

Ciò che le persone pensavano si fosse verificato

Quando il team ha iniziato, gli è stato chiesto di selezionare elementi di backlog del prodotto da convertire in attività completate (nessun lavoro rimanente, utilizzabile, potenzialmente realizzabile) in uno sprint di un mese. Il team di sviluppo ha tutte le competenze completamente per sviluppare i requisiti in un incremento eseguito.

Quando il team scrum ha iniziato il primo sprint, hanno visto che c'erano 80 unità di lavoro da completare in 10 mesi. Di conseguenza, il team di sviluppo ha correttamente selezionato 8 unità di lavoro per ogni sprint. Hanno spiegato che impostando semplicemente 8 unità per Sprint, avrebbero terminato nei 10 mesi indicati dalla società.

Il team di sviluppo è illustrato un incremento funzionante alla fine di ogni sprint. Dall'esterno, sembrava che Scrum stesse lavorando e Nanomedtronics AZ stesse per fornire il prodotto come previsto.

Ciò che si è appena verificato

Quello che non era chiaro al di là del team di sviluppo era che ogni incremento prodotto in realtà includeva alcune implementazioni di scarsa qualità, bug non critici, passaggi logici ripetuti e codice strutturato male. Inoltre, non è stato eseguito il test completo degli incrementi perché il team di sviluppo ha smesso di eseguire i test una volta raggiunto il tempo in uno sprint. +Il team di sviluppo ha eseguito il commit di soddisfare la pianificazione e ritagliare la qualità è spesso la modalità rimanere in corso.

Il team ha lavorato duramente e ha realizzato il prodotto in 10 mesi. Il cliente è contentissimo e quindi possibile applicare e utilizzare il software. Tuttavia, il team di sviluppo ha accumulato 48 unità di lavoro annullate, come illustrato nella seguente figura in qualità di nuovo debito tecnico.

Il team di Nanomedtronics AZ non ha considerato tutte le attività e il lavoro effettivamente necessario a completare il progetto. Di seguito sono riportati alcuni degli aspetti che il team non ha considerato. Potevano essere inclusi molti altri aspetti.

• Analisi

• Progettazione

• Analisi delle dipendenze

• Test delle prestazioni

• Test di stabilità

• Refactoring

• Test di risposta immunologica

• Integrazione con il lavoro degli altri team che lavorano a un prodotto

• Test di integrazione con il lavoro di tutti gli altri team in modo dall'incremento rappresenti la totalità dei contributi di tutti i team

• Note sulla versione

• Internazionalizzazione in base alle sei impostazioni cultura in cui il prodotto viene venduto

• Test di accettazione utente

• Test di regressione

• Revisioni del codice

Il lavoro sopra indicato deve essere eseguito per creare un incremento intero e integrato per la fine dello sprint. Tuttavia, la maggior parte dei team di sviluppo non hanno completato tutto il lavoro. Lasciano indietro del lavoro "annullato" ad ogni Sprint. Ciò determina incrementi che presentano problemi di progettazione, codice duplicato, logica troppo complessa, funzionalità o caratteristiche non testate, o altre forme di incompletezza. È così che i team creano il debito tecnico nel software.

Nanomedtronics AZ ha appreso che il proprio prodotto include tutte le funzionalità necessarie per essere fornito ai clienti, ma anche molti difetti e manca dell'imballaggio e del lavoro di completamento necessario effettivamente di introdurre il prodotto nel mercato. Il team di sviluppo inavvertitamente ha creato un backlog di lavoro aggiuntivo che richiede altri 6 mesi per completare, presupponendo che una velocità già errata di 8 unità per sprint.

Attendere 6 mesi per fornire il prodotto non era accettabile per i leader della società e il prodotto è stato consegnato con del lavoro ancora da completare dopo solo 3 mesi. Il potenziale perso non era solo il ritardo di 3 mesi nella fornitura del prodotto, ma il rallentamento nella capacità di aggiungere nuove funzionalità dal momento che il team di sviluppo doveva a quel punto affrontare gli sprint successivi con un debito tecnico.

Lezione

Debito tecnico nasconde lo stato di avanzamento effettivo e la trasparenza richiesta per processo decisionale empirico dal proprietario del prodotto e dalle parti interessate. Debito tecnico viene ripagato, in tempo trascorso intenzionalmente per risolve i problemi tecnici o nella perdita a causa di spedizione in ritardo o qualità scadente.

Nella maggior parte delle situazioni, almeno il 50% del lavoro annullato rimane nei prodotti rilasciati. Di conseguenza, il lavoro non eseguito viene istituzionalizzato come debito in corso. Debito tecnico causa rapidamente la fragilità del prodotto e infine può forzare le decisioni negative come l'investimento nella riscrittura del software o l'abbandono del prodotto.

Debito tecnico si amplifica con più team

Un team di sviluppo deve scegliere attentamente solo il lavoro che può effettivamente eseguire in uno sprint. Il team di sviluppo impara quanto lavoro è esperti. Tuttavia, un team deve utilizzare le procedure di progettazione moderne come test di regressione e compilazione automatizzato per eseguire gran parte di qualsiasi elemento. Se non vengono utilizzate, il lavoro manuale tenderà a sovraccaricare un team dal quarto o il quinto sprint.

Si consideri un team di sviluppo di tre programmatori e due specialisti di controllo di qualità. Ogni giorno i programmatori archiviano il codice nel sistema di codice sorgente. Viene testato e i bug vengono rilevati e forniti al programmatore appropriato. L'archiviazione del codice e l'individuazione e la segnalazione dei difetti richiedono tempo. Durante questo intervallo, gli altri programmatori potrebbero aver archiviato il codice sostituendo quello errato. A questo punto, l'impegno necessario a correggere il problema è maggiore. Se il team di sviluppo avesse avuto a disposizione una funzionalità di compilazione e test continua, l'errore sarebbe stato rilevato immediatamente. Le persone potrebbero effettuarne l'analisi. la correzione e quindi procedere. Il lavoro aggiuntivo e lo spreco potrebbero essere evitati.

Molte organizzazioni richiedono più di un team scrum per lo sviluppo del software. In questo caso, il problema del debito tecnico descritto nella sezione precedente è notevolmente amplificato. Le possibilità per archiviare del codice sopra a un codice errato sono molto maggiori. Il costo per compensare la crescente fragilità del software aumenta esponenzialmente con l'avanzamento del lavoro.

Il piano di rilascio alla Datum Corporation

Recentemente ho lavorato con un'altra società che chiamerò A Datum Corporation, una società di software per infrastrutture. La linea di prodotti principale utilizza oltre 800 sviluppatori, tra cui 250 programmatori. l'infrastruttura di sviluppo parzialmente è stata automatizzata e parzialmente manuale. Il test ha ritardato spesso la codifica per giorni. Il tempo trascorso tra la verifica di un codice difettoso da parte di un programmatore e le relative individuazione e segnalazione era spesso di dieci o più giorni.

Per ridurre al minimo la complessità di così tanti programmatori, ogni team di sviluppo si è dedicato al proprio branch di codice. Gli amministratori di sviluppo contribuiti per organizzare i requisiti di backlog del prodotto ridurre al minimo le dipendenze. Se ogni team di sviluppo eseguisse ogni giorno il merge del proprio codice nella riga di codice principale, la quantità di rielaborazione potenziale risulterebbe ridotta.

Tuttavia, la gestione ha ritenuto che avrebbe richiesto troppo tempo. Il management ha deciso di unire tutti i rami di codice nella radice ogni terzo sprint. I est di integrazione dovrebbero individuare tutti i problemi, che quindi verranno corretti. Un release candidate è pronto per la fine di ogni terzo mese.

Ciò che le persone pensavano si fosse verificato

Nella figura seguente sono illustrati la pianificazione e il ciclo della versione pianificata.

Il piano originale presupponeva:

• 9 Sprint

• 3 release candidate e quindi una versione completa

• Un'organizzazione di sviluppo a 800 utenti

Ciò che si è appena verificato

Quando questa organizzazione ha raggiunto la data di rilascio dopo nove mesi di Sprint, il prodotto non era pronto al rilascio. La sesta versione finale candidata si presentava con oltre 5.000 difetti e oltre 2.000 requisiti di backlog del prodotto incompleti. Ci domandammo come potesse essere accaduto. Avevamo prodotto una versione finale candidata ogni tre mesi. Quando abbiamo esaminato la situazione, abbiamo scoperto che la dimostrazione riguardava il branch di codice di ciascun team di sviluppo. Nessuna integrazione si è verificata. Nessun test di integrazione si è verificato.

Per mantenere la velocità necessaria per rispettare la data di rilascio, i team di sviluppo avevano rinviato tutto il lavoro di integrazione, creando così un debito tecnico ampio. Il risultato è stato uno slittamento di otto mesi rispetto alla data di rilascio pianificata. Le parole "versione finale candidata" non avevano alcun senso.

Nella figura seguente viene illustrato il progetto reale più il tempo necessario per la stabilizzazione.

Le versioni finali candidate avevano funzionalità parzialmente funzionanti dal branch del codice per ogni team. Sono necessari cinque mesi "di stabilizzazione" prima del rilascio. Un difetto particolarmente fastidioso che ritarda più di altri la consegna sono le "scarse prestazioni". Questa versione è stata connessa nel primo sprint.

Lezione

I team diversi che utilizzano lo stesso software alla uniranno il proprio lavoro. Integrazione del software per assicurarne il funzionamento riduce il rischio delle integrazioni e dovrebbe avvenire frequentemente.

Attendere per eseguire il merge del lavoro di più team è una tentazione in quanto consente di ritardare il costo dell'operazione di merge. Il costo finale del ritardo, tuttavia, è spiegato dal numero di team coinvolti e dal numero di branch che devono essere integrati.

Tecniche su vasta scala per il completamento

Raggiungere lo stato "completato" tra i team è un'operazione complessa. Le complessità coinvolte sono numerose. Esistono le dipendenze tra i team e tramite le diramazioni del codice. Sebbene questa complessità della scala presenti dei costi, è comunque raggiungibile e fornisce un valore straordinario quando i team sincronizzati consegnano tutti insieme.

Esistono diverse tecniche che ho trovato utili nella collaborazione tra più team.

Scrum di scrum

Quando molti team scrum lavorano allo stesso progetto, è necessaria una tecnica per coordinare il loro lavoro. Ho consigliato uno "scrum di scrum", ovvero un evento giornaliero, tenuto subito dopo lo scrum giornaliero di ogni team. Partecipa un tecnico da ogni team. Ciascuno rappresentante del team descrive ciò su cui il team ha lavorato. Ognuno illustra quindi su cosa pensa di lavorare il giorno successivo. Sulla base di queste informazioni, i rappresentanti tentano di identificare tutte le rielaborazioni necessari, le dipendenze imminenti e tutto il lavoro che potrebbe dover essere ripianificato.

Lo scrum degli scrum è stato utile a molte organizzazioni. Tuttavia, risulta non adeguata. Le dipendenze e la rielaborazione possono essere identificate correttamente o meno, poiché i problemi vengono anticipati piuttosto che conosciuti. Le dipendenze non preventivate sono state la causa della rielaborazione e dell'insuccesso nei test. Alcuni tam dedicano più del 50% di ogni sprint a elaborare e rielaborare le dipendenze.

Integrazione continuata

Extreme programming (XP) richiede l'integrazione continua e il test di integrazione di lavoro del team. Perché non estenderlo a tutti i team? Che siano in due o in cinquanta team, alla fine di ogni Sprint i team devono produrre un incremento integrato e con test di integrazione superato. A tale scopo, i team devono integrare spesso il proprio lavoro. Poiché qualsiasi lavoro non integrato potrebbe contenere dipendenze non risolte, l'integrazione continuata è la migliore soluzione.

L'integrazione continuata di tutto il lavoro è simile alle tecniche di produzione snella. Nelle linee di produzione snella vengono utilizzate molte tecniche per valutare la qualità del prodotto durante il processo di produzione. Quando si verificano deviazioni o problemi di qualità, la linea di produzione si interrompe. L'integrazione continua e il test di integrazione forniscono le stesse tecniche per lo sviluppo del prodotto software.

Sebbene non sia facile, si consiglia a ogni team e membro del team di arrestare la codifica se una compilazione continua o un test hanno un esito negativo. È possibile che il lavoro continuo sia stia compilando sugli errori, causando un effetto Ripple degli errori. Se si utilizza l'integrazione continuata, i team collaborano attivamente per evitare errori di integrazione. Le abitudini di lavoro migliorano, lo spreco viene ridotto e la qualità aumenta.

La maggior parte delle organizzazioni che adottano scrum non iniziano con tutte le competenze di progettazione e gli strumenti per compilare un incremento completato. È necessario avviare ed eseguire un programma rigoroso per ottenere gli incrementi eseguiti. I gruppi di meno di cinquanta utenti possono rapidamente raggiungere uno stato in cui viene completato un incremento eseguito nello sprint. Le organizzazioni di oltre cinquecento sviluppatori spesso richiedono più anni per arrivare a quel punto.

Gli incrementi annullati creano spreco e impediscono ai team di raggiungere la vera agilità. Il costo effettivo del lavoro annullato è molto superiore alla mancanza di una funzionalità o di una funzione nell'incremento. Il costo include gli sprechi di ripianificazione e la ripresa necessarie quando un incremento true non fa nonché costa di prevedibilità inferiore e dell'elevato rischio.

Molte organizzazioni richiedono i vantaggi di flessibilità e utilizzano la formazione per ottenerle. La consegna di un incremento eseguito è un'operazione importante per avere successo con Agile Software Development. I team devono iniziare con una definizione di risultato che ha senso, quindi deliberatamente espandere la definizione nel tempo. Solo successivamente, raggiungeranno la vera agilità.

Vedere anche

Concetti

Collaborare [reindirizzamento]

Collaborare (approfondimento) [reindirizzamento]

Creare il backlog

Pulire e stimare il backlog

Eseguire un'iterazione [reindirizzato]

Terminare un'iterazione [reindirizzato]