Le "storie di utenti tecnici" sono consentite in Scrum?

Le storie di utenti tecnici sono consentite in Scrum? In tal caso, qual è il modello standard per scrivere storie di utenti tecnici in Scrum? È lo stesso As a <user> I want to do <task> so that I can <goal>??

In alcuni blog ho letto che la storia di uno sviluppatore non è un utente , ma ho anche letto che Scrum non li impone. Ci sono alcuni blog in cui hanno condiviso storie utente con il sistema come utente , è come as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Quindi qual è lo standard?

Ad esempio, ci sono storie utente come:

Come revisore voglio caricare foto di qualsiasi hotel / cibo in modo che altri utenti possano vederli e apprezzarli

Come utente voglio aggiungere commenti fotografici in modo da poter spiegare meglio la mia visione

Ora, per entrambe queste storie utente, esiste un grande elemento tecnico: il salvataggio e il recupero dell'immagine

Quindi posso aggiungere un articolo tecnico intitolato "Meccanismo di memorizzazione e recupero delle immagini", con la seguente descrizione?

Come sviluppatore voglio sviluppare un meccanismo per archiviare e recuperare immagini in modo che gli utenti possano aggiungere / visualizzare immagini ovunque sia richiesto

Sono consentite storie tecniche, ma ti consiglio 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 storie utente normali

1. Come revisore, voglio che le mie foto caricate vengano archiviate in modo persistente, in modo che altri utenti possano visualizzarle in qualsiasi momento.
   (Tieni presente che ciò presuppone che nella tua storia di caricamento originale, l'immagine non verrà archiviata in modo persistente dopo il caricamento. Sebbene possa sembrare strano, è un modo valido di dividere le storie per renderle gestibili.)
2. Come utente, desidero visualizzare le immagini caricate in un momento adatto a me.
   (Ciò implica che le immagini memorizzate possono essere recuperate in un secondo momento.)

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

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 immagini ovunque sia richiesto, a meno che un utente non voglia aggiungere o visualizzare immagini?

Cioè, mentre la tua domanda è buona, l'esempio no. Questa è una funzione utente e dovrebbe avere una storia utente. E se l'utente non ha davvero bisogno di tale 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 modifiche in 6 punti".

La domanda se questi debbano essere inclusi nello sprint è difficile e dipende in parte da chi consideri il tuo cliente. È l'utente finale, o l'azienda che ti impiega, o l'azienda che impiega l'azienda che ti impiega?

Molte persone guidano l'opinione pubblica del settore da parte di persone che lavorano per società di consulenza. Da quel punto di vista, posso vedere l'argomento secondo cui le storie degli sviluppatori sono brutte. Dovrebbero essere solo una parte di ciò che fai, giorno per giorno, invisibile alla compagnia che lo sta pagando. Quelle aziende sanno istintivamente che far salire le bollette troppo in alto assicura che il tuo lavoro si prosciughi, quindi ogni sviluppatore lavora secondo un principio di fare solo sviluppo tecnico che migliora i tuoi tempi di sviluppo o migliora la tua capacità di rilasciare software privo di bug.

La mia esperienza è maggiore con il lavoro in team interni, fornendo software direttamente all'azienda che paga i miei stipendi. In molte di quelle aziende, esiste una barriera di fiducia tra il business e l'ala tecnica del business. In tutti loro, esiste una mentalità diversa, in cui la riduzione dei costi equivale ad aumentare il reddito.

In quegli ambienti, può essere utile definire storie significative per gli sviluppatori. Aumenta la visibilità, genera fiducia e incoraggia sia gli sviluppatori che i dirigenti a pensare al valore di tali compiti per l'azienda e ad assegnare le priorità di conseguenza.

Alla fine, ti consiglio di provarlo. E, se non offre 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 renderlo una storia per sviluppatori. È buono per l'utente finale o non lo è. In caso contrario, non vi è alcun valore per l'azienda.

Questa è una buona domanda Non ho una risposta ufficiale, ma dove lavoro aggiungiamo storie di utenti tecnici e le chiamiamo debito tecnico. Se non fossero autorizzati, troverei un altro modo per aggiungerli al 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 ci è permesso di aggiungere storie tecniche, è che starò canticchiando per una settimana dopo l'inizio di uno sprint creando modelli di database e aspettando l'approvazione del mio modellatore di dati li, iterare con il modellatore e quando fatto 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à detto e avrò il tempo di creare una landing page vuota e distribuirla.

Giorno per giorno mentre succede, se non registro le informazioni, l'azienda si sta chiedendo che il nostro team non stia lavorando al progetto quando in realtà lo siamo. La presenza di questi elementi nelle storie ci consente di controllare il nostro lavoro, documentare il lavoro e comunicare all'azienda che stiamo facendo progressi.

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

La mia sensazione personale è che i team non dovrebbero essere troppo attaccati a ciò che la mischia lo consente ed essere più preoccupati per ciò che funziona per il team. Parte della ragione per cui la mischia ha ottenuto una cattiva reputazione è che i professionisti possono concentrarsi sul processo, che è antitetico alle idee alla base della gestione agile del progetto.

Scenderò dalla mia soapbox ora ma se ti chiedi se il sotto sia davvero 'mischia', per favore (ri) leggi quanto sopra.

È importante separare le "caratteristiche" definite dalle storie utente e i "risultati" che il team tecnico deve fornire per supportare tali funzioni. In questo caso la necessità di salvare e recuperare le immagini è un prodotto tecnico che l'utente (in qualità di team tecnico) deve implementare. Praticamente ogni storia avrà bisogno di alcuni risultati tecnici.

La ragione per cui questo è importante è che un prodotto tecnico (di per sé) non è qualcosa che produce valore dal punto di vista dell'utente. Se inizi a tenere traccia dei risultati tecnici come storie degli utenti, puoi facilmente cadere nella trappola del trattamento della produzione tecnica come produzione di valore commerciale. Sfumare le acque in questo modo confonderà il lavoro che supporta gli obiettivi di business (cioè cose che costano soldi) con obiettivi di business reali (cioè cose che fanno soldi).

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

Il Product Backlog elenca tutte le caratteristiche, funzioni, requisiti, miglioramenti e correzioni che costituiscono le modifiche da apportare al prodotto nelle versioni future.

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

Il termine user story non appare mai in The Scrum Guide perché

è un framework all'interno del quale è possibile impiegare vari processi e tecniche.

L'uso di una user story è solo una possibile tecnica per la registrazione dei PBI. Sebbene sia comune vedere il formato "As a, I Want, So that", può essere in contrasto con il suo intento originale . Questo formato problematico è stato affrontato anche ad Agile 2017 .

La comprensione e l'utilizzo dell'affettatura verticale saranno utili per ridurre le dimensioni degli elementi del Product Backlog (PBI). Considerate affettare quel singolo salvare e recuperare elemento in Salva e recuperare voce s .