Raccomandare risorse per i leader del team di sviluppo [chiuso]

Di recente sono stato nominato caposquadra di un team di sviluppo di database (95% MS SQL Server, 5% misc-Oracle, Sybase, Access) che gestisce e sviluppa un gran numero di database in un ambiente aziendale. Sto cercando risorse (liste di controllo, programmi di utilità, migliori pratiche, procedure, siti Web, libri, ecc.) Che mi aiuteranno a implementare i fondamentali che in passato sono stati carenti in questo gruppo di sviluppo, come revisioni del codice, formazione incrociata, documentazione , applicare norme, condivisione delle conoscenze, tutoraggio e così via.

La maggior parte di ciò che sto trovando sono risorse generali relative alle competenze di gestione, ma vorrei trovare qualsiasi cosa possa essere specifica per guidare un team di sviluppatori. I processi aziendali sono SDLC a cascata "standard", quindi le risorse orientate verso Agile non sono altrettanto rilevanti.

Libri che ho comprato e raccomandato per responsabili tecnici e manager che hanno lavorato per me:

Sviluppo rapido (S. McConnell) - ottima "bibbia" di risposte a cose comuni di gestione / tipo di piombo (più gestione però)

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

Manager's Toolkit (Harvard Business Essentials) - ancora una volta, più focalizzato sulla gestione, ma buono con alcune delle questioni interpersonali

Collaboration Explained (Jean Tabaka) - più focalizzato sull'Agile, ma un'altra buona bibbia di "come fare X" molto pratica

Oltre quello ... ascolta. Impara dalla tua squadra. Impara dai tuoi colleghi. Impara dal tuo capo. Trova un mentore al di fuori della tua catena di comando, ma qualcuno che rispetti e può correre quando sei frustrato o bloccato. Incontrali una volta ogni due settimane per 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 degli 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 esserti utili come capo squadra e puoi prenderlo davvero a buon mercato. L'ho trovato eccellente.

Potresti anche prendere in considerazione " Rapid Development " di Steven McConnell. Ancora una volta, è un vecchio (1996), quindi in qualche modo precede il lavoro della metodologia Agile, quindi troverai approcci a "cascata", "a spirale" e "a tempo" discussi per i loro meriti. Troverai alcuni dei precursori dell'approccio Agile (prototipazione rapida e così via). Inoltre, per quanto riguarda le "Best Practices", troverai una vasta gamma riassunta a pagina 400 insieme alle valutazioni citate in merito alla loro efficacia e spiegazioni dettagliate all'interno.

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

Ancora più importante, entrambi i libri descrivono come gestire i team di sviluppo software: motivazione, programmazione, pensiero strategico, leadership e così via.

Sono in una posizione simile. La prima cosa è definire come dovrebbe funzionare il team, quali processi dovrebbero essere in atto, qual è il ruolo del team. Crea una pagina wiki (o sharepoint o altro) per mettere tutto questo. Dopodiché intrattenete regolarmente conversazioni all'interno del team per definire in dettaglio ognuna di queste. L'unica cosa importante è impostare una cultura e un comportamento che la squadra vuole avere. Per conoscenza del team questo è ciò che usiamo. Inizia una sessione regolare di condivisione delle conoscenze quindicinale o mensile, crea un foglio di calcolo con varie aree di conoscenza in righe e membri del team in colonne. Quindi assegnare un punteggio da 1-5 a conoscere i punti di forza e le lacune per ciascun membro. Fare un piano assegnare responsabilità primaria, secondaria e terziaria per ciascuna area con un punteggio target rispettivamente di 5, 4 e 3.

Documentare tutti i tuoi processi è molto importante. ad es. abbiamo un processo di revisione del codice e una lista di controllo. Se i processi coinvolgono altri team, sollevalo con il management e accetta i processi a quel livello. ad esempio un processo di rilascio.

Non posso sottolineare l'importanza della documentazione (può essere leggera in una wiki) poiché hai una solida 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.