{"id":559,"date":"2015-04-08T10:30:11","date_gmt":"2015-04-08T08:30:11","guid":{"rendered":"http:\/\/onofri.org\/b\/?p=559"},"modified":"2015-04-08T21:20:29","modified_gmt":"2015-04-08T19:20:29","slug":"team-la-dimensione-di-un-team-di-progetto-quale-ottimale","status":"publish","type":"post","link":"https:\/\/bcs.was.mybluehost.me\/b\/team-la-dimensione-di-un-team-di-progetto-quale-ottimale\/","title":{"rendered":"#Team Building: La dimensione di un team di #progetto, qual \u00e8 ottimale?"},"content":{"rendered":"

Quanto deve essere la dimensione di un team di gestione di un progetto? Quando devono essere gli sviluppatori per singolo team? Qual \u00e8 la dimensione ottimale in Scrum? Quale in DSDM\u00ae? Lo sport ci insegna che il numero \u00e8 variabile: nel calcio le squadre sono composte da 11 giocatori, nel rugby 15, 13 o 7, nella pallavolo in campo sono 6. Ma in un team di progetto?\u00a0Parlando con Steve Messenger del DSDM\u00ae Consortium, una delle cose che pi\u00f9 mi ha fatto riflettere \u00e8 che per lui in italiano \u00e8 normale tradurre “Team” in “Squadra”, mentre in ambito Gestione Progetti siamo soliti lasciare la parola “Team” in inglese.<\/p>\n

<\/p>\n

<\/p>\n

Formare i team \u00e8 un elemento critico per il successo del progetto. COCOMO II<\/strong>, modello matematico per la stima dello sviluppo software, considera il fattore “personell\/team capability<\/em>” con un peso di 3.53 su 4.00. Il Manifesto Agile<\/strong> indica che sono pi\u00f9 importanti “Gli individui e le interazioni pi\u00f9 che i processi e gli strumenti<\/em>“. Il PMBOK\u00ae<\/strong>, arrivato alla sua quinta edizione, dedica un intero capitolo alle risorse umane, in “Project Human Resource Management<\/em>” e 4 processi a riguardo. PRINCE2\u00ae<\/strong>, nonostante escluda dal suo ambito gli elementi di leadership, considera molto importante il team nel suo principio “ruoli e responsabilit\u00e0 predefiniti”.<\/p>\n

Uno degli elementi cruciali nel formare un team \u00e8 capire la sua dimensione ottimale.<\/p>\n

Studi sulla dimensione del Team<\/h2>\n

Sono stati eseguiti diversi studi a riguardo.<\/p>\n

Gi\u00e0 nel 1913 Maximilien Ringelmann aveva teorizzato che la produttivit\u00e0 di un team era inversamente\u00a0proporzionale\u00a0alla sua\u00a0<\/strong>dimensione<\/b>, a causa di problemi di motivazione e coordinamento. Questa teoria \u00e8 anche conosciuta come “Effetto Ringelmann”.<\/p>\n

Nel 1970 J. Richard Hackman e Neil Vidmar, professori di Psicologia Sociale e delle Organizzazioni ad Harvard, esaminando il lavoro di gruppo dei loro studenti, hanno identificato la dimensione di un team perfetta: 4.6.<\/strong><\/p>\n

Nel 1972 Ivan Steiner, dopo ulteriori studi esaminando i fattori indicati nell’Effetto Ringelmann ha identificato un picco di produttiivt\u00e0 quando la dimensione di un team \u00e8 parti a 5 persone<\/strong>.<\/p>\n

Jennifer Mueller, Assistant professor di Management all’Universit\u00e0 della Pensilvenia, indica pi\u00f9 in generale che “Se facciamo gruppi troppo grandi, saranno le persone stesse a farne di pi\u00f9 piccoli<\/strong>. Formando delle cricche”.<\/p>\n

Parere interessante \u00e8 di Jeff Bezos, CEO di Amazon.com, che indica la “Regola delle due pizze”, meglio conosciuta come “Two-pizza rule”, se ad un team non puoi dar da mangiare con due pizze, allora \u00e8 troppo grande<\/strong>.<\/p>\n

Relativamente ai framework agili, ognuno propone direttive sulla dimensione di un team.<\/p>\n

Dimensione di un Team Scrum<\/h2>\n

In Scrum<\/strong> i team sono auto-gestiti ed interfuznionali. La Scrum Guide<\/em> indica che la dimensione ottimale di un Team di Sviluppo<\/em> deve essere abbastanza piccola per rimanere agile e abbastanza grande per avere le competenze necessarie. Un Team di Sviluppo<\/em> composto da meno di tre<\/strong> persone pu\u00f2 avere problemi relativamente alle competenze necessarie, un team composto da pi\u00f9 di nove<\/strong> persone invece pu\u00f2 incorrere in problematiche di coordinamento. Questi numeri escludono il Product Owner<\/em> e lo Scrum Master<\/em>, a meno che non facciano anche parte del Team di Sviluppo<\/em>.<\/p>\n

Dimensione di un Team DSDM\u00ae o Agile Project Management\u00ae<\/h2>\n

In DSDM\u00ae Atern\u00ae<\/strong> e Agile Project Management\u00ae<\/strong> sono presenta\u00a0due principi relativi al team “Collaborate<\/em>” e “Communicate continuously and clearly<\/em>“. Il Solution Development Team<\/em> \u00e8 interfunzionale: sono previsti diversi ruoli, e una persona pu\u00f2 ricoprire pi\u00f9 ruoli. La dimensione ottimale \u00e8 di 7 +\/- 2 persone<\/strong>. Se non \u00e8 possibile avere la dimensione ottimale va trattato come un rischio<\/em><\/strong>, quindi registrato nel Risk Register<\/em>. Se i team sono pi\u00f9 piccoli allora va gestita l’eventualit\u00e0 che non si riesca a consegnare in tempo, ad es. in caso di assenza di una persona. Se i team sono pi\u00f9 grandi allora si presenta \u00e8 possibile che ci siano problemi di comunicazione. In caso di team troppo grandi, DSDM\u00ae Atern e Agile Project Management\u00ae consigliano infatti di dividere il team in team pi\u00f9 piccoli, cos\u00ec da ottimizzare i rischi.<\/p>\n

E’ interessante notare che questa direttiva corrisponde alla nota Legge di Miller del 1956 dove viene indicato che i chunk di informazioni processabili dalle persone sono “Cinque pi\u00f9 o meno due”.<\/p>\n

Riferimenti<\/span><\/h1>\n