Pratiques d'ingénierie du logiciel

Il est courant de classer les pratiques agiles en 2 : ingénierie et management

Distinguer les pratiques d’ingénierie et de management, c’est par exemple ce que fait Denis dans son questionnaire sur le niveau d’agilité.

Vous aurez noté que dans ce blog je parle plus des pratiques de management. C’est parce que je préfère parler de ce que je pratique (!) couramment : je suis impliqué dans de nombreux projets agiles, mais je n’écris plus de code depuis déjà un certain temps.

Les pratiques d’ingénierie, c’est évidemment très important. Certaines sont même indispensables. Une grave erreur serait, pour ceux qui appliquent Scrum en particulier, de les oublier. Assimiler Scrum au management et XP à l’ingénierie, ce serait aussi une ânerie. Vive le maul !

Mais quelles sont ces pratiques dites d’ingénierie ? Il y a bien sûr le triptyque :

  • intégration continue,
  • remaniement du code (refactoring)
  • test unitaire. Avec le test écrit avant le code, on parle de TDD

On peut ajouter celles liées à la fabrication du code :

  • standard de codage,
  • responsabilité collective du code,
  • gestion des versions,
  • déploiement fréquent des builds,
  • le binômage (pair programming), qui est une pratique de collaboration, voire de réflexion plutôt que d’ingénierie.

Dans les pratiques d’ingénierie on intègre souvent celles liées au développement, comme :

  • conception émergente,
  • architecture incrémentale,
  • spike.

Toutes les autres pratiques seraient qualifiées de management.

Cette classification est simple, mais assez arbitraire. Par exemple passer des tests d’acceptation pendant l’itération n’est pas dans la liste ci-dessus mais pourrait y être, par son impact sur les développeurs.