Cosa consegnate nelle prime due iterazioni in Agile?

A quanto ho capito, l'idea con le metodologie Agile è che offri qualcosa di funzionale e lo offri spesso. L'applicazione passa all'incremento della forma finale dopo l'incremento.

Ma nelle prime iterazioni potresti costruire il framework o le basi su cui poggerà l'applicazione, quindi è qualcosa di importante ma non visibile agli utenti.

Cosa viene consegnato al client in queste prime iterazioni? Come si mostrano i progressi nella giusta direzione quando si costruisce il codice ponteggi?

È tipico avere sprint di 2 settimane.

Per me, il primo sprint o 2 avranno probabilmente meno funzionalità "visibili" rispetto agli sprint successivi per questo motivo esatto (per una tenue descrizione di "less").

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

Forse non rifinisci tutti gli elementi dell'impalcatura nel primo sprint o 2. Forse le parti possono attendere ed essere aggiunte in seguito.

Forse il tuo primo sprint ha "Crea pagina Web X con dati fittizi" in modo da poter ottenere qualcosa di brillante da mostrare al tuo cliente. E poi lo sprint successivo ha "Cambia la 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 la fornitura di software collaudato e funzionante con valore commerciale sia un requisito per ogni sprint.

Perché? Bene, tra l'altro, designer e sviluppatori spesso cadono vittima di dedicare molto tempo agli articoli YNNI (non ne avrai mai bisogno). Sfortunatamente, quei quadri di cui stai parlando sono spesso una grande responsabilità in questo settore. Gli sviluppatori iniziano a mettere insieme tutto ciò che il framework POTREBBE supportare e all'improvviso ci sono 3 mesi e non hai nulla di valore aziendale da mostrare. Quindi si scopre che il framework non supporta nemmeno ciò di cui hanno bisogno.

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

Ciò NON significa che non è possibile costruire parti riutilizzabili e simili, ma lo si fa sempre solo a supporto di una necessità attuale. Inoltre, ciò non significa che devi indossare completamente i paraocchi per quello che sta succedendo lungo la strada - non costruire cose in modo che sia impossibile cambiarle / migliorarle in seguito. Ma la chiave è offrire sempre valore per l'azienda.

Spesso ci sono alcune cose chiave che devono assolutamente essere stabilite prima che qualcosa possa essere consegnato, come la creazione di ambienti e simili. Per queste cose, molte squadre trovano utile avere uno "Sprint 0" in cui vengono poste le basi. Lo 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 deve comunque essere programmato per un periodo di tempo ragionevole.

Cosa viene consegnato al client in queste prime iterazioni?

Ciò che ha il più alto valore commerciale per l'utente. Ad esempio, se le applicazioni hanno regole aziendali complesse, le prime iterazioni conterranno solo quelle regole aziendali codificate sotto forma di codice. Il cliente dovrebbe essere soddisfatto fintanto che si dispone di codice per tali regole aziendali. (Il problema di persuadere il cliente ad accettare una cosa del genere è una questione completamente diversa.) Ad esempio, potresti mostrare agli esperti del cliente i tuoi test unitari / di collaudo che esprimono ciò che il dominio dovrebbe fare e che il codice lo supera con un risultato ecologico. O ancora meglio, fai aiutare gli esperti del business a creare quei test.

C'è anche una domanda

potresti costruire il framework o le basi

Il che credo sia molto più importante di ciò che viene effettivamente consegnato. C'è una grande cosa per Evolutionary Design , che dice che dovresti creare l'architettura nel tempo invece di provare a crearla all'inizio. Per quanto riguarda la fondazione, questo di solito significa una sorta di database o framework dell'interfaccia utente. Nel qual caso, c'è l'idea di " Una buona architettura è quella che ti consente di rimandare decisioni importanti ". E la scelta del database o dell'interfaccia utente è una decisione importante. Ad esempio, potresti andare bene solo con l'archiviazione in memoria dei dati, invece di provare a utilizzare DB dalla prima iterazione.

Ciò che proviamo a fare è fornire nelle prime iterazioni la più semplice applicazione possibile (una versione ciao mondiale di ciò che stiamo offrendo). Vediamo 3 importanti vantaggi in questo:

• Imposta la procedura di consegna (sempre una delle parti più difficili imho) (installa ambienti, server, aggiorna la sicurezza per questo ambiente). Come forniremo spesso, è importante farlo bene il prima possibile.
• Dai agli utenti una prima occhiata di come apparirà l'applicazione. Questo aiuta gli utenti e gli sviluppatori a capire cosa vogliono veramente e di cui hanno bisogno.
• Avere un'idea di base su come apparirà l'architettura dell'applicazione (l'applicazione dovrebbe coprire i "livelli" di base o i componenti dell'applicazione).

Ma nelle prime iterazioni potresti costruire il framework o le basi su cui poggerà l'applicazione, quindi è qualcosa di importante ma non visibile agli utenti.

Questo è sbagliato, poiché non è necessario creare un framework che potrebbe essere utilizzato in futuro. L'idea è di costruire solo ciò che è necessario (vedi anche YAGNI ).

Nello zero dello sprint, devi prepararti per il vero lavoro. Molte persone sostengono che cosa dovrebbe essere fatto in questo sprint, ma secondo me è finito quando puoi iniziare a lavorare sugli articoli nel backlog. Questo passaggio include l'impostazione dei PC, l'impostazione del processo di creazione, la scelta dei framework, ecc.

Quando hai finito con lo 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 uno, avrai qualcosa di utile. La prima iterazione di solito include alcune delle funzionalità più importanti.

Cosa viene consegnato al client in queste prime iterazioni? Come si mostrano i progressi nella giusta direzione quando si costruisce il codice ponteggi?

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

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

Puoi consegnare praticamente tutto quello che vuoi. La costruzione dell'idea di infrastruttura è semplicemente sbagliata / non agile / insostenibile.

Ad esempio: la creazione di un'app Hello World completamente funzionale può essere realizzata in poche ore. È possibile avviare un server (anche temporaneamente) nel cloud o come macchina virtuale in poche ore.

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

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

Le prime iterazioni, in particolare la prima, conterranno o dovrebbero almeno pianificare picchi di architettura, che includono un certo tempo di scoperta e forse alcuni prototipi architettonici.

Come hai detto, in generale, ci sono requisiti strutturali che potrebbero non significare molto per gli stakeholder / clienti, ma sono tenuti a formare una forte piattaforma o orientamento al modello. Non puoi aggirare questo dato che non puoi iniziare a costruire B finché A non è completo.

Parte dell'approccio Agile è quello di far chiudere il cliente, quindi non è necessaria la documentazione 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 conciso e NECESSARIO . Nessuna doratura, nessun "Potresti averne bisogno", ecc. Costruisci ciò che ti serve in A per passare a B.

A seconda di come stai attaccando il progetto, puoi solo costruire le basi necessarie per completare un certo modulo, quindi durante la riunione di pianificazione dello sprint definiresti i piani per lo sprint corrente in base alle priorità stabilite dal cliente, a seconda di ciò che è necessario per quello sprint, potrebbero esserci alcuni requisiti fondamentali, quindi questo è lo sprint 1. Dopo che il 1 ° sprint è completo e A è stato costruito e quindi pianifica di completare B.

Se hai concordato una tempistica con il cliente, purché tu rispetti 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 consegnerai, stabilirà una forte precedenza. I clienti dovrebbero essere ragionevoli tanto quanto lo sono gli sviluppatori ed entrambi stanno lavorando allo stesso obiettivo. Un progetto completato che soddisfa le esigenze del cliente e funziona come previsto. Così preoccupante che non c'è nulla da vedere dopo lo sprint 1 è un punto controverso perché il cliente vuole solo assicurarsi che dopo lo sprint 20, il progetto sarà completato (-ish).