Come possiamo fornire stime di tempo valide durante la pianificazione Sprint senza fare una progettazione "troppo"?

Il mio team si sta aggiornando con Scrum, ma la maggior parte di noi ha più familiarità con metodologie non agili o "pseudo-" agili. La parte che costituisce il maggiore ostacolo per noi è la gestione di una riunione Sprint Planning efficiente in cui suddividiamo gli articoli arretrati in attività e stimiamo le ore. (Sto usando la terminologia del VS2010 Scrum Template; mi scuso se uso la parola sbagliata da qualche parte.)

Quando proviamo a capire quanto tempo impiegherà un'attività, spesso cadiamo nella trappola della progettazione della funzione a livello di codice - layout della tabella, interfacce, ecc. - per capire quanto tempo ci vorrà .

Sono abbastanza sicuro che questo non sia il posto giusto dove fare quel tipo di design. Dovremmo programmare le attività per queste riunioni di progettazione durante lo sprint. Tuttavia, abbiamo difficoltà a capire in che altro modo elaborare stime significative per i compiti.

Esistono abitudini / tecniche / ecc. Pratiche. per esprimere un giudizio su quanto tempo impiegherà una funzione, senza sapere come prevedi di implementarla? Se le nostre stime temporali cambieranno in modo significativo una volta completato il progetto, come possiamo preventivamente pianificare preventivamente il nostro backlog Sprint?

MODIFICARE:

Giusto per chiarire, dal momento che alcuni dei commenti / risposte sono molto validi, ma penso che affrontare la domanda sbagliata.

Noi sappiamo che quello che stiamo facendo non è giusto, e che dovremmo costruendo volta nella sprint per questo disegno. Concettualmente tutti gli sviluppatori lo capiscono. Inoltre, stiamo introducendo un membro del team con esperienza Scrum per tenerci in pista se iniziamo a uscire dalle erbacce.

Il problema è che, senza passare attraverso questo processo di progettazione, ci risulta difficile fornire stime temporali concrete per qualsiasi cosa. Diciamo costantemente cose del tipo "beh, se lo progettiamo in questo modo potrebbero impiegare 8 ore, ma se dovessimo finire in questo modo invece ci vorranno circa 32 ma potrebbe non essere così male una volta che iniziamo a provare a scriverlo ... ".

Suppongo anche che questo processo migliorerà una volta che avremo una certa velocità storica su cui lavorare, ma molte delle tecnologie e dei modelli architettonici che stiamo usando sono nuovi per noi. Ma se le stime potenzialmente sbagliate sono solo una parte naturale dell'adattamento di questo processo, allora dovremo solo ricondizionarci per accettarlo :)

1. Pianifica una riunione di "grooming" ricorrente in cui hai queste discussioni di progettazione. La squadra in cui sono li ha una volta per sprint, il giorno prima della pianificazione. L'obiettivo è quello di avere una progettazione abbastanza precisa da consentire al team di concordare le stime dei tempi per la storia complessiva. Potresti prendere in considerazione la suddivisione dei compiti in questa riunione, in modo che la pianificazione diventi semplicemente un esercizio per decidere quanto raccogliere. In altre parole, dovresti fare il disegno negli sprint PRIMA di iniziare a fare il lavoro vero e proprio.

2. Valuta la possibilità di utilizzare la pianificazione del poker , ovvero punti / unità di "sforzo" anziché giorni lavorativi per stimare le attività. Prova anche a scomporre le storie il più possibile. Più una storia è lunga / complessa, meno è probabile che la stima sia accurata.

3. Nella pianificazione, lo Scrum Master dovrebbe tenere la pianificazione in linea di battuta interrompendo qualsiasi discussione che si spinge troppo a "risolvere". A quel punto i membri del team sono tenuti a raggiungere rapidamente un accordo sulla stima, in genere fornendo un limite superiore / numero del caso peggiore. È molto più facile raccogliere più lavoro se le attività finiscono per essere più facili di quanto pianifichi, piuttosto che gestire i programmi che slittano a causa delle attività che richiedono più tempo del previsto e che le storie passano in più sprint.

4. Parla di come le stime si sono svolte nella retrospettiva alla fine dello sprint. Soprattutto se ce ne fossero stati straordinariamente lontani. Il team ha imparato qualcosa da come è andata la storia rispetto a come si aspettavano che andasse? Lo scrum master dovrebbe concentrarsi sulle modifiche attuabili che possono essere apportate al processo di progettazione / stima.

Penso che il problema sia che stai cercando di stimare il tempo. Non farlo.

Stimare la complessità. Guarda un requisito, (si spera una storia utente) e valuta quanto è complicato il team pensa che sarà capire come costruirlo e testarlo, rispetto a quanto sono complicati altri requisiti o storie utente. A volte ti sbagli, ma spesso avrai una buona idea di quanto sarà difficile qualcosa. Scoprirai inoltre che gli oggetti con la stessa complessità tendono a richiedere lo stesso sforzo per il completamento.

Pertanto, le classifiche di complessità diventano i "punti della storia" associati alle storie degli utenti nel backlog del prodotto. Dopo aver superato alcuni sprint, avrai un'idea di quanti punti della storia puoi superare in uno sprint, e questa è la tua velocità. A quel punto, avrai un'idea molto migliore di quanto tempo impiegherà ogni articolo.

Consiglio vivamente le storie utente di Mike Cohn applicate .

So che la tua domanda riguarda specificamente l'evitare il design nella pianificazione. Ma questo è una specie di problema XY .

Sono stato dove sei. Piuttosto che darti qualcosa che possa fornire un miglioramento incrementale, vorrei aiutarti a scavalcare alcuni di quegli stati intermedi.

Qui ci sono tre cose che il nostro team fa specificamente in relazione alla pianificazione ed esecuzione del lavoro. Questi ci hanno aiutato a evitare il thrashing del progetto e a sfuggire a stime del tempo imprecise.

Criteri di accettazione automatizzabili

Le nostre storie sono indicate dal loro numero di criteri di accettazione automatizzabili . Ciò significa che se dovessimo scrivere test automatici per confermare che la storia è stata fatta, quali sarebbero?

Ad esempio, "Quando l'utente fa clic su" Riproduci "su un iPad con iOS 6+, inizia la riproduzione del video." Potrebbe essere difficile automatizzare effettivamente questo test, ma è un criterio di accettazione (AC) della storia e contribuisce a un punto.

Usiamo la scala di Fibonacci e arrotondiamo sempre per eccesso. Quindi se una storia ha quattro criteri di accettazione automatizzabili, è una storia in cinque punti.

La dimensione massima dei nostri punti trama è di otto punti, ma raramente li abbiamo. Se una storia ha più di cinque criteri di accettazione automatizzabili, troviamo un modo per dividerli.

Pre-Grooming

Lunedì abbiamo un incontro preliminare, ma i nostri incontri di preparazione sono dove avviene la pianificazione della squadra. Prima di governare, i membri del team prepareranno una storia descrivendo il risultato e prendendo a pugni i criteri di accettazione automatizzabili.

Grooming porta l'esperienza del team a fare affidamento sulle storie preparate, a svelare requisiti non specificati, a rompere storie, ecc.

A volte elenchiamo le attività oltre ai criteri di accettazione, ma questi non sono stimati nel tempo. Non stimiamo mai il tempo. Le attività sono solo dichiarazioni di lavoro che devono essere eseguite a sostegno dei criteri.

Limitazione dei lavori in corso

La mischia tradizionale tenta di limitare il tempo di lavoro alla durata dello sprint. Abbiamo scoperto che questo ci ha costretto ad affrettarci a rispettare le scadenze dello sprint, uccidendo i nostri fine settimana perché lo sprint termina venerdì.

Un altro approccio è limitare i lavori in corso in un dato momento. Siamo migrati verso quest'ultimo e siamo stati significativamente più felici per questo.

Una volta che una storia passa dal backlog al work in progress, la caratterizziamo come in uno dei diversi stati:

• In attesa: il lavoro di gruppo non può avvenire perché stiamo aspettando alcune attività extra di gruppo
• In sviluppo: lavorare per raggiungere i criteri di accettazione
• Test delle esigenze: crediamo di aver incontrato l'AC, in attesa che qualcun altro lo verifichi
• In Test: la storia viene valutata in base all'AC, i bug vengono risolti
• Pronto per la distribuzione: alla prossima opportunità disponibile, sarà disponibile

Quindi usiamo il numero di storie in ogni stato per guidare l'attenzione del team. Ad esempio, uno sviluppatore potrebbe essere disponibile ad affrontare una nuova storia, ma se abbiamo molte storie in Test, è meglio per loro dare una mano su storie esistenti.

Innanzitutto, riconoscere che stime precise sono impossibili in tali circostanze. Non stressarti se sbagli. Tuttavia, hai ancora bisogno di un'idea approssimativa per pianificare, e davvero l'unico modo per tenere conto della completa incertezza è aggiungere più punti della storia alla tua stima. Se non sai se è un 5 o un 13, usa il 13.

È anche utile scomporre le storie il più piccolo possibile. Spesso abbiamo una storia di ricerca / design con l'unico scopo di fare abbastanza lavoro per avere un'idea migliore di come fare la funzione, quindi la storia della caratteristica stessa passa a uno sprint successivo. Pensa al motivo per cui funziona. Anche se non hai idea di quanto sarà difficile qualcosa, di solito sai abbastanza accuratamente dalle esperienze passate quanto tempo ci vorrà per scoprirlo.

Ci sono due cose che puoi fare qui.

Prima di tutto devi avere una sorta di scrum master il cui ruolo è monitorare la discussione e dire "Ehi, stai progettando di nuovo" quando lo sei. È più difficile di quanto sembri, trasforma le persone giorno dopo giorno e inizialmente fai diventare tutti gli scrum master in modo che chiunque possa fare pipa.

In secondo luogo, se stai progettando durante la pianificazione dello sprint devi essere in grado di distinguere tra non sapere abbastanza per effettuare una chiamata sulla durata di un'attività o se stai semplicemente progettando perché è più divertente.

Ancora una volta, lo Scrum Master dovrebbe entrare qui e dirti di rimettere in posizione l'oggetto fino a quando non avrai abbastanza informazioni per programmarlo, o farti smettere di progettare e rispondere alla domanda originale (quanto tempo ci vorrà).

Quindi, se stai pianificando uno sprint, ha senso avere uno sponsor commerciale lì per andare oltre l'arretrato con te e dare la priorità alle cose che vogliono vedere prima fatte. Se lo fai scoprirai che è più difficile progettare durante la sessione perché diventeranno irrequieti e alla fine non vorranno venire.

Abbiamo operato sulla base della stima della storia "fredda" durante la pianificazione dello sprint con solo alcune discussioni limitate. Le stime sono davvero piuttosto imprecise nonostante la costituzione di team con un focus ragionevolmente ristretto ... principalmente a causa dell'esistenza di un sacco di codice legacy non documentato e non commentato con nessuna idea reale di ciò che dovrebbe realmente accadere e un personale che è sostanzialmente cambiato da quando è stato scritto l'originale.

Quello che stiamo provando ora è di passare un po 'di tempo prima di pianificare di indagare su ogni storia - e qui un solo sviluppatore indagherà su una storia ... Speriamo che questo significhi che il sviluppatore che ha indagato sarà in grado di fornire alcuni chiarimenti e approfondimenti a aiutare la stima. Finora questo ha aiutato nelle occasioni in cui è stato provato.

Devo ancora essere convinto che l'indagine aggiuntiva renda le stime abbastanza più accurate per giustificare il costo, ma lo proveremo per alcuni sprint per vedere.