Come si inserisce la prototipazione rapida in una metodologia agile?

Il concetto di "prototyping", come previsto in RAD , è un po 'estraneo allo sviluppo agile. Questo non significa che non possa essere fatto, ma è insolito.

Ci sono diversi casi che devono essere esplorati:

1. Il prototipo è una "shell vuota", un mock up o una demo, costruita per dare un'idea di come sarebbe un prodotto? Puoi certamente farlo con una o più storie - comunque stai costruendo qualcosa dalla tua immaginazione, non costruendo un prodotto da un vero feedback. Le persone non valutano una demo come valutano un prodotto. Per esempio vedi il feedback sul nostro prototipo di barra superiore rispetto alla nostra implementazione della barra in alto .

2. Il prototipo è qualcosa che deve essere costruito per comprendere meglio lo spazio dei problemi? Quindi dovrebbe essere coperto come uno picco e conservati solo i suoi risultati (il codice sorgente è transitorio).

3. Il prototipo è una versione 0.x? Un prodotto realizzabile minino ? Quindi usa il processo agile di tua scelta per questo. Se è necessario ricostruirlo in un'altra lingua, è probabile che si stia meglio se si tratti di un prodotto diverso. Nota che a volte questo è trattato come un modo per abbreviare la scrittura di una specifica ("dovrebbe fare lo stesso del prototipo!"). Questo è un modo davvero scadente di documentare un prodotto, ma probabilmente è meglio spiegarlo come una domanda e una risposta separate: -)

Non è prototipazione rapida (cioè sviluppo iterativo e incrementale) del tutto il punto di Agile?

Sembra che tu abbia problemi con "la percezione è realtà" nella tua organizzazione. Potresti voler ricordare a tutti che Agile non significa "buttare via tutti i piani", non più di Test-Driven Development significa "buttare fuori tutta l'architettura."

E Python non è (se mai lo era) un linguaggio giocattolo. La NASA e i suoi appaltatori usano Python , e se è abbastanza buono per loro, è abbastanza buono per me.

Stai per buttare via il codice e non metterlo in produzione (rendilo perfettamente chiaro a TUTTI), quindi essere agili o meno non ha molta importanza. Qualsiasi pratica agile è puramente facoltativa per i prototipi: sprint, burn-down, test, programmazione della coppia o qualsiasi altra cosa tu preveda di utilizzare.

Se stai principalmente costruendo modelli funzionali in Python per aiutare i proprietari di prodotti e altri decisori a concettualizzare il progetto, non è necessario essere pronti per l'impresa. Tuttavia, se stai creando un proof of concept o stai provando a vedere se riesci a gestire certi livelli di performance, dovresti probabilmente limitarti al linguaggio di produzione. Ciò non significa che non puoi provarlo in Python.

Indipendentemente, stai per buttare via il codice, ma hai la consapevolezza di essere in grado di farlo funzionare insieme a un migliore senso di ciò che vogliono i proprietari. Ora puoi utilizzare qualsiasi metodo che desideri.

Aggiungo che i prototipi sono cruciali per l'apprendimento, e anche nello spirito Agile. Se il prototipo ti permette di imparare, specialmente all'interno di cicli di feedback più rapidi, allora vai a farlo. Si tratta di massimizzare l'apprendimento e condividere gli apprendimenti con il team.

In termini di apprendimento, aggiungerei che la prototipazione ti porta ad imparare, più velocemente. In questo modo, puoi verificare se alla gente interessa anche il problema che stai cercando di risolvere, e se la soluzione che hai in mente è proprio quello che stai cercando - senza perdere molto tempo a costruire una soluzione completa che potrebbe , alla fine, non risolvere un problema abbastanza doloroso o non risolverlo nel modo giusto.

Il vero spirito di Agile riguarda l'interazione e la comunicazione. Direi che se il prototipo funziona bene come strumento per aiutare la comunicazione, non c'è niente di sbagliato da usare nel mondo Agile. Nel nostro team (abbiamo praticato Agile per più di 5 anni) lo abbiamo usato di volta in volta. E ci sono alcuni benefici che posso vedere da questo

1) Assist comunicazione

2) Consenti agli utenti di interviste alla soluzione e ottieni feedback precoce

Caveat:

La comunicazione diretta tra UX e gli ingegneri non dovrebbe MAI essere sostituita da alcun artefatto di prototipazione. Se possibile, l'abbinamento con l'ingegnere funziona molto meglio della comunicazione tramite un mediatore (prototipo).