Quanti dettagli su una storia di un utente possono aspettarsi uno sviluppatore?

Ti manca un po 'il punto di agilità. Quello che stai chiamando una user story a , vedo almeno sei: una ricerca bare-bone e una per ciascuno dei tuoi punti elenco. Con tutti i mezzi, fare piani sufficienti per evitare di dipingere te stesso in un angolo che sarà costoso per uscire, ma l'idea è quella di fornire il minimo necessario per fornire un certo valore, e farlo abbastanza velocemente per ottenere un feedback rapido.

Quando si divide una storia in questo modo, non solo rende più facile la stima, ma consente al proprietario del prodotto di dare la priorità in modo più dettagliato. Certo, a loro piace la possibilità di ordinare i risultati della ricerca, ma forse non è così importante come un altro elemento nel backlog che non è completamente correlato alla ricerca.

Inoltre, sull'idea che i programmatori abbiano bisogno di tutto ciò che è specificato, prova a guardarlo dal punto di vista del cliente. Un sacco di volte, è come se stessi andando a comprare una macchina, e il venditore ti chiede di che colore vuoi il pomello del tergicristallo. Molti dettagli che potremmo trovare importanti sono completamente irrilevanti dal punto di vista del cliente. Ho lavorato dove i requisiti sono altamente sovradimensionati e credimi, non è molto divertente. Il tipo di latitudine di cui ti lamenti, molti programmatori vorrebbero avere.

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

1 - Puoi farlo nel sonno e non vale la pena di implementarlo. 2 - Lo capisci e puoi farlo rapidamente con poco rischio di invadere. 3 - Lo capisci, ma potrebbe esserci una sorpresa o due. 5 - Questo sta andando a un po 'di 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 andrà bene in uno sprint. C'è un rischio enorme. ecc.

Generalmente, qualsiasi storia utente di 8 o superiore deve essere suddivisa in storie più piccole.

Se non hai le informazioni per farlo, dovresti sicuramente restituirlo al project manager e dire che hai bisogno di ulteriori informazioni.

Dovresti solo stimare il tempo una volta che hai accettato la storia nello sprint, ma anche in questo caso, c'è meno enfasi su questo. L'idea è che una volta che il tuo team si abitua al processo di puntamento, puoi misurare il suo risultato approssimativo per sprint nei punti della storia e pianificare in questo modo. Non vuoi pianificare un periodo di tempo più breve dello sprint. L'idea è che se stai abbattendo le attività correttamente in modo che le storie multiple si adattino a uno sprint e siano nell'intervallo di 1-5 story point, significa che sono sufficientemente ben definite.

Inoltre, sembra che i PM della tua azienda non capiscano cosa sia una "storia". Una parte critica di una "user story" è il criterio di uscita. Il criterio di uscita è una breve frase o due che descrive in modo inequivocabile come si può dimostrare che questo spazio di archiviazione è stato completato. Idealmente, questo dovrebbe essere qualcosa che i tuoi ragazzi del QA hanno detto "sì, possiamo testarlo". Il punto importante è che i PM devono capire che una storia utente è completa quando il software soddisfa i "criteri di uscita". "Ma non volevamo che" non lo tagli. Se non volevano ciò che è stato consegnato, ma corrisponde ai criteri di uscita, devono inserire una nuova storia.

Qui c'è sicuramente un elemento di "addestramento dei PM". Devono imparare che le storie vaghe generano grandi punti narrativi e che se hanno definito la storia in modo ambiguo per ottenere quello che vogliono, devono farlo di nuovo.

Ovviamente se gli stakeholder non stanno raccogliendo informazioni sufficienti, allora devi farlo, e se è necessario, allora c'è molto più lavoro, vero? Molto prima dei miei agili giorni, ho avuto successo fornendo stime molto ampie e affermando esplicitamente che le stime erano così ampie da consentire il rischio causato dalla mancanza di informazioni. Ho dovuto assumere il caso peggiore per tutte le domande e stimato in base a questo caso peggiore. Ho scoperto che i gestori erano più disposti a fornire maggiori dettagli quando lo vedevano, con conseguente riduzione delle stime.

Questo non è il gioco del sistema ... questo è perfettamente valido. Se non sai se si tratta di "A" o "B", stimerai in base a quale sia la stima più grande per coprire il tuo culo.

Nelle mie esperienze, molti dei cambiamenti o progetti su cui sto lavorando affrontano proprio questa cosa. Custom X vuole qualcosa e loro hanno un'idea di ciò che vogliono, ma ti danno solo una piccola email di valore. Questo è principalmente dovuto al fatto che il cliente non "esattamente" sa cosa vuole. Questo è il motivo per cui la maggior parte del lavoro del nostro dipartimento di assistenza clienti sta arricchendo le richieste dei clienti e filtrando le informazioni necessarie, prevedendo anche ciò che il cliente VERAMENTE vorrà o ciò di cui ha realmente bisogno.

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

Quando questo tipo di chiamate arriva ai nostri rappresentanti del cliente, sono in grado di elaborarlo con il cliente, sapendo che cosa hanno bisogno di chiedere loro di rispondere alle domande giuste. Hanno anche la premura di sapere che cosa il cliente ha chiesto in passato e sanno abbastanza dei sistemi che sviluppiamo che possono dire sì o no a qualcosa senza nemmeno chiedere al cliente.

Certo, ci saranno molti casi in cui il cliente avrà ancora bisogno di qualcos'altro che sia tu e il cliente mancati, ma succederà sempre. Il tuo obiettivo e l'obiettivo dei servizi client dovrebbero ridurre al minimo il ritardo tra lo sviluppo di qualcosa e il recupero dal client con le modifiche che devono essere apportate. E questo si riduce alla comunicazione e alla formazione con i tuoi servizi clienti.

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

Clienti

Voglio cercare prodotti

Responsabile del prodotto Ho analizzato la storia del cliente e ho trovato i seguenti requisiti. Ogni requisito è stato registrato come una user story separata.

• Cerca prodotti
• Ordina risultato
• Filtra i risultati di ricerca

Developer Ho ricevuto storie di utenti da un product manager. Ho analizzato la storia di ciascun utente e ho trovato un elenco di attività per ogni story utente.

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

Cliente, product manager e sviluppatore sono tutti portatori di interessi 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 nostre storie di utenti vengono analizzate e perfezionate nel seguente ordine (con alcune varianti ovviamente):

Help Desk - > Proprietario del prodotto - > Product Manager - > Responsabili di reparto (sviluppatori senior, lead di qa, ecc.) - > Gli sviluppatori

Una volta che tutti gli stakeholder rilevanti hanno contribuito al processo di analisi, possiamo stimare quanto ci vorrà per consegnare la storia. Il processo di stima che seguiamo si basa sulla velocità e sulla competenza dei singoli sviluppatori.

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