Per visualizzare l'articolo in inglese, selezionare la casella di controllo Inglese. È possibile anche visualizzare il testo inglese in una finestra popup posizionando il puntatore del mouse sopra il testo.
Traduzione
Inglese

Scrum distribuito

David Starr è Chief Software Craftsman per Scrum.org con il compito di migliorare la professione dello sviluppo di software. Ha inoltre fondato la community tecnica online, ElegantCode.com.

Luglio 2012

I team distribuiti hanno spesso difficoltà nel raggiungere una comunicazione coerente, tempestiva ed efficace. È importante analizzare in che modo Scrum fornisca un contenitore in cui diversi tipi di team distribuiti possono fare progressi e ottenere risultati positivi.

Panoramica

Gradi di separazione

Strumenti e procedure

Conclusione

Il framework Scrum non fornisce informazioni in merito ai team di sviluppo distribuiti. Scrum non richiede che tutti i membri di un team Scrum o i membri di un team di sviluppo lavorino nella stessa stanza, nello stesso edificio, nella stessa città o nello stesso fuso orario. I team Scrum rivelano attivamente gli impedimenti all'incremento della produttività e quando la comunicazione rappresenta un impedimento, Scrum lo rende decisamente visibile.

Quando i membri del team non lavorano insieme fisicamente, le comunicazioni all'interno del team diventano inevitabilmente più complesse e pertanto lo diventa anche il software creato dal team. Nel 1968 Melvin Conway ha scritto:

Ogni organizzazione che progetta un sistema produrrà inevitabilmente un design che rappresenta una copia della struttura di comunicazione dell'organizzazione stessa.

Si è dimostrato che la legge di Conway è molto più di una massima; è una dinamica misurabile all'interno dei team di sviluppo di software. Uno studio ha dimostrato l'effetto della legge di Conway misurando l'effetto che può avere la distribuzione dei team sull'architettura del sistema. Quando i membri del team sono distribuiti, gli sviluppatori di software tendono a creare più livelli di astrazione nel codice nel tentativo di rimanere indipendenti gli uni dagli altri[1].

Stella è una sviluppatrice di un team Scrum che consegna regolarmente il lavoro previsto per ogni sprint. Il suo team ha la reputazione di creare software di alta qualità, anche se il codice è un po' difficile da comprendere quando viene letto dagli altri.

Stella lavora da casa e si trova in un fuso orario diverso dal resto del team. Il team utilizza la posta elettronica, un sistema di gestione dei requisiti costoso e talvolta i servizi di videoconferenza per discutere del lavoro durante ogni sprint. Il team utilizza Scrum come previsto con uno Scrum giornaliero pianificato per conciliare la pianificazione di ognuno. Stella partecipa alle riunioni di pianificazione e allo Scrum giornaliero per telefono senza vedere le facce degli altri membri del team quando parlano. Stella inoltre non ascolta le conversazioni che si tengono prima e dopo ogni Scrum giornaliero.

Con i migliori intenti, Stella crea un livello di astrazione nel codice in modo tale che il suo lavoro possa essere isolato e testato più facilmente. La nuova astrazione separa la sua implementazione dall'interfaccia che ha dichiarato e reso disponibile agli altri membri del team. Stella afferma che questo tipo di sistema modulare porta ad architetture di sistema nettamente disaccoppiate. "L'utilizzo delle interfacce come limite di implementazione rappresenta semplicemente una buona tecnica di progettazione orientata agli oggetti", ricorda a se stessa. Il nuovo modello di plug-in le consentirà di lavorare solo nella sua sezione del codice senza interferire nel lavoro degli altri membri del team in altre aree.

Come previsto dalla legge di Conway, il codice riflette ora la sua comunicazione con il team, ovvero a regime di controllo libero ("loosely-coupled"). La sua progettazione sostituisce le conversazioni che potrebbe avere avuto con il team e il sistema diventa inutilmente complesso. Questa inutile complessità è un'immagine speculare dei suoi rapporti con gli altri membri del team di sviluppo. Tali decisioni comporteranno fondamentalmente alla sua società un incremento dei costi poiché ci saranno più righe di codice da gestire, più livelli di riferimento indiretto per gli sviluppatori futuri da comprendere e più test per verificare la corretta funzionalità dell'astrazione.

Stella non ha fatto niente di sbagliato. Infatti, ha sfruttato appieno le ottime procedure di progettazione orientata agli oggetti per isolare un'area problematica nel sistema. Sfortunatamente, il problema che Stella ha isolato è rappresentato dalle sue problematiche di comunicazione e la soluzione consente una comunicazione ancor meno frequente. Purtroppo, il sistema che Stella ha modificato per risolvere il problema era il software. Un modo più efficace per gestire questo problema può essere quello di semplificare le comunicazioni con il team di sviluppo.

Quando i membri del team non siedono insieme tendono a sostituire i semplici scambi verbali con conversazioni più difficili e formali. Anziché discussioni rapide ed efficienti su piccole decisioni tattiche, gli argomenti si accumulano in attesa di essere discussi in un secondo momento, che spesso non arriva mai. Una riduzione delle comunicazioni tra i membri del team comporta una riduzione della comunicazione anche in altri ambiti, quali specifiche, ticket di lavoro o persino codice. Gli oggetti ISomeInterface consentono di prendere in considerazione le disfunzioni dei team che ne effettuano la creazione.

Le decisioni prese al di fuori di un team Scrum sono quelle che verosimilmente incrementano la complessità. La composizione o le attività dei team di sviluppo del software in genere non sono semplici. Scrum stabilisce i confini entro i quali il team Scrum agisce e lavora per ridurre la complessità. Nonostante ciò, la complessità insita nella scrittura del codice e nel rilascio del software talvolta svanisce a confronto della complessità che cultura e processi organizzativi impongono ai team di sviluppo.

Di conseguenza, la decisione di costituire un team Scrum di membri che vivono in paesi con fusi orari diversi in genere non viene presa da coloro che svolgono il lavoro. Creare un team Scrum distribuito è quasi sempre una scelta dei leader, nel tentativo di mettere insieme un team di specialisti altamente qualificato o, più verosimilmente, di abbassare i costi di produzione coinvolgendo collaboratori esterni, al fine di sviluppare software a costi minori. Nonostante questi modelli siano in grado di ridurre i costi iniziali di sviluppo del software, in genere non considerano i costi della manutenzione continua e della complessità aggiuntiva necessari per affrontare le difficoltà di comunicazione del team di sviluppo.

Indipendentemente dal modo e dal motivo per cui vengono creati, i team distribuiti costituiscono una realtà che non sembra voler scomparire. Anche in situazioni con team distribuiti, Scrum resta un eccellente framework per gestire la pianificazione e l'esecuzione del rilascio di un prodotto software. I membri del team devono essere solo più attenti a migliorare i canali di comunicazione esistenti e a proteggersi da ottimizzazioni di poca importanza come quelle descritte nell'esempio precedente.

I team distribuiti offrono la possibilità di assumere la persona giusta per un lavoro indipendentemente da dove viva o, per alcune persone, di vivere nel luogo che hanno scelto anziché dove si trova la sede della propria azienda. Nonostante sia semplice criticare i team distribuiti, i vantaggi economici legati a outsourcing, in-sourcing, near-sourcing e rural-sourcing restano impellenti per molte organizzazioni.

La Guida a Scrum, pubblicata su Scrum.org, codifica il framework Scrum e rappresenta il set di regole per l'applicazione di tale framework. Nonostante la Guida a Scrum non affronti il problema dei team distribuiti e non fornisca alcuna indicazione in tal senso, il framework Scrum renderà molto evidenti i ritardi e gli sprechi relativi alla comunicazione che esistono nei team i cui membri non possono parlare tra loro senza un dispositivo elettronico che colmi il divario.

Molto di ciò che le persone si dicono è comunicato attraverso il linguaggio del corpo. Le informazioni raccolte osservando qualcuno durante una riunione di progettazione possono essere preziose quanto le informazioni che vengono scritte alla lavagna. Per questo motivo, colmare il divario tra i lavoratori distribuiti significa principalmente superare la barriera del linguaggio del corpo.

Steve McConnell scrisse: "Il tempo di dimezzamento della fiducia è circa 6 settimane". [2] Con questa affermazione si riconosce che gli sviluppatori che lavorano e collaborano insieme ogni giorno raggiungono un livello di fiducia reciproca. Il livello di fiducia varia come in qualsiasi relazione, ma il potenziale è altissimo quando i colleghi si vedono e lavorano spesso insieme.

Quando i colleghi non si vedono quotidianamente e non lavorano fianco a fianco per circa sei settimane, il livello di fiducia della relazione diventa circa la metà di quello che era in origine. La poca fiducia che resta diminuisce rapidamente man mano che trascorre il tempo.

Questo non significa che le persone coinvolte non abbiano stima o rispetto reciproco, ma la fiducia e l'efficacia del team vanno perdute. Senza fiducia, diminuisce la collaborazione e aumentano i confini tra i colleghi. Questi confini si riflettono spesso nel codice.

Videocamere, teleconferenze, Instant Messenger, video chat, strumenti di condivisione schermo e altri strumenti di collaborazione aiutano a colmare il divario tra i colleghi e non devono mai mancare per garantire che i team distribuiti siano altamente produttivi. Comunicazioni video frequenti possono, a lungo andare, ricostituire alti livelli di fiducia.

Qualunque strumento venga utilizzato, i team distribuiti possono incrementare la loro efficacia, sfruttando le opportunità di comunicazione ad alta fedeltà. In breve, la voce dal vivo è preferibile a Instant Messenger, che è preferibile alle e-mail e così via. Ridurre il tempo tra le interazioni rappresenta poi la scelta migliore.

Molti sono i modi che possono separare i membri del team gli uni dagli altri e molti sono i modelli comunemente ricorrenti di distribuzione del team. Come i modelli presenti in altri ambienti (ad esempio quello della progettazione del software), i modelli di distribuzione del team possono essere creati intenzionalmente o accidentalmente. I modelli accidentali vengono creati come una risposta inconscia alla pressione esistente, mentre i modelli intenzionali vengono implementati deliberatamente per controllare la complessità.

I modelli Scrum distribuiti descritti in questa sezione possono essere prescritti o involontari. Possono essere ispirati da decisioni prese al di fuori del team Scrum o possono essere il risultato dell'auto-organizzazione del team Scrum rispetto ad un particolare problema. Indipendentemente dal motivo per cui vengono creati, i seguenti modelli di distribuzione sono comuni in circostanze normali.

  • I team di sviluppo remoti lavorano insieme, ma sono separati fisicamente dal resto dell'azienda.

  • Nel modello membro del team remoto un singolo membro del team lavora in un luogo diverso dal resto del team di cui fa parte.

  • In un team distribuito i singoli membri del team lavorano insieme per lo stesso obiettivo, ma ciascuno da un luogo diverso.

Alcuni team di sviluppo sono separati geograficamente dall'organizzazione principale più estesa o, ancora peggio, dai Product Owner. Questo accade, ad esempio, quando un'azienda ne acquisisce un'altra o quando due aziende si fondono. Se il team di sviluppo deve essere remoto, Scrum è una soluzione ideale per gestire il lavoro e la comunicazione di quel team con l'organizzazione più estesa. Molti team oggi hanno successo grazie a questa formula.

In varie situazioni, i team di sviluppo remoti si sentono spesso privati dei diritti, sottovalutati e tagliati fuori dall'organizzazione principale. I membri del team remoto possono sentirsi ignorati e isolati dall'azienda principale, che può, spesso involontariamente, considerare il team remoto meno importante dei team che lavorano presso la sede.

I team di sviluppo remoti cercano continuamente motivazioni, pretesti ed opportunità per non integrare il proprio lavoro con quello degli altri team. Risulta così evidente il motivo per cui l'integrazione di questo Sprint non è importante, necessaria o possibile. Il risentimento cresce e il team di sviluppo inizia a giudicare le richieste di integrare il codice con l'organizzazione più estesa come "irragionevoli", "lontane dalla propria realtà", "non necessarie" o "insensibili alle proprie esigenze".

Se queste impressioni sono vere o meno è del tutto irrilevante. Il team di sviluppo remoto deve sentirsi ascoltato, compreso e valorizzato all'interno dell'organizzazione più estesa. È facile dimenticare che una persona fa parte di qualcosa di più grande se lavora da un luogo remoto.

Uno Scrum Master che lavora in un luogo diverso da quello del team di sviluppo significa fallimento assicurato. Gli Scrum Master non possono svolgere in modo efficace i compiti di coaching, semplificazione di eventi Scrum efficaci e gestione di Scrum a distanza. La distanza tra un team di sviluppo e uno Scrum Master impedisce la comunicazione e introduce un livello di rischio troppo elevato nel team Scrum. Per avere fiducia è necessario avere familiarità e una grande fiducia reciproca è fondamentale per il successo di Scrum.

Gli Scrum Master lavorano nello stesso luogo dei team di sviluppo.

Per fare in modo che un team di sviluppo collabori nel modo giusto con il proprio Product Owner è necessaria una comunicazione chiara e senza impedimenti. Durante ciascuno sprint, il Product Owner deve essere disponibile per il team di sviluppo, rispondere alle domande e fornire il feedback sui lavori in corso. Nonostante questa frequente interazione sia possibile in situazioni remote, deve essere stabilito un metodo affidabile per mantenere questo grado di comunicazione.

Un Product Owner assente è una delle forze più distruttive che un team Scrum può incontrare. Un team di sviluppo trascurato è costretto a prendere da solo decisioni relative a funzionalità e priorità. Questo gruppo è spesso quello meno capace di fare le scelte giuste relative alle funzionalità, in quanto è in genere meno informato del Product Owner sulle esigenze del cliente.

I Product Owner prestano attenzione e forniscono il feedback al team di sviluppo per tutta la durata dello sprint.

Sfortunatamente, i Product Owner assenti o poco disponibili sono una disfunzione comune nei team Scrum, anche in ambienti predisposti. Per fare in modo che Scrum realizzi il proprio potenziale, il team Scrum deve funzionare come un'unità coesiva, affidabile e collaborativa che richiede attenzione regolare da un Product Owner dedicato.

Alcuni sviluppatori sono separati dai loro colleghi, che si trovano e lavorano insieme in un luogo condiviso. Il classico esempio è quello dello sviluppatore che lavora da casa e collabora coscienziosamente con un team dal proprio studio. Anche se per motivi diversi, questa situazione è incredibilmente comune.

Alistair Cockburn ha coniato il termine Osmotic Communication[3] (comunicazione osmotica) per identificare un tipo di comunicazione intrinseca all'interno della stanza del team.

Comunicazione osmotica significa che le informazioni arrivano come sottofondo all'udito dei membri del team, che acquisiscono informazioni importanti come per osmosi. Questa situazione si verifica in genere quando i membri sono seduti nella stessa stanza. Quando una persona pone una domanda, le altre persone presenti nella stanza possono sintonizzarsi o meno, contribuendo alla discussione o continuando il proprio lavoro.

La comunicazione osmotica non è limitata solo ai team di sviluppo del software. Se si entra in una sala stampa di un grande quotidiano o organo di stampa spesso si nota esattamente la stessa dinamica. Anche le squadre di investigazione dei dipartimenti di polizia di tutto il mondo utilizzano le stanze dei team per incrementare la conoscenza collettiva quando indagano sui crimini.

Perdita di comunicazione osmotica significa perdita di consapevolezza situazionale all'interno del team. Quando uno sviluppatore di software non viene messo a conoscenza delle modifiche apportate al software dai suoi colleghi nel momento stesso in cui tali modifiche vengono apportate, si verifica una perdita di coesione e di contesto condiviso all'interno del team. Il membro del team remoto, concentrato ed in costante attività, non può trarre i vantaggi della propria presenza nella stanza del team. Questo membro resta fuori da discussioni ad-hoc relative alla progettazione e da altre decisioni che vengono prese con estrema naturalezza nel corso di un determinato giorno.

La tendenza a rilasciare il software più rapidamente, facendo trascorrere un periodo di tempo minore tra un release e l'altro, richiede anche una maggiore consapevolezza situazionale all'interno del team di sviluppo. Per il membro del team remoto che non è presente nella stanza del team, la consapevolezza situazionale viene semplicemente perduta.

Per risolvere questo problema si stanno diffondendo soluzioni di telepresenza. Una semplice soluzione di telepresenza può essere costituita utilizzando un laptop, una videocamera e degli altoparlanti comuni. Posizionando questo sistema nella stanza del team, un canale di comunicazione aperto sarà disponibile per lo sviluppatore remoto, che può lasciare il canale aperto per tutto il giorno.

Video e teleconferenze aiutano a colmare la barriera linguistica del corpo.

I segnali che indicano che lo sviluppatore remoto avrà difficoltà ad essere effettivamente una parte del team sono i seguenti:

  • Uso di comunicazioni scritte mediante tastiera, come e-mail o Instant Messenger, per discutere problemi complessi.

  • Definizione di interfacce fisse da usare come contratti nel codice, anziché avere discussioni regolari con altri sviluppatori.

  • Necessità di un ramo di codice privato o personale nel controllo versioni.

Per colmare il divario tra uno sviluppatore remoto e il resto del team, sono molto utili le visite periodiche. Le videochiamate sono meglio delle telefonate. Le telefonate sono meglio delle comunicazioni scritte mediante tastiera e affidarsi alle e-mail è un disastro annunciato.

In un team Scrum realmente distribuito le persone lavorano insieme per raggiungere lo stesso Sprint Goal e ciascun membro del team lavora in un luogo diverso. L'esempio tipico è un progetto open source a cui contribuiscono persone che vivono in posti diversi del mondo. Nonostante i problemi di comunicazione siano significativi, questo modello ha una validità inconfutabile. La comunicazione in un team come questo è sicuramente carente, ma sta diventando più comune grazie alla tecnologia, che continua a ridurre la barriera del linguaggio del corpo.

Quando i membri del team si trovano in posti diversi, il software di condivisione schermo è essenziale per avere conversazioni efficaci su progettazione e codice. Riguardo al codice, a meno che entrambe le parti di una conversazione non vedano la stessa cosa, la discussione include troppe supposizioni. Per fortuna, il software di condivisione schermo è facilmente disponibile e altamente efficace. I membri del team che non si trovano nella stessa stanza condividono gli schermi con i propri colleghi varie volte al giorno.

La condivisione schermo può essere uno strumento di abbinamento e collaborazione molto valido.

Trovare pretesti per esaminare insieme il codice, gli elementi di backlog o altri artefatti è un modo eccellente per mantenere alta la consapevolezza situazionale nei team distribuiti. Un'altra tecnica efficace è l'aggiunta di una semplice regola di verifica per qualsiasi elemento rilasciato come parte dello sprint. La regola, costituita da due parti, è la seguente:

Ciascun elemento deve essere verificato in un ambiente di integrazione per essere considerato "fatto".La persona che esegue la verifica può non essere la stessa persona che ha svolto il lavoro.

I team di sviluppo che adottano questa semplice regola acquisiscono una maggiore conoscenza collettiva del lavoro che deve essere svolto da tutto il team.

Nota dell'autoreHo collaborato con un team di sviluppo i cui membri lavoravano nello stesso edificio ma in uffici diversi. Assegnare uffici privati a tutti i dipendenti era un motivo di orgoglio per l'azienda. Il team di sviluppo alla fine decise di creare una stanza del team virtuale in cui ciascun membro del team poteva entrare utilizzando una videocamera, un microfono e degli altoparlanti. La stanza del team virtuale era sempre aperta e i membri del team vi entravano quando lavoravano su un prodotto condiviso.Dopo un po' il team iniziò ad apprezzare questa stanza virtuale. Anziché percorrere l'intero corridoio, i membri del team iniziarono ad usare il software di condivisione schermo per visualizzare gli schermi degli altri membri, essendo questo sistema di gran lunga più veloce. Iniziarono quindi ad usare la stanza del team virtuale tutto il giorno, anche se lavoravano in uffici separati solo da pochi centimetri di muro.Alla fine, uno dei membri del team provò a non andare in ufficio per qualche giorno e a lavorare da casa propria. Durante la Sprint Retrospective, il team di sviluppo constatò che, grazie alla stanza del team virtuale, era irrilevante se una persona si trovava a poche porte di distanza nel corridoio o a casa propria. La stanza del team virtuale si dimostrò più preziosa dei singoli uffici.

I team agili che utilizzano strumenti a bassa tecnologia e alta fedeltà per gestire il proprio lavoro sono molto discussi. Quando ad una situazione già confusa si aggiungono la complessità della distribuzione geografica o la presenza di più team di sviluppo, schede analogiche e marcatori nonché una soluzione basata sul software non riducono le difficoltà. Tutto ciò ha portato ad un eccesso di strumenti di gestione del lavoro, progettati soprattutto per team Scrum o "agili" e molti fornitori di strumenti promettono essenzialmente di migliorare l'agilità del team.

Naturalmente, nessuno strumento può fare in modo che un team sia "agile". La vera agilità deriva dalla cultura, dalle attitudini e dai comportamenti delle persone che creano e rilasciano il software. Per questo motivo, il manifesto per lo sviluppo agile di software[4] valorizza "gli individui e le interazioni più che i processi e gli strumenti".

Una massima comune nella community agile è "Le persone più che i processi e i processi più che gli strumenti".

Una massima comune dei pragmatisti è "Gli strumenti stabiliscono le regole".

Entrambe queste massime analizzano la relazione che le persone hanno con il software utilizzato per comunicare, collaborare e gestire il lavoro. Gli strumenti per tenere traccia del lavoro sono concepiti per ridurre la complessità nella comunicazione e nella conoscenza, l'esatto opposto di quello che potrebbe accadere. Non è insolito, ad esempio, che le persone acquisiscano l'abitudine di riportare inutilmente un malfunzionamento anziché correggerlo.

Nota degli autoriUna grande risorsa per coloro che considerano l'equilibrio tra strumenti, processi e procedure è il whitepaper di Kent Beck, Tools for Agility. Il documento risulta oggi ancora più interessante, se si considera che fu scritto da Beck nel 2008.

Scrum Master e membri del team di sviluppo sono propensi a lamentarsi del fatto che gli strumenti non siano aggiornati, quando i dati del lavoro o il sistema di traccia delle funzioni non sono attuali. Questa affermazione trascura ciò che è possibile comprendere intuitivamente:

L'obiettivo è mantenere attuale il team, non lo strumento. A volte, lo strumento può aiutare a raggiungere questo scopo.

Scrum è progettato specificamente per incrementare la consapevolezza situazionale del team Scrum. Scrum non affronta questioni come formato dei requisiti, stesura delle minute, suddivisione del lavoro, unità di stima o traccia del tempo. I team possono trovare questi argomenti utili e possono lavorare all'interno del contesto di Scrum. Ma i team che utilizzano queste procedure supplementari lo fanno in aggiunta a Scrum, non a causa di Scrum.

Qualsiasi strumento utilizzato da un team Scrum viene scelto con fiducia per supportare una procedura selezionata prima della strumento stesso. In altre parole, i team Scrum forti migliorano deliberatamente. Questo significa scegliere una nuova procedura o tecnica da provare perché il team desidera migliorare in un determinato settore. L'uso di uno strumento per supportare la nuova procedura avviene dopo che gli elementi fondamentali sono stati provati. In breve:

Scegliere innanzitutto persone capaci. Facendo parte di un team auto-organizzato, queste persone possono selezionare le proprie procedure e scegliere quindi uno strumento per supportare la procedura selezionata. Valorizzare le persone più dei processi e i processi più degli strumenti.

Per ulteriori informazioni sugli strumenti per supportare le procedure disponibili in Microsoft Visual Studio 2012, vedere Collaborare (approfondimento) [reindirizzamento], Collaborare [reindirizzamento] e la sezione Introduzione del portale di benvenuto in Visual Studio Online.

Il modo in cui i membri del team lavorano insieme ha effetti innegabili e ovvi sul software che viene creato. Se la comunicazione è semplice ed efficace, ciò si riflette nella progettazione del software che ne risulta. Al contrario, quando i team hanno difficoltà a comunicare internamente o con i team con cui collaborano, il software prodotto dal team riflette l'impedimento riscontrato.

Cicli regolari di ispezione e adattamento di Scrum a lungo andare aiutano i team in situazioni distribuite. Gli eventi prescritti in Scrum forzano la comunicazione, ma non necessariamente influiscono sulla forma in cui la comunicazione avviene.

Una stanza del team predisposta resta il modo più efficace, a più bassa tecnologia e a più alta fedeltà in cui un team può collaborare per creare software complesso. Tuttavia, i team remoti sono qui per restare. Se motivati da situazioni personali, vantaggi economici o mancanza di lungimiranza, moltissimi team Scrum si trovano a lavorare in situazioni in cui i membri del team non sono insieme fisicamente.

Curando la comunicazione del team oltre i confini fisici si otterranno migliore qualità, meno confusione, risultati più rapidi e individui più felici. Quando un'attenta considerazione viene attribuita a strumenti e procedure all'interno del team, la distribuzione può funzionare bene. Può funzionare perfino in modo eccellente.

Riferimenti

  1. Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. IEEE Software, 7

  2. McConnell, S. (2009). Travel Restrictions and Offshore Development.

  3. Cockburn, A. (2008). Osmotic Communication.

  4. Autori vari. Manifesto per lo sviluppo agile di software.

Aggiunte alla community

Mostra: