Qual è il modo migliore per dividere il lavoro tra gli sviluppatori

Il mio team e io stiamo ricostruendo un sito che abbiamo sviluppato circa dieci anni fa e vogliamo farlo in Agile.

Quindi, dopo aver trascorso molto tempo a leggere (probabilmente non abbastanza), ho problemi con la domanda su come dividere il lavoro tra sviluppatori.

Sarò più specifico e dirò che il sito è diviso in moduli separati che non hanno molta integrazione tra loro.

Qual è il modo migliore / più accettato per dividere il lavoro tra gli sviluppatori?

• Dare ad ogni persona un modulo diverso su cui lavorare.
• Assegna tutti gli sviluppatori allo stesso modulo e dividi il lavoro per diverse parti del modulo (UnitTesting, DAL e Mapping, Logics, UI)
• Assegna tutti gli sviluppatori allo stesso modulo e dividi il lavoro con logiche diverse (ad esempio ogni sviluppatore è responsabile di una logica specifica (probabilmente un metodo nel BL) e It's UnitTesting, DAL e Mapping e UI ...

O forse qualcosa di completamente diverso?

Il mio team ha cercato di diventare "agile" per poche versioni ora, ma far parte di una grande società non ha esattamente reso facile. Non pretendo di avere la risposta, ma posso condividere alcune delle mie osservazioni.

• Dividere gli sviluppatori per modulo:

  • Devi stare attento perché se le persone lavorano troppo da sole, la tua squadra non beneficia della condivisione incrociata di abilità e conoscenze
  • Pianificare riunioni e stand up giornalieri può diventare incredibilmente noioso per tutti se le persone si concentrano troppo sui propri moduli e non vedono un quadro più ampio. Una volta che le persone si annoiano, iniziano a fare il check-out e perdi gran parte del vantaggio che l'agile porta sul tavolo
  • Potresti finire con alcuni componenti scritti davvero bene, e altri componenti, beh ... non così tanto. Se le persone lavorano in isolamento, i tuoi ragazzi più anziani non saranno in grado di addestrare quelli più giovani.

• Tutti lavorano sullo stesso modulo contemporaneamente

  • Lo abbiamo provato per una versione, quando il management ha deciso che imporranno agili su tutto il team e sarà completamente a modo loro. Come un disastro ferroviario assoluto. Avevamo un team di 9 sviluppatori che consegnava in un anno ciò che in genere sarebbe stato fatto da 1 sviluppatore. (Potrei esagerare qui, ma non di molto).
  • Nessuno pensava che ci fosse spazio per respirare. Quelli a cui non importava del software, si sentivano come a casa perché facevano parte di un pacchetto più grande, si diluivano nel gruppo. Quelli di noi che avevano la passione per il software, si sentivano assolutamente soffocati poiché non c'era libertà di muoversi o andare oltre i limiti su cui 9 persone hanno concordato.
  • Tutti gli incontri sono andati per sempre al punto in cui volevo spararmi. Troppe persone con un'opinione nella stessa stanza sono costrette a lavorare sulla stessa strana DLL. L'orrore.
• Nell'ultima versione, abbiamo deciso di provare qualcosa di diverso
  • Innanzitutto, suddividere il gruppo di sviluppo in team più piccoli di 3-4 sviluppatori. Ogni squadra ha lavorato in relativo isolamento l'una dall'altra, ma all'interno della squadra le persone hanno lavorato in modo molto più coeso
  • Con questo approccio, gli stand up sono veloci e le riunioni di pianificazione richiedono 1-2 ore rispetto alle solide 4 ore.
  • Tutti si sentono coinvolti perché ogni squadra discute solo di ciò che gli sviluppatori di quella squadra si preoccupano.
  • Il responsabile tecnico di ciascun team parla periodicamente con altri leader tecnologici per assicurarsi che il progetto complessivo sia sulla buona strada.
  • Invece di rendere le persone "proprietarie" di un modulo specifico, abbiamo assegnato aree di competenza alle persone, quindi quando abbiamo iniziato il progetto sembrava che le persone avessero il proprio modulo, ma dopo diversi mesi, gli sviluppatori avrebbero iniziato a guardare il codice di ogni altro come le aree hanno iniziato a sovrapporsi.
  • Le revisioni del codice sono essenziali. Questa è stata la seconda versione in cui avevamo una rigida politica di revisione del codice e tutti i membri del team li adorano. Esperto di un'area specifica è sempre in una revisione del codice quando qualcun altro modifica quel codice.
  • Con le revisioni del codice abbiamo un sacco di condivisione delle conoscenze e puoi vedere il miglioramento complessivo della qualità del codice dei nostri team. Anche perché il codice viene rivisto così spesso, quando le persone entrano nell'area di competenza di qualcun altro, è probabile che abbiano già visto il codice almeno alcune volte.
  • La maggior parte di ogni team viene coinvolta nelle riunioni di revisione del progetto, quindi anche se non hanno mai visto il codice, tutti hanno familiarità con il flusso generale di tutti i moduli di cui il loro team è responsabile.
  • Lo abbiamo fatto per circa 10 mesi ed è come se avessimo iniziato con un approccio al modulo isolato e ci fossimo trasformati in tutti i lavori su tutto. Ma allo stesso tempo, nessuno si sente come se fossero angusti o limitati. E per assicurarci che i ragazzi abbiano ancora il senso di una certa autorità, li abbiamo lasciati come esperti di area, anche se ora è principalmente una formalità.

Abbiamo fatto l'ultima cosa, e sebbene ci sia un sacco di spazio per miglioramenti, nel complesso tutto il nostro team è stato molto felice e questo dice molto, quando facciamo parte di una gigantesca società.

Una cosa importante che ci siamo sbagliati le prime 3 volte in cui "siamo diventati agili", è ciascuna di quelle volte in cui alle persone veniva detto come lavorare e dovevano dire su cosa lavorare. Questo è il modo numero uno per far perdere completamente l'interesse al progetto per il tuo team e quindi sei davvero nei guai.

Invece, prova il contrario. Dì al team che possono fare quello che vogliono e come manager / leader (se lo sei, se non fai ripetere al tuo manager queste parole), il tuo compito è assicurarti che siano il più produttivi e felici possibile. Il processo non è una cosa negativa, ma il processo dovrebbe essere lì per aiutare il tuo team quando si rende conto di averne bisogno, non viceversa.

Se alcuni membri del tuo team preferiscono lavorare in isolamento, lasciali (fino a un certo punto). Se preferiscono lavorare in coppia, lascia che facciano così. Assicurati che il tuo personale scelga il proprio lavoro il più possibile.

Infine, e questo è molto importante ed è sempre trascurato. NON AVRAI QUESTO DIRITTO (a meno che tu non sia un superuomo, o almeno un batman). Avere riunioni periodiche retrospettive è estremamente importante. Quando abbiamo lanciato le retrospettive, sono state completate dal libro e sembrava che ci fosse un altro processo da affrontare. Non è per questo che retrospettiva. È per ascoltare la tua squadra, identificare le aree che causano più dolore e risolverle in modo che tutti possano andare avanti con il proprio lavoro. Apparentemente gli ingegneri del software in generale, come la fornitura di prodotti e funzionalità e la più importante riunione di retrospettiva sui messaggi che devono comunicare, è che è solo a loro vantaggio. Vuoi identificare e affrontare gli ostacoli, a partire da quelli più grandi (o quelli più semplici, lì '

Incontra il team, mostra loro l'elenco delle cose da fare e chiedi a chi vuole fare cosa.

Non pensare nei moduli. Pensa agli elementi di funzionalità. Descrivi questi elementi di funzionalità in base alle storie degli utenti (o in altro modo) e non dimenticare di descrivere i criteri di accettazione (probabilmente definiti dalla tua attuale applicazione e dai cambiamenti che l'azienda si aspetta). Metti i tuoi elementi funzionali in arretrato. Quindi lascia che le aziende diano la priorità a quale funzionalità deve essere fornita per prima (lavorerai in modo incrementale e iterativo e la priorità ti dirà cosa deve essere implementato per primo).

Una volta che hai questo almeno per parte della tua applicazione originale, sei pronto per lo sviluppo. Ciò che accade dopo dipende dalla metodologia agile selezionata. La parte importante è che ogni funzionalità può di solito essere suddivisa in più attività e i membri del team selezioneranno le attività che vogliono fare - che si chiama auto-organizzazione. Quando inizi con l'agile, l'auto-organizzazione potrebbe aver bisogno di un aiuto in cui qualcuno si assicurerà che i compiti impopolari e popolari siano equamente condivisi dal team. Una volta che il team sarà più maturo, gli sviluppatori non esiteranno a esprimere il proprio disaccordo con l'attuale auto-organizzazione e questo verrà gestito automaticamente all'interno del team.

Pensare nei moduli dall'inizio non deve essere un buon modo. Stai riscrivendo l'applicazione per qualche motivo e forse l'attuale architettura dell'applicazione basata su una separazione dei moduli errata è una delle ragioni nascoste dietro problemi visibili. Inoltre puoi scoprire che alcune funzionalità dei moduli esistenti verranno completamente ridefinite e spostate altrove.

Anche se sono d'accordo con la risposta di David, ho pensato che potesse trarre profitto da alcuni elaborati:

• Agile significa che non prendi queste decisioni e non le spingi nella squadra. Non esiste un project manager / leader del genere. Solo la squadra.
• Quelli che sanno meglio, come dividere il lavoro sono i membri del team stessi.
• Discuti il ​​tuo backlog e scopri cosa vuoi realizzare nella prossima iterazione / sprint.
• Usa la pianificazione del poker o metodi simili per avere un'idea di quanto lavoro dividerai comunque, e solo allora inizia a dividere i pacchetti di lavoro reali insieme .

Fondamentalmente, la linea di fondo è: nessuno qui su SE può rispondere a questa domanda per te, né ha molto senso, perché è molto meglio se trovi una risposta come una squadra.

L'approccio più semplice è spesso il migliore.

Eviterei di dividere le attività in gruppi come testing / log / UI / etc a meno che non sia possibile definire alcune ragioni molto valide e chiare per farlo. Il mio ragionamento è che quando permetti ai programmatori di lavorare al di fuori delle loro solite aree di competenza, può mantenere le cose più interessanti e stimolanti per loro e permettere loro di svilupparsi e crescere nel loro campo. Se ritieni che i vincoli temporali richiedano di dividere il lavoro in base alle competenze, assicurati almeno che ogni sviluppatore sia ancora tenuto a fare i propri test unitari e usa la revisione del codice e i test di accettazione per raccogliere i problemi. Scrivere i tuoi test è molto agile e aspettare che i tester diventino disponibili può essere molto dispendioso.

Di fronte a questo stesso tipo di dilemma, ho adottato il seguente approccio:

• Scopo del progetto. Concediti un'idea di cosa ti stai cacciando e sviluppa un elenco di funzionalità suddividendo il progetto in una serie di attività.

• Dai la priorità alle funzionalità. Decidi quali funzionalità devono essere completate in anticipo e quali forniranno un valore immediato ai tuoi clienti. Non preoccuparti se i tuoi sviluppatori finiscono per lavorare sugli stessi moduli, ma assicurati di avere un buon processo e strumenti per gestire le fusioni di codice.

• Coinvolgi il tuo team e chiedi ai tuoi sviluppatori di aiutarti a scomporre le funzionalità in un elenco di attività più facilmente gestibili. Rivedere come gruppo e regolare le attività in base alle esigenze in modo che possano essere stimate più facilmente.

• Chiedi a ogni sviluppatore di scegliere un'attività da implementare - o un gruppo di attività a seconda di come verranno eseguite le iterazioni - dalla cima della coda di priorità su cui lo sviluppatore vorrebbe lavorare.

• Chiedi a ciascuno sviluppatore di lavorare su una sola cosa fino a quando non viene completato prima di passare alla selezione dell'elemento successivo dalla cima della coda di priorità. Potresti essere tentato di far cambiare attività occasionalmente alle tue persone, tuttavia ciò comporterebbe uno spreco in termini di tempo dello sviluppatore. Se ti trovi con i colli di bottiglia delle dipendenze, dovrai adeguare le priorità delle attività e ridurre al minimo gli sprechi.

• Non aver paura di avere sviluppatori in esecuzione con iterazioni sovrapposte e gestisci le tue versioni di conseguenza. Ciò consentirà di ridurre al minimo il tempo perso tra le versioni in attesa del completamento delle attività.

In definitiva, essere Agili significa trovare una soluzione che funzioni bene per il tuo team, la tua azienda e i tuoi clienti. Sta a te ottimizzare il tuo processo trovando l'equilibrio delle pratiche che funzionerà meglio per te. Il modo in cui dividere i compiti sarà una parte molto importante di un processo molto più ampio, ma dovrebbe essere tenuto il più semplice possibile per incoraggiare la partecipazione volontaria ed evitare problemi di processo difficili da risolvere che si svilupperanno in seguito.

Nessuna discussione organizzativa del team di sviluppatori sarebbe completa senza menzionare il team chirurgico del Dr. Fred Brooks .

La formula di base è: una squadra chirurgica per unità di lavoro

Definizione di un team chirurgico

Il concetto del team chirurgico si basa su due idee fondamentali:

1. Meno sviluppatori sono migliori per unità di lavoro perché il cross-talk uccide la produttività.
2. Gli sviluppatori ad alto rendimento superano gli sviluppatori a basso rendimento (e secondo Brooks, non esiste uno sviluppatore di medio livello), quindi è meglio dare loro il lavoro più importante da fare e limitare le loro distrazioni.

Un team chirurgico è composto da 3-10 sviluppatori:

1. Un capo programmatore. Uno sviluppatore ad alto rendimento, che svolge la maggior parte della programmazione effettiva.
2. Un copilota. Un altro sviluppatore ad alto rendimento, che fa un po 'di programmazione, ma anche alcune attività amministrative, come partecipare a riunioni e raccogliere requisiti.
3. 1 - 8 assistenti. Brooks li descrive come sviluppatori responsabili di cose come documentazione, pulizia del codice, ricerca, strumenti / algoritmi di scrittura, test, ecc. Negli anni '60 Brooks ha proposto esattamente 8 ruoli, ma con strumenti moderni potresti aver bisogno di un minimo di 1 o 2, e dovrebbe probabilmente essere assegnato in base alle esigenze del progetto.

Definire un'unità di lavoro

Quindi ora che possiamo mettere insieme una squadra, cosa le assegniamo?

• Se il progetto è molto piccolo , questo è facile. Assegni una squadra chirurgica all'intero progetto.
• In caso contrario, allora si avrà bisogno di iniziare con una persona o un gruppo che si occupa di tutto il progetto di architettura . Sarà loro compito modulare il software in modo appropriato in modo che il lavoro possa essere suddiviso tra sotto-team aggiuntivi. Il team di achitecture può anche svolgere altri lavori, in modo da non diffondere sviluppatori troppo sottili.

Dovresti vedere emergere tre modelli di base accettabili:

1. Esattamente 1 sotto-squadra per ogni livello (UI, DAL, ecc.)
2. Esattamente 1 sotto-squadra per ciascun modulo (Home Page, Sito di supporto, Negozio)
3. Un mix dei due (un team di framework di basso livello e un team focalizzato sull'interfaccia utente per ciascun modulo)

A seconda del numero di sviluppatori e moduli (e tempistiche) generalmente spingo i miei sviluppatori a scegliere un modulo interessante (per loro) e un modulo stimolante (preferibilmente qualcosa che non hanno fatto) e poi il resto che divido per livello di abilità e vincoli di tempo. Trovo che questo dia ai miei sviluppatori qualcosa su cui vogliono lavorare e qualcosa che li spinga.

Ovviamente questo non funziona sempre ...

Ecco cosa farei:

Se tutti i moduli sono piccoli, puoi dare a ciascuno un modulo su cui lavorare. Altrimenti, fai come segue:

1. Definire le dimensioni, la complessità e le competenze di ciascun modulo necessarie per farlo.
2. Definire le abilità di ciascun membro del team.
3. Definisci quali persone lavorano bene insieme e quali non lavorano bene con gli altri.
4. Assegna moduli di grandi dimensioni a team di persone che lavorano bene insieme in base ai requisiti delle competenze del modulo e alle capacità del team.
5. Assegna i moduli rimanenti a persone che non possono lavorare bene con altre persone in base ai requisiti delle competenze del modulo e alle capacità del team.

Quanto sopra non funzionerà se le persone a cui non piace lavorare con gli altri sono le più competenti e questo è un caso comune, quindi fai un'eccezione a 4 e 5 di conseguenza