Qual è un buon processo per scrivere le storie? [chiuso]

StackOverflow https://stackoverflow.com/questions/235299

Domanda

Stiamo solo definendo le nostre carte trama per il prossimo progetto.

  • Abbiamo una buona idea di ciò che il cliente desidera attraverso le officine
  • Abbiamo un documento relativo ai requisiti aziendali che verrà firmato da loro.

Il nostro processo di definizione dei piani è il seguente

  1. Prendiamo una funzionalità che il cliente desidera e scriviamo una storia
  2. Abbiamo una breve discussione di progettazione tra il team
  3. Determiniamo quindi una stima per la carta
  4. Se la carta è più lunga di 3 giorni, la suddividiamo ulteriormente e riprendiamo dal passaggio 2

Sfortunatamente il cliente desidera una stima di quanto tempo ci vorrà per l'intero progetto, quindi dobbiamo definire tutte le storie in anticipo.

Questo richiede un po 'di tempo e può essere abbastanza drenante

Quali altri metodi possono essere utilizzati per definire le carte trama? Questo può prendere Quali altri modi per raccogliere i requisiti sulle carte trama?

EDIT:

  1. Non è la prima volta che lo facciamo, è il normale processo
  2. Il cliente è un cliente interno
  3. Sono interessato a come scrivi le carte su cui finisci per codificare
È stato utile?

Soluzione

Suggerirei qualcosa che abbiamo chiamato " gioco di pianificazione del rilascio " ;. È molto simile a quello che fai per un'iterazione, tuttavia, l'abbiamo fatto a un livello superiore. Cioè, prenderemmo l'insieme di caratteristiche o punti funzione desiderati dall'utente per una determinata versione e stimeremmo sapendo che saremmo stati fuori . Puoi quindi aggiungere tutte queste stime insieme per avere un'idea approssimativa di quando pensi, in base alle tue informazioni attuali, di poter consegnare il tuo prodotto.

Questo dovrebbe dare ai tuoi clienti un'idea di quando pubblicherai, ma devi comunque insistere sul fatto che hai bisogno di un po 'ma di spazio di manovra perché, come i tuoi clienti, non puoi prevedere il futuro (o almeno io posso' t).

Altri suggerimenti

Non puoi sapere quando tutto sarà fatto e seguire comunque un processo agile. Anche se lavori molto duramente per stimare tutto, maggiore è il lavoro maggiore è la percentuale di errore. La maggior parte delle stime per i progetti di medie dimensioni finisce con il doppio di sconto e quelli più grandi fino a 10 volte di meno

Invece, chiederei al cliente una data target funzionale. La conversazione procede in questo modo:

Tu: quando hai bisogno di queste funzionalità?

(C) utente: quando puoi consegnarli?

Tu: inquadriamo prima i confini. Se consegnassi tutte queste funzionalità in 10 anni, sarebbe troppo tardi?

C: certo.

Tu: se domani consegnassi tutte queste funzionalità, sarebbe abbastanza presto?

C: certo.

Tu: tra circa un anno?

C: è ancora troppo tardi.

Tu: 3 mesi?

C: è un po 'troppo tardi, più o meno 2 mesi. Dobbiamo essere pronti a usarlo con il nostro team di gestione a gennaio.

Tu (pensa): Ah ah!

Tu: non possiamo offrire tutte queste funzionalità in 2 mesi. Penso che potremmo consegnare queste 4 storie in 1 mese e questi 3 negozi nel mese successivo.

C: avremo davvero bisogno della funzione X per gennaio.

Tu: OK, se aggiungiamo la funzione X dovremo rimuovere una funzione. Di quale non hai bisogno?

C: possiamo fare solo con una parte della funzione Y.

Tu: OK. Prenderemo questo elenco e elaboreremo una stima più dettagliata.

C (pensa): Ah! Ho ottenuto quello che volevo!

Ho scoperto più e più volte che il motivo alla base delle stime e della pianificazione " tutto " è che vogliono una promessa di consegna di qualcosa entro una data. Lavorare fino alla data prevista funziona molto meglio perché:

  1. Forza il cliente ad aiutare a fare i compromessi

  2. Espone il vero motivo delle stime

  3. Riduce il numero di cose da stimare.

  4. Aiuta a identificare quali funzioni sono importanti per quale sprint.

Non racconterei storie così piccole per la pianificazione del rilascio (che sembra ciò che vuoi fare). La pianificazione del rilascio sarà comunque meno accurata (perché le cose cambieranno nel tempo), quindi ha senso usare un'unità meno accurata per la stima.

Generalmente utilizziamo Planning Poker con 13 o 21 il valore più grande consentito prima che una storia debba essere divisa. Per la pianificazione del rilascio, stimiamo tra & Quot; giorni ideali " ;, per la pianificazione dell'iterazione in " ore ideali " ;. Funziona bene per noi.

Come pensi di rilasciare l'applicazione al client? Stai effettuando consegne incrementali? O è questa pianificazione per un risultato finale?

Suggerisco di suddividere lo sviluppo in sprint di due o tre settimane e quindi aggiungere una settimana in più per ogni sprint nel budget di consegna per comprarti un po 'di tempo extra ... nel caso in cui il cliente cambi idea su una funzione ( lo faranno). Si spera che questo renderà più facile la stima della data di consegna finale ...

Se riesci a convincere il tuo cliente che dovresti consegnare in modo incrementale scoprirai che creerai meno storie ridondanti man mano che le specifiche cambiano. Inoltre, non dovrai fare così tanto lavoro iniziale e, man mano che lo sviluppo avanza, puoi scrivere il prossimo lotto di storie mentre lo sviluppo è in corso.

Spero che questo aiuti.

Di solito chiedo solo i titoli delle storie in anticipo. Cerco di vedere se riesco a farle tralasciare almeno in un ordine di grandezza. Fornisco una stima molto approssimativa in base al numero di titoli e alla mia velocità / titolo stimati. Di solito faccio in modo che il cliente suddivida i titoli in (1) che ora devono avere, (2) necessari ma possono aspettare e (3) questi sarebbero carini.

Comincio affrontando il gruppo (1) e trovando abbastanza informazioni per suddividerle in una serie di rilasci. A questo punto in genere posso fornire una stima migliore utilizzando le informazioni più dettagliate per fornire stime per titolo. Pianifico solo le storie di gruppo (1). Se ci sono troppe storie di gruppo (1) da inserire in una versione, la suddividiamo in più versioni / iterazioni coerenti.

Quando arriviamo a circa un mese dall'inizio delle storie di gruppo (2), mi siedo di nuovo con il cliente (in una sessione di pianificazione più mirata, usu. parlando con loro tutto il tempo), per ricominciare il processo con le storie del gruppo (2).

Le storie che vengono aggiunte man mano che il progetto procede vengono inserite nel gruppo giusto e gestite in modo appropriato per quel gruppo - se è la versione corrente, dettagli sufficienti per lavorare, se in seguito, solo il titolo come segnaposto.

L'altra cosa che faccio è assicurarsi che il cliente capisca che si tratta di un processo cooperativo e finiremo con quello che vogliono. Possono scegliere quando fermarsi, anche se ci sono storie lasciate sul tabellone. Finché fornirò il valore a cui tengono, continuiamo a svilupparci. Devono fidarsi che sto facendo ciò che è giusto per loro e che lavoro diligentemente. Devo fidarmi che mi daranno le migliori informazioni possibili su ciò che vogliono non appena possibile.

Se stai cercando di essere fedele a XP, ti suggerirei di andare qui e leggere la differenza tra Pianificazione rilasci e Pianificazione iterazione. Non dovresti fare una stima delle singole attività finché non sei pronto per iniziare effettivamente la codifica.

Storie! = Compiti. Le storie sono suddivise in compiti, che poi fai & Lt; Stima di 3 giorni per. La stima delle storie è più aperta e dovresti essere in grado di decidere le soglie delle stime delle storie che funzionano meglio per te e il tuo team dopo averlo fatto per un po '. (IE & Lt; 1 settimana, 2 settimane, & Gt; 2 settimane, ecc.)

La parte più importante della stima è il follow-up con il tempo effettivo impiegato e le modifiche al processo di stima. XP è tutto basato sul feedback.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top