Définir les spécifications de façon agile

Le développement agile est une révolution qui a renversé la règle du processus en cascade ou en V. Comme toute révolution, ses partisans estiment que la meilleure chose à faire est d’aller complètement à l’encontre des anciennes méthodes. Dans le monde d’Agile, l’action est plus importante que le processus, et les spécifications et la documentation font plus de mal que de bien. S’appuyant sur la méthode Agile, les organisations estiment qu’elles devraient d’abord écrire du code et faire face aux conséquences plus tard, comme si la vitesse et la productivité étaient interchangeables.

Au fil du temps, de nombreux révolutionnaires ont commencé à revoir leurs hypothèses et à réaliser que l’ancien monde n’était peut-être pas parfait mais que leurs prédécesseurs avaient quelque chose à leur apporter dans certains domaines. À la lumière de cette prise de conscience, les adeptes d’Agile et de DevOps ont peu à peu compris que les spécifications et la documentation des projets restaient un aspect essentiel du processus de développement.

Cet article présente des directives qui vous permettront de créer des spécifications utiles et une documentation pertinente. En combinant les approches shift left, de collaboration (Three Amigos) et d’échec rapide, vous pourrez définir des spécifications moins rigides le plus tôt possible dans le processus et les combiner avec des outils et pratiques itératives modernes.

 

Comprendre la méthodologie en cascade

Aux yeux des adeptes d’Agile et de DevOps, la méthode en cascade ressemble aux derniers jours des monarchies française et russe. Il fut une époque, heureusement révolue, où l’on ne pouvait pas écrire de code sans suivre un processus rigide et complexe qui prenait beaucoup de temps et se soldait fréquemment par un échec. Pour comprendre pourquoi ce modèle est tant détesté aujourd’hui, examinons-le d’un peu plus près.

Le processus en cascade est souvent appelé « modèle du cycle en V ». Dans ce modèle, le processus de programmation est décomposé en étapes :

• Découverte
• Spécifications
• Ingénierie système
• Architecture

Toutes les étapes doivent être effectuées dans l’ordre, et on ne peut pas commencer l’étape suivante avant d’avoir achevé l’étape en cours. Ces étapes représentent le côté gauche du V et sont effectuées de haut en bas.

Une fois la phase de programmation achevée, on procède à une nouvelle série d’étapes de tests :

• Test unitaire
• Test d’intégration du sous-système
• Test d’intégration
• Test système
• Test d’acceptation
• Test fonctionnel

Cette approche comportait un certain nombre de problèmes. Pour commencer, pour réussir un projet en utilisant le modèle du cycle en V, il fallait abattre autant de travail que possible à l’avance et respecter au plus près les décisions prises lors des premières étapes d’un projet. Par conséquent, après avoir terminé l’ensemble des recherches nécessaires à l’étape de découverte, on rédigeait des spécifications détaillées et on créait un concept qui respectait rigoureusement ces spécifications.

Pour gagner du temps, on ne testait les spécifications et le concept que peu de temps avant la fin du processus de développement. Et pour couronner le tout, lorsque survenaient des problèmes qui venaient contredire les spécifications d’origine ou les hypothèses sur lesquelles elles reposaient, on ne les traitait pas avant l’étape de test. Ces problèmes traités en différé refaisaient généralement surface aux étapes d’intégration du sous-système et du système, donnant lieu à des échecs d’intégration monumentaux. Le projet se soldait par un raz-de-marée de dette technique qui submergeait les ressources disponibles et menait souvent à la fin prématurée du projet.

Résoudre les problèmes de la méthodologie en cascade grâce au shift left

Résoudre les problèmes du modèle en cascade/V nécessite d’adopter une approche préventive qui porte sur le processus (shift left), la collaboration (Three Amigos) et la mise en œuvre (fail fast soit « échec rapide »).

 

Tester au plus tôt (shift left)

Les tests logiciels reposant sur l’approche shift left déplacent les tâches normalement accomplies aux dernières étapes du développement pour les placer le plus tôt possible dans le processus. En d’autres termes, ils font passer ces étapes du côté droit du V au côté gauche. Il existe quatre types de tests shift left : traditionnels, incrémentaux, agiles/DevOps et basés sur un modèle. Cette approche se concentre sur la structuration des spécifications qui doit permettre de souligner la valeur qu’elles présentent pour les utilisateurs finaux et/ou sur les correspondances entre les spécifications et les fonctionnalités de l’application.

• Lorsque les tests logiciels reposent sur l’approche shift left, la plupart des tests d’un projet sont effectués dès les étapes des tests unitaire et d’intégration, et non aux étapes de tests système et d’acceptation qui se déroulent plus tard.
• Les tests logiciels incrémentaux reposant sur l’approche shift left consistent à décomposer un projet en plus petites étapes incrémentales et à effectuer des tests à chacune de ces étapes.
• Les tests logiciels agiles/DevOps reposant sur l’approche shift left consistent à créer un certain nombre de courtes itérations qui comportent leurs propres tests. On peut considérer ces itérations comme un groupe de processus en V individuels. Ce modèle est fortement influencé par les pratiques agiles comme le développement piloté par les tests (TDD).
• Les tests logiciels reposant sur l’approche shift left et basés sur un modèle consistent à créer un modèle de test avant d’écrire le moindre code.

 

Three Amigos

Cette approche promeut la collaboration entre les trois composantes principales d’une organisation de développement : la société elle-même représentée par ses parties prenantes, ses analystes métier, et enfin les responsables produits, développeurs et testeurs. En se rassemblant pour discuter des projets le plus tôt possible, ces « trois amigos » créent un climat de confiance et développent une compréhension commune du projet sur lequel ils travaillent. En collaborant, ils définissent les scénarios utilisateur du projet qui mettent en œuvre ses fonctionnalités et gèrent les tâches de mise en œuvre en souffrance. Ensemble, les Three Amigos définissent les critères qui permettront de déclarer que le projet est terminé.

 

L’échec rapide

Cette approche gère les aspects relatifs à la mise en œuvre d’un projet. Dans ce modèle, les développeurs emploient la pratique du développement piloté par les tests pour écrire des tests avant d’écrire le moindre code. Le code est stocké dans des référentiels communs avec gestion de versions à partir desquels tout développeur impliqué dans le projet peut y accéder. L’échec rapide promeut également l’utilisation de systèmes d’intégration, de livraison et de déploiement continus qui peuvent rapidement créer et déployer du code. Ces systèmes sont déclenchés lorsqu’un développeur valide son code dans un système de gestion des codes source, exécute des tests automatisés pour s’assurer que son code fonctionnera en production, crée une nouvelle version de l’application, puis la publie et la déploie immédiatement. Lorsque de nouvelles versions d’un logiciel sont livrées fréquemment aux utilisateurs finaux, une boucle de feedback se met en place, grâce à laquelle les développeurs peuvent prévenir l’équipe de développement dès qu’un utilisateur trouve un défaut. De cette façon, ils peuvent corriger le code et le remettre rapidement entre les mains des utilisateurs.

 

Spécifications et documentation : les pièces manquantes

Il ne suffit pas de mettre en œuvre les approches shift left, Three Amigos et d’échec rapide : il faut toujours prendre en charge la documentation et les spécifications. Comme nous l’avons vu, la gestion des spécifications a mauvaise réputation à cause de son association avec le modèle en cascade. Au lieu d’écrire des spécifications détaillées, la pratique agile consistant à écrire des scénarios utilisateur a été adoptée. Un scénario utilisateur tient en une phrase et une tâche que l’utilisateur souhaite accomplir. Contrairement aux spécifications traditionnelles, les scénarios utilisateur ne traitent qu’un nombre limité d’hypothèses et de résultats, et pour couronner le tout, les pratiques agiles placent l’écriture du code bien au-dessus de l’écriture de toute forme de documentation. La documentation est souvent perçue comme une étape inutile qui, quelle qu’en soit la qualité, n’est jamais mise à jour et est rapidement dépassée. De nombreux développeurs agiles considèrent ainsi les scénarios utilisateur comme la seule documentation nécessaire à un projet.

En appliquant les approches shift left, Three Amigos et d’échec rapide, l’écriture des spécifications et de la documentation du projet deviendra un aspect essentiel de notre nouveau monde agile/DevOps. Commencez par le shift left en plaçant les processus de spécifications et de documentation vers le début du projet. Une fois les brouillons de vos spécifications et documents initiaux rédigés, partagez-les avec les Three Amigos pour les faire examiner. Il est important d’écrire et de gérer vos spécifications dans un système qui facilite la collaboration en temps réel. De nombreuses sociétés écrivent et partagent encore leurs spécifications à l’aide de documents de traitement de texte et de feuilles de calcul, ce qui complique la consultation, la mise à jour, la maintenance et le suivi des spécifications. Mettre les spécifications à disposition des personnes concernées présentera d’importants avantages à long terme et vous aidera à obtenir rapidement des retours de haute qualité.

En mettant les spécifications et la documentation à disposition le plus tôt possible, vous pourrez repérer et corriger les hypothèses et spécifications erronées avant que vos développeurs n’aient écrit la moindre ligne de code. Si vous suivez les principes de l’échec rapide, vous constaterez une amélioration spectaculaire de l’ensemble du processus de développement. Vous remarquerez notamment une forte réduction du nombre d’itérations de test et de correction des défauts à effectuer avant le passage en production de votre logiciel.

 

Assembler tous ces éléments avec Panaya

L’un des meilleurs moyens de mettre en pratique l’ensemble des éléments abordés dans cet article est d’utiliser Panaya. La solution Release Dynamix [RDx] de Panaya permet une approche de la livraison agile en entreprise basée sur les principes du shift left. Release Dynamix [RDx] gère toutes les étapes du processus de développement, de sa création jusqu’au déploiement, et intègre une approche Three Amigos de la collaboration à l’échelle de l’entreprise. RDx vous permet également de gérer les spécifications et la documentation en continu et comprend de puissants outils d’analyse, de gestion des modifications et de suivi des problèmes.

Conclusion : passez à la vitesse supérieure avec ces trois approches

Comme de nombreuses révolutions, le développement agile était au début un mouvement marginal qui a fini par devenir un courant dominant. Dans l’ensemble, les modifications apportées par les mouvements Agile et DevOps ont entraîné une nette amélioration du processus de développement logiciel. Cependant, malgré quelques problèmes majeurs, les anciens modèles en cascade/V avaient également quelques mérites, notamment au niveau de leur approche de la gestion des spécifications et de la documentation.

En combinant les approches shift left, Three Amigos et d’échec rapide, vous pouvez grandement améliorer tout processus de développement. De plus, il peut être très utile aux pratiques agiles et DevOps modernes d’appliquer ces approches à des aspects comme la documentation et les spécifications. Écrivez les spécifications et la documentation le plus tôt possible et faîtes-les tester et examiner par l’ensemble des parties prenantes pour réduire le nombre d’interactions pré-publication, ce qui vous aidera également à publier des produits plus fiables.

Après avoir lu cet article, penchez-vous sur votre processus de développement actuel et essayez d’identifier les aspects à améliorer. Renseignez-vous sur les approches shift left, Three Amigos et d’échec rapide et réfléchissez à la manière dont elles peuvent vous aider. Trouvez un moyen d’employer ces approches pour améliorer vos processus actuels de gestion des spécifications et de la documentation, et déployez une solution intégrée comme Release Dynamix [RDx] de Panaya.