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.

Commentaires

1. Le lundi 19 janvier 2009, 21:02 par david

plus que jamais, il me paraît intéressant de réflechir sur l'orchestration de toutes ces pratiques
Bien sur, leur applicabilité dépend du contexte et de l'environnement.
Mais quid de la compatibilité entre elles, de leur complémentarité, des dégats éventuels provoqués si on applique qu'une pratique sans sa/ses complémentaires ?
Claude : la plupart du temps, ce n'est pas binaire : pratique appliquée ou pratique pas appliquée. Les dégâts c'est plutôt quand : pratique mal appliquée.
De même, on doit pouvoir considérer qu'il y a des pratiques "minimum" sans lesquels l'agilité est fortement compromise (ex: stories, sprints, priorisation, retrospective...)
Claude : c'est sûr que c'est difficile d'être agile si on ne fait pas de sprints. Mais sans utiliser les user stories c'est sûrement possible.
Je vais essayer de bloguer sur le sujet...