Questo si è rivelato più lungo di quanto avessi pianificato (era iniziato come un commento), ma spero che la lunghezza / i dettagli aggiunti siano utili e li trovi giustificati.
Agile non è specifico delle app CRUD
La maggior parte della letteratura sull'agile sembra essere distorta verso le applicazioni aziendali di tipo CRUD in cui l'utente è praticamente consapevole di ciò che accade dietro le quinte. (Va bene perché la maggior parte del codice in fase di scrittura appartiene probabilmente a questa classe.)
Penso che questo sia perché è più facile creare esempi di questo tipo facili da seguire, non proprio perché la metodologia si rivolge a quel tipo di sistemi. Se crei un esempio non così facile da seguire, rischi di far bloccare il lettore cercando di capire l'esempio quando il tuo punto doveva insegnare al lettore concetti concreti.
User Stories! = Requisiti
Per questo tipo di applicazione la relazione tra user story (requisiti) e attività di sviluppo è per lo più semplice: basta dividere la user story in alcune attività.
Una user story non è la stessa di un requisito. È vero, ci possono essere alcune sovrapposizioni a seconda di quanto sia "alto livello" il requisito, ma generalmente non è lo stesso. Ho l'impressione che stai affrontando la stessa trappola in cui sono caduti molti dei miei ex manager: pensare alle storie degli utenti semplicemente come sinonimi di "requisiti", che è simile a quando gli utenti SVN provano a passare a Git, ma continuano pensando in termini di SVN. (Si imbattono quindi in problemi dovuti alle cattive ipotesi di partenza.)
IMHO, una differenza chiave tra i requisiti e le storie degli utenti è che i requisiti specificano, in dettaglio, come devono comportarsi determinati componenti del sistema; sono specifiche che includono input, output, presupposti / pre-condizioni, possibili eccezioni sollevate, ecc. Si concentrano su ciò che fa il sistema .
OTOH, le storie degli utenti si concentrano sul risultato atteso per l'utente finale senza cercare di creare una specifica comportamentale dettagliata per i componenti di sistema. Si concentrano sull'esperienza utente prevista .
Quello che ero solito fare, e questa era una pratica adottata dal mio team, era di scomporre le storie degli utenti in attività. I tuoi compiti potrebbero essere specifici o vaghi come volevi / ne avresti avuto bisogno, ma dovevano essere i tuoi indicatori di progresso per il vero lavoro svolto per portare la storia a uno stato compiuto.
Esempio
Ricordo approssimativamente un USA su cui ho lavorato anni fa, in cui gli utenti dovevano autoassegnare i casi di test in modo che tutti i membri del team fossero a conoscenza di quali TC stavano lavorando per evitare sforzi duplicati; l'interfaccia utente era un'applicazione web (n interna). L'utente ha visto solo un pulsante, ma la storia è stata divisa in diverse attività che includevano alcuni dettagli tecnici di implementazione, ecc.
Visibilità dell'utente
Esiste tuttavia un altro tipo di applicazione in cui la maggior parte del codice ha a che fare con elaborazioni complesse che non sono direttamente visibili all'utente.
È possibile renderlo visibile all'utente in qualche modo?
Prendi in considerazione un GPS. Quando ti sei perso il turno, non vedrai il processo di ricalcolo del percorso effettivo, ma l'utente riceve un feedback utile (ad esempio "Ricalcolo ...").
I compilatori possono visualizzare avvisi o errori o includere nuove impostazioni / opzioni nella GUI affinché gli utenti possano vedere che è stato aggiunto qualcosa di nuovo. Penserei che gli utenti per i compilatori sarebbero programmatori, giusto? Non vedrebbero il supporto per un nuovo standard aggiunto?
Sebbene il supporto di un nuovo standard sia probabilmente a livello di funzionalità e debba essere suddiviso in storie utente, ti sei assicurato che, almeno in alcuni casi, non stai provando a usare storie quando invece dovresti usare funzionalità ?
L'analisi delle immagini in un'auto potrebbe essere formulata in modo tale da far sapere all'utente che le possibilità di finire in un incidente d'auto sono state ridotte. Per esempio:
Come passeggero in un'auto a guida autonoma, ho bisogno della probabilità che il veicolo causi un incidente schiantandosi contro un oggetto non riconosciuto per essere il più vicino possibile allo zero, in modo da poter viaggiare in sicurezza.
Che gli Stati Uniti catturano, ad alto livello, cose che dovresti normalmente specificare usando una combinazione di requisiti funzionali e non funzionali, tra cui sicurezza, sicurezza, ecc.
Tuttavia, un requisito potrebbe riguardare maggiormente il sistema; per esempio:
La funzione abcnel componente Adeve avere il valore della soglia di tolleranza ridotto nell'algoritmo di confronto delle immagini per rilevare meglio gli oggetti che si muovono lentamente.
Per me, questo sarebbe facilmente un compito sotto la user story che ho menzionato sopra, intitolato qualcosa come: Ridurre la tolleranza nella funzioneA.abc e quindi includere altri dettagli rilevanti in essa.
Per un sistema di simulazione fluido, potresti persino avere una barra di avanzamento che fornisce feedback sulle attività in background che il sistema sta eseguendo, se questo ha senso. (C'è sempre un modo per informare l'utente di qualcosa, anche se potresti voler evitare di essere spammato.)
Non so abbastanza sui domini particolari che hai menzionato per trovare esempi migliori e / o più realistici, ma se c'è un take-away qui è che puoi usare diversi modi per fornire feedback degli utenti su qualcosa di meno visibile che il sistema potrebbe fare, cioè potrebbero esserci modi per rendere le cose invisibili un po 'più visibili. (Anche se si riduce a scrivere una serie di note di rilascio che documenta quanto più velocemente le prestazioni del sistema sono ora dovute ai tuoi sforzi, ecc.)
Relazione tra storie e compiti
Qui può essere davvero difficile mettere in relazione compiti e storie degli utenti.
Il nostro approccio era quello di mantenere le storie degli utenti focalizzate su ciò che la richiesta era, perché era stata fatta e quali cose dovevano essere vere per considerare "fatto" gli Stati Uniti. Il come è stato sempre lasciato fuori dagli Stati Uniti e lasciato agli sviluppatori.
Gli sviluppatori avrebbero suddiviso il problema descritto negli Stati Uniti in una serie di attività su cui avrebbero lavorato.
Lo dico come qualcuno che, per la maggior parte, ha eseguito una programmazione lato server back-end, che è probabilmente "invisibile" come si può ottenere per l'utente finale.
A seconda di ciò che dovevo fare, a volte usavo AJAX per mostrare una semplice animazione / caricamento "caricamento ..." in modo che l'utente sapesse che dovevano aspettare un po 'per completare qualcos'altro, senza avere l'impressione sbagliata. A volte era così semplice. Un compito per questo sarebbe appropriato.
Paradigma, pratica ed esperienza diversi
Esistono tecniche per superare questo problema o è solo qualcosa che dobbiamo accettare e trarne il meglio?
Oltre ad accettare il cambio di paradigma, la pratica e l'esperienza maturata, probabilmente non c'è molto altro da dire. Ho visto spesso persone che cercavano di prendere scorciatoie durante il processo. Lo sconsiglio, soprattutto se stai iniziando. Man mano che acquisisci più esperienza, puoi consentire una certa flessibilità, ma evita di minarti.
Data la tua precedente formulazione, stai ancora pensando alle storie come se fossero "requisiti ribattezzati", che credo sia un falso presupposto. Penso che questo sia un sintomo di una questione più profonda riguardante le differenze fondamentali tra approcci Agile e non Agile.
In secondo luogo, penso che dovresti accettare che l'agile è un cambio di paradigma rispetto alla cascata, il che significa che, sebbene il processo abbia obiettivi simili, lo affrontano in modi molto diversi. (Pensa a SVN vs Git, se questo aiuta.)
Cerca di migliorare la tua attuale comprensione delle differenze concettuali tra requisiti e storie degli utenti e accetta che non siano la stessa cosa.
Imparare dai tuoi Sprint - Retrospettive
Quello che non posso sottolineare abbastanza è la retrospettiva tra Scrum Master e gli sviluppatori alla fine di ogni sprint. Questo è il luogo in cui discutono di cose che "sono andate bene" o "non sono andate bene" in modo onesto / trasparente, e quali cambiamenti fattibili saranno implementati per il prossimo sprint per affrontare i punti "non è andato bene" .
Ciò ci ha permesso di adattarci e persino di imparare dalle reciproche esperienze e, prima di rendercene conto, avevamo migliorato in modo significativo come misurato dalla coerenza generale della velocità del nostro team.