Supponiamo che qualcuno del tuo team di sviluppo stia presentando uno sprint al cliente, ma ha problemi di connessione web tali da non poter presentare una storia completa. Per motivi di pulizia della presentazione, aiuti il tuo collega a suggerire possibili soluzioni e cerchi di risolverlo nel momento? O è un po 'disordinato?
Può essere il cliente (chi è "parte" del team) capirà? Perché?
Se la presentazione è importante per te, dovresti fare tutto il possibile per essere preparato per situazioni estreme. Cosa puoi fare?
Anche in questo caso la presentazione a volte va storta. Non puoi combattere la qualità della tua infrastruttura e degli strumenti disponibili per mostrare i risultati dei clienti del tuo lavoro. Se tali problemi sono regolari, lo Scrum Master dovrebbe intensificarli e questi dovrebbero essere risolti dalla direzione (aumento della qualità dell'infrastruttura, migliore connessione Internet mobile o qualsiasi altra cosa).
Se il problema si verifica raramente il cliente molto probabilmente capirà (a meno che i rapporti con il cliente siano già in cattive condizioni). Risulterà posticipare la riunione o ripianificare la riunione a un altro giorno (il prima possibile). Questo è male, ma non è così male come saltare l'intero incontro. Se ciò accade spesso il cliente non sarà così gentile e influenzerà negativamente la tua partnership.
Se il problema riguarda la configurazione del dispositivo, è necessario risolverlo prima che il cliente arrivi. Pasticciare con il computer e cercare di connettersi alla tua VPN mentre il cliente è già presente alla riunione non sembra buono.
May be the client (who is "part" of the team) will understand?
Il cliente di solito non fa parte del team. Generalmente il proprietario del prodotto non è considerato parte del team e la revisione sprint non è (non dovrebbe essere) per il proprietario del prodotto. Il proprietario del prodotto dovrebbe partecipare con il team durante l'intero sprint, quindi dovrebbe già sapere cosa è stato fatto. Inoltre dovrebbe essere lei a dire che la feature / user story è stata fatta e può essere presentata nella rivista sprint. La revisione Sprint è rivolta a rappresentanti dei clienti, stakeholder / manager e forse anche a utenti finali selezionati, ecc.
No, non proverei a risolverlo in questo momento come regola generale. Preferirei programmare un incontro di follow-up e tra allora e ora capire come risolvere ciò che è andato storto. Qualcosa da considerare è quanto vuoi che i tuoi clienti vedano quello che sembra per un paio di voi a lottare qui. A seconda di come sia formale e professionale la presentazione, ho potuto vedere alcuni rari casi in cui avrei lavorato su di esso anche se quelli sono dove sto lavorando con persone in cui il 99% di noi sarebbe d'accordo nel cercare di ottenere la parte buona rapidamente e che abbiamo abbastanza conoscenza e controllo sul problema che potrebbe essere risolto in 5 minuti o meno.
Mentre il cliente può dire di capire, mi chiedo che tipo di reputazione stai creando qui. Vuoi avere quel tipo di reputazione in cui le cose vanno male e devi affrettarti a ripararle durante l'orario di presentazione? Ciò che qualcuno dice può essere molto diverso da quello che pensa.
Dato che stai utilizzando Scrum, da Sprint Presentation, stai parlando della Sprint Review? Tutti i membri di The Team più PO e ScrumMaster fanno parte della Sprint Review, quindi potresti e dovresti intensificare e aiutare la sua parte della recensione, oltre a presentare la tua partecipazione allo Sprint.
Quando dici che il cliente è "parte del team" - sta effettivamente facendo lo sviluppo come parte del team o è il proprietario del prodotto?
Se tu e il cliente (il tuo insegnante) partecipi alla riunione di revisione Sprint e stai dimostrando il prodotto funzionante, ma il prodotto non può essere mostrato funzionante, allora non è fatto.
Detto questo, se il proprietario del prodotto (il tuo insegnante?) e gli sviluppatori hanno lavorato come "parte del team", probabilmente già sanno che funziona e potrebbero aver provato a provare le stesse funzionalità. In tale situazione, il proprietario del prodotto potrebbe decidere che la trama è stata completata.
Quindi, direi che se tutti "davvero" stanno lavorando insieme, salta la demo (la tua presentazione). Se la dimostrazione è ciò che determina il fatto o meno, allora devi bilanciare il costo di mantenere la squadra più a lungo durante la riunione o spostare la storia in un'altra sprint.
Leggi altre domande sui tag agile scrum sprint presentation