Scrum - Cosa sono i membri del team impegnati durante uno sprint

At the beginning of the sprint there is nothing to test yet

Davvero? Non hai requisiti per convalidare? Nessuna discussione da avere con il tuo cliente? Nessun wireframe da valutare? Nessun piano di test a cui pensare?

at the end of the sprint there is typically nothing or very little left to develop/fix

Non sono mai stato in quel posto in un progetto. Non c'è più lavoro da fare? C'è sempre qualcosa. Tutti i tuoi test sono completamente automatizzati? Come sta il tuo CI? Lo strato di accesso al database potrebbe essere refactored per essere più semplice? E non ho mai lavorato a nulla con una lista di bug e un backlog vuoti. Cosa facevano gli sviluppatori in una fase di test di cascata?

So che alcune persone diventano molto religiose su ciò che è e ciò che non è "SCRUM". Non me ne potrebbe importare di meno. Ma penso che tu abbia due problemi qui:

1. Un dipartimento di QA "tradizionale" che verifica il codice una volta che è stato "completato" dagli sviluppatori anziché lavorare con clienti e sviluppatori per assicurarsi di costruire la cosa giusta e costruire correttamente. Dai un'occhiata ai quadranti di test agili di Lisa Crispin. I migliori tester sono coinvolti in ogni fase del ciclo di vita dello sviluppo del software e i migliori sviluppatori scrivono i propri test.

2. Cercando di restare fedeli a un calendario SCRUM di sprint di 1 settimana / 2 settimane senza avere un backlog con priorità e dimensioni suddiviso in attività che sono abbastanza facili da completare in un breve lasso di tempo entro un singolo sprint. Se tu avessi questo, ci sarebbe sempre più lavoro per andare avanti. Forse l'ultima funzione su cui si lavora in questo sprint non entra in questa versione di sprint, ma può sempre andare a quella successiva.

A parte. Se hai una piccola squadra coesa, i ruoli sono meno importanti. Invece di avere qualcuno con l'etichetta tester che non è autorizzato a scrivere codice di produzione, o qualcuno etichettato come uno sviluppatore che pensa di essere sopra test, tutti dovrebbero fare tutto il necessario per il successo del team, incluse le temute attività di gestione del progetto quando sono necessari, questo è chiamato un gruppo interfunzionale.

Un altro punto sollevato da @Cort Ammon nei commenti. Il manifesto agile parla della collaborazione con il cliente rispetto alla negoziazione del contratto. Dici questo:

the client may be disappointed to see the team waste time on something that does't bring immediate value

Può essere difficile da spiegare e capisco che i clienti possono essere molto difficili a volte, ma questa sarebbe una grande bandiera rossa per me. Si fidano di te con il loro codice sorgente / relazione con il cliente / azienda / qualsiasi cosa tu stia sviluppando per loro. Se non possono fidarsi di te ad agire professionalmente nel loro miglior interesse, allora o hai un problema o lo fanno.

Ho scritto un post che parla di sviluppatori di software non considerati professionisti. Un medico professionista, un avvocato, un ingegnere civile di fronte a un cliente che ha cambiato i requisiti a loro carico in parte non solo ne ridurrebbe la qualità e ne lamenterebbe. Dicevano ai loro clienti che sarebbe stato un problema. Se il cliente spingesse, un professionista non lo farebbe solo ciecamente a uno standard pericolosamente inferiore perché sarebbe responsabile. Non accettiamo esami di ammissione professionali e quindi non siamo responsabili. Ciò non significa che non dovremmo cercare di essere migliori.

In sintesi, non mi preoccuperei troppo di cercare di far diventare le persone più efficienti all'inizio e alla fine di uno sprint, ma piuttosto di vederlo come un sintomo di un problema più ampio all'interno del team. Hai sentito parlare di eXtreme Programming (XP) . Direi che i principi di XP da applicare qui sono comunicazione e rispetto:

• Rispetta la tua squadra per fare ciò che pensa sia meglio. Direi che se c'è un sacco di guardare video di gatti, allora hai degli sviluppatori poveri o li stai trattando male.
• Comunicazione. Se i tuoi sviluppatori parlano tra loro, ai tester, alla direzione, al cliente, allora tutti dovrebbero probabilmente avere una buona sensazione di ciò che succede dopo e se non lo fanno, possono semplicemente chiedere.

Il primo punto è che Scrum si occupa di ottimizzare il team , non ogni individuo. Se il team è produttivo ed efficiente, non importa molto se qualcuno è inattivo all'inizio o alla fine dell'attività.

Tuttavia, su tutte le squadre in cui sono stato, c'è sempre molto lavoro. Lasciatemi indirizzare un paio dei tuoi dubbi specifici:

At the beginning of the sprint there is nothing to test yet,

Sebbene ciò possa essere vero in senso letterale, ciò implica che l'unico compito per un tester è "testare". C'è molto che può essere fatto prima che inizino a testare. Per uno, possono incontrarsi con il proprietario del prodotto e gli sviluppatori per comprendere appieno i requisiti. Possono essere impegnati a lavorare su un piano di test, a raccogliere dati di test e così via. Se hanno il lusso di un buon framework, sono in grado di iniziare a scrivere test automatici prima del tempo.

at the end of the sprint there is typically nothing or very little left to develop/fix

Devo ancora vedere un team di sviluppo che ha esaurito le cose da sistemare. Tuttavia, non è quello che dovrebbero fare alla fine dello sprint. Verso la fine dello sprint dovrebbero aiutare i tester a testare il prodotto. Possono aiutare a scrivere test automatici, possono testare i codici e fixtures / keywords / etc scritti dai tester. Possono lavorare con il team di documentazione per aiutarli a finire il loro lavoro, ecc.

I've seen 2 approaches to handle this... 1) Let the team members decide what to do whenever they're out of tasks.

Il difetto nel tuo pensiero è che le persone finiscono i compiti. I compiti appartengono alla squadra nel suo complesso. Non dovrebbero fare altro lavoro a patto che ci siano storie o compiti rimasti per il team nello sprint corrente.

Make room in the sprint only for development,

Questo approccio non rientra nella definizione tradizionale di scrum o agile. L'intero punto di agilità è che un'intera squadra è coinvolta nel lavorare verso un obiettivo comune. Ciò significa che tutto il lavoro richiesto per completare una storia deve essere rappresentato in uno sprint - progettazione, sviluppo, test, documentazione, ecc.

Infine, questa non è l'unica altra soluzione praticabile. Trascuri la vera soluzione, ovvero che ogni membro della squadra dovrebbe inserirsi come necessario per aiutare a finire le storie in uno sprint.

L'obiettivo è un obiettivo team , ma stai scrivendo come se ogni singola persona avesse obiettivi individuali ("completa i miei compiti"). Se qualcuno non ha nulla da fare, può vedere su cosa sta lavorando e offrire aiuto. Oppure possono prendere il prossimo compito o storia e iniziare a lavorarci su.

In tutti i negozi agili in cui ho lavorato, i tester sono considerati polli quindi non sono timebox nello sprint come lo sono gli sviluppatori. Prima di mettere le mani sul software, i tester dovrebbero scrivere piani e assicurarsi che gli ambienti siano impostati correttamente per ricevere il software. Come parte di questo, dovrebbero essere a portata di mano tutti i documenti di progettazione come sono.

In seguito, dovresti cercare di riempire lo sprint. Non ci dovrebbe essere alcun tempo libero alla fine dello sprint se le stime sono buone, sebbene la stima sia ovviamente un'arte nera, quindi riempie raramente esattamente .

Se uno sviluppatore ha del tempo libero alla fine dello sprint, questa volta dovrebbe essere monitorato per assicurarsi che stia aggiungendo valore (imparando un nuovo framework, facendo analisi, ulteriori test, ecc.)

Il bug fixing è un'attività perfettamente accettabile per essere inserita in uno sprint. Contribuisce a una funzione e quindi aggiunge valore. Questo non dovrebbe essere visto come il tempo rubato dallo sprint successivo - più correttamente terminare una funzione.

In un mondo ideale, la tua squadra sarebbe cross- funzionale. Ognuno ha la sua specializzazione, ma ognuno è anche in grado di lavorare come un'altra specializzazione. Se i tuoi tester non possono codificare le attività più semplici, allora non hai un team interfunzionale.

Il modo SCRUM sarebbe quello di consentire al tuo team di essere funzionale. I tuoi tester dovrebbero avere comunque competenze per l'automazione dei test, è un breve passo per codificare alcune delle cose meno complesse.