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.

1. Comment transformer des
«débutants»...
en super développeurs en un an ?

2. Définitions
(à considérer dans le contexte de l’entreprise !)

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. 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

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. Environnement
Timing : 2 à 4 semaines

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. Définir un environnement cohérent
= uniformiser
-> les systèmes
-> les IDE
-> les accessoires
= rester en veille
-> nouveaux outils, nouveaux besoins

9. Organisation du team
Timing : 4 à 8 semaines

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. 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. Méthodologie
Timing : 5 à 14 semaines

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. 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 !

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. Code Reviews
Timing : 2 à 4 semaines

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. 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. Refactoring
Timing : 4 à 8 semaines

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. Quoi et quand ?
= Quoi ?
-> priorité aux objets métiers
-> composants
= Quand ?
-> après les code reviews
-> après les retrospectives

22. Unit Testing
Timing : 2 à 6 semaines

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. 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. Intégration continue
Timing : 4 à 8 semaines

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. 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. Conclusion

29. Prendre le temps !
= faire la différence entre "perdre" et "investir"
= organisation
= méthodologie
= formation
= refactoring
= tests unitaires

30. Ne pas oublier l’essentiel !
= acceptation de l’équipe
= esprit d'équipe
= communication
= partage

31. Merci de votre attention !
Gauthier Delamarre / gde@vaconsulting.lu /
@gdelamarre
Christophe Massin / cma@vaconsulting.lu
@Christophe2dot0