Scrum est un sous-ensemble de l’ancienne méthode RAD qui a tenté d’évoluer indépendamment, mais malheureusement de manière imparfaite et incomplète. XP est aussi un sous-ensemble, mais d’un apport indéniable à l’ingenierie du logiciel même s’il s’avère lui aussi incomplet.
Il faut comprendre qu’il manque beaucoup de pratiques aux méthodes Agiles actuelles pour couvrir le large scope des techniques nécessaires à un développement de système d’information conséquent ou faisant appel à des architectures sophistiquées. Cette évidence, pour ceux qui utilisent ces techniques depuis lontemps, ou pour moi qui ai passé ces vingt dernières années à les faire évoluer, méritait bien quelques justifications simples. Avec cette article ce sera fait.
En premier lieu, rappel des dates : RAD 1991, Scrum 1996, XP 1999.
Sur le fond, les méthodes RAD, XP, Scrum ou Puma Essentiel, ainsi que les autres méthodes Agiles, sont identiques en termes de cycle, phasage, valeurs et principes. Pour le phasage, par exemple, en plus d’être incrémentale et adaptative, l’approche est semi-itérative (et non pas totalement itérative comme le pense les simplistes).
Lire « Le mythe de l’itératif sans concession » http://agiles.blog.com/2008/3/
Note : Je suis prêt à parier qu’une grosse partie des problèmes actuels de Scrum est une mauvaise interprétation de ce point par des débutants sans réelle expérience du développement et qui sous-estiment l’importance de l’expression des exigences et des différentes formes d’architectures.
Voici les trois points à considérer à partir des techniques RAD déja publiées avant 1996, date d’émergence de Scrum :
Point positif 1 : la méthode XP présente un apport de spécialisation en ce qui concerne l’ingénierie du logiciel lors de la phase de Construction.
Point neutre 2 : si Scrum n’a rien apporté de nouveau, les techniques qu’il préconise ne sont pas mauvaises mais simplement et régressivement insuffisantes.
Point négatif 3 : Scrum, certainement à cause de son manque de spécialisation, fait régresser la méthode en termes de pilotage. Cette régression à pour source l’usage de solution d’un simplisme inadéquat en regard de la réelle technicité et complexité des projets de développement informatiques. En effet, ces derniers nécessitent souvent une estimation préalable au codage ainsi qu’une modélisation formelle. Cette modélisation permettra de réaliser une planification prenant en compte de nombreuses interdépendances tant fonctionnelles que techniques et des concepts non triviaux, comme par exemple, la stabilité ou la granularité des objets.
Lire « Le Mythe du périmètre variable » http://agiles.blog.com/2008/1/
Les « emprunts » de Scrum à la première des méthodes Agile, le RAD, sont aisés à mettre en évidence à travers les techniques et même leurs dénominations, qui n’ont pas été adaptées à la métaphore du Rugby, mais conservent les métaphores « commando » du RAD (SWAT, War Room, etc.).
Voila une simple petite synthèse des pratiques les plus en vue.
L’équipe : Team pour Scrum et SWAT Team pour RAD (SWAT à l’origine du mot : Special Wapons And Tactic ou dans le cas informatique : Skill With Advanced Tools). La composition de l’équipe est strictement identique et se limite dans les deux cas aux représentants du client, aux informaticiens de développement et à la présence d’un facilitateur nommé Animateur pour le RAD ou Scrumaster pour Scrum.
La salle de travail se nomme War Room aussi bien pour le RAD que pour Scrum (On notera que cette dénomination militaire correspond à la salle de travail du SWAT).
Le reporting mural : même usage des murs avec, pour Scrum et XP, l’avantage indéniable de l’évolution et de la formalisation de cette pratique.
La planification est adaptative et essentiellement basée sur la valeur pour l’ensemble des méthodes. La comparaison s’arrête là pour Scrum car le RAD, qui est une approche dédiée aux développements applicatifs, prend en compte plusieurs autres interdépendances techniques ou besoins exprimés et propose une planification stratégique incluant des variables de contraintes pour compléter la priorité basée sur la valeur ajoutée.
Les réunions : Morning meeting pour le RAD, Stand Up meeting pour Scrum
Les retrospectives : Focus de fin d’itération (ou Show) pour le RAD et « de fin d’itération » pour Scrum. Rétrospectives de fin de projet pour Scrum et post-mortem de projet pour le RAD (rarement fait dans le cas d’équipes externes).
La comparaison entre RAD et Scrum s’arrête là car Scrum ne comprend pas de pratiques d’ingénierie du logiciel (Construction du RAD et techniques XP).
Au niveau de la réalisation, pour pouvoir continuer la comparaison entre la méthode RAD et une autre méthode de développement, il faut switcher de Scrum à XP. On s’aperçoit alors que l’ « architecture de réalisation » de RAD) est absolument identique à la structure itérative incrémentale de XP (dernier graphique de l’article « Le Mythe du périmètre variable » http://agiles.blog.com/2008/1/) .
En matière d’ingénierie du logiciel, il sera noté deux différences : une de forme dans les dénominations et une de fond concernant l’usage eXtrême des techniques :
- Pair Programming systématique avec rotation journalière des binômes pour XP et Pair Programming de contexte avec revue de code par les « pairs » avant les Focus de livraisons pour le RAD.
- Les jalons journaliers se nomment ZD comme Zéro-Défaut pour le RAD. Les vérifications d’intégration qui sont relativement identiques peuvent éventuellement être en partie manuelles et en partie automatisées pour le RAD et semblent plus mécaniques et instrumentés dans XP (ces aspects n’ont pas été traités depuis des années dans le cas du RAD) .
Note : Le RAD des années 90 ne disposait pas des matériels et outils actuels permettant d’accroitre la mise en œuvre aisée du pair programming, du TDD et d’accroître la fréquence ou de l’intégration continue qui se réalisait une fois par jour en général.
C’est cette similitude entre la structure RAD et XP qui m’avait amené en 2000 à préconiser de remplacer la phase de construction du RAD par XP pour ceux qui désiraient atteindre un haut niveau technique de qualité applicative en acceptant d’en payer le prix en termes de formation et de rigueur de mise en œuvre.
Ce papier représente un simple historique et une comparaison entre les méthodes Agiles actuelles et leur souche commune le RAD désormais pratiquement en désuétude en tant que méthode commercialisée.
Lire le « Comparatif Scrum, XP, PUMA » http://agiles.blog.com/2008/4/
Bon, je ne vais pas perdre plus de temps dans ces souvenirs méthodologiques, bien que cela me rajeunisse grave.
Une nouvelle génération de méthodes Agiles va naturellement émerger et PUMA en est le précurseur.
