Come calcolare gli sprint in Scrum per allocare il tempo per TDD?

L'idea alla base di TDD è che la creazione dei test è parte dello sviluppo. Non dovresti veramente calcolarlo come development + unit test , il modo migliore per vederlo è development = function + unit test , dove la creazione dei test unitari non è un separato attività. Mentre i tuoi sviluppatori stanno lavorando sulla funzionalità, stanno anche creando i test unitari.

Allo stesso modo, la tua bacheca non dovrebbe avere un compito separato per "Crea test unitari" - i test unitari dovrebbero essere implementati insieme alla funzionalità, in realtà non dovrebbe esserci alcuna separazione.

Non dovrebbe essere come 1,5 settimane di sviluppo e quindi 1,5 settimane di test unitari. Invece, si desidera avere 3 settimane di sviluppo e finire con la funzionalità in uno stato completamente testato. Se la tua definizione di Done specifica che ogni funzionalità è testata dall'unità, allora non dovrebbe esserci alcuna separazione tra l'implementazione della funzionalità e il test delle unità.

Per quanto riguarda l'altra domanda relativa all'integrazione del controllo di qualità: disponiamo di risorse di controllo qualità come parte del team, testando ogni funzionalità non appena disponibile, con un test di regressione completo giornaliero (o notturno). Se l'implementazione di una funzione viene eseguita il giorno 3 dello Sprint, il nostro QA inizierà a testarlo in questo giorno - idealmente hanno sviluppato gli script di test contemporaneamente all'implementazione della funzionalità dello sviluppatore.

Entrambi devono lavorare mano nella mano e con molta collaborazione. C'è molta comunicazione tra gli sviluppatori e QA nel team. "Ehi, la funzionalità A è ora pronta, puoi iniziare a provarla." e "Ho trovato il seguente problema nel mio test per la funzione B, puoi risolvere questo problema?" Abbiamo questo avanti e indietro tutto il tempo durante lo Sprint, con l'obiettivo che tutto sia testato e funzionante alla fine.

Combina quello con un test di regressione completo eseguito ogni notte, dove i risultati sono pubblicati, e puoi praticamente svilupparti fino all'ultimo giorno dello Sprint. I test dovrebbero avvenire in tutte le fasi dello Sprint, non solo nell'ultimo paio di giorni.

Per prima cosa devo menzionare che 3 settimane di sviluppo e 1 settimana di test è non Scrum, ma invece cascata time-boxed. Poiché la filosofia di base di scrum è l'ispezione continua e l'adattamento, raccomanderei vivamente di considerare l'interazione tra programmatori e tester e insegnare loro a lavorare in modo incrementale.

La risposta Scrum corretta sarà "Chiedi al team" poiché questo è ciò che riguarda l'auto organizzazione, l'ispezione e l'adattamento. Il problema che devono risolvere è come un programmatore può scrivere un po 'di codice con un massimo di 1/2 giorno e dare qualcosa a un tester da testare. Ciò non significa che la funzione deve essere completa, ma solo aggiunta in modo incrementale al controllo del codice sorgente e verificabile da un tester.

Il TDD è un buon approccio da guardare in quanto ciò incoraggerà i programmatori a pensare a come verrà testato, prima di codificarlo e quindi a fare il minimo per far passare i test.

L'idea alla base di TDD è che, mentre consuma il tempo stesso, riduce il tempo richiesto in altre aree. Dovresti scrivere il tuo codice più velocemente e non spendere tanto tempo per la risoluzione dei bug e per i test manuali, quindi puoi ridurre questi aspetti di conseguenza.

Pertanto, la tua affermazione (sottolineatura mia):

Following the same we would get only [x time for] development which is not enough.

non è necessariamente vero.

Spetta a te determinare se questo è ciò che ottieni, ma questa è la teoria:)

• Se hai appena iniziato a lavorare in Scrum, 4 settimane sono una durata piuttosto lunga per i tuoi sprint. Sprint più brevi ti permettono di fallire presto e spesso (non è una brutta cosa) e così ispezionando e adattando puoi migliorare i tuoi processi molto più velocemente. Ti consente anche di essere più reattivo al cambiamento.

In my previous experience writing tests and getting 80% coverage requires round about 50% of the development time

• In TDD, tempo di sviluppo IS sviluppo + tempo di test delle unità. Non hai uno sviluppo di 2 settimane + 1 settimana di test, hai 3 settimane di sviluppo di alta qualità. Poiché una così grande percentuale del costo di sviluppo del software è la manutenzione, la qualità dovrebbe essere di grande importanza e dovrebbe essere incorporata nella tua definizione di fatto e nei criteri di accettazione per le storie.

1 week of pure manual/automated testing, stabilization and shipment assurance testing

• nwinkler ha risposto molto bene sopra, quindi non ripeterò ciò che ha detto. Quello che stai facendo è essenzialmente mini-cascata in ogni sprint! Crea attività di stabilizzazione / assicurazione della spedizione (o qualsiasi altra cosa) nel tuo backlog sprint per ogni storia che stai testando, se necessario. Ovviamente, se hai ruoli di tester nella tua organizzazione, dovrebbero essere nel tuo team di scrum se non lo sono già

Vedo un paio di problemi e miglioramenti qui.

• TDD non riguarda solo la copertura e assicura che i test siano scritti, ma in realtà è un paradigma di progettazione. Inoltre, se hai TDDing correttamente, ottieni automaticamente una copertura del 100%. È una metodologia di programmazione. Quindi dovresti considerarlo parte della tua attività di codifica.
• Affettare i backlog a dimensioni ottimali è fondamentale per ottenere la giusta quantità di lavoro svolto in uno sprint. Se noti troppo lavoro probabilmente significa un grosso arretrato. Se il backlog è dimensionato correttamente, probabilmente stai stimando più lavoro di quanto possa essere fatto in uno sprint.