Consiglia risorse per i team leader di sviluppo [chiuso]

Libri che ho comprato e amp; consiglia per Tech Lead e Manager che hanno lavorato per me:

Rapid Development (S. McConnell) - grande "bibbia" di risposte a cose tipo gestione / piombo comuni (più gestione)

Diventare un leader tecnico (Gerald Weinberg) - una lettura densa, ma fantastica.

Manager's Toolkit (Harvard Business Essentials) - di nuovo, più incentrato sulla gestione, ma buono con alcuni degli interpersonali problemi

Collaboration Explained (Jean Tabaka) - più agile, ma un'altra buona bibbia di "come fare X "molto pratico

Oltre a questo ... ascolta. Impara dalla tua squadra. Impara dai tuoi colleghi. Impara dal tuo capo. Trova un mentore fuori dalla tua catena di comando, ma qualcuno a cui rispetti e puoi correre quando ti senti frustrato o bloccato. Incontra con loro una volta ogni due settimane a colazione.

Ho appena letto Peopleware di recente e l'ho trovato molto illuminante. Ti aiuterà sicuramente a capire le dinamiche del team di sviluppo (e molti errori che commettiamo nel gestirli / guidarli). Mi è stato consigliato da qualcuno qui sui programmatori.

Dai un'occhiata a Debug del processo di sviluppo "di Steve Maguire.

Anche se non è più il libro più moderno (1994), ha ancora una grande quantità di informazioni che dovrebbero dimostrarsi utili come leader di una squadra e puoi prenderle a prezzi davvero convenienti. Ho trovato eccellente.

Potresti anche prendere in considerazione " Rapid Development " di Steven McConnell. Ancora una volta, è un vecchio gioco (1996), quindi è un po 'prima che la metodologia Agile funzioni, quindi troverai gli approcci "a cascata", "a spirale" e "timebox" in discussione nei loro meriti. Troverai alcuni dei precursori dell'approccio Agile (Rapid Prototyping e così via). Inoltre, per quanto riguarda le "Best Practices", troverai una vasta gamma riassunta a pagina 400 insieme a opportune valutazioni citate sulla loro efficacia e spiegazioni dettagliate all'interno.

Entrambi i libri sono pubblicati da Microsoft Press, quindi dovrebbero presentare riferimenti sufficienti con le tecnologie esistenti.

Soprattutto, entrambi i libri trattano come gestire i team di sviluppo del software: motivazione, pianificazione, pensiero strategico, leadership e così via.

Sono in una posizione simile. La prima cosa è definire come dovrebbe funzionare la squadra, quali processi dovrebbero essere in atto, qual è il ruolo della squadra. Crea una pagina wiki (o sharepoint o qualsiasi altra cosa) per metterli tutti. Quindi avere molte conversazioni regolari all'interno del team per definire in dettaglio ognuno di questi. L'unica cosa importante è impostare una cultura e un comportamento che il team vuole avere. Per la conoscenza della squadra questo è ciò che usiamo. Avvia una regolare sessione di condivisione delle conoscenze quindicinale o mensile, crea un foglio di lavoro con varie aree di conoscenza in righe e membri del team in colonne. Quindi assegna un punteggio da 1 a 5 per conoscere i punti di forza e gli spazi per ciascun membro. Fai in modo che un piano assegni la responsabilità primaria, secondaria e terziaria per ogni area con un punteggio obiettivo di 5, 4 e 3 rispettivamente.

La documentazione di tutti i tuoi processi è molto importante. per esempio. Abbiamo un processo di revisione del codice e una lista di controllo. Se i processi coinvolgono altri team, sollevali con la gestione e accetti i processi a quel livello. Ad esempio, un processo di rilascio.

Non posso sottolineare l'importanza della documentazione (può essere leggera in un wiki) poiché hai una strong posizione di base per migliorare e dimostrare la gestione. Molte volte il mio team ha vinto agli occhi del senior management perché disponevamo di documenti e processi efficaci.