Sono permesse le "storie utente tecniche" in Scrum?

Sono consentite storie tecniche, ma ti consiglierei di cercare di evitarle il più possibile.

Ad esempio, la tua storia per il salvataggio e il recupero delle immagini può essere facilmente scritta come due normali storie di utenti

1. Come revisore, desidero che le mie foto caricate vengano archiviate in modo permanente, in modo che altri utenti possano visualizzarle in qualsiasi momento.
   (Nota che questo presuppone che nella tua storia di caricamento originale, l'immagine non verrà memorizzata in modo persistente dopo il caricamento. Anche se questo potrebbe sembrare strano, è un modo valido per dividere storie per renderle gestibili.)
2. Come utente, voglio visualizzare le immagini caricate in un momento che è conveniente per me.
   (Ciò implica che le immagini memorizzate possono essere recuperate in seguito.)

Le storie tecniche dovrebbero essere riservate a lavori importanti per l'organizzazione, ma non direttamente visibili come funzionalità / funzionalità per gli utenti. Ad esempio, aggiungendo il bilanciamento del carico per gestire un numero o richieste più grandi.

La domanda, dato il tuo esempio particolare, sarebbe perché uno sviluppatore vuole sviluppare un meccanismo per archiviare e recuperare le immagini in modo che gli utenti possano aggiungere / visualizzare le immagini ovunque richiesto, a meno che un utente non voglia aggiungere o visualizzare le immagini? p>

Cioè, mentre la tua domanda è buona, l'esempio non lo è. Questa è una funzione utente e dovrebbe avere una storia utente. E se l'utente non ha realmente bisogno di quella funzionalità, lo sviluppatore non dovrebbe volerlo fare.

Una storia tecnica è più "Come sviluppatore, voglio ridurre la duplicazione nei moduli di archiviazione dei dati, in modo da non dover apportare ogni modifica in 6 punti."

La questione se questi dovrebbero essere inclusi nello sprint è difficile e dipende in qualche modo da chi consideri il tuo cliente. È l'utente finale, o l'azienda che ti assolda, o l'azienda che impiega l'azienda che ti impiega?

Un sacco di opinioni del settore - la guida è fatta da persone che lavorano per società di consulenza. Da quella prospettiva, posso vedere l'argomento secondo cui le storie degli sviluppatori sono cattive. Dovrebbero solo essere una parte di ciò che fai, giorno per giorno, invisibile all'azienda che paga per questo. Quelle aziende sanno istintivamente che eseguire le bollette troppo in alto fa sì che il tuo lavoro si asciughi, quindi ogni sviluppatore lavora su un principio di fare solo lo sviluppo tecnico che migliora i tuoi tempi di sviluppo, o migliora la tua capacità di rilasciare software privo di bug.

La mia esperienza è più legata al lavoro con i team interni, fornendo software direttamente all'azienda che paga i miei stipendi. In molte di queste aziende esiste una barriera di fiducia tra il business e l'ala tecnica del business. In tutti, c'è una mentalità diversa, in cui i costi decrescenti sono ugualmente un aumento del reddito.

In quegli ambienti, può essere utile definire storie di sviluppo significative. Aumenta la visibilità, genera fiducia e incoraggia gli sviluppatori e il management a pensare al valore di tali attività per il business e a stabilire le priorità di conseguenza.

In definitiva, ti suggerisco di provarlo. E, se non offre un valore, smetti di farlo.

Ma il mio istinto dice che se stavi considerando il valore di questo sviluppo per il business, non avresti nemmeno provato a farlo diventare una storia per sviluppatori. È buono per l'utente finale o non lo è. Se non lo è, non c'è alcun valore per il business.

Questa è una buona domanda. Non ho una risposta ufficiale, ma dove lavoro aggiungo storie di utenti tecnici e li chiamiamo debito tecnico. Se non fossero autorizzati, troverei un altro modo per farli aggiungere per il solo scopo di registrare e comunicare il mio lavoro all'azienda. Allo stesso modo, avere questa documentazione ci ricorda ciò che è necessario per i progetti futuri.

Ad esempio, la disconnessione in una nuova applicazione, se non è consentito aggiungere storie tecniche, è che mi canticcherò per una settimana dopo l'inizio di uno sprint, creando modelli di database e attendendo i miei dati modellatore per approvarli, iterare con il modellatore e al termine inviare gli script al dba e attendere che creino gli oggetti db. Nel frattempo, creerò un nuovo progetto di codice, alcune funzionalità ORM di base e il mio layout di controllo del codice sorgente e, quando tutto sarà pronto, avrò il tempo di creare una pagina di destinazione vuota e distribuire.

Di giorno in giorno mentre succede, se non registro le informazioni, il business si sta arrampicando sul fatto che il nostro team non sta lavorando al progetto quando in effetti lo siamo. Avere questi articoli nelle storie significa che possiamo controllare il nostro lavoro, avere un lavoro documentato e comunicare al business che stiamo facendo progressi.

Se c'è una migliore pratica migliore per farlo, sono tutto orecchie.

Il mio personale sentimento è che le squadre non dovrebbero essere troppo attaccate a ciò che la mischia consente ed essere più preoccupate di ciò che funziona per la squadra. Parte del motivo per cui la mischia ha ottenuto una cattiva reputazione è che i professionisti possono diventare focalizzati sul processo che è antitetico al idee alla base della gestione agile del progetto.

Ora vado via dal mio soapbox ma se ti chiedi se il sotto è davvero "scrum", ti preghiamo di (ri) leggere quanto sopra.

È importante separare le "funzionalità" definite dalle storie degli utenti e i "deliverable" che il team tecnico deve fornire per supportare tali funzionalità. In questo caso la necessità di salvare e recuperare le immagini è un materiale tecnico che tu (come il team tecnico) devi implementare. Praticamente ogni storia avrà bisogno di alcuni risultati tecnici.

La ragione per cui questo è importante è che un prodotto tecnico (da solo) non è qualcosa che produce valore dal punto di vista dell'utente. Se inizi a tenere traccia dei deliverable tecnici come storie degli utenti, puoi facilmente cadere nella trappola di considerare l'output tecnico come un valore aziendale. Muddying le acque in questo modo confonderà il lavoro che sostiene gli obiettivi di business (cioè le cose che costano soldi) con gli obiettivi di business reali (cioè cose che fanno soldi.)

Tutte le risposte di cui sopra non riescono a fare riferimento al documento di origine autorevole per il framework Scrum: The Scrum Guide .

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

L'attenzione dovrebbe essere sulla produzione di valore. A volte questo valore deriva dal lavoro tecnico, come l'aggiornamento dell'infrastruttura. Non escludere quegli articoli!

Il termine story utente non compare mai in The Scrum Guide perché

it is a framework within which you can employ various processes and techniques.

Utilizzare una user story è solo una delle possibili tecniche per registrare i PBI. Anche se è normale vedere il formato "Come A, Voglio, Così", può essere contrario alla sua intenzione originale . Questo formato problematico è stato anche affrontato all'indirizzo Agile 2017 .

La comprensione e l'utilizzo di taglio verticale saranno utili per ridurre la dimensione degli elementi del Product Backlog (PBI). Prendi in considerazione l'idea di affettare quel singolo elemento salva e recupera in salva e recupera elemento s .