Distributed Scrum
David Starr è un Chief Software Craftsman per Scrum.org in cui viene analizzato il miglioramento della professione dello sviluppo software.Ha inoltre fondato la community tecnica online, ElegantCode.com.
Luglio 2012
I team distribuiti lottano spesso con la comunicazione coerente, tempestiva e valido.Comprendere come scrum fornisce un contenitore in cui i diversi tipi di team distribuiti migliora e gestire.
Il framework scrum non fornisce alcuna operazione sui team di sviluppo distribuiti.Scrum non richiede a tutti i membri di un team scrum o anche ai membri di un team di sviluppo eseguire nello stesso spazio, compilazione, city, o fuso orario.I team scrum attivamente espongono ostacoli alla produttività e quando la comunicazione è un impedimento, scrum che rende molto visibile.
Quando i membri del team non sono fisicamente insieme, le comunicazioni all'interno del team sono necessariamente più complesse e pertanto è anche il software creato dal team.In 1968, Melvin Conway impiegati:
Organizzazioni che i sistemi di progettazione sono limitati per scrivere le progettazioni che sono copie di strutture di comunicazione delle organizzazioni.
La lettura di Conway ha tentato più massima; è un flusso miglioramento all'interno dei team di sviluppo software.Uno studio è stato illustrato l'effetto della lettura di Conway misurazione il team che l'effetto della distribuzione potrebbe avere sull'architettura di sistema.Quando i membri del team sono distribuiti, gli sviluppatori di software consentono di creare più livelli di astrazione nel codice nel tentativo di isolarsi l'uno[1]da.
Panoramica
.gif "JJ620910.collapse_all(it-it,VS.110).gif")
Visualizzare il team nel codice
Stella è uno sviluppatore in un team scrum che consegna coerente il lavoro che ha pianificato per ogni sprint.Il team ha una reputazione per creare il software di alta qualità, anche se il codice presenta alcune difficile capire quando altri la lettura.
Funziona da casa e un fuso orario diverso dal resto del team.Utilizzano la posta elettronica, un sistema di gestione oneroso di requisiti e talvolta la videoconferenza per discutere il lavoro in ogni sprint.Utilizza scrum come stabilito con una metodologia scrum giornaliero pianificata contenere tutti pianificazione.Elabora le riunioni di pianificazione e la scrum giornaliero da telefono senza visualizzare le facce dei colleghi del team quando parlano.Non si sente le conversazioni verificarsi prima e dopo ogni scrum giornaliero.
Con una buona scopo, Proporzionale crea un livello di astrazione nel codice in modo che il relativo lavoro può essere isolato e testato.La nuova astrazione con l'implementazione dall'interfaccia che ha dichiarato e reso disponibile da altri membri del team.Questo tipo di sistema di collegamento consente alle architetture di sistema disaccoppiate eliminati, può asserisce."L'utilizzo delle interfacce come limite di implementazione è progettazione orientata a oggetti semplicemente buona," quanto si ricorda.Il nuovo modello di plug-in consente a di funzioni solo nella sezione di codice e non interferire con i colleghi del team che operano in altre aree.
Come la lettura di Conway stimato, il codice risulterà riflette la comunicazione con il team: a regime di controllo libero (" loosely-coupled ").La progettazione di sostituire le conversazioni che potrebbe avere con il team e il sistema diventa inutilmente complesso.Questa complessità non è un'immagine speculare delle relative relazioni con altri membri del team di sviluppo.Tali decisioni infine le costeranno i costi della società come esistono più righe di codice al proprio, più livelli di riferimento indiretto gli sviluppatori futuri comprensione e più test per provare la funzionalità di funzionamento di astrazione correttamente.
Stella viene effettuata alcuna operazione di errato.Infatti, correttamente è stato utilizzato in buono procedure di progettazione orientata a oggetti isolare un area problematica nel sistema.Sfortunatamente, il problema che ha isolato è le proprie problematiche di comunicazione e la soluzione consente anche la comunicazione meno frequentemente.Tristemente, il sistema ha modificato quando risolvere il problema era il software.Un modo più efficace per gestire questo problema può essere di semplificare le comunicazioni con il team di sviluppo.
Quando i membri del team non siedono raccolta tendono a sostituire gli scambi verbali facile con le conversazioni più difficili e più formale.Anziché rapidamente, le discussioni efficienti sulle piccole, decisioni tattiche, oggetti mette in coda e in attesa di essere descritti più avanti.Spesso, successivamente non viene mai.Un mezzo di comunicazione meno personali che eseguono la comunicazione giù in altre operazioni, quali le specifiche, vengono eseguiti i ticket, o addirittura codice.ISomeInterfaces esiste per analizzare le disfunzioni i team che vengono creati.
La complessità accidentale di distribuzione del team
Le decisioni prese da un team scrum sono quelle molto probabilmente per aumentare la complessità.I team di sviluppo software sono semplici raramente nella composizione o incarico e scrum fornisce un limite interno della quale il team scrum manovra e funziona per ridurre la complessità.Nonostante questo, la complessità effettivamente la scrittura di codice e di fornire software talvolta impallidisce rispetto a quella delle impostazioni cultura organizzative e processi inseriti nella modalità del team di sviluppo.
Pertanto, la decisione per comporre un team scrum i membri che risiedono nei fusi orari diversi viene effettuata raramente da utenti che hanno il lavoro.Le decisioni per creare un team distribuito scrum probabilmente provengono dai leader che è possibile assemblare un team è qualificato di pari livello o, più probabile) da tentare di ridurre i costi di produzione impegnando gli appaltatori del sito allo sviluppo del software per meno valuta.Mentre questi modelli possono ridurre il costo iniziale di sviluppo software, in genere non riescono a rappresentare i costi di manutenzione in corso e la complessità aggiunta per adattarli alle comunicazioni di lotta del team di sviluppo.
Indipendentemente da l o perché i team distribuiti vengono creati, sono una realtà e non mostrare segno di essere disattivato.Anche in situazioni del team distribuito, scrum rimane un framework eccellente per gestire la pianificazione e l'esecuzione della distribuzione di prodotti software.I membri del team che devono essere più diligenti sul miglioramento dei canali di comunicazione esistenti e come proteggersi dai miglioramenti quali quelli descritti nell'esempio precedente.
La realtà distribuita
I team distribuiti possono fornire funzionalità impiegare la persona destra per il processo indipendentemente dalla posizione in cui risiedono, o per alcuni utenti vivano cui scegliere anziché in cui la società è acquartierata.Sebbene comunicare con i team distribuiti sia semplice, in economia di esternalizzazione, nell'sourcing, il quasi sourcing e il rurale- sourcing rimangono accattivanti per molte organizzazioni.
La guida di scrum, pubblicata in Scrum.org, codifica scrum e è il set di regole da applicare il framework scrum.Mentre la guida scrum è invisibile all'utente sulla versione di team distribuiti e non fornisce istruzioni particolarmente li ha punti su, scrum farà più ovvio gli intervalli e gli sprechi di comunicazione che esistono in team che i membri non possono comunicare reciprocamente senza un apparecchio di calcolo che colma il divario.
Argomenti di attendibilità
Gran parte di che esseri umani indichino reciprocamente viene comunicato al linguaggio del corpo.Le informazioni raccolte osservando uno per una discussione di progettazione possono essere utili le informazioni che vengono scritte in lavagna.Per questo motivo, una parte dello stato attivo in colmare il divario tra i lavoratori distribuiti include superare la barriera di lingua del corpo.
Steve che McConnell impiegati,emivita di attendibilità è di circa 6 settimane." [2] Ciò riconosce che gli sviluppatori che lavorano e che collaborano a ogni giorno evoluzione un livello attendibili reciproca.La quantità di attendibilità varia come in qualsiasi relazione, ma la possibilità di attendibilità è superiore ai colleghi del team vedere e interagiscono tra loro spesso.
Quando i colleghi del team cessano di vedersi quotidianamente e non funzionano in prossimità di grandi dimensioni tra loro per circa sei settimane, il livello di attendibilità nel rapporto su ½ qual è la prima.Un breve tail rimanente di attendibilità diminuisce rapidamente mentre più tempo trascorre.
Non è che le persone coinvolte non dispone del relativo o anziché reciproco positivo, ma è considerato attendibile e l'efficacia del team viene persa.Senza attendibilità, le diminuiscano e i limiti di collaborazione tra i colleghi del team aumentano.I limiti vengono riflessi spesso nel codice.
Le fotocamere, il sistema di teleconferenze, la messaggistica immediata, visualizzare chat, schermo di condivisione e altri strumenti di collaborazione consentono di colmare il divario tra i colleghi del team e strumenti quali queste devono essere universale all'aria per i team distribuiti sono estremamente produttive.La frequente visualizzare comunicazione può passare una modalità lunga a ricompilare i file di attendibilità.
Gli strumenti utilizzati, i team distribuiti possono aumentare la propria efficienza sfruttando le possibilità per la comunicazione ad alta fedeltà.In breve, voce attiva è consigliato alla messaggistica immediata, che è preferibile di posta elettronica e così via.Ridurre il tempo tra le interazioni è comunque preferibile.
Gradi di separazione
Esistono diversi modi che i membri del team si trova svincolata l'uno da e sono comunemente modelli ricorrente di distribuzione del team.Come i modelli disponibili in altri ambienti (come progettazione software), i modelli di distribuzione del team possono verificarsi intenzionalmente o accidentalmente.I modelli accidentali si verificano durante una risposta a incosciente pressione esistente e i modelli intenzionali vengono implementati deliberatamente a complessità del controllo.
I modelli distribuiti scrum descritti in questo argomento possono essere prescritti o non.È possibile ispirati dalle decisioni prese dal team scrum o possono derivare dall'auto-organizzazione del team scrum intorno a un problema specifico.Indipendentemente da perché non a esistere, i modelli di distribuzione sono comuni in selvaggio.
I team di sviluppo remoto collaborano, ma fisicamente sono separati dal resto della società.
Nel modello remoto del membro del team, un membro del team lavora in un percorso diverso dal resto del team di cui ciascun utente è una parte.
In un team distribuito, i singoli membri del team si trova che insieme allo stesso obiettivo, ma ognuno da una posizione univoca.
Il team di sviluppo remoto
Alcuni team di sviluppo si trovano geograficamente separati dalla maggiore organizzazione nativa, o addirittura più valido, i proprietari del prodotto.Ciò è comune a una società acquisisce un altro o quando due società si uniscono.Se il team di sviluppo deve essere remoto, scrum è un modo ideale per gestire il lavoro e la comunicazione del team con la più vasta organizzazione.Molti team sono oggi con la formula.
Sebbene le situazioni varino, i team di sviluppo remoto si sentono spesso privati del diritto di voto, sottovalutati e tagliati dall'organizzazione principale.I membri del team remoto può risultare ignorati e estraneo dalla società nativa, che può (spesso in modo non intenzionale) si consideri il team meno importante che quelli presenti in sedi della società.
Questi team di sviluppo remoto cerca ripetutamente i motivi, le giustificazioni e funzionalità non integrare il lavoro con quella di altri team.Diventa facile spiegare perché l'integrazione di questo sprint non è importante, necessaria, o possibile.Il rancore si compila e il team di sviluppo per visualizzare le richieste di integrare il codice con la più vasta organizzazione "irragionevole", "dal tocco tramite la realtà", "a", o "non rispondere ai requisiti su".
Se nessuno o tutte queste impressioni è true è semplice.Il team di sviluppo remoto deve ritenere incontrata e riconosciuto, mentre conosce il proprio valore nella più vasta organizzazione.È facile dimenticare che una parte di qualsiasi operazione di maggiore di quando viene utilizzato in un post remoto.
Un lo scrum master che funziona in una posizione diversa dal team di sviluppo è una in per errore.I lo scrum master non è effettivamente eseguire le funzioni di preparazione, di semplificare gli eventi efficaci scrum e di stewarding scrum stessa da una distanza.La distanza tra un team di sviluppo e un lo scrum master impedisce la comunicazione e introduce un rischio troppo il team scrum.La conoscenza è richiesta di attendibilità e la fiducia reciproca di livello è fondamentale per il successo di scrum.
Lavoro dello scrum master nella stessa posizione dei team di sviluppo.
Per un team di sviluppo fungono la presenza del proprietario del prodotto richiede la comunicazione senza difficoltà e lineare.Il proprietario del prodotto deve essere disponibile al team di sviluppo in ogni sprint rispondere a domande e fornire feedback su lavoro in corso.Sebbene questa interazione frequente è possibile nelle situazioni remote, un metodo più affidabile per gestire tale comunicazione deve essere impostato.
Presente un proprietario del prodotto è uno dei vantaggi che più distruttive un team scrum può verificarsi.Un team di sviluppo ignorato deve prendere decisioni relative a funzionalità e la priorità.Questo gruppo è spesso il minimo in grado di effettuare le opzioni appropriate per quanto riguarda funzionalità come in genere meno sono dipendenti da sulle esigenze del cliente che il proprietario del prodotto.
I proprietari del prodotto forniscono l'attenzione e commenti al team di sviluppo nello sprint.
Sfortunatamente, assente o proprietari del prodotto disponibili vengono raramente un malfunzionamento comune nei team scrum, anche in ambienti collocati.Per scrum eseguire il relativo potenziale il team scrum deve essere eseguito come un coesivo, attendibili e unità di collaborazione e che richiede l'attenzione normale da un proprietario del prodotto dedicato.
Il membro del team remoto
Alcuni sviluppatori sono segregati i colleghi del team che costituiscono collocati e interagire in una posizione condivisa.L'esempio classico è lo sviluppatore di lavoro alla Home che con obbedienza funziona con un team dal Ministero di Interni.Sebbene i motivi varino per questa disposizione, è sempre più comune.
Alistair Cockburn ha coniato la comunicazione[3] osmotica di termine per identificare un tipo di comunicazione intrinseca nello spazio del team.
La comunicazione osmotica significa che flussi di informazioni sui precedenti e sentono risolvere i membri del team, in modo che accettano informazioni rilevanti come se da osmosi.In genere è possibile mettendoli a sedere nello stesso spazio.Quindi, quando un utente esegue un'applicazione, altre nella stanza possibile ottimizzare in o ottimizzare esterno, inerenti la discussione o continuando con il lavoro.
La comunicazione osmotica non è limitata ai team di sviluppo software.I visitatori a una scrittura in un grande journal o l'utilizzo di comunicazione cercheranno spesso esattamente questo flusso a gioco.Anche le stanze di squadra agente investigativo in dipartimenti di polizia di tutto il utilizzano le stanze del team per approfondire la conoscenza collettiva quando si esamina i crimini.
La comunicazione osmotica è la perdita di compatibilità base all'interno del team.Quando uno sviluppatore software non riconosce le modifiche apportate al software dai colleghi del team durante le modifiche vengono estese, esiste una perdita di coesione e di contesto condiviso all'interno del team.Il membro del team ininterrotto, attivata e remoto non si sente oro l'aria dello spazio del team.In questo modo consente alle discussioni ad hoc per quanto riguarda progettazione e altre decisioni che si verificano durante fluido un giorno specificato.
La tendenza fornire software con meno tempo tra versioni richiede più rapidamente nuovamente la consapevolezza base più elevata all'interno del team di sviluppo.Per il membro del team remoto senza la presenza nello spazio del team, la consapevolezza base viene persa semplicemente.
Le soluzioni di Tele- presenza si utilizzano più comuni risolvere questo problema.Le soluzioni semplici di tele- presenza possono essere compilate utilizzando un computer portatili, una fotocamera e di altoparlanti economici.Il posizionamento del sistema nello spazio del team può fornire un canale di comunicazione aperto per lo sviluppatore remoto che può lasciare sufficiente utilizzare il canale viene aperto durante una giornata.
La visualizzazione e il sistema di teleconferenze consentono di integrare un ponte la barriera di lingua del corpo.
Firma lo sviluppatore remoto è lottando effettivamente sia una parte del team sono:
Utilizzando le comunicazioni dattilografate come la posta elettronica o la messaggistica immediata per illustrare le problematiche complesse.
Definizione delle interfacce specificate come contratti nel codice anziché a discussioni normali con altri sviluppatori.
Essere un oggetto privato, o personale, ramo di codice nel controllo della versione.
In colmare il divario tra uno sviluppatore remoto e il resto del team, le visite di sono molto utili.Visualizzare le chiamate sono migliori di telefonate.Le telefonate sono migliori la digitazione e basarsi sulla posta elettronica è un un'eventuale calamità che attende per verificare.
Il team distribuito
Gli utenti true distribuiti di un team scrum contribuiscono a raggiungere lo stesso obiettivo sprint e funzionamento di ogni membro del team in un percorso diverso.L'esempio arco- tipico è un progetto open-source con i collaboratori che risiedono in diverse posizioni di tutto il mondo.Sebbene i problemi di comunicazione siano significative, questo modello dispone di validità dimostrabile.La comunicazione in un team di questa necessariamente è sfidata, ma sta divenendo più comune mentre la tecnologia continua a ridurre la barriera di lingua del corpo.
Quando i membri del team siedono in posizioni diverse, lo schermo che condivide il software è essenziale a efficaci conversazioni su progettazione e il codice.Per quanto riguarda il codice, a meno che entrambe le parti di una conversazione visualizzare la stessa operazione, la discussione sono troppe premesse.Fortunatamente, lo schermo che condivide il software è disponibile facilmente ed estremamente efficiente.I membri del team che non si trovano nello stesso spazio di cercarsi che condividono gli schermi con i colleghi del team diverse volte in cui il giorno.
Condividere lo schermo può essere un'associazione e uno strumento di collaborazione molto efficaci.
Ricerca di giustificazioni per esaminare il codice, gli elementi di backlog, o altri elementi raccolta è un ottimo modo per mantenere la compatibilità base in team distribuiti elevata.Un'altra tecnica efficace sta aggiungendo una regola semplice di verifica per qualsiasi elemento restituito come parte dello sprint.La regola in due parti è:
Ogni elemento deve essere verificato in un ambiente di integrazione da considerare il fatto.
La persona che esegue la verifica non può essere la persona che ha eseguito il lavoro.
I team di sviluppo che adottano questa regola semplice trova una maggiore conoscenza collettiva di lavoro che viene eseguito in tutto il team.
Il NoteI
creator eseguito con un team di sviluppo cui membri hanno eseguito nella stessa compilazione, ma in fra differenti. È un punto di orgoglio per la società immettere gli fra private per tutti i dipendenti. Il team di sviluppo che ha deciso di creare uno spazio virtuale del team in cui ogni membro del team potrebbe essere visualizzato utilizzando una fotocamera, un microfono e di altoparlanti. Lo spazio virtuale del team rimane sempre aperto e i membri del team cadrebbero nello spazio quando viene eseguito nel prodotto condivisi.
Dopo un breve periodo di tempo, il team è riuscito a apprezzare questo spazio virtuale. Avviate mediante lo schermo che condividono il software per visualizzare schermate di ogni oggetto anziché scorrendo verso il hall, perché verrà trovata per essere più veloci. Il team ha iniziato qualsiasi giorno utilizzando lo spazio virtuale del team, anche se sono sedendo di uffici presenti solo dai pollici dello spazio di muro.
Infine, uno dei membri del team ha tentato di non rientrano in ufficio per alcuni giorni e non funzionare dalla home page. Durante la retrospettiva dello sprint, il team di sviluppo ha accettato lo spazio virtuale del team reso semplice se un utente è alcune porte giù sul hall, o da casa. Lo spazio virtuale del team ha tentato più importante di uffici presenti diversi.
Strumenti e procedure
Più difficile viene effettuata dei team agile con gli strumenti di bassa tecnologia e ad alta fedeltà per gestire il lavoro.Quando la complessità di distribuzione geografica o team di sviluppo più aggiunto alla combinazione, moduli analogici e marcatori non vengono ridimensionati semplicemente nonché una soluzione basata software.Ciò ha portato a una sovrabbondanza gli strumenti di gestione di lavoro progettati in modo specifico per scrum o i team agile "," con più fornitori di strumenti essenzialmente che promettono il termine "strumento si renderanno Agile".
Strumenti confusione con le procedure
Naturalmente, nessuno strumento può provocare un team "è" Agile.La flessibilità genuina deriva dalle impostazioni cultura, da atteggiamenti e dai comportamenti di persone che esegue e consegna il software.Per questo motivo, l'agile manifesto[4] indica un valore di "utenti e interazioni nei processi e strumenti".
La massima nella community Agile è "persone sul processo e il processo sugli strumenti".
La massima di pragmatisti è ", gli strumenti definire le regole."
Entrambe massime parlano agli utenti di relazione hanno con software utilizzato per comunicare, collaborare e gestire il lavoro.Gli strumenti di rilevamento di lavoro vengono utilizzati per ridurre la complessità di comunicazione e la comprensione, ma è esattamente opposto a risultato può verificarsi.Per le persone non è raro eseguire il fallback della carreggiata inutilmente di segnalazione degli errori anziché correggerlo, ad esempio.
Note autori
I membri di master e di sviluppo team scrum a lamento incline, "strumento non aggiornati," quando i dati del lavoro o nel sistema di gestione della funzionalità non vengono aggiornate.Ciò evita che è possibile sapere intuitivo:
È necessario mantenere il team, non lo strumento.Talvolta lo strumento può consentire all'oggetto.
Scrum è specificamente progettata per aumentare la consapevolezza base del team scrum.Scrum è invisibile all'utente sul formato dai requisiti, minuti che consentono, le suddivisioni di lavoro, le unità di stima, o la verifica di tempo.I team possono trovare queste operazioni utili e possono lavorare nel contesto di scrum.Ma i team che utilizzano queste procedure aggiuntive sono in tal modo oltre alla metodologia scrum, non a causa di.
Procedure degli strumenti
Qualsiasi strumento utilizzato da un team scrum eventualmente viene scelto per supportare una pratica selezionata prima dello strumento.Ovvero i team integro scrum migliorano intenzionalmente.In tal modo è possibile scegliere una nuova procedura o tecnica provare perché il team desidera aggiornare in una determinata area.Utilizzando uno strumento supportare la nuova operazione potrebbe non funzionare dopo i principi vengono trovati insoddisfacenti.In breve:
Scegliere la quale gli utenti prima.Quando un team auto-organizzato, possono selezionare il relativo le proprie procedure e infine scegliere uno strumento per supportare la pratica che hanno scelto.Stimare le persone sul processo e il processo sugli strumenti.
(Per ulteriori informazioni sugli strumenti per supportare le procedure disponibili in Microsoft Visual Studio 2012, vedere Attività iniziali di un teamPianificazione Agile e iterazioni,e Informazioni la sezione del portale di benvenuto sul servizio Team Foundation).
Quando i membri del team collaborano effetti innegabili e intuitive il software che creano.Quando la comunicazione è facile ed efficace, la progettazione software risultante riflette la.Al contrario, quando i team lottano per comunicare internamente o con quelli non soddisfare, il software che il team produce rifletterà la impedenza esperienze del team.
I cicli standard di integrare e di ispezione di scrum per una modalità lunga ai team di aiuto in situazioni distribuite.Gli eventi prescritti in scrum forzano la comunicazione per verificare, ma non influiscono sulla forma che la comunicazione prendere.
Uno spazio collocato del team rimane la tecnologia più bassa, maggiore fedeltà e il modo efficiente un team può creare in collaborazione il software complessi.Tuttavia, i team remoti vengono qui rimanenti.Se base dalle situazioni personali, il vantaggio economico, o la mancanza di anteprima, sempre più team scrum si trova in esecuzione in situazioni in cui i membri del team non sono fisicamente raccolta.
Assistendo la comunicazione di un team sui limiti fisici pagherà i dividendi in più di alta qualità, in meno confusione, velocità effettiva più veloce e più soddisfatti utenti.Quando un avviso reflection consente agli strumenti e le procedure all'interno del team, la distribuzione può essere eseguita correttamente.Può essere molto bene.
Riferimenti
Herbsleb, 1999 Architetture e coordinamento distanza: La legge di Conway e oltre.Software IEEE, 7
McConnell, S.(2009).Restrizioni di viaggio e sviluppo offshore.
Cockburn, A.(2008).Comunicazione osmotica.
varie.Agile manifesto.