L'Agilité au détriment de l'architecture ?

La réponse est non.

Dans InfoQ, un article de Amr Elssamadisy qui se demande si les pratiques Agiles ne se font pas au détriment de l'architecture et de la conception.

C'est vrai que lorsque je présente les méthodes Agiles, on me fait souvent la remarque suivante : avec des itérations aussi courtes, on n'aura pas le temps de réfléchir à une architecture solide. Eventuellement suivie d'une autre : si on construit un logiciel juste pour les quelques fonctionnalités [1] sélectionnées pour une itération, le risque est grand de devoir retoucher l'architecture dans les itérations suivantes.

Par ma culture de développement, par mon expérience du RUP, je suis porté à considérer que la qualité de l'architecture est essentielle pour le succès d'un développement. Je préconise d'avoir prouvé l'architecture[2] avant de commencer les itérations. Je conseille de faire de la conception lors de chaque itération, notamment lors des réunions de planification en début d'itération. Je suis partisan d'organiser une session de modélisation en groupe [3]au début d'une release. Une démarche Agile incluant ces pratiques[4] ne va pas au détriment de l'architecture et de la conception.

Notes

[1] par exemple des histoires d'utilisateur (user stories)

[2] notion de preuve de concept

[3] et d'afficher les diagrammes au mur

[4] sans parler du TDD évoqué dans l'article

Commentaires

1. Le mercredi 18 juillet 2007, 13:25 par Frédéric Monjo

Oui mais l'article insistait tout particulièrement sur le TDD. C'est vrai que la philosophie du TDD poussé à l'extrême tend à produire une architecture probablement moins robuste. Ce que conclut l'article, c'est que le TDD devrait être vu comme un outil à mettre au service du développement. Par exemple, un sprint démarrerait par une courte phase de conception (le nécessaire pour clarifier les choses et s'assurer de la robustesse de l'architecture), et la production du code s'appuierait sur le TDD avec tous les avantages que ça apporte.

2. Le mercredi 18 juillet 2007, 17:19 par Oaz

J'aurais tendance à me méfier des affirmations concernant la production (ou la non-production) d'une bonne architecture via du TDD.
Pour moi, la conclusion de l'article mentionné est hors-sujet. Le fameux exemple du Sudoku de Ron Jeffries ne prouve rien du tout quant à l'inefficacité du TDD. Faire émerger une architecture à partie d'exigences et concevoir un algorithme dans un contexte entièrement défini sont 2 choses totalement différentes.

En tout cas, avec le temps, j'en suis arrivé à préférer démarrer le développement en TDD avec rien de plus qu'une stratégie en tête sans trop m'embarasser de tache préalable "sur papier" (si ce n'est des scenarios représentés sous forme de diagramme de séquence afin d'identifier vaguement quelques entités).

Claude : C'est l'idée. Et dans un projet où on est pas tout seul, c'est cela qui doit être partagé et accepté par toute l'équipe.

J'ai trop souvent vu par le passé des "conceptions" où les auteurs (moi le premier) se sont fait plaisir à faire des usines à gaz pour risquer de retomber dans ce travers.

Claude : Et moi j'en ai vu sûrement encore plus (à cause de ma plus grande expérience, Oaz est jeune), des conceptions sur papier soit-disant génériques qui allaient permettre de satisfaire tous les besoins actuels et futurs. Le pire c'est quand c'est décrit avec seulement un diagramme de classe. Parce que sans diagrammes de séquence pour le tester (le diagramme de séquence, le TDD du MDA, mais c'est une autre histoire), c'est d'un intérêt tout limité.

3. Le jeudi 19 juillet 2007, 09:57 par Frédéric Monjo

Dans le projet annuel de cette année scolaire, nous avons élaboré en début de projet une architecture très générale, dont l'objectif était davantage de mettre en place des grands schémas d'organisation des classes. Plus particulièrement dans notre cas, où nous devions réaliser un jeu basé sur le moteur XNA de Micorosft au fonctionnement particulier, nous avons choisi un bon vieux MVC agrémenté d'un ou deux patterns un peu plus précis, de façon à anticiper nos besoins en modularité du code.

Par exemple, il s'agissait de prévoir des personnages avec des comportements différents, des vues de nature et technologies variées. Au final, après une ou deux heures de réflexion, on a produit un slide avec des gros carrés et quelques fils... Et ça a bien marché, puisque dès les premières fonctionnalités implémentées la structure globale s'est montrée robuste et adaptable.

Je persiste à croire qu'un minimum d'architecture globale (et pas plus) ne fait vraiment pas de mal. Il me semble aussi nécessaire d'avoir d'autres réflexions préliminaires sur les utilisateurs, leur façon de travailler, le workflow de l'entreprise, etc. toujours dans le même esprit d'un niveau de granularité grossier.