Quanti dettagli su una user story può aspettarsi uno sviluppatore?

Il più grande svantaggio dello sviluppo agile che ho riscontrato è che le persone non coinvolte nello sviluppo si concentrano sul mantra che una user story (3-10 giorni della persona ideale) non dovrebbe contenere più di 1-3 frasi come:

Come cliente, posso usare la ricerca a testo libero per trovare i prodotti che sto cercando.

Dando questa frase, i project manager si aspettano che io come sviluppatore mi impegni a fare una stima e sviluppare la storia. Presumono che uno sviluppo agile significhi che frasi come questa sono tutto ciò che devono fornire agli sviluppatori.

Non li biasimerò perché la nota letteratura sullo sviluppo agile crea l'impressione che questo funzionerebbe davvero. Ho letto qualcosa come 2 pagine in linguaggio naturale per racconto in "Planning XP", ma il gioco è fatto. Poiché "software funzionante" è preferito rispetto a "documentazione completa", questo argomento sembra essere generalmente evitato.

La realtà è, ovviamente, che se allo sviluppatore viene data la possibilità di farlo, un colloquio con il cliente fa apparire un lungo elenco di requisiti che il cliente ha sulla storia:

• Abbiamo bisogno di operatori booleani come AND e OR.
• Abbiamo bisogno di una ricerca confusa e di tutti i termini.
• Dobbiamo cercare con parole singole o per frase.
• Non vogliamo trovare prodotti che soddisfino i criteri X, Y e Z.
• Vogliamo ordinare il risultato. Oh, e comunque, l'utente può selezionare i criteri di ordinamento in una casella combinata con le opzioni a, b e c.

Quindi vedi che non sto parlando di dettagli tecnici o di progettazione del software o di dettagli di implementazione. Sono requisiti puri. Più parliamo, più il cliente si rende conto che in realtà c'è molto da dire su ciò che vuole.

Ma abbastanza spesso mi trovo nella situazione in cui tali informazioni non vengono fornite o in modo molto scadente. Né è possibile che io faccia l'intervista, né la persona che sarebbe in grado di fare l'intervista mi fornisce un risultato.

A volte, i manager hanno persino fornito dettagli tecnici come "vogliamo la ricerca di Lucene", ma non vogliono pensare se vogliono trovare solo nomi di prodotti o anche descrizioni di prodotti. A volte penso che siano solo pigri;)

Per me, questo è il problema principale nei progetti in cui lavoro (applicazione web e-business, 500-2000 giorni al giorno per progetto). Ho affrontato questo problema abbastanza spesso, e i manager sono consapevoli che la maggior parte degli sviluppatori ha un problema con la situazione. Ma credono che gli sviluppatori siano semplicemente troppo "perfezionisti". Sembrano infastiditi dal fatto che gli sviluppatori "vogliano sempre avere tutto specificato".

A causa della mancanza di numeri generalmente riconosciuti, è difficile discutere. Tutti sanno quanto dovrebbe durare un'iterazione. Ma nessuno può dire quanti requisiti sono necessari per stimare e sviluppare una storia.

Hai qualche riferimento?

Ti manca un po 'il punto di agilità. Quello che stai chiamando una user story, ne vedo almeno sei: una ricerca a ossa nude e una per ciascuno dei tuoi punti elenco. Sicuramente, fai abbastanza piani per evitare di dipingerti in un angolo che sarà costoso per uscire, ma l'idea generale è quella di fornire il minimo necessario per fornire un valore e farlo abbastanza rapidamente per ottenere un feedback rapido.

Quando dividi una storia in questo modo, non solo è più facile stimare, ma consente al proprietario del prodotto di stabilire le priorità in modo più preciso. Certamente a loro piace la possibilità di ordinare i risultati della ricerca, ma forse non è così importante come un altro elemento del backlog completamente estraneo alla ricerca.

Inoltre, sull'idea che i programmatori necessitino di tutto quanto specificato, prova a guardarlo dal punto di vista del cliente. Molte volte, è come se tu stessi andando a comprare una macchina, e il venditore chiede di che colore vuoi per la manopola del tergicristallo. Molti dettagli che potremmo trovare importanti sono completamente irrilevanti dal punto di vista del cliente. Ho lavorato laddove i requisiti sono eccessivamente specificati e, credetemi, non è molto divertente. Il tipo di latitudine di cui ti lamenti, molti programmatori adorerebbero avere.

Sembra che il primo problema sia che non dovresti applicare stime temporali alle storie degli utenti. Dovresti prendere una storia e applicare "punti storia", che sono una stima generale della complessità da 1 a INFINITY. I punti storia sono spesso gestiti come 1,2,3,5,8,13,20 ... (Ogni organizzazione ha le sue regole.) In genere applicano qualcosa come:

1 - Puoi farlo nel sonno e non vale la pena implementarlo. 2 - Lo capisci e puoi farlo rapidamente con poco rischio di superamento. 3 - Lo capisci, ma potrebbero esserci una sorpresa o due. 5 - Questo sta andando a una piccola ricerca e ha una piccola quantità di rischio. 8 - Questo è un compito importante, richiede molte ricerche e potrebbe non rientrare in uno sprint. 13 - Questo è enorme e sicuramente non si adatta a uno sprint. C'è un rischio enorme. eccetera.

In genere, qualsiasi user story che sia un 8 o superiore deve essere suddivisa in storie più piccole.

Se non hai le informazioni per farlo, dovresti sicuramente buttarle indietro al project manager e dire che hai bisogno di maggiori informazioni.

Dovresti davvero stimare il tempo solo dopo aver accettato la storia nello sprint, ma anche in questo caso, c'è meno enfasi su questo. L'idea è che una volta che la tua squadra si abitua al processo di puntamento, puoi misurare la sua produzione approssimativa per sprint nei punti della trama e pianificare in quel modo. Non vuoi pianificare in tempi più brevi rispetto allo sprint. L'idea qui è che se si eseguono correttamente le attività in modo che le storie multiple si adattino a uno sprint e si trovino nell'intervallo di 1-5 punti della storia, significa che sono abbastanza ben definite.

Inoltre, sembra che i PM della tua azienda non capiscano cos'è una "storia". Una parte critica di una "user story" sono i criteri di uscita. I criteri di uscita sono una o due frasi brevi che descrivono in modo inequivocabile come si può dimostrare che questa memoria è stata completata. Idealmente, questo dovrebbe essere qualcosa che i tuoi ragazzi del QA hanno detto "sì, possiamo provarlo". Il punto importante è che i PM devono capire che una user story è completa quando il software soddisfa i "criteri di uscita". "Ma non lo volevamo" non lo taglia. Se non volevano ciò che veniva consegnato, ma corrispondeva ai criteri di uscita, dovevano inserire una nuova storia.

C'è sicuramente un elemento di "formazione dei PM" qui. Devono imparare che storie vaghe danno luogo a grandi punti della storia e che se hanno definito la storia in modo ambiguo per ottenere ciò che vogliono, devono farlo di nuovo.

Ovviamente se le parti interessate non stanno raccogliendo abbastanza informazioni, allora devi, e se devi, allora c'è molto più lavoro, no? Molto prima dei miei giorni agili, ho avuto successo dando stime molto grandi e dicendo esplicitamente che le stime erano così grandi da consentire il rischio causato dalla mancanza di informazioni. Ho dovuto assumere il caso peggiore per tutte le domande e stimato sulla base di questo caso peggiore. Ho scoperto che i manager erano più disposti a fornire maggiori dettagli quando l'hanno visto con conseguente riduzione delle stime.

Questo non è un gioco del sistema ... questo è perfettamente valido. Se non sai se è "A" o "B", fai una stima in base alla quale fornisce la stima più grande per coprire il culo.

Nelle mie esperienze, molti dei cambiamenti o progetti a cui sto lavorando per affrontare proprio questa cosa. X personalizzata vuole qualcosa e ha un'idea di ciò che vuole, ma ti dà solo una piccola e-mail di requisiti. Ciò è dovuto principalmente al fatto che il cliente non "esattamente" sa cosa vuole. Ecco perché la maggior parte del lavoro del nostro servizio clienti sta soddisfacendo le richieste dei clienti e filtrando le informazioni necessarie, prevedendo al contempo ciò che il cliente VERAMENTE vorrà o ciò di cui ha realmente bisogno.

Supponiamo che un cliente (per me) desideri che una sezione della nostra applicazione Web restituisca un elenco di tutti i numeri di telefono. Non specificano mai se intendono quelli fisici, quelli logici, quelli assegnati a una persona o un luogo, ecc. Vogliono semplicemente tutti i numeri di telefono. Come sviluppatore, posso sedermi lì e pensare a una dozzina o più domande che avrei bisogno di porre al cliente, proprio come hai fatto tu. Ma, come dici tu, non è possibile. Ecco perché avere un buon servizio clienti che conosce il prodotto e il cliente è prezioso.

Quando quel tipo di chiamata arriva ai nostri rappresentanti del cliente, sono in grado di elaborarlo con il cliente, sapendo cosa devono chiedere loro per ottenere le risposte alle domande giuste. Hanno anche la premura di sapere cosa ha chiesto il cliente in passato e sanno abbastanza sui sistemi che sviluppiamo da poter dire sì o no a qualcosa senza nemmeno chiedere al cliente.

Certo, avrai molti casi in cui il cliente avrà ancora bisogno di qualcos'altro che sia tu che i servizi clienti hai perso, ma succederà sempre. Il tuo obiettivo e quello dei servizi client dovrebbero essere la riduzione al minimo del tempo di ritardo tra lo sviluppo di qualcosa e il recupero da parte del cliente con le modifiche che devono essere apportate. E questo dipende solo dalla comunicazione e dalla formazione con i servizi del cliente.

Forse non è fattibile per te come è dove sono io, ma avere una buona linea di comunicazione e fiducia con i rappresentanti dei tuoi clienti ti aiuterà quasi sempre a gradi, e ridurrà la tua frustrazione e aumenterà la soddisfazione del cliente. Inoltre, puoi dare più facilmente un lasso di tempo per i tuoi progetti piuttosto che scrollare le spalle e dire "Non conosco la portata completa del progetto, quindi non so quanto tempo ci vorrà". Qui abbiamo lo stesso problema e una migliore comunicazione e formazione è ciò che ci aiuta a creare scadenze ragionevoli e rispettarle in modo coerente.

Cliente

Voglio cercare prodotti

Product manager Ho analizzato la storia del cliente e ho escogitato i seguenti requisiti. Ogni requisito è stato registrato come una user story separata.

• Cerca prodotti
• Ordina il risultato
• Filtra i risultati della ricerca

Sviluppatore Ho ricevuto le storie degli utenti da un product manager. Ho analizzato ogni user story e ho creato un elenco di attività per ogni user story.

• Cerca prodotti
  1. Attività 1: modifiche al database
  2. Attività 2: modifiche lato server
  3. Attività 3: modifiche front-end

Il cliente, il product manager e lo sviluppatore sono tutti gli stakeholder in questo processo. Tutti devono contribuire al processo di analisi prima che il lavoro possa iniziare. Si noti che questo è un esempio molto semplificato.

Le storie degli utenti vengono analizzate e perfezionate nel seguente ordine (con alcune varianti ovviamente):

Help desk -> Product Owner -> Product Manager -> Responsabili del dipartimento (sviluppatori senior, responsabili della qualità, ecc.) -> Sviluppatori

Una volta che tutte le parti interessate hanno contribuito al processo di analisi, possiamo stimare quanto tempo ci vorrà per consegnare la storia. Il processo di stima che seguiamo si basa sulla velocità e sull'esperienza dei singoli sviluppatori.

Non sto dicendo che questo è un modo corretto di fare le cose, ma funziona davvero bene all'interno della nostra organizzazione.