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 / gde@vaconsulting.lu / @gdelamarre

Christophe Massin / cma@vaconsulting.lu@Christophe2dot0