In che modo Scrum può essere adattato all'impostazione di un volontario?

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 di lavoro "in corso" rimanga sotto controllo e abbia qualcosa di solido alla fine di ogni sprint. Se si abbandonano le cerimonie e la cadenza degli sprint si finisce con Kanban: un arretrato ordinato e una strong enfasi sul limitare il lavoro "in atto" direttamente e assicurandosi che tutto ciò che è contrassegnato come "fatto" sia fatto piuttosto che imponendo stabilità alla fine del ogni sprint.

Hai ancora i benefici agili: rilascia in qualsiasi momento, flessibilità, una certa misura di prevedibilità - anche se SCRUM può darti un po 'di più su questo aspetto - e senza le cerimonie o aspetti di SCRUM che non si adattano bene a un team libero e distribuito senza impegno. La presa? Lasciare le cerimonie richiede più disciplina, quindi è DAVVERO necessario prestare attenzione ai test, alla qualità del codice, al lavoro in corso e assicurarsi che la parte superiore del backlog (materiale pronto per essere raccolto dalle persone) sia sufficientemente elaborato.

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

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

Per risolvere le differenze che noti per prima:

• 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 impegnarsi per il progetto nelle prossime settimane. Avendo i membri del team disponibili per un diverso periodo di tempo, ogni sprint renderà la pianificazione un po 'più difficile, perché è più difficile determinare quanti punti storti sono realistici, ma non rende Scrum non fattibile.
• Il proprietario del prodotto è responsabile del consolidamento e della comunicazione della visione (e dei requisiti) che gli stakeholder hanno per il prodotto al team di sviluppo. La parte consolidante è probabilmente già coperta dal comitato "direttivo". Per la parte relativa alla comunicazione, possono delegare uno dei loro membri come loro principale portavoce. Quindi, per tutti gli scopi pratici, sarà il proprietario del prodotto.
• Non avere una scadenza esterna non è un problema per Scrum. Si tratta solo dell'orgoglio della squadra nel prodotto per finire. Lo stesso Scrum ha una scadenza naturale per ogni sprint.

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

Inoltre, non eliminerei i grafici di burndown immediatamente. Possono anche essere utili per il team stesso per vedere come stanno facendo il loro impegno. Lascerei decidere alla squadra di tenerli o di abbandonarli. Lo stesso vale per i calcoli di velocità. in particolare con la grande variazione delle ore di manodopera disponibili per ogni sprint, possono rivelarsi molto utili (specialmente se si calcola il numero di punti completati per uomo) nella stima degli sprint futuri.

Per quanto riguarda gli standup giornalieri, saranno comunque utili nelle tue impostazioni, se non altro per far sapere a tutti cosa sta affrontando o ha problemi con (e questo è indipendente dalla complessità). Ma potrebbe essere più difficile realizzare una situazione quotidiana, quindi potrebbe essere necessario scendere a compromessi lì.

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

Mi sorprende che nessuno lo abbia indicato, 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 dimenticarti di SCRUM e pensarci da una prospettiva di agilità generale.

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

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

E nel modo in cui descrivi il tuo progetto, sarebbe difficile avere una comunicazione faccia a faccia con tutti coloro che lavorano al progetto, qualcosa che incoraggia Agile e SCRUM. Quindi, la prima cosa su cui vorrei concentrarmi è stabilire canali di comunicazione per l'intero team (sia i volontari che i product committee). Cose come wiki, forum, videoconferenze e un backlog adeguato, il sistema di tracciamento di attività e bug sono ottimi modi per garantire che tutti sappiano cosa sta accadendo e cosa deve essere fatto.

La seconda cosa che osserverei è non solo spazzolare le parti tecnologiche dell'agile. Molti credono (me compreso) che sono quelli che fanno il lavoro agile, non il lato processo delle cose. La revisione del codice è importante e la maggior parte del lavoro open source consiste nel far sì che qualcuno che conosce il progetto riesamini il commit / push per garantire che venga mantenuta una qualità sufficientemente elevata. TDD è praticamente dato per qualsiasi progetto agile. Garantisce che eventuali modifiche al codice non interrompano la funzionalità precedente, il che è ancora più importante nel tuo caso quando i volontari non possono essere disturbati a correggere gli errori e gli errori di altre persone. Rende anche più semplice la revisione del codice perché il revisore può vedere nei test quale funzionalità è stata aggiunta e, eseguendoli, garantisce che la funzionalità funzioni effettivamente come previsto. L'integrazione continua è la stessa di TDD. Garantisce che l'applicazione esegua ciò che è previsto consentendo un ciclo di feedback breve con il comitato cliente / prodotto.

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 : sebbene sia bello avere un intero comitato dedicato a questo, dovrebbe esserci una persona che è responsabile dell'interpretazione delle parole di questo comitato nelle specifiche o nelle storie degli utenti e assicurarsi che siano correttamente implementate.
• Coordinatore e amp; 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 task & bug tracking. Se qualcuno ha una domanda sul progetto, questa è la prima persona che dovrebbero chiedere.
• Sviluppatore principale e amp; architetto : la persona che conosce meglio il codice. Esegue le revisioni del codice e garantisce che la qualità del codice sia sufficiente per uno sviluppo agile.

Non è possibile adattarlo come si sta descrivendo e lo si chiama ancora SCRUM. ma secondo me, puoi usare Scrum come segue per il setup che hai descritto.

1. Hai corretto l'iterazione. In modo che tu possa misurare i tuoi progressi. Questo è non solo per la gestione ma anche per la squadra per "sapere" come sono esecuzione.
2. Chiedi ai volontari di condividere le capacità all'inizio dell'iterazione. Tutta la squadra ha bisogno di ciò che i membri stanno commettendo altrimenti certi membri possono lascia la squadra per un lavoro più professionale.
3. Non avere una scadenza va bene. Scrum non costringe questo comunque lo 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 a quel momento (che funziona).
4. Non avere il proprietario del prodotto può funzionare anche ... Puoi avere una sorta di votazione sistema per impilare il backlog di rango e accettare / rifiutare il lavoro svolto.
5. La raccolta dei requisiti non fa parte di Scrum. Puoi farlo comunque tu lo voglio. Ma non includerlo come parte dell'ambito di iterazione. Avere capacità separata per quello. Quindi, per un'iterazione, pianifica solo il lavoro per quali requisiti sono chiari, ad es. la squadra conosce i criteri di accettazione.
6. La retrospettiva è buona. Quindi avvia Scrum come ma poi usando retrospettiva vedi cosa funziona e cosa no ad es. Potresti aver bisogno per cambiare la dimensione delle iterazioni, potrebbe essere necessario liberarsi di alcuni volontari che stanno trascinando tutti gli altri ..
7. Lo stato giornaliero è obbligatorio. Ciò dà l'opportunità al team di sincronizzarsi l'un l'altro, cioè allineeranno i loro sforzi in modo che nessun compito arrivi bloccato inutilmente a causa di indisponibilità di altri membri deliverable.
8. XP è buono. Avere una definizione rigorosa di fatto basata su XP, ad es. no il codice viene inserito a meno che non venga esaminato. 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. Il tuo team avrà probabilmente un alto turnover, la vita si intrometterà e la gente si distrarrà. Di quelli lasciati pochi contribuiranno in modo consistente, ma non molto, e infine avrai quel gruppo hardcore che affonda i denti nel progetto. Sto facendo molte supposizioni 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 di questo.

Ora hai bisogno di una strategia che permetta alle persone che non lavorano molto di essere in grado di lavorare in modo abbastanza autonomo, hanno solo così tanto tempo da dedicare a questo e non vuoi far loro passare il tempo maggior parte di ciò nella comunicazione. Le persone che sono più coinvolte dovrebbero essere responsabili dell'integrazione e del lavaggio di alcune delle idee più complesse.

Questo mi porta a pensare a un processo di sviluppo più focalizzato su wireframe e prototipi.

Puoi avere a disposizione un pool di elementi di lavoro e incoraggiare le persone a scrivere telegrammi per questi. Puoi utilizzarli come Tracer Bullet (terminologia presa in prestito dal programmatore Pragmatic) per affinare l'idea e fornire ispirazione per le persone su cui costruire. Da lì puoi trasformare le idee di successo in prototipi, ancora una volta questi sono progetti molto piccoli progettati per aiutare le persone a imparare 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 passare ad alcuni membri del team che è un po 'più attivo e che possono lavorare per integrare queste idee nel tuo sistema.

Penso che Kanban si adatterebbe meglio per questa situazione.

Scrum ha alcune cose che non si adattano. Le misurazioni di timing o scope non sono necessarie e lo sviluppo di everoyone ha la stessa visione di prodotto degli incontri. Responsabilità e seguendo un piano breve con coerenza sono obiettivi di business.

Kanban offre molti degli stessi vantaggi di Scrum senza i suoi svantaggi. Può darti una rapida prototipazione. I prototipi possono essere eseguiti prima delle riunioni. Fornisce inoltre TDD per test di codice e regressione mutevoli. La programmazione di coppie può facilitare i principianti e non regolari nel codice base trasferendo le conoscenze.

Kanban ha anche vantaggi unici. Se la visione di ciò che gli utenti fanno è sviluppata parallelamente, Kanban funziona bene. Prova di ciò è il successo per i programmi di 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.