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

Stavo leggendo i documenti Scrum e si dice che i compiti in Sprint dovrebbero essere "potenzialmente spedibili".

Sono confuso da ciò che questo significa. Supponiamo che in Sprint 1 l'obiettivo fosse "modulo di registrazione utente".

Quanti dettagli devo aggiungere affinché qualcosa sia pronto per la spedizione? Per esempio:

1. Posso mostrare la forma semplice con i campi senza uno stile elegante e contrassegnarli come completati
2. Posso solo fare la convalida lato client come contrassegnato come fatto ma lato server è anche l'opzione o entrambi
3. Posso anche aggiungere alcuni suggerimenti per gli strumenti jQuery, hover over, captcha, colori, etichette per il modulo
4. Quindi c'è molto stile su come mostrare i messaggi di errore sullo schermo

Posso fare all'infinito su un argomento. Quindi, come possiamo dividerlo e quando posso considerarlo pronto per la spedizione.

O devo scrivere ogni cosa più piccola possibile come mostrare errori, popup o testo in light box come attività secondarie e metterle come sprint. Ciò porterebbe a migliaia di compiti per l'intero progetto.

Voglio dire ancora una volta, se alcuni funzionano per Internet Explorer e altri per Firefox, allora devo dividere anche quelli come attività. Il tempo deve essere dedicato a loro e quando il manager mi chiede cosa hai fatto in quel momento, non avrò alcun compito da dire ma in realtà fanno tutti parte della registrazione dell'utente

Accetto questo con il proprietario del prodotto e il team Scrum, non Internet. Questo dovrebbe essere determinato nella tua Definizione di Fatto e dipenderà in larga misura da come funziona il team.

Sebbene la funzionalità dovrebbe essere "shippable" (odio questo termine in Scrum), si potrebbe sostenere che la funzionalità è shippable senza l'interfaccia utente. Molte persone soffrono di questo malinteso in Scrum - lo scopo di uno sprint è quello di ottenere il maggior numero possibile di storie (idealmente tutte) "Fatto", ma sicuramente non ha bisogno di essere incorporato in qualcosa che potrebbe essere rilasciato.

È importante appianare presto cose del genere, quindi tutti i membri del team stanno lavorando per un obiettivo comune. L'etica di Scrum è la comunicazione, quindi chiedi al team di Scrum e trai una conclusione logica.

Puoi lavorare in un team in cui l'interfaccia utente viene generalmente gestita separatamente, ad esempio da un team diverso o una volta che gli esperti dell'interfaccia utente decidono come deve essere il modulo, ecc. In alternativa, in un piccolo progetto / team è prevedibile che l'interfaccia utente venga creata come te partire.

Finché tutti i team conoscono la risposta, è irrilevante quale sia la risposta.

Se le caratteristiche cosmetiche fanno parte della funzione, probabilmente dovrebbero essere fatte come parte della storia. Il punto è, una volta che hai detto che una storia è finita, non dovresti più dover scrivere codice su una particolare caratteristica. Tuttavia, alla fine questo è deciso dal proprietario del prodotto: potrebbero volere le caratteristiche cosmetiche o potrebbero non esserlo. Ciò dovrebbe essere precisato nei criteri di accettazione.

Ciò non significa necessariamente che sia pronto per l'utente finale, ma significa che è pronto per qualcuno . Che qualcuno potesse essere un tester o un'altra squadra come la squadra di back-end.

Se lo stai chiedendo come sviluppatore, la risposta diventa "sai, perché il proprietario del prodotto ti dirà se desidera o meno le caratteristiche cosmetiche".

Se lo chiedi come proprietario di un prodotto, devi semplicemente decidere se desideri suddividere la funzionalità in più di una storia. Non v'è alcun obbligo, diverso da quello che deve soddisfare voi , come un mezzo per soddisfare il cliente .

Ricorda: l'obiettivo non è aderire rigorosamente alla mischia. L'obiettivo è fornire software di alta qualità all'utente finale. Usalo come guida quando devi affrontare domande come questa. L'aggiunta dei cosmetici nella stessa storia delle parti puramente funzionali ti aiuterà a fornire un codice di qualità ai tuoi clienti? Oppure, dividerlo in due storie aiuterà? O la risposta è chiara o non importa e puoi fare qualunque cosa funzioni per la tua squadra.

"Potenzialmente spedibile" significa che non è possibile spedire qualcosa che non può essere spedito. Per esempio:

Un modulo di registrazione web che sembra terribile e non ha alcuna convalida sui campi, potrebbe andare bene per alcune situazioni, come un progetto scolastico, ma in un'azienda multimilionaria danneggerebbe il marchio da mostrare agli utenti finali. Il codice potrebbe essere shippable senza essere qualcosa che vorresti spedire o che marketing o legale ti lascerebbero spedire.

È qualcosa che i programmatori (e le altre persone che sono in corso a questo punto, ad esempio i designer) sarebbero felici di rilasciare come è adesso, anche se, per qualche ragione, non verrebbero mai rilasciati in quel modo (ad es. deve essere tradotto in altre lingue prima di poter essere spedito a chiunque - il Canada ha regole rigide in merito al governo che acquista software che tiene conto in egual misura del francese e dell'inglese).

Questo è un punto di controllo della 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 è quella di essere il più agile possibile. Il più veloce è possibile ottenere qualcosa per gli utenti reali; che si tratti di copie beta del codice per selezionare singoli o test A / B sul tuo sito Web, meglio è. Se mostri agli utenti un codice troppo approssimativo, approssimativo come definito dalle loro aspettative per il tuo prodotto, ti daranno un feedback inutile. Parleranno di cose su cui non stai cercando informazioni come: a loro non 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. Più rapidamente ricevi questo feedback, meglio è! È possibile convalidare l'adattamento del prodotto / mercato e le ipotesi formulate in merito alla funzionalità che si è tentato di creare.

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

A mio avviso, ogni storia dovrebbe essere "fattibile" e "spedibile" nella misura in cui è pronta per il consumo da parte di qualcuno , non necessariamente dell'utente finale . Pertanto, la tua storia potrebbe offrire alcune funzionalità che possono quindi essere consegnate al proprietario del prodotto, che può scegliere di rilasciarlo agli utenti finali o di ripetere l'iterazione della funzione.

Detto questo, non ti preclude di includere lo stile nella storia "Come utente finale, sarò in grado di registrarmi". Nel nostro team, cerchiamo di rendere ogni storia il più piccola possibile per mantenere una maggiore prevedibilità e garantire meglio che siamo in grado di mantenere ciò che promettiamo. Se abbiamo un design pronto in anticipo e pensiamo che sia banale da applicare, è incluso nella storia. Se pensiamo che potrebbe esserci qualche iterazione sul design, questa è una storia separata, forse multipla.

Oltre alle altre grandi risposte a questa domanda, puoi anche pensare alle caratteristiche cosmetiche come alla parte variabile dell'ambito del triangolo ambito-risorse-tempo. Assicurati di soddisfare i requisiti di base di quella storia e aggiungi le cose carine se hai tempo.

Scrum non dovrebbe garantire la consegna di determinate funzionalità in un determinato momento. Dovrebbe darti il ​​massimo lavoro utile possibile in un dato momento. Se le caratteristiche cosmetiche "opzionali" non vengono eseguite durante quello sprint, dovrebbe essere perché non erano possibili.

Dipende dalla persona che imposta i requisiti, il "proprietario del prodotto". Come programmatore, potrei accontentarmi di una pagina di "modulo di registrazione" non stilata che dimostra semplicemente che la logica aziendale nei miei servizi web funziona correttamente e che la registrazione ti consente di essere autenticato rispetto ad altre risorse nel sistema. In effetti, "potenzialmente spedibile", dal momento che non implica necessariamente che lo spediremo 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 arretrati separati.

Su un progetto più maturo, potresti spedire una versione "progettata dallo sviluppatore" della funzionalità, con uno stile minimo, a un client pilota o beta, ma rivisitare la stessa funzionalità per entrambe le modifiche di funzionalità (basate sul feedback) e il completamento del progetto.

Lo scopo della metodologia Agile è consentire ai tuoi requisiti di guidare il processo di sviluppo del software, piuttosto che il contrario. Non cadere nella trappola di assumere 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.