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 met pas son travail dans une perspective «business»
Un «Super développeur»...
= se focalise sur la satisfaction client
= prend le temps de concevoir et tester avant d’écrire du code
= remet en question la qualité de son travail
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 !)
EnvironnementTiming : 2 à 4 semaines
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
Définir un environnement cohérent
= uniformiser-> les systèmes
-> les IDE
-> les accessoires
= rester en veille-> nouveaux outils, nouveaux besoins
Organisation du teamTiming : 4 à 8 semaines
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
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 !
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
-> 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
Sélectionner= "Manifeste pour l'agilité"
-> 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 !
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
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 é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
Trouver le rythme et la forme
= planifiées ou spontanées
= formelles ou informelles-> améliorer la qualité
= laisser son ego au vestiaire-> il est votre pire ennemi !
Texte
RefactoringTiming : 4 à 8 semaines
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
Quoi et quand ?
= Quoi ?-> priorité aux objets métiers
-> composants
= Quand ?-> après les code reviews
-> après les retrospectives
Unit TestingTiming : 2 à 6 semaines
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
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
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 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 !
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
Conclusion
Prendre le temps !
= faire la différence entre "perdre" et "investir"= organisation
= méthodologie
= formation
= refactoring
= tests unitaires
Ne pas oublier l’essentiel !
= acceptation de l’équipe
= esprit d'équipe
= communication
= partage
Merci de votre attention !Gauthier Delamarre / [email protected] / @gdelamarre
Christophe Massin / [email protected]@Christophe2dot0
Recommended
