Dan Fuller, Directeur Associé du Centre d’Excellence Agile chez Cognizant,  explique comment déterminer si un projet est prêt à utiliser une méthode de développement de logiciel Agile

L’un des principaux thèmes abordés par le « Manifeste pour le Développement Agile de Logiciels » est la nécessité de « valoriser les logiciels opérationnels plutôt qu’une documentation exhaustive. » Concrètement, cela signifie que nous ne nous contentons pas simplement de créer des logiciels fonctionnels, nous leur conférons une valeur opérationnelle.

De nombreuses entreprises ont déjà adopté la méthode Agile comme principale méthode de développement logiciel pour de nouvelles applications sur mesure ; des méthodes Agiles telles que Scrum se sont très vite imposées sur le marché de la conception logicielle. Cependant, de nombreux projets entrepris par les organisations informatiques ne correspondent pas exactement au modèle type d’une nouvelle application.

Depuis quelques temps, la plupart des grands projets informatiques complexes se concentrent aussi bien sur la combinaison de systèmes que sur la conception de nouvelles applications logicielles sur mesure. Pour autant, ces types de projets se prêtent-ils à l’utilisation de la méthode Agile ?

Afin de savoir si une méthode Agile peut convenir à un projet, il convient d’abord de se poser quatre questions. S’il s’avère difficile de répondre à ces questions, il se peut fort bien que l’équipe en charge du projet ne soit pas prête à adopter une méthode Agile.

1ère question : « À quoi ressemblent nos scénarios clients (user stories) ? »

Par exemple, une entreprise spécialisée dans la conception de logiciels bancaires pourrait avoir une User Story dans lequel l’utilisateur souhaiterait pouvoir accéder aux opérations effectuées sur son compte au cours des trente derniers jours. Bien sûr, cela demande une vision claire des autres types d’objets qu’il nous faudra créer pour améliorer la User Story. Il est essentiel de garder à l’esprit le manifeste Agile et de se rappeler qu’en le suivant, nous privilégions les logiciels fonctionnels à une documentation exhaustive. Il s’agit donc de trouver le bon équilibre en déterminant le volume de documentation idéal pour concevoir des systèmes fonctionnels.

De même, il est primordial de savoir s’il est question d’une interaction avec un système, d’une caractéristique ou d’un composant. Par exemple, dans le cadre d’une entreprise qui migre d’un ensemble d’applications maison de gestion et d’exécution des commandes vers un « package » prêt à l’emploi, il est fort probable que les utilisateurs finaux interagissent avec le système.

2ème question : « Comment allons-nous assurer le séquencement du backlog ? » Est-il préférable de se concentrer en priorité sur les User Stories  se fondant sur une architecture complexe ou incertaine, ou bien sur les scénarios fondamentaux dont dépendront naturellement de futurs User Stories ?

Généralement, le chef de produit est responsable de l’organisation de l’ensemble des Users Stories, souvent classées par ordre numérique selon un classement absolu qu’il doit pouvoir justifier. Dans certains cas, la valeur monétaire définit l’emplacement d’une User Story (par exemple, certains scénarios peuvent concerner une nouvelle caractéristique d’un produit susceptible d’attirer de nouveaux clients et ainsi accroître le chiffre d’affaires). Dans d’autres cas, les User Stories sont classées selon le nombre d’utilisateurs finaux ayant réclamé telle ou telle nouvelle caractéristique ou possibilité.

Cependant, les User Stories ETL se distinguent radicalement  de celles d’un projet de développement sur mesure. Au lieu de décrire la manière dont un acteur interagit avec une application logicielle, elles décrivent une routine d’extraction nécessitant de prélever des données d’un système source. Dans ce cas, le séquencement du backlog peut s’effectuer selon une chaîne d’héritage dans le modèle de données, les premières User stories peuvent donc concerner l’extraction et le chargement des clés principales ainsi que l’identification des entités autonomes telles que le client, l’emplacement et le produit.

En reprenant l’exemple de l’entreprise qui migre vers une solution prête à l’emploi, plutôt que d’effectuer un classement en fonction des avantages d’une caractéristique, il est probable que certains modules essentiels de la solution choisie doivent être préalablement configurés pour que d’autres éléments du progiciel de gestion intégré (PGI) puissent fonctionner. Par exemple, il est indispensable d’installer et de charger le module du produit avant de pouvoir installer et configurer les applications de saisie de commandes. Les user stories peuvent alors être organisées selon ces exigences et ressembler à un programme de chemin critique.

3ème question : « Comment seront réparties les tâches ? »

Est-il possible de partitionner les User Stories en ensemble de tâches que l’équipe Scrum (équipe chargée de la conception du projet) exécute dans un certain délai, appelé « Sprint », au terme duquel elle délivre une version du produit, « potentiellement livrable », pouvant être présentée chef produit ?

Ces tâches concernent la conception, le codage, le test unitaire, la création et l’intégration. Dans d’autres cas, les tâches peuvent même comprendre des activités de remaniement des données telles que l’extraction, la transformation ou le chargement. Il peut également s’agir de tâches pouvant être exécutées parallèlement à l’utilisation d’un outil 3GL ou CASE (outils de programmation à interface graphique) pour générer du code.

Dans le cas du développement d’une application sur mesure, diviser la User Story en une succession de tâches constitue une approche simple et directe ; les tâches telles que le codage et les tests unitaires, après acceptation et validation, peuvent être concentrées autour de la création de scénarios techniques.

Cependant, dans le cas d’une entreprise qui migre vers un package prêt à l’emploi concernant le partitionnement de l’expérience, une grande partie du travail exécuté est davantage axée sur la configuration que sur le développement logiciel. Cela signifie que la User Story  est davantage en accord avec le type de travail technique qui est exécuté, celui-ci étant partitionné en tâches telles que « la configuration de la hiérarchisation » ou « la personnalisation des règles commerciales ».

4ème question : « Qu’entendons-nous par "achevé" ? »

Autrement dit, comment savoir que le projet est potentiellement livrable ? Des quatre questions, celle-ci est probablement la plus importante à prendre en considération, étant donné qu’elle implique de nombreux débats sur la manière de vérifier ce que nous livrons, que l’on mette en place un développement piloté par les tests, ou que l’on crée  une équipe de contrôle indépendante en aval de l’équipe Scrum pour garantir la qualité du produit issu des Sprint, avant livraison finale au client.

Chaque projet est différent et les indicateurs prouvant qu’un projet est fini sont à définir  au cas par cas par le chef de projet. Dans la plupart des cas, l’aboutissement du projet impliquera la réalisation de la User Story décrite au démarrage du projet, à partir d’objectifs fonctionnels, par exemple  permettre à un utilisateur final d’exécuter une tâche commerciale, telle que la saisie d’une commande. Pour reprendre l’exemple du logiciel bancaire précédemment évoqué, si les clients accèdent aux opérations effectuées sur leur compte bancaire lors des trente derniers jours, cela signifie que le projet est terminé comme initialement prévu.

Pour déterminer qu’un projet est achevé, il peut être utile d’envisager deux niveaux d’aboutissement différents. Nombreux sont ceux qui s’accordent à dire que le projet est abouti lorsque 80 % ou plus des données commerciales s’écoulent proprement vers les magasins de données, cet ensemble inabouti pouvant néanmoins être utilisé pour prendre des décisions relativement fiables en matière de marketing produit. Ensuite, lorsque la qualité des données atteint le niveau le plus élevé, il s’agit de se rapprocher le plus possible d’un niveau de qualité de 99 à 100 %, correspondant au second niveau d’aboutissement.

S’il s’avère facile de répondre à ces questions, une méthode Agile contribuera certainement au succès du projet. Cependant, d’autres éléments, tels que la formation, la maturité, l’adaptation organisationnelle et culturelle ainsi que la disponibilité des ressources doivent également être pris en compte et peuvent influencer le résultat du projet.

Notre entreprise, Cognizant, a par exemple été missionnée pour mettre au point un tout nouveau portail client. Voici comment  nous avons répondu aux quatre questions:

Au démarrage, nos User Stories étaient de très longs textes décrivant la manière dont un utilisateur se servait d’une page ou d’un script sur l’ensemble du portail client. Nous sommes progressivement arrivés à la conclusion que nos User Stories étaient bien trop fournies, par rapport à ce dont avait besoin les développeurs pour répondre aux fonctionnalités voulues par le chef de produit. Nous avons donc amélioré notre procédé et sommes revenus à une User Story plus traditionnelle, susceptible d’être synthétisée en une simple fiche.

L’essentiel du projet était la réécriture complète du portail existant. Notre chef produit ne cherchait pas nécessairement à ce que notre travail porte sur de nouvelles caractéristiques. Nous avons donc travaillé avec le client pour donner une priorité à nos  User Stories selon un ordre logique privilégiant les scenarios fondamentaux à la conception des principaux éléments des pages du portail, auxquels se sont ensuite ajoutés d’autres User Stories.

Nous avons ensuite partitionné nos User Stories en fonction des principales tâches techniques requises par nos équipes Scrum transversales afin de transformer la User Story en fonction du texte à l’origine de la vision de notre chef de produit. Dans notre cas, les tâches techniques de développement ont été assurées par des développeurs Java, les tâches relatives au portail ont été réalisées à l’aide d’outils WebSphere, les tâches liées à l’interface utilisateur ont été prises en charge par des ingénieurs en ergonomie et les tâches de gestion du contenu ont été réalisées par Interwoven.

La User Story a finalement été achevée, après acceptation du chef de produit, validation des critères d’acceptation grâce à des tests, et soumission de la documentation relative aux résultats des tests et établissement, par l’équipe en charge du contenu, d’un catalogue reprenant le contenu nécessaire à la User Story, dans un outil de gestion de contenu.

Si vous avez du mal à répondre à ces quatre questions, peut-être que votre projet n’est pas encore prêt à adopter une méthode Agile. Pourtant, la plupart des entreprises devraient envisager les méthodes Agiles comme une solution de développement viable. Même si votre projet n’est peut-être pas encore prêt pour la méthode Agile, son déploiement pourrait bien constituer la clé du succès futur de ce projet.

Dan Fuller, Directeur Associé du Centre d’Excellence Agile chez Cognizant