Comment transformer des«débutants»...en super développeurs en un an ?
Définitions(à considérer dans le contexte de l’entreprise !)
Un débutant...= n’apprend pas de ses erreurs= passe l’essentiel de son temps à écrire du code= s’identifie à son code= ne m...
Un «Super développeur»...= se focalise sur la satisfaction client= prend le temps de concevoir et tester avantd’écrire du ...
Postulat de départ= équipe constituée = renforcée d’une nouvelle recrue = à la recherche de plus d’efficacité= nouvelle équ...
EnvironnementTiming : 2 à 4 semaines
Objectifs= Bénéfices -> éviter de perdre du temps au quotidien -> amener chacun à exploiter au mieux les outils utilisés= R...
Définir un environnement cohérent = uniformiser   -> les systèmes   -> les IDE   -> les accessoires = rester en veille   ->...
Organisation du teamTiming : 4 à 8 semaines
Objectifs= Bénéfices -> optimiser les ressources de l’équipe -> permettre à chacun d’exploiter ses talents -> responsabilis...
Chacun doit trouver sa place= prendre ses responsabilités -> exercer le super-pouvoir du développeur : le pouvoir de dire ...
MéthodologieTiming : 5 à 14 semaines
Objectifs= Bénéfices -> optimiser les cycles de développements -> améliorer la relation avec le client en l’impliquant plus...
Sélectionner= "Manifeste pour lagilité"  -> agilemanifesto.org= Se documenter= Faire un choix  ? Scrum  ? Kanban  -> Scrum...
Implémenter = adapter  = à son organisation  = à ses priorités= rester souple  ≠ dogme= léquipe doit devenir responsable d...
Code ReviewsTiming : 2 à 4 semaines
Objectifs= Bénéfices -> détection précoce des erreurs de conception et d’implémentation -> réduction de la quantité de code...
Trouver le rythme et la forme= planifiées ou spontanées= formelles ou informelles -> améliorer la qualité     Texte= laisse...
RefactoringTiming : 4 à 8 semaines
Objectifs= Bénéfices -> uniformisation des API (application des coding standards) -> réduction de la quantité de code déplo...
Quoi et quand ?= Quoi ? -> priorité aux objets métiers -> composants= Quand ? -> après les code reviews -> après les retro...
Unit Testing	Timing : 2 à 6 semaines
Objectifs= Bénéfices -> prévention des régressions -> documentation du code -> validation des règles métiers= Risques -> pe...
Parmi les bénéfices du test unitaire = facilite le refactoring   -> informe des régressions immédiatement = guide la concep...
Intégration continueTiming : 4 à 8 semaines
Objectifs= Bénéfices -> exploitation maximale des bonnes pratiques mise en oeuvre -> automatisation des tâches répétitives ...
Le Graal ! = convergence = visibilité = contrôle = Early bug killing   -> plus vite on identifie un bug, plus on limite ses...
Conclusion
Prendre le temps != faire la différence entre "perdre" et "investir"  = organisation  = méthodologie  = formation  = refac...
Ne pas oublier l’essentiel ! = acceptation de l’équipe = esprit déquipe = communication = partage
Merci de votre attention !Gauthier Delamarre / gde@vaconsulting.lu /@gdelamarreChristophe Massin / cma@vaconsulting.lu@Chr...
Prochain SlideShare
Chargement dans…5
×

Comment transformer un débutant en super-développeur

2 194 vues

Publié le

Les bonnes pratiques qui permettent d'encadrer une équipe de développement sont nombreuses.

Nous proposons ici une chronologie pour les mettre en place dans un ordre cohérent, qui permettra d'en faciliter l'acceptation et d'en maximiser les bénéfices.

Le tout dans le contexte d'une équipe professionnelle qui ne perd pas de vue que sa mission est de satisfaire les besoins de son client !

Ces slides sont une version adaptée à la consultation en ligne d'une conférence présentée les 29 et 30 Novembre dans le cadre du PHP Tour 2012 à Nantes.

Publié dans : Technologie

Comment transformer un débutant en super-développeur

  1. 1. Comment transformer des«débutants»...en super développeurs en un an ?
  2. 2. Définitions(à considérer dans le contexte de l’entreprise !)
  3. 3. Un débutant...= n’apprend pas de ses erreurs= passe l’essentiel de son temps à écrire du code= s’identifie à son code= ne met pas son travail dans une perspective«business»
  4. 4. Un «Super développeur»...= se focalise sur la satisfaction client= prend le temps de concevoir et tester avantd’écrire du code= remet en question la qualité de son travail
  5. 5. Postulat de départ= équipe constituée = renforcée d’une nouvelle recrue = à la recherche de plus d’efficacité= nouvelle équipe = from scratch (oui, ça existe encore !)
  6. 6. EnvironnementTiming : 2 à 4 semaines
  7. 7. Objectifs= Bénéfices -> éviter de perdre du temps au quotidien -> amener chacun à exploiter au mieux les outils utilisés= Risques -> ne pas imposer les outils - laisser l’équipe en décider -> ne pas être rigide - selon les tâches, les outils peuvent varier
  8. 8. Définir un environnement cohérent = uniformiser -> les systèmes -> les IDE -> les accessoires = rester en veille -> nouveaux outils, nouveaux besoins
  9. 9. Organisation du teamTiming : 4 à 8 semaines
  10. 10. Objectifs= Bénéfices -> optimiser les ressources de l’équipe -> permettre à chacun d’exploiter ses talents -> responsabiliser et donner confiance en soi à l’équipe -> éviter le bloquage de situations grâce à des arbitrages= Risques -> une responsabilité ne doit pas être qu’une pression de plus -> enfermer les membres de l’équipe dans un rôle peut causer des frustrations contre-productives
  11. 11. Chacun doit trouver sa place= prendre ses responsabilités -> exercer le super-pouvoir du développeur : le pouvoir de dire «Non» ! Refuser les contraintes irréalistes sera le meilleur moyen de préserver la qualité du projet -> quand il n’est pas possible de s’opposer à une mauvaise décision, le super-pouvoir doit se transformer en super-devoir : il faut alerter sur les risques engendrés= partager son expérience= faire confiance !
  12. 12. MéthodologieTiming : 5 à 14 semaines
  13. 13. Objectifs= Bénéfices -> optimiser les cycles de développements -> améliorer la relation avec le client en l’impliquant plus -> avoir plus de visibilité et de contrôle sur le déroulement des projets -> introduire la qualité à tous les moments du cycle de développement= Risques -> appliquer de manière dogmatique la méthodologie ne permettra pas d’atteindre ces objectifs
  14. 14. Sélectionner= "Manifeste pour lagilité" -> agilemanifesto.org= Se documenter= Faire un choix ? Scrum ? Kanban -> Scrum :) Scrum propose un compromis intéressant entre souplesse et visibilité, qui s’adaptera à la majorité des équipes/projets mais pas à tous !
  15. 15. Implémenter = adapter = à son organisation = à ses priorités= rester souple ≠ dogme= léquipe doit devenir responsable de son projet = éduquer son "client" (interne ou externe) = pour collaborer avec lui
  16. 16. Code ReviewsTiming : 2 à 4 semaines
  17. 17. Objectifs= Bénéfices -> détection précoce des erreurs de conception et d’implémentation -> réduction de la quantité de code écrite -> réduction de la quantité de bugs != Risques -> sans aucun protocole, peut consommer un temps trop important -> mal comprises ou mal menées, les code reviews peuvent déclencher des conflits d’ego
  18. 18. Trouver le rythme et la forme= planifiées ou spontanées= formelles ou informelles -> améliorer la qualité Texte= laisser son ego au vestiaire -> il est votre pire ennemi !
  19. 19. RefactoringTiming : 4 à 8 semaines
  20. 20. Objectifs= Bénéfices -> uniformisation des API (application des coding standards) -> réduction de la quantité de code déployé -> amélioration de la réutilisabilité= Risques -> rentrer dans des boucles infinies de réécriture -> causer des régressions -> c.f. «Tests unitaires» pour prévenir ce risque -> déclencher des conflits d’ego en reprenant le code d’un autre membre de l’équipe de manière arbitraire
  21. 21. Quoi et quand ?= Quoi ? -> priorité aux objets métiers -> composants= Quand ? -> après les code reviews -> après les retrospectives
  22. 22. Unit Testing Timing : 2 à 6 semaines
  23. 23. Objectifs= Bénéfices -> prévention des régressions -> documentation du code -> validation des règles métiers= Risques -> perdre du temps tenter de tester trop d’éléments, notamment des éléments non-testables -> ne pas maintenir les tests les rend inutiles
  24. 24. Parmi les bénéfices du test unitaire = facilite le refactoring -> informe des régressions immédiatement = guide la conception -> en appliquant le TDD, qui consiste à écrire les tests avant le code, on = vision objective de la qualité -> le résultat du test ne dépend pas de qui l’exécute = métrique de progression -> une méthode est implémentée lorsqu’elle passe tous les tests associés
  25. 25. Intégration continueTiming : 4 à 8 semaines
  26. 26. Objectifs= Bénéfices -> exploitation maximale des bonnes pratiques mise en oeuvre -> automatisation des tâches répétitives souvent source d’erreurs (particulièrement le déploiement)= Risques -> aller trop vite vers l’intégration continue au risque de ne pas avoir mis en oeuvre toutes les pratiques associées en amont !
  27. 27. Le Graal ! = convergence = visibilité = contrôle = Early bug killing -> plus vite on identifie un bug, plus on limite ses conséquences, et donc son coût
  28. 28. Conclusion
  29. 29. Prendre le temps != faire la différence entre "perdre" et "investir" = organisation = méthodologie = formation = refactoring = tests unitaires
  30. 30. Ne pas oublier l’essentiel ! = acceptation de l’équipe = esprit déquipe = communication = partage
  31. 31. Merci de votre attention !Gauthier Delamarre / gde@vaconsulting.lu /@gdelamarreChristophe Massin / cma@vaconsulting.lu@Christophe2dot0

×