Come dovremmo gestire le funzionalità extra cosmetiche negli sprint Scrum?

Accordalo con il proprietario del prodotto e con il team di Scrum, non con Internet. Questo dovrebbe essere determinato nella tua Definizione di Fatto e dipenderà in gran parte da come funziona la squadra.

Sebbene la funzione dovrebbe essere 'shippable' (odio questo termine in Scrum) si potrebbe sostenere che la funzionalità è disponibile senza interfaccia utente. Molte persone soffrono questo malinteso in Scrum - l'obiettivo di uno sprint è di ottenere quante più storie possibili (idealmente tutte) "Fatto", ma sicuramente non ha bisogno di essere incorporato in qualcosa che potrebbe essere pubblicato.

È importante stirare cose del genere presto, quindi tutti i membri del team stanno lavorando per raggiungere un obiettivo comune. L'ethos di Scrum è comunicazione, quindi chiedi al team di Scrum e tragga una conclusione logica.

Potresti lavorare in un team in cui l'interfaccia utente viene generalmente gestita separatamente, ad esempio da un team diverso o quando gli esperti dell'interfaccia utente decidono come dovrebbe apparire il modulo. In alternativa, in un piccolo progetto / team ci si può aspettare che l'interfaccia utente sia costruito come si fa.

Fintanto che la squadra conosce la risposta, è irrilevante la risposta.

Se le funzionalità cosmetiche fanno parte della funzionalità, dovrebbero probabilmente essere fatte come parte della storia. Il punto è che, una volta che hai scritto una storia, non dovresti fare più codice su una particolare caratteristica. Anche se, in ultima analisi, questo è deciso dal proprietario del prodotto, potrebbero volere le caratteristiche estetiche o meno. Questo dovrebbe essere spiegato nei criteri di accettazione.

Questo non significa necessariamente che sia pronto per l'utilizzo da parte dell'utente finale, significa semplicemente che è pronto per qualcuno . Che qualcuno potrebbe essere un tester o un'altra squadra come il team di back-end.

Se lo chiedi come sviluppatore, la risposta diventa "lo sai, perché il proprietario del prodotto ti dirà se vogliono o meno le funzioni estetiche".

Se lo chiedi come proprietario del prodotto, devi semplicemente decidere se vuoi suddividere la funzione in più di una storia. Non vi è alcun obbligo oltre a quello di soddisfare voi , come mezzo per soddisfare il vostro cliente .

Ricorda: l'obiettivo non è quello di aderire rigorosamente alla mischia. L'obiettivo è fornire software di alta qualità all'utente finale. Usalo come guida quando stai lottando con domande come questa. Aggiungere i cosmetici nella stessa storia delle parti puramente funzionali ti aiuterà a fornire un codice di qualità al tuo cliente? Oppure, rompere questo in due storie aiuta? O la risposta è chiara, o non importa e puoi fare tutto ciò che funziona per la tua squadra.

"Potenzialmente spedibile" significa shipp-able non necessariamente qualcosa che spedisci. Ad esempio:

Un modulo di registrazione web che sembra terribile e non ha alcuna validazione sui campi, può essere ok per alcune situazioni, come un progetto scolastico, ma in un business da molti milioni di dollari, danneggerebbe il marchio da mostrare agli utenti finali. Il codice potrebbe essere spedito senza essere qualcosa che vorresti spedire o che il marketing o il legale ti permettessero di spedire.

È qualcosa che i programmatori (e le altre persone che sono in questo processo, ad esempio i designer) sarebbero felici di rilasciare come è adesso, anche se, per qualche motivo, non sarebbe mai stato rilasciato in quel modo (ad esempio, deve essere tradotto in altre lingue prima che possa essere spedito a chiunque - il Canada ha regole severe sul software di acquisto del governo che dà uguale considerazione al francese e all'inglese).

Questo è un punto di controllo di qualità, guardi tutti negli occhi e chiedi se sarebbero felici di spedirlo come è adesso, senza lavoro extra, senza controllo per vedere se hanno fatto quell'ultima cosa. Ho sentito questo chiamato il punto di controllo dell'ingegnere dell'aeroplano. Sembri un ingegnere negli occhi e chiedi loro se sono disposti ad accompagnarti durante il volo di prova.

L'idea è di essere il più agile possibile. Quanto più velocemente puoi ottenere qualcosa agli utenti reali; se si tratta di copie beta del codice per selezionare individui o test A / B sul tuo sito web, tanto meglio. Se mostri agli utenti codice troppo approssimativo, approssimativo come definito dalle loro aspettative per il tuo prodotto, allora ti daranno un feedback inutile. Parleranno di cose che non si cercano informazioni su come: non gli piace che il pulsante sia giallo o che la casella di testo non sia allineata con le etichette. Se è abbastanza buono, puoi ottenere un feedback utile. Quanto più velocemente ottieni questo feedback, tanto meglio! Puoi convalidare il prodotto / market fit e le ipotesi che hai fatto sulla funzione che hai provato a costruire.

La spedizione della funzione è la parte meno importante di questo. Spostare il team di sviluppo e terminare User Story è la cosa importante. Arrivare al punto in cui si può affermare che qualcosa è fatto è un grande motivatore.

Nella mia comprensione, ogni storia dovrebbe essere "fattibile" e "spedibile" nella misura in cui è pronta per essere consumata da qualcuno , non necessariamente dall'utente finale . Pertanto, la tua storia potrebbe fornire alcune funzionalità che possono essere poi consegnate al proprietario del prodotto, che può scegliere di rilasciarlo agli utenti finali o di ripetere nuovamente la funzione.

Detto questo, non sei precluso dall'includere lo stile nella storia "Come utente finale, potrò registrare". Nel nostro team, cerchiamo di rendere ogni storia il più piccola possibile per mantenere una maggiore prevedibilità e garantire che siamo in grado di offrire ciò che promettiamo. Se abbiamo un design pronto e pensiamo che sia banale da applicare, è incluso nella storia. Se pensiamo che possa esserci qualche iterazione sul design, questa è una storia a parte - forse più.

Oltre alle altre grandi risposte a questa domanda, puoi anche pensare alle funzionalità cosmetiche come parte dell'ambito della variabile scope-resources-time. Assicurati di soddisfare i requisiti di base di questa storia e aggiungi le cose belle se hai tempo.

Scrum non dovrebbe garantire la consegna di alcune funzionalità in un dato momento. Dovrebbe darti il massimo lavoro utile che è possibile in un dato momento. Se le funzioni cosmetiche "facoltative" non vengono eseguite durante lo sprint, dovrebbe essere perché non erano possibili.

Dipende dalla persona che stabilisce i requisiti, il "proprietario del prodotto". Come programmatore, potrei accontentarmi di una pagina di "form di registrazione" senza stile che dimostra semplicemente che la logica di business nei miei servizi web funziona correttamente e che la registrazione consente di essere autenticati rispetto ad altre risorse nel sistema. Infatti, "potenzialmente spedibile", poiché non implica necessariamente che lo stiamo per spedire letteralmente a un cliente, potrebbe consentire che questo sia il risultato della prima user story sull'argomento, in particolare se il team tecnico e il team di progettazione sono risorse separate con backlog separati.

In un progetto più maturo, potresti spedire una versione "progettata dallo sviluppatore" della funzionalità, con uno stile minimo, a un cliente pilota o beta, ma rivisitare la stessa funzionalità sia per le modifiche di funzionalità (basate sul feedback) che per la progettazione completamento.

Lo scopo della metodologia Agile è di consentire alle tue esigenze di guidare il processo di sviluppo del software, piuttosto che il contrario. Non cadere nella trappola di presupporre che una descrizione della metodologia sia il vero e unico requisito ortodosso. Più facile a dirsi che a farsi, ovviamente, soprattutto se sei in una grande organizzazione in cui Scrum è diventato una scusa per imporre il caos al team di sviluppo.