Gestione di epop che forniscono solo un prodotto spedibile alla fine

"shippable" non significa necessariamente "utilizzabile dall'utente finale" e non significa necessariamente che lo spedisci effettivamente. Tutto ciò significa che hai finito di scrivere e testare il codice e che ha un livello di qualità appropriato.

Con questo in mente, devi abbattere i tuoi poemi epici in storie che possono essere completate nel contesto di un singolo sprint. Forse una storia consiste nel trasferire un singolo programma o funzione in una nuova versione di java. Quella storia verrà quindi suddivisa in attività per eseguire la porta, scrivere i test e così via. Alla fine di questa storia, il codice dovrebbe essere trasferito e dimostrato corretto con test automatici. Anche se quel singolo programma non può essere usato perché ha dipendenze da altri programmi, la porta di quel particolare programma può essere considerata conclusa.

Altre storie potrebbero essere utilizzate per trasferire altri programmi o funzioni. Un'altra storia potrebbe essere quella di passare a qualcosa di diverso da jboss, o ad una nuova versione di jboss. Ancora una volta, quel lavoro dovrebbe rientrare in uno sprint. Continua a scrivere storie come questa per realizzare tutte le cose che devono accadere prima che l'epica sia completa. Può essere che l'ultima storia sia qualcosa sulla falsariga di "capovolgere l'interruttore e iniziare a usare il nuovo codice".

Per ogni storia è necessario identificare chi è la storia (e non deve necessariamente essere un utente finale) e qual è il valore commerciale della storia.

Scrum non è nient'altro che un meccanismo per rompere grandi progetti in progetti più piccoli, con l'idea che possiamo pianificare ed eseguire meglio su piccole cose meglio di quanto possiamo fare di grandi cose. E, completando le storie più piccole prima o poi, possiamo ottenere un feedback che può aiutarci a prendere decisioni migliori in futuro.

L'altro vantaggio centrale di scrum è che non si considera una storia finchè non è "spedibile", ma, ancora una volta, ciò non significa necessariamente che sia utilizzato dal prodotto, o che sia visibile all'utente finale. Significa semplicemente che sei assolutamente, completamente finito con il lavoro per quella storia.

Agile si concentra sul valore (a.k.a. "risoluzione dei problemi per qualcuno")

Questo refactoring porta valore? Se no, o se non riesci a puntare il dito su di esso, allora hai due alternative: torna al tavolo da disegno e prova a capire esattamente quale problema stai cercando di risolvere con questo , o semplicemente non usare agile per qualcosa con un ambito fisso e un valore indefinibile.

Supponendo che tu abbia una chiara idea del valore di questo progetto, e esattamente quali problemi risolve, quindi concentrati su quelli. Applica un approccio "divide et impera" al problema e al valore, questo ti permette di ottenere una serie di problemi più piccoli da risolvere e valori da guadagnare.

È abbastanza raro che, una volta che i problemi di grandi dimensioni siano ben specificati, rimangono indivisibili. Se ne resti bloccato, chiediti se stai cercando di trovare un problema da risolvere o una soluzione a un problema. Nel primo caso: non fare nulla; nel secondo caso, forse la soluzione non è l'approccio giusto.

Ad esempio "Abbiamo bisogno di migrare un software molto grande che è stato mantenuto così com'è in Java 1.4 / JBoss 3 in una configurazione più attuale" non è qualcosa che dovresti fare senza una ragione specifica! Non hai bisogno di per migrare nulla, supponendo che tu abbia un pezzo di software funzionante ... ci sono dei problemi reali che stai cercando di risolvere con questo aggiornamento? Concentrati su quelli e considera la migrazione una soluzione opzionale.

Mi rendo conto che quanto sopra è abbastanza generico, ma la tua domanda è anche generica: -)

Scrum è solo un punto di partenza per il tuo processo, guardalo, mantieni i bit che ti piacciono, dimentica i bit che non hai. NON è una religione, (nonostante l'insistenza di molte persone ad aderire alle sue sacre scritture).

Quindi, tenendo presente questo, il punto di Agile nel suo complesso è rimuovere gli impedimenti (come i processi di gestione) per consentire all'utente di svolgere il proprio lavoro nel modo più semplice possibile, tuttavia, si rende conto che senza alcun processo di gestione si può andare 'fuori pista', quindi introduce alcuni processi diversi progettati per aiutarti a organizzarti e lavorare in modo spaventoso. I principali processi che fanno questo sono aggiornamenti regolari e comunicazione di gruppo.

Quindi questo significa che la tua epopea è "fai un po 'di lavoro" ma non puoi realisticamente fare tutto in un giro lungo senza comportare molti rischi (cioè quando hai finito lo mostrerai, e solo allora saprai se l'hai fatto correttamente). Quindi, suddividi questo compito epico in parti più piccole che puoi mostrare agli altri per dimostrare che stai ancora lavorando sulla cosa giusta e che si adatta ancora al risultato desiderato.

Può essere difficile capire come dividere un'epopea di "fare un aggiornamento" in pezzi più piccoli, a dimensione di bit, ma penso che se avessi iniziato a lavorare lo stavi rapidamente suddividendo comunque. Il problema è quello della percezione, un blocco mentale che ti impedisce di pensarci (come vedere una pagina vuota e non essere in grado di iniziare a scrivere). Puoi immaginarti mentre esegui l'aggiornamento, e naturalmente dividi i compiti - scrivili e hai praticamente finito di dividere l'epopea in storie. Ad esempio, per eseguire tale aggiornamento è possibile avere attività secondarie come fornire un nuovo ambiente, eseguire l'aggiornamento a JBoss più recente, aggiornare il DB, documentare la configurazione, testare il sistema, aggiornare il codice (che a sua volta viene convertito in aggiornamento ogni componente o livello a seconda del sistema).

Personalmente penso che gli sprint di 2 settimane siano duff, ho lavorato meglio con 6 sprint settimanali una volta, quindi non abbiate paura di cambiare i tempi, ma non aumentare i tempi di sprint per rimuovere il valore di essi - è necessario mostrare i progressi dopo ognuno, o il suo inutile sprint a tutti. E se non mostri progressi, non ha senso fare Agile. Quindi, tienilo in tempi ragionevoli e rilascialo spesso. Se ciò significa tirare una doppia sprint di tanto in tanto, quindi cosa fare. (molte persone diranno "ma questo influenzerà la tua velocità", e io dico "velocità di sod, relativo ai progressi reali non ai rapporti di gestione").