Lavoro in una squadra in cui ogni membro sta lavorando a una storia utente. Come possiamo evitare di creare funzionalità duplicate o in conflitto?
Ad esempio, se la mia storia utente richiede la creazione della classe A e il mio membro del team ha bisogno della stessa funzionalità e crea una classe simile (magari con un nome leggermente diverso), come dovremmo pianificare il nostro lavoro in modo che entrambi ci muoviamo senza problemi ?
Comunicazioni.
Gran parte del lavoro di squadra agile è sapere su cosa sta lavorando la tua squadra. Hai pianificato riunioni e dovresti avere discussioni sul design prima di partire e programmare da solo.
Nei nostri team sappiamo sempre su cosa stanno lavorando gli altri sviluppatori e non appena viene fuori il pensiero che esiste un potenziale per il riutilizzo o il superamento dei limiti, ci si alza e si avvicina alla scrivania dell'altra persona (o se è remoto, scegli telefono).
UPDATE (risposta al commento) :
All'inizio di ogni sprint, il team decide quali storie devono essere consegnate e quali attività devono essere completate. Abbiamo un modello standard (un po 'come una lista di controllo per assicurarci che nulla sia dimenticato) e una delle cose, è il compito di progettazione.
Quasi tutte le storie hanno un compito di progettazione, ma generalmente sono 10 minuti a 1 ora di discussione tra i membri del team per discutere dell'approccio generale di completamento del lavoro da svolgere. Questo non serve solo come testa a testa per le altre persone, ma è anche utile perché a volte altre persone offriranno una soluzione diversa che è migliore di ciò che stavi considerando di fare. Nella pianificazione della riunione, decidiamo quali sviluppatori dovrebbero partecipare alla discussione sulla base di a) complessità eb) la familiarità di altre persone del codice esistente che è coinvolto.
Se due persone sanno che lavoreranno in un'area simile, molto probabilmente parteciperanno alla stessa discussione. I nostri team agili hanno anche un vantaggio tecnico, che tipicamente partecipa a una parte più ampia delle revisioni di design / codice e una delle responsabilità di quella persona è quella di diffondere la conoscenza attraverso la squadra, ma ho la sensazione che questa sia una posizione temporanea che otterremo liberarsi (o ridimensionarlo) una volta che gli altri membri del gruppo acquisiscono familiarità con il prodotto (attualmente molti nuovi membri).
Inoltre, durante le alzate quotidiane, generalmente parliamo di ciò su cui abbiamo lavorato e di quello che è avanti e se menziono ho iniziato a scrivere una classe di utilità per aiutare con la funzione X, e quella classe è utile per un altro sviluppatore, quindi altri sviluppatori mi parlerebbero dopo l'incontro e discuteremo su come assicurarci che non stiamo ripetendo il lavoro e che la classe è abbastanza generica per soddisfare le esigenze di tutti.
Infine, tutto il codice scritto viene revisionato dal codice e ruotiamo attraverso chi esamina cosa, quindi in generale il team ha una buona familiarità con l'intera base di codice. Anche se passano due classi duplicate (e non riesco a pensare che ciò avvenga effettivamente), il 95% delle probabilità potrebbe essere sollevato in una revisione del codice e le due classi verrebbero unite in quel punto.