Lavoro collaborativo (piccola squadra) - Migliori pratiche [chiuso]

Per una piccola squadra probabilmente non hai bisogno di concentrarti troppo sul tipo di processo rigido che i team più grandi attraversano, tuttavia qui ci sono alcuni frutti bassi che possono davvero aiutare.

Stand-up quotidiano

Un semplice stand-up all'inizio di ogni giornata, in cui tutti spiegano brevemente cosa hanno fatto ieri, cosa faranno oggi e solleva tutto ciò che impedisce loro di fare progressi.

Standard di codifica

La maggior parte delle lingue ha uno standard o alcuni standard disponibili. La cosa importante non è quella che scegli ma che ne scegli una. Poi tutti ci tengono d'occhio, nessuna eccezione.

documento

Prima di iniziare su un progetto di tipo "costruisci il motore di ricerca per questo prodotto", devi mettere insieme una specifica funzionale per quel motore di ricerca. Questo descriverà in termini chiari il modo in cui il sistema funzionerà senza entrare troppo nei dettagli di implementazione. Il documento deve essere completato e il team deve averlo esaminato prima che inizi la codifica. Probabilmente sarebbe sufficiente una supervisione architetturale assumendo che tutti i membri del team abbiano un livello ragionevole come sviluppatore. Queste specifiche possono anche essere utilizzate come base per la futura documentazione da trasmettere agli utenti o come materiale di riferimento per la rivisitazione di lavori precedenti.

Revisione codice

Il codice di nessuno viene unito al ramo principale per qualsiasi progetto fino a quando non viene esaminato da almeno un altro membro del team. Il codice che non soddisfa lo standard di codifica non entra, il codice che non è documentato non entra. Questo in seguito farà risparmiare un sacco di problemi e, combinato con gli standard di codifica sopra, dovresti finire con molto più leggibile codice.

Potresti anche prenderlo a turno per scegliere esempi di codice di volta in volta da condividere su CodeReview.se - che darebbe tutti nel team hanno la possibilità di imparare dalla più ampia esperienza di altri sviluppatori e aiutano a incoraggiare una buona codifica da parte di tutti.

Test

Nessuno esegue test funzionali sulle proprie caratteristiche. Devi chiedere a qualcun altro di testare per te.

Inoltre, nessun codice è completo fino a quando non ha i test unitari e quei test unitari passano. I test unitari fanno parte del processo di compilazione e se falliscono, la compilazione fallisce.

Unisci in anticipo, unisci spesso

Se esegui fusioni settimanali e collisioni tra sviluppatori, potresti dover controllare la tua strategia di ramificazione: se qualcosa ha un effetto a catena per altri sviluppatori, allora deve essere unito il più presto possibile in modo che tutti possano usare la nuova versione. Questa è una questione di prioritizzazione e renderà la vita di tutti più facile.

Uno dei maggiori vantaggi di una piccola squadra è che sei una piccola squadra. Tutti possono facilmente dire a tutti gli altri cosa stanno facendo e chiedere consiglio a tutti. Molti dei suggerimenti che sto facendo qui sono davvero solo dei modi per facilitare la comunicazione e questo dovrebbe essere molto più semplice in una piccola squadra che in una grande.

Sono completamente d'accordo con l'altra risposta sull'importanza delle revisioni del codice e delle situazioni quotidiane.

Ruolo architetto

Questo è difficile. Immagino dipenda dall'esperienza degli sviluppatori del tuo team. In una squadra della tua taglia più esperto lo sviluppatore meno hai bisogno di un architetto. Vorrei suggerire più programmazione e mentoring di coppie di sviluppatori meno esperti prima di aggiungere un architetto.

Analista aziendale

Se vuoi aggiungere una persona al team, ti consiglio vivamente di aggiungere un esperto analista aziendale in grado di scrivere molto bene i requisiti / le storie di stile agili. Ho scoperto che a lungo termine avere qualcuno in grado di definire correttamente le esigenze aziendali e scrivere requisiti / storie che possono essere facilmente testati può essere più prezioso per il prodotto finale.

Standard di codifica

Utilizzare uno strumento che ti avverta quando non stai seguendo gli standard accettati è un buon punto di partenza. Tutti devono usare il formato accettato.

Revisione periodica del codice pranzi

Una squadra in cui mi trovavo era in una situazione simile. Abbiamo istituito pranzi settimanali in cui ognuno ha portato il proprio pranzo e si è incontrato in una sala conferenze e una persona del team ha presentato un pezzo di codice o funzionalità che desiderava discutere. Avrebbero fatto una rapida presentazione del codice e quindi ne parleremmo con diversi aspetti.

Passaggi per bambini

Vai piano con qualsiasi modifica che apporti. Fare tutto in una volta solo sconvolgerà l'equilibrio che la tua squadra ha già. Crea un piano a lungo termine per dove vuoi portare la squadra e condividerla con loro. Scegli un passo alla volta e concentrati su di esso fino a quando il team non ha accettato e integrato nel proprio flusso di lavoro. Quindi passare a quello successivo.

Non calpestare

Se non sei il manager del team, siediti con lui / lei e presenti i tuoi obiettivi per il team e suggerisci come le cose potrebbero essere cambiate. Se sei il manager, assicurati di rispettare la posizione di ogni membro del team. Eventuali modifiche apportate sconvolgeranno il saldo già esistente e non vorrai che le persone se ne vadano perché qualcuno è stato escluso dal processo quando avrebbe dovuto essere effettivamente incluso.