Scrum, Kanban o Altro per il team di sviluppo di 4 persone

Question

Abbiamo un team di sviluppo di quattro persone che ha bisogno di un sistema di gestione del progetto formalizzato. Ho una conoscenza generale di Scrum e Kanban ma è difficile da capire fino a che non viene provato. Non abbiamo il lusso di provarne uno per un paio di settimane e poi passare a un altro, quindi speravo che qualcuno là fuori in una situazione simile potesse avere pensieri su cui ha funzionato meglio per loro e perché. Inoltre, qualsiasi altro sistema per la gestione dello sviluppo che funzionasse sarebbe bello da ascoltare.

Un'altra nota: c'è la possibilità che il team cresca, ovviamente, quindi avremmo bisogno di un sistema che si adattasse bene.

Ancora un'altra nota: Noi lavoriamo su tre applicazioni software separati in Windows che sono tutti basati su una libreria centrale che abbiamo anche scritto (quindi credo che si possa dire che quattro progetti)

Answer 1

Scrum e Kanban sono entrambi "scheletri" di processo. Né è specifico per lo sviluppo del software. Scrum è stato reso popolare dalle organizzazioni di sviluppo software ma è posizionato come tecnica di gestione generale piuttosto che come tecnica di project management del software. Kanban è emerso dalla produzione ed è stato adattato allo sviluppo del software, inizialmente dai team di manutenzione. Sia Scrum che Kanban mirano a gestire il flusso di unità di lavoro attraverso il team che sta facendo quel lavoro, a misurare la rapidità dei flussi di lavoro in modo che le stime possano essere rese sempre più accurate e rendere i colli di bottiglia altamente visibili in modo che possano essere affrontati.

Poiché nessuno dei due è specifico per lo sviluppo del software, i team che utilizzano Scrum e Kanban aggiungono pratiche di sviluppo del software al processo per aiutarle in modo incrementale e iterativamente a rilasciare e migliorare il software. La maggior parte dei team, che lavorino all'interno di un processo Scrum o Kanban, adottano le pratiche tecniche di XP e le pratiche riflessive di Crystal.

XP è fondamentalmente Scrum applicato a un singolo team oltre a linee guida su ciò che rende il codice "alta qualità" e su come i programmatori possono conseguirlo. Crystal Clear si applica anche ai piccoli team co-localizzati, ma è più flessibile sulle pratiche di programmazione anche se raccomanda anche le pratiche XP (il libro che descrive il processo è eccellente e ricco di preziosi consigli, qualunque sia il processo che si decide di adottare). I team Scrum di solito adottano le pratiche riflessive di Crystal: regolari retrospettive "heart-beat" e retrospettive più ampie dopo ogni importante pietra miliare. Kanban richiede continue riflessioni e miglioramenti, ma alcuni team usano anche retrospettive.

Se si desidera iniziare ad applicare un processo incrementale/iterativo in un piccolo team di programmazione, quindi penso che XP sia un buon processo per iniziare perché imposta la barra piuttosto in alto per capacità tecniche ed è molto ben documentato. Il modo in cui il flusso continuo e il Kanban si applicano meglio a diverse aree del settore dello sviluppo del software sono ancora oggetto di discussione sulla mailing list di kanban-dev e altrove.

Consiglierei anche di eseguire retrospettive regolari per migliorare il processo e adattarlo alla situazione specifica.

Answer 2

La parte più importante è quella di avere un meccanismo di riflessione/retrospettiva che faciliti il ​​miglioramento continuo. Inizia con un modello di processo ed evolvilo nel tempo per le tue esigenze di. Smetti di fare cose che non vale la pena fare. Continuate a fare cose che portano in alto valore. Prova nuove cose che ritieni possano essere preziose o affrontare problemi specifici.

Answer 3

Qual è la domanda? E 'questa la metodologia più adatta?

Answer 4

Non si ottiene molto beneficio da tutto il sovraccarico che un sistema formattato imporrà con quella dimensione della squadra. Prova invece a a good management technique per assicurarti che tutti si stiano ascoltando a vicenda e che i blocchi vengano rimossi.

Answer 5

Penso che lo Scrum funzioni per team di piccole o medie dimensioni. Rispetto ad XP lascia alcuni dettagli, quindi puoi prendere in prestito da XP o fare qualcosa che abbia un senso. Qualunque sia la metodologia scelta, devi considerare il ruolo dei polli (clienti/manager/stakeholder/esperti di dominio). A volte devi giocare i ruoli da solo, ma molte metodologie agili funzionano perché c'è un'auto di pace esterna con una conoscenza di base del dominio.

Altri aspetti chiave sono il livello di comunicazione tra il team e una qualche forma di meccanismo di garanzia della qualità. È difficile programmare la coppia se non si è nello stesso edificio. Scrum cerca di ottenere una funzionalità da accettare entro un ciclo di sprint e XP tenta di integrare la funzionalità nel corso della giornata utilizzando test unitari, revisione del codice e integrazione continua.

*) Sprint può variare da 15-30 giorni.

Answer 6

Ho lavorato con un team di quel tipo e ancora più grande in due team che condividevano alcune librerie comuni. Scrum ha funzionato bene per noi. Ora lavoro con una squadra con 6 membri e usiamo XP e penso che funzioni pure. La prima squadra ha sviluppato un prodotto e le influenze da "lo spazio esterno" non erano così grandi. Quindi le iterazioni più lunghe funzionavano bene. No sviluppiamo un progetto cliente e quindi cicli di rilascio più brevi sono migliori per noi.

Ma SCRUM e XP sono più di questo. Ora usiamo TDD e Pair Programming (entrambi provenienti dal mondo XP). Abbiamo anche incontri giornalieri stand up che sono più simili SCRUM. Quindi abbiamo adottato XP e SCRUM per lavorare per il nostro progetto e la nostra situazione.

Vorrei iniziare con cicli brevi (1 settimana) e recensioni di questo ciclo. Ci vorrà del tempo per adottare una nuova metodologia nel tuo team, ma se i membri sono disposti a imparare e cambiare funzionerà.