Cosa distribuisci nel primo paio di iterazioni in Agile?

È tipico avere scatti di 2 settimane.

Per me, il primo sprint o il 2 avranno probabilmente meno caratteristiche "visibili" rispetto agli sprint successivi per questo motivo esatto (per qualche decisa descrizione di "meno").

Detto questo, certamente non dovresti impiegare 2 settimane per costruire il tuo intero scaffold e non avere nulla nell'interfaccia utente visibile da mostrare.

Forse non afferri ogni articolo di scaffold nel primo sprint o 2. Forse le parti possono aspettare ed essere aggiunte in seguito.

Forse il tuo primo sprint ha "Crea una pagina web X con dati fittizi" in modo che tu possa ottenere qualcosa di brillante da mostrare al tuo cliente. E poi il prossimo sprint ha "Modifica pagina web X per utilizzare i dati dal database".

Il Manifesto Agile suggerisce che il software di lavoro è più prezioso della documentazione completa e il framework Scrum prende questa idea per suggerire che fornire un software funzionante e collaudato con valore aziendale sia un requisito per ogni sprint.

Perché? Bene, tra le altre cose, i progettisti e gli sviluppatori sono spesso vittime di spendere un sacco di tempo su articoli YNNI (non ne avrete mai bisogno). Sfortunatamente, quelle strutture di cui parli sono spesso di grande responsabilità in questo settore. Gli sviluppatori iniziano a costruire tutte le cose che il framework MIGHT deve supportare e all'improvviso hai 3 mesi e non hanno nulla di valore aziendale da mostrare per questo. Poi si scopre che il framework non supporta nemmeno realmente ciò di cui hanno bisogno.

Quindi l'approccio suggerito è quello di costruire solo ciò che è effettivamente necessario ora e consegnarlo ora.

Questo NON significa che non puoi costruire parti riutilizzabili e simili, lo fai sempre per supportare la costruzione di un bisogno attuale. Inoltre, ciò non significa che devi indossare completamente i paraocchi per quello che sta arrivando in fondo alla strada - non costruire cose in modo che sia impossibile modificarle / migliorarle in seguito. Ma la chiave è offrire sempre valore per il business.

Spesso ci sono alcune cose fondamentali che devono assolutamente essere stabilite prima che tutto possa essere consegnato, come ad esempio la creazione di ambienti e simili. Per queste cose, molti team trovano utile avere uno "Sprint 0" in cui vengono poste le basi. Sprint 0 può essere un po 'più lungo degli altri sprint, in quanto non viene applicato al backlog o al burn-down del prodotto, ma dovrebbe comunque essere conservato per una durata ragionevole.

What gets delivered to the client in these first iterations?

Ciò che ha il valore aziendale più alto per l'utente. Ad esempio, se le applicazioni hanno regole aziendali complesse, la prima iterazione conterrà solo quelle regole aziendali codificate sotto forma di codice. Il cliente dovrebbe essere soddisfatto finché ha il codice per quelle regole aziendali. (Il problema di persuadere realmente il cliente ad accettare una cosa del genere è completamente diverso.) Ad esempio, potresti mostrare agli esperti aziendali del cliente i tuoi test di accettazione / unità che esprimono ciò che il dominio dovrebbe fare e che il codice lo passa con risultato verde. O ancora meglio, aiuta gli esperti di business a creare questi test.

C'è anche una domanda di

you might build the framework or foundations

Quale credo sia molto più importante di ciò che viene effettivamente consegnato. C'è una grande cosa per Design evolutivo , che dice che dovresti creare l'architettura nel tempo invece di provare a crearla in l'inizio. Per quanto riguarda le fondamenta, questo di solito significa un qualche tipo di database o framework UI. Nel qual caso, c'è un'idea di " Buona architettura è quella che ti permette rimandare decisioni importanti . " E la scelta del database o dell'interfaccia utente è una decisione importante. Ad esempio, si potrebbe andare bene con la sola memoria in-memory per i dati invece di provare a utilizzare DB fin dalla prima iterazione.

Quello che cerchiamo di fare è consegnare nelle prime iterazioni l'applicazione più semplice possibile (una versione di Hello World di ciò che stiamo consegnando). Vediamo 3 importanti vantaggi in questo:

• Imposta la procedura di consegna (sempre una delle parti più difficili imho) (ottieni ambienti, server installati, aggiorna la sicurezza per questo ambiente). Dato che consegneremo spesso, è importante farlo nel più breve tempo possibile.
• Dai agli utenti un primo sguardo su come sarà l'applicazione. Questo aiuta gli utenti e gli sviluppatori a capire cosa vogliono e di cui hanno bisogno.
• Avere un'idea di base su come sarà l'architettura dell'applicazione (l'applicazione dovrebbe coprire i 'livelli' o componenti di base dell'applicazione).

But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users.

Questo è sbagliato, dal momento che non è necessario creare un framework che è possibile utilizzare in futuro. L'idea è di costruire solo ciò che è necessario (vedi anche YAGNI ).

Nello sprint zero, è necessario prepararsi per il vero lavoro. Molte persone sostengono che cosa dovrebbe essere fatto in questo sprint, ma a mio parere, è finito quando puoi iniziare a lavorare sugli articoli nel backlog. Questo passaggio include l'impostazione di PC, l'impostazione del processo di compilazione, il prelievo di quadri, ecc.

Quando hai finito con sprint zero (o iterazione zero), puoi iniziare a lavorare sulla tua applicazione. Prendi gli oggetti dal backlog e finiscili uno per uno. Dopo aver terminato l'iterazione, avrai qualcosa di utile. La prima iterazione di solito include alcune delle funzionalità più importanti.

What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?

Dopo l'iterazione zero, ovviamente non hai nulla da consegnare. Il risultato arriva dopo l'iterazione. Contiene funzionalità che hai impostato per l'iterazione.

Se la tua domanda è "come scegliere cosa va in iterazione X?", quindi dare un'occhiata a questi video (video per iterazione 0 A e parte di B).

Puoi consegnare praticamente tutto ciò che vuoi. La costruzione dell'infrastruttura è semplicemente sbagliata / non agile / insostenibile.

Ad esempio: la creazione di un'app Hello World completamente funzionale può essere costruita in poche ore. Portare un server (anche temporaneamente) nel cloud o come una VM può essere fatto in poche ore.

Questi sono sufficienti per iniziare a sviluppare . Quindi, se hai bisogno dell'elemento della configurazione, puoi aggiungere una storia dell'elemento della configurazione, se hai bisogno di un server fisico, certo, aggiungi una storia per quello.

Ma inizia a consegnare il giorno 1 e non smettere mai!

Le iterazioni iniziali, in particolare la prima, conterranno o dovrebbero almeno pianificare i picchi architettonici, che includono una certa quantità di tempo di scoperta e forse alcuni prototipi architettonici.

Come hai detto, generalmente, ci sono requisiti strutturali che potrebbero non significare molto per lo stakeholder / cliente, ma sono necessari per formare una strong piattaforma o un modello di orientamento. Non puoi aggirare questo problema perché non puoi iniziare a costruire B finché A non è completo.

Una parte dell'approccio di Agile è di avere il cliente vicino, quindi la documentazione non è necessaria perché tutto ciò che devi fare è prendere il telefono / inviare e-mail ed è previsto. Le aspettative dei clienti dovrebbero essere impostate in modo appropriato e qualsiasi lavoro completato dovrebbe essere molto terso e NECESSARIO . Nessuna placcatura in oro, no "Potresti averne bisogno", ecc. Costruisci ciò di cui hai bisogno in A per spostarti su B.

A seconda di come stai attaccando il progetto, puoi costruire solo le basi necessarie per completare un determinato modulo, quindi durante la riunione di pianificazione dello sprint dovrai delineare i piani per lo sprint corrente in base alle priorità impostate avanti dal cliente, a seconda di ciò che è necessario per lo sprint, ci possono essere alcuni requisiti fondamentali, quindi è quello che va in sprint 1. Dopo che il primo sprint è completo e A è stato costruito e quindi pianifica di completare B.

Se hai concordato una tempistica con il cliente, fino a quando avrai raggiunto tale accordo, il cliente probabilmente non si preoccuperà di ciò che fai 1 o 2. Puoi sempre mostrare loro i risultati del test unitario, ma se dici che avremo qualcosa da vedere dopo lo sprint 2 (o 3), e fornirai, stabilirà una strong precedenza. Ci si aspetta che i clienti siano ragionevoli quanto gli sviluppatori e stanno entrambi lavorando per lo stesso obiettivo. Un progetto completato che soddisfa le esigenze del cliente e funziona come previsto. Quindi preoccuparsi che non ci sia niente da vedere dopo lo sprint 1 è un punto controverso perché il cliente vuole solo assicurarsi che dopo lo sprint 20, il progetto sarà fatto (-ish).