Come si demo software con No UI in Sprint Review?

Durante lo sprint crei valore. C'è sempre qualche differenza tra ciò che hai avuto all'inizio e alla fine dello sprint. Normalmente anche in un modo evidente dal cliente. Quindi mostra solo la differenza.

in alcuni casi lo sprint riguarda la scoperta o riarrangiamenti interni che possono sembrare sottili, tuttavia devi essere in grado di mostrare la differenza e spiegare al pubblico perché pensi che sia buono e qual è il beneficio di tutti gli sforzi fatti. ( ? In un caso ad angolo puoi fare riferimento a Edison che ha scoperto per la prima volta oltre mille modi di come NON è possibile creare una lampadina funzionante.)

Se l'elaborazione reale richiede molto tempo, va bene mostrare un video con time-zip o solo una tabella di cifre. O output dei risultati pre-raccolti.

La mia preferenza personale per le cose che fanno il lavoro di back-end è trovare la modifica dell'utente finale. Se i dati che stai elaborando finiscono per finire in un rapporto, mostra le differenze prima / dopo nel rapporto.

Sto assumendo che il desiderio per il cambiamento sia venuto da un bisogno. Qual è stato il problema che ha scatenato la necessità di fare la storia? Il tuo "modulo vocale" per l'utente dovrebbe indicare come sarai in grado di dimostrare il problema agendo come utente nella tua storia (ad esempio, come Joanne, devo visualizzare il rapporto senza utenti che si trovano in Europa).

Inoltre, puoi consultare il tuo team di test per aiutarti in questo caso. Deve esserci stato un modo in cui il team di test è stato in grado di verificare che la trama sia stata completata. Come hanno fatto questo? Sei in grado di mostrare questo processo all'interno della demo?

Come fai a sapere che una funzione funziona da solo? Quando lo distribuisci, come fai a essere sicuro che funzioni?

Se non riesci a rispondere a queste domande, hai problemi più grandi di una Sprint Review. Dovresti essere in grado di mostrarlo nella tua demo.

In Scrum, durante una demo, il Product Owner esamina tutte le storie in fase di sviluppo e le accetta o le restituisce allo sviluppo. Devi essere in grado di dimostrare che una funzionalità funziona; questo è normalmente meglio fatto con un test automatico. Puoi scegliere i test automatici che corrispondono ai test di accettazione e evidenziare i cambiamenti chiave?

Il tuo Product Owner dovrebbe anche essere in grado di aiutarti; dovrebbero avere una comprensione dettagliata del prodotto in fase di sviluppo. Non hanno bisogno di comprendere i dettagli completi dell'implementazione, ma hanno bisogno di comprenderlo abbastanza bene da essere in grado di alzarsi in piedi e spiegare lo scopo (o il valore aziendale) di ciascuna caratteristica. Dopo tutto, il Product Owner è la persona che ti ha chiesto di implementare la storia in primo luogo!

Un'opzione che trovo potenzialmente soddisfacente per le imprese (BSA, BA, manager e simili) fornisce una presentazione di diapositive da cinque a dieci su ciò che ci si aspettava e su ciò che è stato realizzato. E poi se c'è un metodo significativo per mostrare i risultati del lavoro svolto, come un dump di dati, o risultati di query SQL, e il tempo di spiegarli un po ', allora trovo che le parti interessate siano spesso soddisfatte.

Spesso è difficile fornire una dimostrazione significativa per i non programmatori / personale non tecnico su sistemi di tipo back-end. Ho provato quanto sopra un paio di volte e ritengo che le parti interessate siano state più soddisfatte nella loro risposta rispetto a quando ho semplicemente eseguito il software e mostrato loro i risultati.

Certo, tuttavia, questo potrebbe essere più lavoro del suo valore per te. Dovrai valutare i vantaggi e il lavoro necessari per realizzarlo.

Puoi usare powerpoint o qualcosa di grafico per trasmettere la modifica. Ad esempio, se è stata aggiunta una regola aziendale che dipende dal valore in una cella di un foglio di calcolo, puoi mostrare quale cella è e spiegare come è stata modificata.

Se c'è un sacco di modifiche del backend, nessuna interfaccia utente cambia, quindi puoi semplicemente scorrere l'elenco spiegandolo e mostrare un cambiamento generale. Se è possibile creare un grafico o un grafico che evidenzia le differenze, potrebbe essere sufficiente. Flash alcune modifiche al codice o un elenco di modifiche / commit che sono stati elaborati nello sprint.

Se la tua modifica è "back end" è probabile che ci sia un'interfaccia utente definitiva in cui le modifiche si manifestano. Puoi dimostrarlo. Al mio team non piace farlo perché non "possiede" quel sistema, ma alla fine della giornata, se è così che i tuoi clienti interagiscono con le tue modifiche, devi essere consapevole di quella interfaccia utente e conoscerla bene abbastanza per mostrare il prodotto finito.