Objectifs du cours
- Les étudiants doivent être capables de mener une petite équipe de développeurs sur un projet, chez leur futur employeur ou dans leur propre entreprise.
- Dans le cadre de ce cours, chaque étudiant doit pouvoir s’essayer au moins une fois au rôle de lead dev, au travers de simulations de projets.
Contenu du cours
- Les bases de la conduite de projet tech.
- Démonstrations de workflows, et dans quels cas les appliquer.
- Retours d’expérience, notamment chez Algolia.
- Mise en pratique sur un projet de groupe.
Pré-requis / Connaissances préalables
- Bases en gestion de projet
- Bases de la méthodologie Agile
Évaluation des étudiants
- 1 QCM individuel en fin de 1ère journée
- Contrôle continu: notes individuelles basées sur les ateliers.
Programme du cours
- Jour 1: sensibilisation aux responsabilités et complexités du lead dev
- Jour 2: bases et outils pour la gestion de crise
- Jour 3: recommandations pour pérennité, prise d’initiatives et accompagnement des membres de l’équipe
Outline du cours
- Jour 1, Objectif: sensibilisation aux responsabilités et complexités du lead dev
- QCM à main levée: cassage de mythes sur le lead dev
- lead dev = meilleur développeur de l’équipe ? -> NON
- lead dev passe la majorité de son temps à développer ? -> OUI
- lead dev est élu par ses supérieurs hiérarchiques ? -> NON
- lead dev tranche quand il y a un conflit au sein de l’équipe sur une décision technique ? -> OUI
- lead dev décide de qui fait quoi, quand, dans l’équipe ? -> NON
- lead dev doit détecter et planifier le remboursement de la dette technique ? -> OUI
- lead dev décide l’ordre de développement des fonctionnalités ? (roadmap) -> NON
- lead dev est responsable du recrutement ? -> NON
- lead dev est responsable du développement de carrière des ingénieurs de son équipe ? -> NON
- lead dev doit régulièrement parler aux clients ? -> NON
- Rappels sur les métiers, rôles et méthodologies de projet en entreprise
- métiers / rôles:
- lead dev:
- son rôle: aider et coordonner l’équipe de développement
- son objectif: la pérennité technique du projet,
- il doit être force d’initiative
- il doit être en mesure de trancher sur les décisions techniques
- rapporteur, (prise de notes, rédaction de comptes rendus de réunions et incidents)
- référent d’une équipe de développement, il discute majoritairement avec son équipe, mais aussi avec autres équipes techniques + managers
- le lead dev peut agir comme project manager, si besoin
- project manager / scrum master:
- son rôle: planifier, suivre et faciliter le bon déroulement d’un projet
- son objectif: l’équipe produit un résultat répondant aux attentes, en respectant au mieux les budgets (temps, argent) et les éventuelles interdépendances avec autres projets, et les imprévus
- product manager / product owner:
- son rôle: identifier les besoins des clients du produit, aider l’équipe de développement à prioriser les évolutions en fonction
- son objectif: une clientèle durablement satisfaite, et croissante + permettre à l’équipe de développement d’avoir un maximum d’impact et d’efficacité en focalisant sur ce qui apporte le plus de valeur
- engineering manager:
- son rôle: suivre, conseiller et aider les développeurs à s’améliorer de manière continue, et à développer leur carrière. + recruter.
- son objectif: maintenir ou faire croître la force et la qualité des développements
- méthodologies
- Cycle en V
- Gestion projet: Gantt, etc…
- Agile / Scrum
- Lean management / lean startup
- Extreme Programming
- UML
- Git / GitHub / GitLab flow
- Jour 2, Objectif: bases et outils pour la gestion de crise
- Brainstorming: lister des exemples de crises qui peuvent survenir lors d’un projet
- problèmes techniques / incidents / urgences
- lenteur de l’infra
- page 503 (site inaccessible)
- problème de facturation (ex: causé par un problème de monitoring)
- fuite de données
- altération de données
- perte de données
- problèmes de qualité / architecture du produit
- régressions
- bugs
- manque de prévisibilité du comportement du produit
- difficulté de faire contribuer des personnes extérieures à l’équipe
- manque d’équilibre / d’efficacité
- trop de temps passé sur bug fixes, pas assez de nouvelles fonctionnalités
- trop de temps passé sur nouvelles fonctionnalités, pas assez sur bug fixes
- trop de temps passé en support client (bugs, questions…)
- trop de temps passé à répondre aux questions des autres équipiers
- trop de temps passé à lire les pull requests
- trop d’itérations sur les pull requests (ex: discussions, documentation, linting…)
- over-engineering
- les nouvelles fonctionnalités prennent beaucoup plus de temps qu’elles ne devraient à développer
- problèmes humains
- conflit intra-équipe sur une décision technique (ex: architecture d’une solution à produire)
- l’équipe ne respecte pas la roadmap / le backlog
- baisse de motivation et productivité de l’équipe
- pas assez de monde en astreinte / équipier en astreinte qui ne répond jamais aux urgences
- demandes RGPD
- Jour 3, Objectif: recommandations pour pérennité, prise d’initiatives et accompagnement des membres de l’équipe
- Brainstorming: quelles responsabilités du lead dev, au delà des crises ?
- choix technologiques => veille et compréhension des valeurs et direction de l’entreprise
- élaboration des budgets:
- développement de fonctionnalités,
- support,
- correction de bugs,
- détection et remboursement de dette technique,
- documentation,
- tests automatisés,
- monitoring et alertes,
- mise en place et suivi d’astreintes (post-mortem, etc…)
- entraide et communication externe (ex: pour recrutement)
- animation de l’équipe: hack day, off-site, et autres activités de team building
Atelier “Lead Dev RPG”
Annexes