Dans les chapitres précédents, nous avons établi les bases de ce que nous voulons modifier dans notre architecture. La prochaine étape est de déterminer dans quel ordre nous travaillerons sur les changements.
Priorisez les user stories
Si je regarde dans mon garage et que je vois des cartons pleins d'affaires à trier et à ranger, cela risque de me décourager. Comment savoir par où commencer ?
La même chose se produit avec notre refonte de logiciel — il y a beaucoup de travail à faire. Si nous essayons de tout accomplir en même temps, nous allons nous retrouver débordés et nous prendrons des risques. Nous devons trouver une manière de prioriser le travail.
N’oubliez pas, nous voulons partir de ceci :
Pour arriver à un résultat avec des couches séparées, comme ceci :
Heureusement, nous pouvons adopter des approches qui ont fait leurs preuves pour prioriser notre travail ! Commençons par les approches “commerciales”. Nous avons deux formules, mais leurs bases sont les mêmes :
Priorisez grâce au retour sur investissement
Voyons tout d’abord le retour sur investissement. On calcule le montant estimé du revenu généré ou des dépenses évitées, et on le divise par le coût de mise en place de la fonctionnalité. La solution qui propose le plus d’argent pour le moindre coût de développement gagne.
Comment savoir quel montant utiliser dans l’équation ?
Ici, vous devrez connaître le coût moyen d’une journée de prestation de l’équipe de développeurs !
Et il n’y a pas de garantie que les chiffres soient totalement exacts. On établit la meilleure estimation possible.
Priorisez par “Weighted Shortest Job First”
Deuxièmement, nous avons la technique de la “tâche la plus courte et la moins coûteuse d’abord" (ou WSJF, pour "weighted shortest job first" en anglais). Comme pour le Retour sur Investissement, on calcule les montants impliqués.
Quelle est la différence avec cette approche ?
La tâche la plus rapide à finir est celle qui génère le plus d’argent.
Ensuite, nous avons des techniques qui sont orientées sur le développement :
Priorisez par nécessité technique
Nous pouvons appliquer une autre option : l’évaluation technique. Quelles stories nécessitent le plus de réécriture ? Laquelle nous permet de mettre en place plus rapidement une meilleure architecture ?
Il pourrait être plus logique de travailler sur des éléments purement architecturaux, afin que toutes les stories suivantes soient plus faciles à mettre en place.
Priorisez par dépendance
Dans mon exemple de garage, certaines cartons sont empilées sur d’autres cartons. Il existe une dépendance naturelle : je dois commencer par les cartons du dessus et descendre à partir de là.
Encore une fois, cela fonctionne de la même façon pour notre logiciel. Certaines user stories ont des choses en commun. Il faut donc commencer par celle qui établit les fondamentaux. Nous choisissons donc celle qui a le plus de dépendances, qui déblaiera le chemin pour les autres stories à compléter.
Dans notre application de compagnie aérienne, de nombreux secteurs ont des dépendances. Nous ne pouvons pas tout changer en une seule fois, mais en classant attentivement nos user stories, nous pouvons construire chacun de ces composants, un par un. Les stories que nous traitons en dernier lieu doivent être faciles à mettre en place, car nous aurons construit les bases pour toutes ces dépendances.
Quelle option choisir ?
Étant donné que notre objectif dans ce cours est de modifier l’architecture, nous utiliserons la nécessité technique comme logique de priorisation. Nous modifierons l’application pour introduire les quatre user stories que nous avons vues précédemment :
En tant qu’opérateur d’agence de voyage, je veux réserver un vol pouvant transporter jusqu’à 12 personnes, pour qu’elles puissent découvrir un lieu unique.
En tant que pilote, je veux saisir tout problème de maintenance mineur dès l’atterrissage, pour qu’il puisse être réparé rapidement.
En tant que mécanicien en charge de la maintenance de l’avion, je veux mettre à jour tout problème de maintenance dès qu’il a été traité, pour que l’avion puisse être considéré comme apte à voler.
En tant que responsable financier, je veux voir une liste des clients qui nous doivent de l’argent, afin de pouvoir leur faire un rappel téléphonique.
À vous de jouer !
Essayez par vous-même
Et maintenant, sur la base de notre diagramme ci-dessus, de quelle user story vous occuperiez-vous en premier ? Demandez-vous :
Quels éléments techniques sont requis ?
Quels éléments techniques elles ont en commun ?
Quels éléments techniques existent déjà dans le code ?
Une fois que vous pensez avoir trouvé une solution, vous pouvez regarder ma réponse :
Réponse
Étant donné que ces stories introduisent toutes un accès à l’application via un front end web, nous commencerons par introduire la couche de vue. Puis, nous extrairons la couche de données.
Actuellement, nous avons une classe de réservation existante. Elle souffre également de la communication avec les classes SQLite et Java Swing. Vu que l’opérateur d’agence de voyage ajoutera et modifiera des réservations, nous commencerons par cette story, car elle touche à tous les aspects dont nous voulons revoir l’architecture.
Une fois que notre classe de réservation est mise à jour correctement, nous pouvons utiliser ces connaissances pour introduire une nouvelle classe qui gère les problèmes de maintenance pour les deux autres user stories. Et nous verrons que le fait d’obtenir la liste des clients ayant des impayés sera facile à refactoriser au bon endroit une fois la couche de données établie.
En résumé
Il existe de nombreuses stratégies de priorisation :
Commerciales :
Retour sur investissement (le plus gros montant de revenu généré ou d’économies réalisées pour le plus petit montant de coûts de développement).
La tâche la plus courte et la moins coûteuse d’abord (mettre en place de petites fonctionnalités rapidement).
Orientées développement :
Nécessité technique.
Dépendances entre stories.
Maintenant que nous savons par quelles stories nous allons commencer, nous sommes prêts à entamer la refactorisation. Avant de vous lancer, n’oubliez pas de répondre au quiz pour tester vos connaissances. Puis, rejoignez-moi en partie 2 pour voir comment refactoriser une application.
