In che modo la prototipazione rapida si adatta a una metodologia agile?

Lavoro per una grande azienda, che impone l'utilizzo di processi agili. Ad esempio, per i nostri progetti, utilizziamo servizi basati su cloud specificamente mirati alla gestione dello sviluppo agile.

Lo specifico gruppo di ingegneri per cui lavoro non ha sviluppato tradizionalmente software (invece aiutiamo a guidare i progetti da un punto di vista molto più avveduto), ma questo sta cambiando. Abbiamo una vasta gamma di progetti software imminenti / pianificati che sono per lo più incentrati sui dati - ad esempio, faremo monitoraggio dei dati, raccolta, aggregazione e alcuni rapporti. Altre attività riguardano l'automazione con hardware specializzato e vari tipi di architetture client / server (a più livelli). Devo assistere nel processo di assunzione di diverse persone e di formulare molti dei nostri piani per andare avanti.

La mia domanda è se la prototipazione rapida (codice usa e getta) rientri o meno in una filosofia agile. Ad esempio, adoro Python e la sua vasta gamma di pacchetti. Vedo la possibilità di implementare molte delle nostre idee molto rapidamente con un flusso di lavoro basato su Python. Tuttavia, penso che ci saranno molte percezioni sul fatto che Python non sia "di qualità aziendale" e che gran parte di questo lavoro dovrebbe essere riscritto in Java o forse in C ++.

Tuttavia, la creazione dei prototipi di Python ci darebbe molto da fare per il nostro dollaro nel consentirci di ottenere rapidamente risultati reali.

Sei stato in grado di incorporare la prototipazione rapida - si spera in Python - in un flusso di lavoro solido e agile in un ambiente aziendale?

Il concetto di "prototipazione", come inteso in RAD , è un po 'estraneo allo sviluppo agile. Questo non significa che non si possa fare, ma è insolito.

Esistono diversi casi che devono essere esplorati:

1. Il prototipo è un "guscio vuoto", un modello o una demo, costruito per dare un'idea di come sarebbe un prodotto? Puoi sicuramente farlo con una o più storie - comunque stai costruendo qualcosa dalla tua immaginazione, non costruendo un prodotto dal vero feedback. Le persone non valutano una demo come valutano un prodotto. Ad esempio, vedi il feedback sul nostro prototipo della barra superiore rispetto alla nostra reale implementazione della barra superiore .

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

3. Il prototipo è una versione 0.x? Un prodotto minimo praticabile ? Quindi utilizzare il processo agile di tua scelta per questo. Se devi ricostruirlo in un'altra lingua, è probabile che tu stia meglio se lo tratti con un prodotto diverso. Si noti che a volte questo viene 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 questo è probabilmente meglio spiegato come una domanda e una risposta separate :-)

La prototipazione rapida (cioè lo sviluppo iterativo e incrementale) non è una specie dell'intero 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", più che Test-Driven Development significa "buttare via tutta l'architettura".

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

Esiste una pratica abbastanza consolidata nella programmazione estrema chiamata Spike . Ciò significa che è un codice usa e getta. Non c'è niente di speciale in esso. È solo uno Sprint in cui il risultato atteso è la conoscenza del codice usa e getta.

Il link sopra ha abbastanza informazioni sulle buone pratiche, le insidie ​​dei picchi.

Il tuo caso d'uso specifico sembra un buon esempio: può essere utile progettare l'interfaccia, convalidare l'utilità e mostrarla ad alcuni utenti.

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

Se stai principalmente creando modelli funzionali in Python per aiutare i proprietari dei prodotti e altri decisori a concettualizzare il progetto, non devi essere pronto per le imprese. Tuttavia, se stai creando una prova di concetto o stai cercando di capire se riesci a gestire determinati livelli di prestazioni, probabilmente dovresti attenerti al linguaggio di produzione. Ciò non significa che non puoi provarlo in Python.

Indipendentemente da ciò, hai intenzione di buttare via il codice, ma hai la conoscenza di essere in grado di farlo funzionare insieme a un migliore senso di ciò che i proprietari vogliono. Ora puoi usare qualsiasi metodo tu voglia.

Aggiungerei che i prototipi sono cruciali per l'apprendimento, e anche nello spirito Agile. Se il prototipo ti consente di apprendere, specialmente all'interno di cicli di feedback più rapidi, procedi. Si tratta di massimizzare l'apprendimento e condividere gli apprendimenti con il team.

In termini di apprendimento, aggiungerei che la prototipazione ti porta all'apprendimento, più velocemente. In questo modo, puoi verificare se le persone si preoccupano persino del problema che stai cercando di risolvere - e se la soluzione che hai in mente è proprio quello che stanno cercando - senza perdere molto tempo a costruire una soluzione completa che possa , 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 ad usarlo nel mondo Agile. Nel nostro team (pratichiamo Agile da più di 5 anni) lo usiamo di volta in volta. E ci sono alcuni benefici che posso vedere da quello

1) Assistere la comunicazione

2) Coinvolgi gli utenti nelle interviste con le soluzioni e ricevi feedback in anticipo

Avvertimento:

La comunicazione diretta tra UX e gli ingegneri non deve MAI essere sostituita da artefatti di prototipazione. Se possibile, l'associazione con l'ingegnere funziona in modo molto più efficace rispetto alla comunicazione attraverso un mediatore (prototipo).

Altri hanno già menzionato lo scopo di apprendimento dei picchi. Ciò che manca è il principio agile che sta alla base, che fallisce rapidamente .

Uno dei pilastri dello sviluppo agile è riconoscere le parti dure e cercare prove di concetti, vedere se riesci a farlo affatto. Il modo classico di affrontare tutte le attività in un ordine "logico" può rivelarsi molto costoso se scopri che non puoi fare qualcosa in ritardo nel progetto. Tutto ciò che è stato fatto finora potrebbe essere uno spreco.

Se deve finire in quel modo, vuoi sapere il più rapidamente possibile. Quindi le parti interessate possono scegliere di smettere di bruciare denaro mentre non è stato ancora bruciato molto e accettare ciò che vogliono non è fattibile o di provare un approccio radicalmente diverso al problema che avrà una nuova possibilità di successo. Se i tuoi prototipi servono a questo scopo, sono davvero molto agili.