Bonnes pratiques de développement


Pourquoi la méthode en "V", ou de type "waterfall", en cascade, est has-been ? Les fameuses étapes spécification / conception / réalisation / validation, souffrent de problèmes chroniques :
  • Les spécifications sont définies au début du projet, alors que c'est là qu'on est sait le moins.
  • Les spécifications font rarement la différence entre ce qui est important de ce qui ne l'est pas.
  • Les activités sont compartimentées en fonction des spécialités des développeurs, ce qui pose des problèmes de répartition des tâches et limite la circulation des connaissances dans l'équipe.
Les méthodes de l'Extrem Programing ou de l'Agile, apportent un peu de bon sens à tout ça. Voici une compilation des choses à faire ou ne pas faire.

La communication
  • Le client est au centre du projet, de l'équipe). C'est le mieux placer pour définir au mieux ses besoins. Il arbitre les priorités (le product owner les défini et les planifie). Il apporte surtout ses connaissances métier à l'équipe.
  • Faire travailler tous les développeurs ensemble. Que chacun sache ce que font les autres. Faire circuler l'information. Instaurer le pair programing. S'entre-aider. Faire des revues de codes par roulement. Sans oublier les réunions quotidiennes (stand-up meeting) pour que chacun connaisse l'état du projet.
Feedback
  • Mettre en place un système d'intégration continue, style Jenkins, par jouer automatiquement une batteries de tests (unitaires et de régression), d'analyser le code, de connaitre l'état global de l'application.
  • Fournir régulièrement des livrables. Il faut pouvoir montrer au client quelque chose de fonctionnel (même partiellement, mais en état de marche), pour qu'il puisse se rendre compte de l'avancement de l'application, et préciser ou corriger ses besoins.
Simplicité
  • Il ne faut pas une spécification complète et détaillée du futur système
  • Avoir une architecture et un code ouvert à tout changement et évolution, et facilement maintenable.
Tests Unitaires
  • Aide à la conception détaillé
  • Les écrire avant le code
  • Ne doit pas passer au début 
  • Doivent passer sans erreur avant d’intégrer le code
  • Aide à la non régression, au changement de conception et au remaniement

Aucun commentaire:

Enregistrer un commentaire