Recommander des ressources pour les chefs d'équipe de développement [fermé]

J'ai récemment été nommé chef d'équipe d'une équipe de développement d'une base de données (95% MS SQL Server, 5% misc-Oracle, Sybase, Access) qui gère et développe un grand nombre de bases de données dans un environnement d'entreprise. Je recherche des ressources (listes de contrôle, utilitaires, meilleures pratiques, procédures, sites Web, livres, etc.) qui m'aideront à mettre en œuvre les principes fondamentaux qui faisaient défaut dans ce groupe de développement dans le passé, tels que les révisions de code, la formation croisée, la documentation , l'application des normes, le partage des connaissances, le mentorat, etc.

La plupart de ce que je trouve sont des ressources de compétences en gestion générale, mais j'aimerais trouver tout ce qui pourrait être spécifique à la direction d'une équipe de développeurs. Les processus d'entreprise sont SDLC de type cascade «standard», de sorte que les ressources orientées vers Agile ne sont pas aussi pertinentes.

Livres que j'ai achetés et que je recommande aux Tech Leads et aux managers qui ont travaillé pour moi:

Développement rapide (S. McConnell) - grande "bible" de réponses aux choses courantes de type gestion / lead (plus de gestion)

Devenir un leader technique (Gerald Weinberg) - une lecture dense, mais une grande.

Boîte à outils du gestionnaire (Harvard Business Essentials) - encore une fois, plus axé sur la gestion, mais bon avec certains des problèmes interpersonnels

Explication de la collaboration (Jean Tabaka) - plus orienté Agile, mais une autre bonne bible de "comment faire X" très pratique

Au-delà de ça ... écoutez. Apprenez de votre équipe. Apprenez de vos pairs. Apprenez de votre patron. Trouvez un mentor en dehors de votre chaîne de commandement, mais quelqu'un que vous respectez et que vous pouvez rencontrer lorsque vous êtes frustré ou coincé. Rencontrez-les une fois toutes les deux semaines pour le petit-déjeuner.

Je viens de lire Peopleware récemment et je l'ai trouvé très instructif. Cela vous aidera certainement à comprendre la dynamique de l'équipe de développement (et beaucoup d'erreurs que nous commettons en les gérant / les dirigeant). J'ai été recommandé par quelqu'un ici sur les programmeurs.

Jetez un œil à " Débogage du processus de développement " par Steve Maguire.

Bien que ce ne soit plus le livre le plus moderne (1994), il contient toujours une mine d'informations qui devraient vous être utiles en tant que chef d'équipe et vous pouvez le récupérer à bon marché. Je l'ai trouvé excellent.

Vous pourriez également envisager le « développement rapide » de Steven McConnell. Encore une fois, c'est un ancien (1996) donc il est en quelque sorte antérieur au travail de la méthodologie Agile, vous trouverez donc des approches "cascade", "spirale" et "timeboxed" discutées sur leurs mérites. Vous trouverez certains des précurseurs de l'approche Agile (Rapid Prototyping, etc.). En outre, en ce qui concerne les "meilleures pratiques", vous trouverez une vaste gamme résumée à la page 400 ainsi que les évaluations citées appropriées concernant leur efficacité et des explications détaillées.

Les deux livres sont publiés par Microsoft Press et doivent donc présenter une référence suffisante avec vos technologies existantes.

Plus important encore, les deux livres couvrent la façon de gérer les équipes de développement logiciel - motivation, planification, réflexion stratégique, leadership, etc.

Je suis dans une position similaire. La première chose est de définir comment l'équipe doit travailler, quels processus doivent être en place, quel est le rôle de l'équipe. Créez une page wiki (ou sharepoint ou autre) pour mettre tout cela. Ensuite, ayez beaucoup de conversations régulières au sein de l'équipe pour définir en détail chacun d'eux. La seule chose qui est importante est de définir une culture et un comportement que l'équipe souhaite avoir. Pour la connaissance de l'équipe, c'est ce que nous utilisons. Commencez une session de partage de connaissances régulière toutes les deux semaines ou tous les mois, créez une feuille de calcul avec différents domaines de connaissances en lignes et les membres de l'équipe en colonnes. Attribuez ensuite un score de 1 à 5 pour connaître les forces et les lacunes de chaque membre. Faire un plan attribuer la responsabilité principale, secondaire et tertiaire pour chaque domaine avec un score cible de 5, 4 et 3 respectivement.

Documenter tous vos processus est très important. Par exemple, nous avons un processus d'examen des codes et une liste de contrôle. Si des processus impliquent d'autres équipes, soulevez-le avec la direction et acceptez les processus à ce niveau. par exemple un processus de libération.

Je ne peux pas souligner l'importance de la documentation (peut être légère dans un wiki) car vous avez une position de base solide pour améliorer et démontrer la gestion. Plusieurs fois, mon équipe a gagné aux yeux de la haute direction parce que nous disposions de solides documents et processus.