Scrum e Scrum Master in un team globale

Molte pratiche Scrum saranno utili. Alcuni di questi mostreranno problemi che dovrai affrontare in modo diverso, data la natura Waterfall del progetto. Ecco le cose che penso saranno utili anche in Waterfall:

• Stand-up quotidiano (può essere fatto per telefono o per video)
• Retrospettive (per telefono, video conf o email)
• Consegna incrementale e iterativa

Riguardo alle stime e alla velocità, Scrum è un po 'strano nel fatto che si basa sul fatto che il costo del cambiamento è piuttosto costante (vedi sotto), ma in realtà non prescrive alcuna pratica per farlo. Se desideri iniziare a utilizzare la stima e misurare la tua velocità, darei un'occhiata alle pratiche di XP. Cose come TDD, programmazione a coppie (o uso di revisioni del codice in cui è distribuito), proprietà del codice collaborativo, refactoring e integrazione continua miglioreranno anche la qualità del software, soprattutto in considerazione della distribuzione del team.

Tuttavia, lo scopo di stima e velocità è quello di consentire una pianificazione efficace e adattiva del rilascio (oltre a incoraggiare l'impegno del team). L'idea è che un burn-up a livello di rilascio o un burn-down mostreranno se si sta andando a rispettare la scadenza o meno. In Scrum, rispondi alla scoperta che perderai la tua scadenza tagliando l'ambito o estendendo la scadenza. In Waterfall, potresti non avere questa opzione. Almeno ti darà più informazioni, permettendoti forse di lavorare in modo più efficace per un periodo più lungo piuttosto che scricchiolare alla fine, e sicuramente ti aiuterà ad avere conversazioni su quel rischio.

Il vero pericolo per te sarà che consegnando e mostrando in modo incrementale i prodotti, le possibilità che l'azienda cambi idea è aumentata . Questo non funziona bene con un budget di Waterfall o un pesante controllo dei cambiamenti. Avere un team distribuito rende anche più difficile comunicare e adattarsi ai cambiamenti. L'alternativa è mostrare gli incrementi solo all'interno del team e fornire software che l'azienda potrebbe non volere - ma questa è la mentalità di Waterfall; l'enfasi è sul fatto che sia giusto iniziare, piuttosto che reagire alla scoperta che hai sbagliato. Se riesci a gestire la politica, allora qualsiasi forma di Agile è una buona mossa (i praticanti Scrum diranno spesso che non è Scrum se la squadra non è co-localizzata).

Un esperto Scrum Master o un allenatore potrebbe aiutare. Sono abituati a vendere i benefici della consegna iterativa e parlano attraverso le politiche associate.

Uno degli scenari in cui Scrum generalmente non è raccomandato è il team distribuito. È molto difficile eseguire il processo Scrum corretto quando i membri del team non si trovano nello stesso spazio di lavoro e nello stesso fuso orario . Scrum parla molto della comunicazione, non solo tra i membri del team, ma anche tra i membri del team e il proprietario del prodotto. È il proprietario del tuo prodotto sul tuo sito o sul sito off-shore? In entrambi i casi, un sito non può comunicare efficacemente con il proprietario del prodotto. Lo stesso accade con lo Scrum master. In che modo lo Scrum Master può risolvere gli impedimenti il più velocemente possibile se lavora in un fuso orario diverso?

Un altro problema della descrizione del processo è in realtà una posizione di leadership tecnologica. Il team Scrum è un gruppo auto-organizzato di persone dotate di poteri e di funzioni trasversali (il potenziamento delle persone è uno dei principali principi agili). Ciò non significa che non possano chiederti un consiglio ma nello stesso tempo non devono farlo e possono farlo a modo loro.

Molte aziende stanno facendo esattamente ciò che descrivono e usano qualcosa che chiamano Scrum - lavoravo per una di queste società. C'è una fiaba globale secondo cui lo sviluppo off-shore è una pallottola d'argento per ridurre i costi, ma la mia esperienza è che non dovresti combinare sviluppatori on-shore e off-shore nella stessa squadra. O crea due team separati o sposta l'intero sviluppo su un sito.

L'utilizzo del team distribuito comporta inoltre costi aggiuntivi per le videoconferenze e le videoconferenze, nonché costi elevati in viaggio. Ad esempio, se si avvia un nuovo progetto, l'intero sito (off-shore o on-shore) deve essere spostato per uno o due sprint in un unico posto in modo che le persone si incontrino e ottengano una relazione di base. È sempre meglio che il morale si conosca a vicenda.

Lo stavo facendo nella mia ultima squadra - Microsoft pattern & pratiche - per diversi anni. Ecco un white paper su ciò che abbiamo imparato facendo distribuito agile (Scrum / XP):

link

Ecco un discorso e alcuni link al lavoro di altre persone sullo stesso argomento:

link

Ciò che vedi è piuttosto tipico. Il lead tecnologico è onshore e passa molto tempo a rivedere il codice, interfacciarsi con gli stakeholder a terra ecc.

My question is, do you think I can use some agile methodologies here in a loose sense (we're a waterfall company, but maybe I could do scrum, sprints, planning poker, etc)? Also, do you think we could benefit from a scrum master? What if I didn't have the additional onshore developer (so basically I'd be one of two onshore developers then, and neither of us might be on the project full time)?

No. Il punto principale nello sviluppo agile è un ciclo di comunicazione piuttosto che di pianificazione e progettazione anticipata.

Nel tuo caso avrai difficoltà con le comunicazioni con il resto della squadra.

Tenendo conto del fatto che si dispone di un'organizzazione di tipo "a cascata" e di 2 coordinatori su entrambi i lati, suppongo che alcuni processi di lavoro più o meno già stabiliti. Hai una sorta di design in anticipo, una sorta di pianificazione. Ha vinto meglio con la mischia.

Certo, cose come le riunioni giornaliere potrebbero essere utili, ma non è una "mischia", è solo un buon senso.

Certamente puoi e non c'è motivo di non farlo perché la tua azienda utilizza un approccio a cascata.

Per prima cosa, le riunioni di mischia o le alzate quotidiane o qualsiasi cosa tu voglia chiamarle sono buone, basta attenersi al formato di

1. Dall'ultima mischia ho raggiunto
2. Dalla prossima mischia realizzerò
3. Imprevisti inattesi che hanno influito su ciò che ho raggiunto
4. Difetti attesi tra ora e la prossima mischia

Poi c'è l'idea degli sprint. Uno dei maggiori problemi con i team off shore è quello di tenere sotto controllo ciò che stanno producendo. Usa gli sprint per tagliare il lavoro in sezioni gestibili piuttosto che dire "Ecco una specifica, ci vediamo tra tre mesi con il prodotto finito"

Infine coinvolgimento e feedback degli stakeholder. Questo si lega agli sprint ed è fondamentalmente la tua possibilità di validare il lavoro fino ad oggi con le persone che lo pagano e mostrare che ci sono progressi. Se ci sono problemi puoi stroncarli sul nascere velocemente.