Guida Scrum | 13. Team di sviluppo in Scrum

Un Team di Sviluppo in Scrum è un gruppo interdisciplinare composto da tutte le persone coinvolte nella creazione di un Prodotto. Nell'articolo di oggi vedremo quali caratteristiche dovrebbe avere. Prenderemo in considerazione anche la composizione e le responsabilità di un Team di Sviluppo in grado di raggiungere efficacemente i propri Obiettivi.

Team di sviluppo in Scrum – sommario:

1. Funzionalità del team di sviluppo
2. Team di sviluppo
3. Responsabilità del team di sviluppo
4. Riepilogo

Funzionalità del team di sviluppo

Il Team di Sviluppo che lavora secondo i principi Scrum è un gruppo indipendente di specialisti. Non si avvale del supporto di specialisti esterni o subappaltatori. Ma cosa determina che la squadra sia ben adattata per raggiungere l'obiettivo? E quali responsabilità sono incluse nei compiti di un Team di Sviluppo, indipendentemente dalla sua specializzazione?

Per essere efficace, un Team di Sviluppo deve avere almeno tre caratteristiche: la capacità di auto-organizzarsi, la spinta a crescere e l'interdisciplinarietà.

Autorganizzazione

Quando si parla di Scrum Team, di cui fa parte il Team di Sviluppo, si usa il termine “autogestione”. Significa autogestione a livello di organizzazione. Lo Scrum Team nel suo insieme decide non solo chi farà il lavoro e come, ma anche su cosa lavorerà. In uno Scrum Team, gran parte dei compiti di gestione spetta al Product Owner e allo Scrum Master.

Pertanto, nel caso di un Team di Sviluppo, l'auto-organizzazione è più importante dell'autogestione. Si riferisce alla pianificazione delle responsabilità, ad es. decidere da soli chi eseguirà determinati compiti, quando e come.

La ricerca dello sviluppo

Una caratteristica fondamentale di un Team efficace è la spinta alla crescita. Il modo di portare a termine i compiti prefissati dovrebbe essere ambizioso. Ciò deriva non solo dalle predisposizioni e dall'atteggiamento individuali di ciascun membro del Team di Sviluppo. L'aumento della competenza e dell'impegno è incoraggiato anche dall'atmosfera del Team, che lo definisce nel suo insieme.

Interdisciplinarità

L'interdisciplinarietà del Team significa che i suoi membri insieme dovrebbero avere tutte le competenze necessarie per creare un prezioso Incremento in ogni Sprint. Significa anche che ogni membro del Team svolge i compiti necessari per quello Sprint. Ognuno fa ciò che è necessario per raggiungere l'Obiettivo. Anche se ciò significa assumere nuovi compiti al di là dell'esperienza dello Sviluppatore. È un errore attenersi rigidamente alle proprie competenze professionali o al proprio ruolo.

Team di sviluppo

Secondo la Scrum Guide, il numero massimo di sviluppatori è otto. Una composizione così piccola incoraggia la comunicazione e l'apertura, poiché i membri del Team hanno l'opportunità di conoscersi. Tuttavia, il Team non dovrebbe essere inferiore a tre persone. Deve essere abbastanza grande da rendere visibili i progressi aziendali in ogni Sprint.

Gli sviluppatori all'interno di Scrum sono chiamati persone con un'ampia varietà di abilità e responsabilità. In nessun caso il nome è riservato a chi fa programmazione. Pertanto, il Team può includere programmatori e designer, ricercatori e analisti, tester e scienziati, nonché altri specialisti.

Non esiste una gerarchia tra gli sviluppatori. Ecco perché non usano titoli professionali o scientifici.

Un presupposto importante sulla composizione del team di sviluppo è che sia un'unità. Pertanto, i team più piccoli che lavorano su altri obiettivi non dovrebbero essere separati da esso.

Responsabilità del team di sviluppo

Le responsabilità del Team di sviluppo possono essere suddivise in tre aree. Questi sono:

• Compiti di pianificazione
• Lavorare sul prodotto
• Migliorare la collaborazione all'interno del Team

Compiti di pianificazione

La pianificazione delle attività è un obbligo che tutti i Team di Sviluppo basati su Scrum devono adempiere. Consiste nel creare un piano Sprint e inserirlo in uno Sprint Backlog, che descriveremo in un articolo separato. La cosa più significativa è che il Team di sviluppo lavora insieme. In questo modo ciascuno degli sviluppatori sarà in grado di determinare realisticamente il numero di attività da svolgere in un determinato Sprint. A lungo termine, ciò consente al Team di mantenere un ritmo costante e pianificare in modo più accurato.

È altrettanto essenziale tenere d'occhio il polso, cioè adattare il piano alla realtà ogni giorno. Se sorgono problemi, potrebbe esserci la necessità di cambiare: riorganizzare i compiti, distribuire il lavoro in modo diverso o parlare con lo Scrum Master delle difficoltà emergenti.

Lavorare sul prodotto

Le forme di lavoro su un Prodotto possono variare notevolmente a seconda dell'area in cui opera un determinato Team di sviluppo. In generale, l'obiettivo da raggiungere in ogni Sprint è creare un Incremento, ovvero una caratteristica del Prodotto di valore aziendale.

È utile qui parlare direttamente e applicare la seguente regola:

Quando si esegue un lavoro su un Prodotto, è necessario lasciarlo in uno stato non solo migliorato ma non meno finito rispetto alla versione precedente.

L'applicazione di questo principio significa che il Team nel suo insieme si assume la responsabilità dell'Incremento. Se uno Sviluppatore esegue le attività con noncuranza, causando il deterioramento della qualità del Prodotto, qualcun altro dovrà fare il lavoro per lui. D'altra parte, se uno sviluppatore riscontra dei bug nel Prodotto, dovrebbe risolverli da solo o passare le informazioni sui bug a qualcuno in grado di farlo. Scriveremo di più su come lavorare sull'incremento del prodotto all'interno di uno Sprint in un articolo separato.

Migliorare la collaborazione nel team

Lavorare sul modo in cui opera il Team significa migliorare costantemente l'efficienza e l'efficacia dei singoli Sviluppatori.

Tuttavia, è anche, o forse soprattutto, lavoro sulla comunicazione tra Sviluppatori. Il miglioramento consiste nell'elaborare soluzioni che consentano una divisione dei compiti efficiente e precisa. E anche abilità pratiche:

• criticare le soluzioni, non le persone : cambiare il linguaggio che usiamo per descrivere il lavoro porta a un cambiamento di atteggiamento e a una migliore collaborazione
• distanziarti dalle tue idee : consente umorismo e feedback più onesti
• costruire fiducia – grazie alla fiducia ci possono essere molte più idee innovative proposte dagli Sviluppatori senza timore di reazioni negative dell'ambiente

Il miglioramento della collaborazione del Team si ottiene attraverso una riflessione continua su come funziona il Team e fornendo feedback durante gli Eventi Scrum descritti in questo articolo.

Riepilogo

Nell'articolo di oggi presentiamo le caratteristiche, la composizione e le responsabilità di uno Scrum Development Team. Interdisciplinarità, autorganizzazione e voglia di sviluppo caratterizzano questo piccolo team. E il miglioramento continuo del lavoro di squadra e un lavoro efficace sul Prodotto : questi sono i compiti che ogni Team di sviluppo deve svolgere.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog