Qual è il ruolo dello sviluppatore principale in una squadra agile?

Niente nelle modifiche agili su come dovrebbe funzionare lo sviluppatore principale. Dovrebbero coinvolgere il resto del team con le decisioni relative all'architettura del sistema e la direzione tecnica, indipendentemente dal modello di sviluppo che viene seguito.

Prendere decisioni per editto è un modo terribile per qualsiasi team di sviluppo. Agile fa in modo che il buy-in del resto del team faccia un processo più esplicito e lo sviluppatore principale avrebbe dovuto farlo comunque.

Solo perché non esiste un ruolo di lead developer in una metodologia di mischia non significa che i programmatori più esperti non siano i più rispettati. Agile non sta lasciando che tutti si scatenino da soli e poi provando a metterli insieme, c'è ancora una visione e una direzione unificate che devono essere impostate.

In una squadra agile ognuno dovrebbe mettere da parte il proprio ego.

Se un membro di un team agile ha più esperienza rispetto agli altri, ciò che probabilmente accadrà è che il membro esperto sarà coinvolto nella maggior parte delle recensioni del codice e le persone rimandano spesso all'esperienza di quella persona quando prendono decisioni di squadra.

Quindi, uno sviluppatore "principale" continuerà a "guidare", ma come una conseguenza naturale della sua esperienza e non come una funzione obbligatoria del loro titolo.

Questo è in un mondo ideale dove le persone possono mettere da parte il loro ego. Buona fortuna!

Oltre alla risposta di Ryathal :

Parli di design emergente e di direzione del team come se uscissero dal team in perfetto unisono e armonia. Gruppi di persone, gruppi di programmatori hanno in particolare conflitto . Come il team guida, il tuo lavoro in una squadra agile è più un arbitro o un catalizzatore che in una cascata. Quando la squadra ha dei conflitti su quale design usare, per esempio, ti assicurerai che le persone abbiano la stessa opinione e si limitino a discutere sui meriti. E finisci per essere l'arbitro con la soluzione proposta alla squadra quando il percorso non è chiaro.

Questa è una delle responsabilità più importanti del ruolo guida, ma sono necessarie molte altre cose per far entrare un gruppo di persone in una squadra. È comunque necessario impostare un esempio per quanto riguarda la buona codifica, e spesso applicarlo (direttamente o creando una cultura per farlo). Devi facilitare la comunicazione tra tutti i membri del tuo team, perché una volta al giorno non lo taglierà.

L'altra cosa importante che hai trascurato sono le riunioni. Non è pratico portare l'intero team in ogni riunione in cui il team deve interagire con uomini d'affari, altri team tecnici, ecc. Come guida la squadra, sei il rappresentante della squadra. Vai alle riunioni in modo che possano rimanere alla scrivania e fare le cose. Sei il punto di contatto in modo che non vengano interrotti da chi si ferma direttamente. E tu lavori per prendere informazioni dal mondo esterno (su quali altri team stanno lavorando, su quali squadre agili assomiglia al prossimo sprint, qual è lo stato di quel req aperto, ecc.), Fallo bollire per loro e comunicalo.

In breve, sei il lubrificante per assicurarti che possano funzionare senza intoppi.

La tua descrizione non agile non invalida la tua descrizione agile.

An agile team will rely on emergent design, rather than up front.

Nulla sulla tua definizione di lead developer dice che il design deve essere affrontato in anticipo. Potrebbe impostare la direzione, e potrebbe ancora disegnare un progetto iniziale. Quel design è sicuramente emergente.

An agile team designs together, rather than design being dictated by one person

Nulla sulla tua definizione di uno sviluppatore principale dice che detta design. Anche se potrebbe avere l'ultima parola, solo una guida inadeguata ignorerebbe del tutto i pensieri dei suoi compagni di squadra di maggioranza. D'altro canto, solo una squadra povera ignorerebbe completamente i pensieri dello sviluppatore principale.

An agile team decides on their own technical direction, which is best to deliver a project

Anche in questo caso, ciò non significa che il lead non inizialmente in questa direzione. Il protagonista fa parte di questa squadra agile. Anche in un ambiente non agile, solo uno scarso vantaggio continuerebbe a marciare verso una squadra in tale direzione quando è diventato inconsapevolmente non fattibile, o quando sono state presentate nuove informazioni per invalidare questa direzione.

La domanda pone alcune altre domande. Cosa pensi ti qualifichi a dire a un team di altri ingegneri del software cosa fare? È la tua esperienza? È il piccolo titolo divertente che ti ha consegnato il tuo capo? È il tuo ego? La tua permanenza in azienda? È il tuo "brio?" Il tuo stile?" Le tue "capacità di leadership?"

Le squadre agili non distribuiscono distintivi o cappelli l'uno contro l'altro che dicono "Congratulazioni, sei il nostro super genio - sei l'unico a cui è permesso fare il lavoro del doppio genio super segreto". Piuttosto, l'obiettivo è IL LAVORO A MANO. Se sei davvero più esperto, allora quell'esperienza dovrebbe MOSTRARE in quanto i tuoi progetti spingono il lavoro verso il completamento. I tuoi compiti (schede) scelti da te dovrebbero riflettere le aree in cui sei più esperto. D'altra parte, se un bambino appena uscito dal college ha un'idea migliore, e si adatta al contesto meglio di qualcosa che un veterano di 40 anni arriva con, perché mai andremmo con il design più povero? I nostri luoghi di lavoro non sono uffici di terapia: sono i luoghi in cui veniamo a costruire grandi cose.

Questo fa sorgere un'altra domanda: chi decide cosa significa "meglio"? La risposta: il team di stakeholder. Ciò significa che gli sviluppatori, i requisiti, i collaudatori, gli uomini d'affari, ecc., Sono i costruttori e gli utenti della cosa in questione. Se hai una grande idea, è meglio essere in grado di dimostrare perché è meglio. Se non puoi farlo, non c'è motivo per il team di credere che la tua idea sia migliore. Agile incoraggia la meritocrazia.

Quindi, cosa succede al "team di sviluppo leader?" in agile? Niente - è meglio che mantengano quel nome - meglio REALMENTE essere in grado di produrre software migliore rispetto alle altre persone del team. Altrimenti, non c'è motivo di chiamarli "protagonisti" - è solo un piccolo distintivo o un cappello buffo, ed è privo di significato. Molte persone trovano questo minaccioso. Si sentono come se stessero "lavorando per" un distintivo o un cappello divertente. I bravi sviluppatori non lavorano per i buffi cappelli. Lavorano per costruire un ottimo software, e pianificano di farlo fino a quando non gracidano: il loro obiettivo è quello di migliorare la qualità del software, ogni giorno. Se non sei tu, forse potresti voler esaminare la gestione del progetto. Probabilmente sarai più felice.

Nella mia esperienza di Agile, il team di sviluppo nel suo complesso riceve meno responsabilità rispetto a quanto suggerito dai tuoi esempi, lasciando il principale sviluppatore e architetto a coordinare le scelte progettuali di alto livello, ma affidando il design di livello inferiore alla squadra agile come un intero.

Quindi, lo sviluppatore principale rimane responsabile dell'architettura del sistema e delle scelte tecnologiche. Questo è molto importante: sebbene agile incoraggi la progettazione emergente e il refactoring, questo dovrebbe accadere a livello di oggetti di codice. Il sistema nel suo insieme deve avere un livello maggiore di pre-design e rigidità, altrimenti il progetto rischia di diventare un disordine non coordinato.

Nel nostro progetto, lo sviluppatore principale ha imposto le scelte tecnologiche e ha progettato il modo in cui i componenti del sistema interagirebbero tra loro. Agili riunioni di pianificazione incentrate su come progettare tali componenti all'interno dei suoi mandati di livello superiore. Per quanto piacevole, questo mantiene un margine di manovra per riunioni di pianificazione altrimenti noiose.

Ha anche funzionato come punto di ultima istanza. Quando i singoli programmatori si sono imbattuti in problemi che non erano in grado di risolvere, sarebbero andati al comando e la responsabilità finale di sistemare le cose era sua.