Come si può adattare Scrum a un ambiente di volontariato?

Di recente mi sono unito a un giovane hackerpace ancora in procinto di installarsi. Siamo fortunati perché lo spazio ha alcuni progetti interni su cui è necessario lavorare e non mancano i volontari per lavorarci.

Ci sono state alcune discussioni su come organizzare questi progetti. La mia esperienza professionale più recente è stata con Scrum, quindi sto prendendo in considerazione un approccio Scrum per i nostri progetti software, ma non sono sicuro che sarà adatto.

Sebbene abbia visto Scrum funzionare bene per piccoli team a tempo pieno, la natura di questa organizzazione è diversa:

• I membri sono volontari . Alcuni sono studenti a tempo pieno. Altri lavorano a tempo pieno. Non possiamo aspettarci un livello costante di contributo da parte di nessuno dato che la loro vita reale ha la priorità.
• Mentre praticamente tutti hanno anni di esperienza nella scrittura di software, non molti membri lo hanno fatto in modo professionale o in team.
• Non esiste un proprietario del prodotto . I requisiti per questi progetti sono determinati da un comitato. I membri di questo comitato lavoreranno anche all'attuazione. Ciò significa che non avremo un singolo, dedicato, Product Owner.
• Non abbiamo scadenze (soft o hard). I progetti verranno completati quando verranno completati.

Queste sono differenze abbastanza significative, ma non sono convinto che bloccheranno l'applicazione di Scrum. Penso che alcune modifiche minori potrebbero farci superare questo ostacolo:

• Se cambiamo Sprint in modo da avere una dimensione del punto della storia fissa, ma una durata fluida (tempo), possiamo ancora beneficiare di rilasci iterativi senza esercitare pressioni irrealistiche sui fornitori di volontari.
• Possiamo abbandonare i grafici di burndown e il calcolo della velocità . Se ho capito bene, questi sono strumenti e metriche che funzionano come un ponte tra il team di sviluppo e la direzione. Servono a segnalare i progressi in una forma significativa sia per gli sviluppatori che per le parti interessate. Considerando che non abbiamo nessuno a cui riferire (nessun Project Manager, nessun Product Owner e nessun stakeholder esterno) credo che possiamo lasciar perdere del tutto.

Cose che penso potremmo trarre vantaggio da cui non sarà necessario modificare:

• La raccolta dei requisiti incontro (s). Dove tutti si siedono intorno a un tavolo e discutono le User Story, disegnano bozze dell'interfaccia utente e creano un Product Backlog.
• Retrospettive Sprint . Questo sarà un modo interessante per noi di convergere su un processo di sviluppo che funziona per noi come una squadra di volontari.

Cose di cui non sono sicuro:

• Come devono essere trattati gli Stand-up quotidiani ? Mi chiedo se avrebbero avuto molto valore nel nostro ambiente. La mia comprensione del rituale stand-up è che aiuta la comunicazione diffondendo naturalmente le informazioni in tutto il team. Considerando il fatto che i nostri Sprint forniranno probabilmente molta meno complessità di uno Sprint medio, potrebbe essere necessario tenere conto di tutti i progressi / sviluppi di tutti gli altri membri del team.
• Devo spingere per XP cose come l'integrazione continua, recensioni di codice e TDD? Sono preoccupato che questo chiederà molto. Sarei più tentato di inserire questi concetti nei progetti futuri una volta che le persone avranno più familiarità con Scrum e lavoreranno in gruppo.

Le mie domande:

Scrum può essere adattato a un ambiente di volontariato?
E il mio approccio pianificato finora sta andando nella giusta direzione?

Guarda in Kanban. È più appropriato di SCRUM per i tuoi vincoli.

Modifica: SCRUM è (molto approssimativamente) un arretrato ordinato con sprint e cerimonie per garantire che il volume del lavoro "in progress" rimanga sotto controllo e abbia qualcosa di solido alla fine di ogni sprint. Se elimini le cerimonie e la cadenza degli sprint finirai con Kanban: un arretrato ordinato e una forte enfasi sulla limitazione diretta del lavoro "in corso" e assicurandoti che tutto ciò che è contrassegnato "fatto" sia fatto piuttosto che imponendo stabilità alla fine di ogni sprint.

Ottieni ancora vantaggi agili: rilascio in qualsiasi momento, flessibilità, una certa misura della prevedibilità - sebbene SCRUM possa portarti leggermente oltre su quell'aspetto - e senza le cerimonie o gli aspetti di SCRUM che non si adattano bene a un team sciolto e distribuito senza impegno . La presa? Abbandonare le cerimonie richiede più disciplina, quindi VERAMENTE è necessario prestare attenzione ai test, alla qualità del codice, all'attuale lavoro in corso e assicurarsi che la parte superiore dell'arretrato (materiale pronto per essere raccolto dalle persone) sia sufficientemente elaborato.

Potresti avere un backlog basato sul voto, anche se in un ambiente di volontariato alcune persone lavorano solo su ciò che vogliono.

(E sì, tutte le idee di TDD, CI, recensioni e programmazione peer sono buone idee).

Per affrontare le differenze che noti per prime:

• Il fatto che i tuoi membri siano volontari non significa che non puoi chiedere loro un impegno. Soprattutto con la durata relativamente breve di uno sprint in Scrum, deve essere possibile per ciascuno dei membri sapere quanto tempo possono dedicare al progetto per le prossime settimane. Avere i membri del team disponibili per un periodo di tempo diverso ogni sprint renderà la pianificazione un po 'più difficile, perché è più difficile determinare quanti punti di immagazzinamento sono realistici, ma non rende impossibile Scrum.
• Il proprietario del prodotto è responsabile del consolidamento e della comunicazione della visione (e dei requisiti) che le parti interessate hanno per il prodotto al team di sviluppo. La parte consolidante è probabilmente già coperta dal comitato direttivo. Per quanto riguarda la comunicazione, possono semplicemente delegare uno dei loro membri come portavoce principale. Quello sarà quindi per tutti gli scopi pratici il proprietario del prodotto.
• Non avere una scadenza esterna non è davvero un problema per Scrum. Dipende solo dall'orgoglio della squadra nel prodotto per farlo finire. Scrum stesso ha una scadenza naturale per ogni sprint.

Per quanto riguarda gli adattamenti proposti, in particolare quando si lavora con volontari, consiglio vivamente di mantenere la lunghezza dello sprint fissa. In questo modo, i volontari sanno sicuramente per quale periodo stanno dando il loro impegno.

Inoltre non abbandonerei immediatamente i grafici di burndown. Possono anche essere utili per il team stesso per vedere come stanno andando sul loro impegno. Lascerei alla squadra la decisione di tenerli o abbandonarli. Lo stesso vale per i calcoli della velocità. specialmente con la grande variazione dei manhour disponibili ogni sprint, possono rivelarsi molto utili (specialmente se si calcola il numero di punti completati per manhour) nella stima degli sprint futuri.

Per quanto riguarda gli standup giornalieri, saranno comunque utili nella tua impostazione, se non altro per far sapere cosa fanno o hanno problemi con tutti (e questo è indipendente dalla complessità). Ma potrebbe essere più difficile realizzare uno standup quotidiano, quindi potresti dover scendere a compromessi lì.

Le pratiche XP menzionate possono essere introdotte o meno indipendentemente dall'uso di Scrum e potrebbero anche essere proposte durante una retrospettiva.

Mi sorprende che nessuno lo abbia sottolineato, ma il tuo progetto sembra la maggior parte dei progetti open source. Se dai un'occhiata ad alcuni progetti open source più popolari, potresti trovare qualche ispirazione. E penso che dovresti dimenticare SCRUM e pensarci da una prospettiva di agilità generale.

Agile è una questione di comunicazione e collaborazione. C'è motivo per cui 2 punti su 4 nel Manifesto Agile ne parlano.

Individui e interazioni su processi e strumenti

Collaborazione con i clienti sulla negoziazione del contratto

E nel modo in cui descrivi il tuo progetto, sarebbe difficile avere una comunicazione faccia a faccia con tutti coloro che lavorano al progetto, cosa che sia Agile che SCRUM incoraggiano. Quindi la prima cosa su cui mi concentrerei è stabilire canali di comunicazione per l'intero team (sia i volontari che il comitato del prodotto). Cose come wiki, forum, videoconferenze e un adeguato backlog, attività e sistema di tracciamento dei bug sono ottimi modi per assicurarsi che tutti sappiano cosa sta succedendo e cosa deve essere fatto.

La seconda cosa che vorrei notare è non limitarsi a spazzolare le parti tecnologiche dell'agile. Molti credono (me compreso) che sono quelli che fanno un lavoro agile, non il lato processuale delle cose. La revisione del codice è importante e la maggior parte del lavoro open source è avere qualcuno che conosce il progetto rivedere gli impegni / spingere per garantire che sia mantenuta una qualità abbastanza elevata. TDD è praticamente dato per qualsiasi progetto agile. Assicura che eventuali modifiche al codice non rompano le funzionalità precedenti, il che è ancora più importante nel tuo caso quando i volontari non possono essere disturbati a correggere errori ed errori di altre persone. Semplifica anche la revisione del codice perché il revisore può vedere nei test quale funzionalità è stata aggiunta e, eseguendole, garantisce che la funzionalità funzioni effettivamente come previsto. L'integrazione continua è uguale a TDD.

L'ultima cosa è che credo che dovresti avere almeno poche persone che lavorano al progetto a tempo pieno. Queste persone dovrebbero avere ruoli specifici:

• Proprietario del prodotto : anche se è bello che tu abbia un intero comitato dedicato a questo, dovrebbe esserci una persona che è responsabile dell'interpretazione delle parole di questo comitato in specifiche o storie degli utenti e di assicurarne la corretta attuazione.
• Coordinatore e Scrum Master : questa persona dovrebbe essere responsabile dell'intero processo e assicurarsi che tutti siano a conoscenza delle cose importanti che accadono nel progetto. Inoltre, mantiene gli strumenti wiki e di tracciamento di attività e bug. Se qualcuno ha una domanda sul progetto, questa è la prima persona che dovrebbe porre.
• Sviluppatore principale e architetto : la persona che conosce meglio il codice. Fa le revisioni del codice e garantisce che la qualità del codice sia abbastanza buona per uno sviluppo agile.

Non puoi adattarlo come stai descrivendo e comunque chiamarlo SCRUM. ma secondo me, puoi usare Scrum come segue per la configurazione che hai descritto.

1. Ho corretto l'iterazione. In modo che tu possa misurare i tuoi progressi. Questo non è solo per la gestione, ma anche per il team di "sapere" come si stanno comportando.
2. Chiedi ai volontari di condividere le capacità all'inizio dell'iterazione. Tutto il team ha bisogno di ciò che i membri si stanno impegnando, altrimenti alcuni membri potrebbero lasciare il team per un lavoro più professionale.
3. Non avere una scadenza va bene. Scrum non impone che comunque ciò che fai alla fine di ogni iterazione dovrebbe essere potenzialmente spedibile. Questo ti permetterà di decidere cosa fare dopo in base a ciò che hai fatto fino ad allora (che sta funzionando).
4. Anche non avere un proprietario del prodotto può funzionare. Puoi avere una sorta di sistema di voto per impilare il backlog di classifica e accettare / rifiutare il lavoro svolto.
5. La raccolta dei requisiti non fa parte di Scrum. Puoi farlo comunque lo vuoi. Ma non includerlo come parte dell'ambito di iterazione. Hanno capacità separate per quello. Quindi, per un'iterazione, pianifica solo quel lavoro per cui sono chiari i requisiti, ad esempio il team conosce i criteri di accettazione.
6. Le retrospettive sono buone. Quindi inizia Scrum così ma poi usando la retrospettiva vedi cosa sta funzionando e cosa no, ad esempio potresti aver bisogno di cambiare la dimensione dell'iterazione, potresti aver bisogno di sbarazzarti di alcuni volontari che stanno trascinando tutti gli altri.
7. Lo stato giornaliero è obbligatorio. Ciò offre al team l'opportunità di sincronizzarsi tra loro, ad esempio allineando i propri sforzi in modo tale che nessuna attività venga bloccata inutilmente a causa dell'indisponibilità dei risultati dell'altro membro.
8. XP è buono. Avere una definizione rigorosa di fatto basata su XP, ad esempio nessun codice entra se non rivisto. Fai di meno per fare di più ..

Potrei suggerire un approccio diverso. Dato che hai a che fare con i volontari, hai alcune cose da considerare. La tua squadra avrà probabilmente un alto turnover, la vita si metterà in mezzo e le persone saranno distratte. Di quelli rimasti pochi contribuiranno in modo coerente ma non molto, quindi alla fine avrai quel gruppo hardcore che affonda davvero i denti nel progetto. Sto facendo molte ipotesi sulla tua forza lavoro qui e se ritieni che la mia valutazione non rifletta le persone con cui lavori, sentiti libero di ignorare il resto.

Ora hai bisogno di una strategia che consenta alle persone che non fanno molto lavoro di essere in grado di lavorare in modo abbastanza autonomo, hanno solo così tanto tempo da dedicare a questo e non vuoi farle spendere la maggior parte nella comunicazione. Le persone che sono più coinvolte dovrebbero essere responsabili dell'integrazione e della cancellazione di alcune delle idee più complesse.

Questo mi porta a pensare a un processo di sviluppo più incentrato su telai e prototipi di filo metallico.

Puoi avere un pool di oggetti di lavoro disponibili e incoraggiare le persone a scrivere cornici di filo per quelli. Puoi usarli come Tracer Bullets (terminologia presa in prestito dal programmatore Pragmatic) per approfondire l'idea e fornire ispirazione alle persone su cui costruire. Da lì puoi trasformare le idee di successo in prototipi, anche in questo caso sono progetti molto piccoli progettati per aiutare le persone a saperne di più sui progetti. Dopo di che ora hai una sezione più piccola di idee solide che sono state costruite da una moltitudine di persone che puoi consegnare ad un team un po 'più attivo e che possono lavorare per integrare tali idee nel tuo sistema.

Penso che Kanban si adatterebbe meglio per questa situazione.

Scrum ha alcune cose che non vanno bene. I tempi o le misurazioni dell'ambito non sono necessari e lo sviluppo di everoyone ha la stessa visione del prodotto degli incontri. Responsabilità e seguire un breve piano con coerenza sono obiettivi aziendali.

Kanban offre quasi tutti gli stessi vantaggi di Scrum senza i suoi svantaggi. Può darti una prototipazione rapida. I prototipi possono essere eseguiti prima delle riunioni. Fornisce inoltre TDD per test di regressione e codice modificabili. La programmazione delle coppie può facilitare i nuovi arrivati ​​e i non regolari alla base di codici trasferendo le conoscenze.

Kanban ha anche vantaggi unici. Se la visione di ciò che fanno gli utenti viene sviluppata in parallelo, Kanban funziona bene. Ne è prova il successo per i programmi per le piccole imprese. Inoltre, per i giorni con pochi volontari come tre persone, Kanban avrebbe comunque funzionato bene. Scrum, nonostante sia leggero sarebbe troppo nastro giallo.