Come si demo software senza interfaccia utente nella Sprint Review?

Stiamo facendo uno sviluppo agile del software, sostanzialmente seguendo Scrum. Stiamo provando a fare le recensioni di sprint ma trovando difficile. Il nostro software sta elaborando molti dati e spesso le storie riguardano il cambiamento di varie regole al riguardo.

Quali sono alcune opzioni per dimostrare le modifiche che si sono verificate nello sprint quando non c'è un'interfaccia utente o una modifica del flusso di lavoro visibile, ma invece la modifica è una regola aziendale sottile su un processo di elaborazione che può richiedere 10 minuti o anche un paio d'ore ?

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

in alcuni casi lo sprint si occupa di scoperte o riarrangiamenti interni che possono sembrare impercettibili, tuttavia devi essere in grado di mostrare la differenza e spiegare al pubblico perché la pensi buona e quali sono i vantaggi di tutto lo sforzo compiuto. (? In caso angolare puoi fare riferimento a Edison che per primo ha scoperto alcune migliaia di modi in cui NON è possibile realizzare una lampadina funzionante.)

Se l'elaborazione reale richiede molto tempo, va bene mostrare un video compresso nel tempo o solo una tabella di cifre. O output pre-raccolto dei risultati.

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

Suppongo che il desiderio di cambiamento sia nato da un'esigenza. Qual è stato il problema che ha innescato la necessità di fare la storia? Il "modulo vocale" della tua user story dovrebbe indicarti come sarai in grado di dimostrare il problema agendo come utente nella tua story (ovvero come Joanne ho bisogno di visualizzare il report 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 storia fosse stata completata. Come hanno fatto? Sei in grado di mostrare quel processo all'interno della demo?

Come fai a sapere che una funzionalità funziona da solo? Quando lo distribuisci come ti assicuri che funzioni davvero?

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 rivede ciascuna delle 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 fatto meglio con un test automatizzato. Puoi scegliere i test automatizzati che corrispondono ai test di accettazione ed evidenziare i cambiamenti chiave?

Il proprietario del prodotto dovrebbe anche essere in grado di aiutare; dovrebbero avere una comprensione dettagliata del prodotto in fase di sviluppo. Non hanno bisogno di comprendere i dettagli completi dell'implementazione, ma devono capirli abbastanza bene da essere in grado di alzare la testa e spiegare lo scopo (o il valore aziendale) di ciascuna funzionalità. Dopotutto, il Product Owner è la persona che ti ha chiesto di implementare la storia in primo luogo!

Un'opzione che trovo potenzialmente soddisfacente per il business (BSA, BA, manager e simili) è quella di fornire una presentazione da cinque a dieci diapositive su ciò che era previsto e ciò che è stato realizzato. E poi se esiste un metodo significativo per visualizzare i risultati del lavoro svolto, come un dump di dati o risultati di query SQL, e il tempo per spiegarli in qualche modo, allora trovo che le parti interessate siano spesso soddisfatte.

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

Concesso, tuttavia, questo potrebbe essere più un lavoro che un valore per te. Dovrai ponderare i benefici e il lavoro necessario per realizzarlo.

È possibile utilizzare powerpoint o qualcosa di grafico per comunicare il cambiamento. Ad esempio, se è stata aggiunta una regola aziendale che dipende dal valore di una cella in un foglio di calcolo, puoi mostrare quale cella è e spiegare come è stata modificata.

Se ci sono un sacco di modifiche al backend, nessuna modifica dell'interfaccia utente, puoi semplicemente scorrere l'elenco spiegandolo e mostrare un cambiamento complessivo. Se riesci a creare un grafico o un grafico che evidenzi le differenze, potrebbe essere sufficiente. Esegui il flash di alcune modifiche al codice o un elenco di modifiche / commit che sono state elaborate nello sprint.

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