Qual è il ruolo dello sviluppatore principale in un team agile?

In un team di sviluppo non agile uno sviluppatore principale generalmente :

• Imposta lo standard (codifica e altro)
• Ricerca nuove tecnologie per il team
• Imposta la direzione tecnica per la squadra
• Ha l'ultima parola sulle questioni
• Progetta l'architettura di un sistema

Tuttavia, un team agile lavora diversamente:

• Un team agile farà affidamento sul design emergente, piuttosto che sul fronte
• Una squadra agile progetta insieme, piuttosto che il design è dettato da una persona
• Un team agile decide la propria direzione tecnica, che è meglio consegnare un progetto

Dove lascia questo sviluppatore principale in un team agile? È possibile avere uno sviluppatore principale in un team agile? Un team agile richiede responsabilità diverse rispetto a un lead?

Nulla di agile cambia il modo in cui lo sviluppatore principale dovrebbe funzionare. Dovrebbero coinvolgere il resto del team nelle decisioni sull'architettura del sistema e nella direzione tecnica, indipendentemente dal modello di sviluppo seguito.

Distribuire decisioni per editto è un modo terribile per qualsiasi team di sviluppo di correre. Agile rende il processo di acquisto dal resto del team un processo più esplicito, e uno sviluppatore capo avrebbe dovuto farlo comunque.

Solo perché non esiste un ruolo di sviluppatore principale stabilito in una metodologia di scrum non significa che le opinioni dei programmatori più esperti non siano le più rispettate. Agile non sta permettendo a tutti di scatenarsi per conto proprio e quindi, cercando di metterlo insieme, c'è ancora una visione e una direzione unificate che devono essere stabilite.

In una squadra agile tutti dovrebbero mettere da parte i loro ego.

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

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

È in un mondo ideale in cui le persone possono mettere da parte i loro ego. In bocca al lupo!

Oltre alla risposta di Ryathal :

Parli del design emergente e della direzione della squadra come se fluissero dalla squadra in perfetta armonia e armonia. Gruppi di persone, gruppi di programmatori in particolare hanno conflitti . Come capo della squadra, il tuo lavoro in una squadra agile è più un arbitro o un catalizzatore che a cascata. Quando il team è in conflitto su quale progetto utilizzare, ad esempio, ti assicurerai che le persone abbiano la stessa voce e continuino a discutere sui meriti. E finisci per essere l'arbitro della soluzione proposta con cui la squadra andrà quando il percorso non è chiaro.

Questa è una delle responsabilità più importanti della guida, ma sono necessarie molte altre cose per formare un gruppo di persone in una squadra. Hai ancora bisogno di dare l'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 in stand-by non lo taglierà.

L'altra cosa importante che hai trascurato sono le riunioni. È impraticabile portare l'intero team ad ogni riunione in cui il team deve interagire con uomini d'affari, altri team tecnici, ecc. Come capo del team, sei il rappresentante del team. Vai alle riunioni in modo che possano stare alle loro scrivanie e fare le cose. Sei il punto di contatto in modo che non vengano interrotti da persone che si fermano direttamente. E lavori per prendere informazioni dal mondo esterno (su cosa stanno lavorando gli altri team, come appariranno i team agili al prossimo sprint, qual è lo stato di quel req aperto, ecc.), Ridurli per loro e comunicarli.

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

La descrizione non agile non invalida la descrizione agile.

Un team agile farà affidamento sul design emergente, piuttosto che sul fronte.

Nulla sulla tua definizione di sviluppatore principale afferma che il design deve essere anticipato. Può stabilire la direzione e può ancora delineare un progetto iniziale. Quel design è sicuramente emergente.

Una squadra agile progetta insieme, piuttosto che il design è dettato da una persona

Nulla sulla tua definizione di sviluppatore principale dice che detta il design. Sebbene possa avere l'ultima parola, solo un cattivo vantaggio ignorerebbe completamente i pensieri dei suoi compagni di squadra di maggioranza. D'altro canto, solo una squadra povera ignorerebbe completamente i pensieri dello sviluppatore principale.

Un team agile decide la propria direzione tecnica, che è meglio consegnare un progetto

Ancora una volta, questo non significa che il lead inizialmente non imposti questa direzione. Il comando fa parte di questa squadra agile. Anche in un ambiente non agile, solo un vantaggio scarso continuerebbe a marciare una squadra in quella direzione quando è diventata consapevolmente irrealizzabile o quando sono state presentate nuove informazioni per invalidare questa direzione.

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

I team agili non distribuiscono badge o cappelli tra loro che dicono "Congratulazioni, sei il nostro super genio - sei l'unico a cui è permesso fare un doppio lavoro super segreto." Piuttosto, il focus è IL LAVORO A MANO. Se sei davvero più esperto, quell'esperienza dovrebbe MOSTRARE in che misura i tuoi progetti spingono il lavoro in avanti verso il completamento. I tuoi compiti (carte) 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 emerge da un veterano di 40 anni con, perché mai dovremmo andare 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.

Ciò pone un'altra domanda: chi può decidere cosa significa "meglio"? La risposta: il team di stakeholder. Ciò significa che gli sviluppatori, i requisiti, i tester, gli uomini d'affari, ecc., Che 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 riesci a farlo, non c'è motivo per il team di credere che la tua idea sia migliore. Agile incoraggia la meritocrazia.

Quindi, cosa succede al "capo del team di sviluppo?" in agile? Niente - sono semplicemente all'altezza di quel nome - Sicuramente sono in grado di produrre un software migliore rispetto alle altre persone del team. Altrimenti, non c'è motivo di chiamarli "lead": è solo un piccolo distintivo o un cappello divertente ed è insignificante. Molte persone lo trovano minaccioso. Si sentono come se stessero "lavorando per" un distintivo o un cappello divertente. I buoni sviluppatori non lavorano per cappelli divertenti. Lavorano per creare un software eccezionale e hanno in programma di farlo fino a quando non graccheranno - il loro obiettivo è migliorare ogni giorno nella creazione di software. 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 insieme ha meno responsabilità di quanto suggeriscano i tuoi esempi, lasciando lo sviluppatore e l'architetto leader a coordinare le scelte di design di livello superiore, ma consegnando il design di livello inferiore al team agile nel suo insieme.

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

Nel nostro progetto lo sviluppatore principale ha incaricato le scelte tecnologiche e ha progettato il modo in cui i componenti di sistema interagirebbero tra loro. Le riunioni di pianificazione agile si sono concentrate su come progettare tali componenti nei suoi mandati di livello superiore. A parte questo, questo mantiene un limite nell'ambito di incontri di pianificazione altrimenti noiosi.

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