Une société dans le monde des médias :
"Deux mois, seulement deux mois pour sortir ces nouvelles fonctionnalités, sinon nous sommes morts !". Pour se différencier, il faut innover. Mais l'innovation métier seule ne suffit pas, il faut innover avec une longueur d'avance, être le premier. Le décor est planté.
Pour adresser l'innovation dans un contexte temporel borné, on aura tendance à privilégier des méthodes agiles plutôt que de se lancer dans des longues phases de spécifications fonctionnelles générales, détaillées, qui ne feront qu'ajouter du risque ... Passons le peu de temps que l'on a à produire plutôt qu'à tout spécifier en détail.
Les méthodologies agiles permettent d'une part de répondre à ces contraintes de planning très fortes où les dérapages sont impossibles et d'autre part d'avancer sur un périmètre fonctionnel et/ou technique non encore défini ou changeant.
Concrètement, on adoptera une approche itérative et incrémentale
Du coté des développements, l'équipe se doit d'être réactive aux orientations de la MOA, c'est-à-dire faire en sorte que le logiciel puisse être facilement adaptable aux évolutions futures ou autre changements de spécification. De cette hypothèse, on va privilégier une conception et une architecture légère : la technique ne doit plus être une contrainte pour faire évoluer le logiciel. C'est là que GRAILS et les tests entrent en jeu...
GRAILS, bien plus qu'un framework est une plateforme JEE complète ayant comme objectif la productivité et la simplification des développements. S'appuyant massivement sur le paradigme " Convention Over Configuration ", cette approche permet de libérer le développeur de toutes les " siouxeries " techniques de configuration, de manipulation des multiples APIs, etc... Précisons que GRAILS n'est pas un autre framework issue du bien connu syndrome " NIH " (Not Invented Here), mais une abstraction des frameworks les plus éprouvés du monde JEE à savoir Spring, Spring MVV, Hibernate, Sitemesh, EhCache, Log4j, etc... ce qui garantit bien évidemment un certain standard.
Cette solution dite " packagée ", permet d'être très rapidement opérationnel, puisqu'elle vient avec tout ce dont le développeur à besoin pour coder, lancer et tester son application : une base de données embarquée (HSQLDB), un serveur web light (Jetty), des scripts Maven /Ant... Bref, en quelques minutes les développeurs sont opérationnels et peuvent commencer à travailler sur les premières fonctionnalités.
Récemment racheté et intégré au portefeuille des produits de Spring Source (éditeur de Spring/Spring DM, etc...), les récents téléchargements de la dernière version montrent clairement un engouement prononcé de la communauté... (30 000 téléchargements en février 08. 72 000 téléchargements pour le mois de novembre, soit plus du double).
La convention apportée par GRAILS alliée à l'expressivité du langage GROOVY permet de se focaliser sur le besoin métier, c'est-à-dire sur les règles de gestion que le développeur devra coder.
Ainsi, pas besoin d'être un expert Hibernate, Spring, etc... pour réaliser les opérations CRUD d'un objet, mais une convention à respecter. Cette approche permet de réduire le temps de développement et ainsi maximiser l'apport de valeur métier. Les démonstrations à la MOA sont plus fréquentes, on obtient un feedback au plus tôt et l'on peut soit valider le besoin soit réajuster le tir si besoin ;-). Ceci est particulièrement appréciable en contexte d'innovation.
Un bémol tout de même; à ce jour (décembre 08), l'intégration dans les IDEs n'est pas aussi étendue qu'avec Java. Ce manque devrait être comblé grâce aux travaux actuels des développeurs de Spring Source.
Pas de cahier des charges, mais une approche TDR (Test Driven Requirements) c'est-à-dire une spécification où les règles de gestion sont écrites sous la forme de tests de recette automatisés. Dans un contexte où le temps est compté, cette approche est particulièrement bien adaptée puisqu'elle présente les avantages suivants :
J'ai l'habitude d'utiliser l'outil FitNesse sur mes projets. Gratuit, léger et autonome (il ne requiert aucun système externe), il répond bien dans un premier temps à mes attentes : installation et prise en main rapide.
FitNesse est un wiki, il donne une véritable visibilité au projet. Les spécifications (ou tests ;-) sont accessibles à l'aide d'un navigateur web, ce qui facilite son adoption et rassemble autour de lui les équipes MOA et MOE.
Pour plus d'information sur FitNesse, je vous invite à consulter le site officiel http://fitnesse.org/
Une fois le contexte posé, voyons à partir d'un exemple concret comment cela se passe dans la réalité.
Mise en situation. Notre client nous demande d'implémenter la fonctionnalité suivante :
La suite dans le prochain billet, ce qui nous donnera l'occasion de voir l'écriture du test de recette et l'intégration de FitNesse avec GRAILS.
A suivre donc...