Scrum - Méthodes agiles

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

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

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

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

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.

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

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

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.