Projet pilote, les premiers tests

Nous démarrons depuis le début de la semaine, un projet pilote Web. Cette démarche est nécessaire pour nous à plusieurs titres:

• une logique de test grandeur nature, pour mettre notre serveur applicatif à l'épreuve; passer partout dans notre code, et multiplier les Use Case est évidemment fondamental pour notre produit. Nous avons à ce sujet 2 règles d'or:
• en phase de développement, toujours passer en mode pas à pas dans toutes les lignes de code écrit.
• corriger un bug tout de suite, dès qu'il est détecté. Cela peut conduire à se disperser, surtout au début, quand un scénario révèle plusieurs bugs qui n'ont rien à voir du tout d'un seul coup, mais c'est vital pour être efficace.
• une validation de l'approche, en montrant qu'on atteint une application d'un niveau professionnelle, sans aucune restriction de customisation. L'essentiel de l'effort est porté sur la conception métier, on a une logique permanente d'état fini, et le résultat est visible tout de suite sans aucun effort.
• la mise en avant de best-practise qui accompagne notre produit; il y a toujours mille et une façons de développer une application. Notre logique de Binding ouvre des possibilités infinies, et il est essentiel d'être clair sur les "How to" fondamentaux. Cela permet de bien délimiter aussi la frontière entre l'inside et l'outside de la solution; qu'est ce que doit connaitre le développeur pour être efficace avec notre produit ?
• la priorisation des futures features à développer; notre Road Map est bien fournie, il est important de bien ordonner les développements à venir, pour accroitre la valeur du produit. Faire la distinction entre les nice-to-have, et le must-have.
• la réalisation d'une application interne qui va directement nous servir, puisqu'il s'agit d'un outil de CRM, dont nous avons besoin.

A ce jour, les premiers résultats sont plus qu'encourageant et enthousiasmant:

• la rapidité de mise en oeuvre est bluffante ! Bien sur, nous connaissons parfaitement notre produit, donc nous allons d'autant plus vite pour configurer le Binding, mais le coup de main s'apprend facilement, et cet effort est vite récompensé par des effets visibles. L'enchainement des écrans, la dynamique du binding, permettent une mise en oeuvre d'un Use Case en quelques minutes. Le confort d'une application full Ajax sans effort est vraiment très satisfaisant.
• l'essentiel de l'effort est bien porté sur la conception métier; comment organiser les données ? au niveau des schémas Entité/Relations, et aussi au niveau des différents DataSet dans le client. Comment organiser les Vues, avec quel niveau de détail pour le layout ? Comment nommer correctement les choses ? Ce qui est certain, et qui reste un de nos principaux objectifs, c'est qu'aucun choix n'est structurant. Il est facile de modéliser un premier jet, de le tester, puis de le modifier, pour arriver à l'application qui correspond à ce que l'on veut. Ces allers et retours sont constants, le cycle devient vite naturel. On commence à travailler avec un stockage XML, qui évite la rigidité du modèle physique de la base de données. C'est très souple, on ajoute, on enlève, on modifie, et ca marche ! Nous passerons à une base physique dès qu'une partie du modèle sera stable, et la migration sera totalement transparente et gratuite. Le code logique d'accès aux données est en effet complètement indépendant de son stockage physique, et ce sera également le cas pour le Cloud Computing.
• le peu de code à écrire s'écrit très facilement; pour l'instant, seul le chargement des données et quelques validateurs ont nécessité d'écrire quelques lignes de code. Ce code est simple, séquentiel, purement métier, et totalement indépendant du reste du monde. Une vingtaine de lignes ont été écrites et j'ai déjà un scénario qui fonctionne avec de la sécurité, et 5 formulaires qui me permettent d'éditer mes données.

Le seul bémol, et sur le quel nous ne pouvons pas grand chose, est l'habillage graphique, qui nécessitera un vrai travail ultérieur au niveau de la CSS.