Quale processo di sviluppo incoraggia le versioni frequenti (rolling code a un sito attivo), nonché l'individualità dello sviluppatore

1

Qualche rapido background: non abbiamo PM o dirigenti che respirano a pieni polmoni sullo stato delle funzioni, ecc., perché quasi sempre anticipiamo il tempo e abbiamo instaurato un alto livello di fiducia con loro. In altre parole, abbiamo una grande quantità di flessibilità per quanto riguarda il processo. Facciamo molto bene con il nostro attuale processo, ma riteniamo che ci possano essere dei miglioramenti.

Abbiamo un piccolo team (3 sviluppatori, 1 tester) e tutti i membri del team sono di livello senior e possono offrire grandi funzionalità e in genere lo fanno su base individuale. A volte due persone lavorano sulla stessa storia / attività, ma dato che conosciamo tutti molto bene il codice (i), in genere gestiamo le cose da soli e ci consultiamo / collaboriamo quando necessario.

Ci rivolgiamo a un sito attivo e abbiamo la possibilità di eseguire il rollover su base giornaliera, cosa che solitamente avviene nel nostro team. In media, direi che un singolo sviluppatore esegue il proprio codice 3 volte a settimana.

Abbiamo fatto scrum con sprint di 2 settimane, ma dalla mia esperienza la scrum è stata più vantaggiosa quando avevamo bisogno che la maggior parte della squadra lavorasse sulle stesse funzionalità contemporaneamente (roba di tipo sciame), e quando bisognava comunicare a squadre esterne. Al momento non abbiamo nessuno di questi requisiti, quindi stiamo rivalutando il nostro processo.

Ciò a cui sembra che ci stiamo avvicinando è un modello in cui ogni membro del team esiste nel proprio sprint (con i compagni di squadra facoltativi meno comuni), che dura da 1 a 3 giorni. Non abbiamo il requisito che tutti gli sprint debbano finire negli stessi giorni, ecc., Quindi in teoria potremmo eliminarlo. La mia domanda è: c'è qualcosa di meglio della mischia che modella questo tipo di processo di sviluppo?

Oh, mi sono quasi dimenticato. Ci stiamo allontanando da TFS per usare Git, e mentre ho esperienza con Git, la maggior parte dei membri del team no. Dal momento che si tratta di un cambio di paradigma per alcuni membri del team, mi chiedo se possiamo usare il cambiamento a nostro vantaggio in qualche modo in termini di processo. Pensieri?

    
posta Dustin Kendall 04.02.2014 - 00:15
fonte

1 risposta

2

Se fai un passo indietro e guarda perché i processi di sviluppo "formali" come Waterfall, Extreme, Scrum si sono evoluti, è perché molte case di sviluppo hanno difficoltà a sviluppare prodotti software (al contrario dei "programmi software") che hanno incontrato il business e requisiti dei clienti. Ogni processo pubblicato è un tentativo di fornire un quadro per aiutare a raggiungere questi obiettivi. Alcune strutture (ad esempio Rational RUP) sono grandi e prescrittive, altre (ad esempio agili) un peso leggero e forniscono linee guida.

Quello che hai evoluto potrebbe non essere Scrum, ma è una forma un Agile. Non ha bisogno di un nome per funzionare. Sembra funzionare per te e non sembra essere rotto, non cambiare quello che stai facendo perché qualcuno dice che hanno un modo diverso.

Quello che ti suggerisco di fare è esaminare il tuo processo e assicurarti che sia più che fortunato che lo stia facendo funzionare. Documenta come lavori ora in modo che sia ripetibile - pretendi che il team di anotehr voglia adottare ciò che stai facendo e scriverlo.

Cerca i punti deboli - Ad esempio, una squadra di 3 persone potrebbe diventare una squadra di due durante la notte e, fattibile, una squadra di uno. Il processo è robusto contro questo tipo di cambiamento, puoi portare un nuovo membro nel team con un piccolo cambiamento di processo? Scala - puoi raddoppiare le dimensioni della squadra e ottenere comunque gli stessi risultati? In caso contrario, chiedi è necessario e documenta la decisione.

    
risposta data 04.02.2014 - 22:18
fonte

Leggi altre domande sui tag