Modèles de Processus de Développement Logiciel : Une Exploration des Méthodologies Agile, Lean et XP
Alexandre Cuva
Dans le domaine de l'ingénierie logicielle, comprendre les divers processus de développement est essentiel pour tout artisan du logiciel. Ces processus définissent comment une équipe produit et livre un logiciel, s'inscrivant dans une théorie plus large de l'ingénierie logicielle connue sous le nom de modèle de processus de développement logiciel. Depuis la première définition du développement logiciel comme un processus d'ingénierie, de nombreux modèles ont été proposés. Cet article se penche d'abord sur les modèles traditionnels avant d'explorer les approches agiles désormais répandues.
Certains modèles issus de la théorie de l'ingénierie logicielle sont aujourd'hui considérés comme traditionnels, voire obsolètes. Bien que cet article n'ait pas pour but de les couvrir exhaustivement, nous nous concentrerons sur ceux encore utilisés dans certaines entreprises : les modèles en cascade et incrémental.
Le Modèle en Cascade : Principes et Limitations
Aborder le modèle en cascade en 2024 peut sembler anachronique. Pourtant, certaines entreprises s'y réfèrent encore comme guide principal de développement logiciel. Ce modèle exécute séquentiellement toutes les tâches fondamentales d'un projet de développement logiciel, qui se décompose en :
- Exigences : Création d'un document d'exigences produit, pierre angulaire du processus de développement.
- Conception : Développement de l'architecture logicielle en fonction des exigences.
- Implémentation : Programmation du logiciel.
- Vérification : Réalisation de tests au sein de l'application.
- Maintenance : Le cycle reprend après la livraison du logiciel.
L'utilisation du modèle en cascade peut entraîner des retards dans la livraison d'une version fonctionnelle du logiciel et une insatisfaction des utilisateurs due à l'écart entre les attentes et le produit final. De plus, démarrer les tests d'application uniquement après l'achèvement du développement est souvent source de stress ; la direction pousse fréquemment les équipes logicielles à travailler plus dur et plus longtemps pour atteindre des délais irréalisables.
Le Modèle Incrémental : Une Réponse aux Limites du Cascade
Le développement incrémental cherche à pallier le principal inconvénient du modèle en cascade : l'impossibilité pour l'utilisateur de tester la solution avant la fin du projet. Ce modèle vise à offrir aux utilisateurs la possibilité d'interagir avec la solution dès que possible, afin de fournir des retours utiles qui faciliteront le développement du logiciel.
Il consiste à appliquer un ensemble de pratiques de développement logiciel (communication, planification, modélisation, construction et déploiement) à chaque incrément. Bien qu'il ait atténué les problèmes liés au manque de communication avec le client, la gestion de projets de grande envergure reste complexe en raison de la longueur des incréments.
L'approche incrémentale, largement adoptée à la fin du dernier siècle, a soulevé de nombreux problèmes bureaucratiques liés à l'importante documentation requise. Cette situation a favorisé l'émergence d'un mouvement significatif dans l'industrie du développement logiciel : l'agilité.
Comprendre les modèles de processus de développement logiciel Agile
Au début de ce siècle, le développement de logiciels était considéré comme l'une des activités les plus chaotiques en ingénierie. Le taux d'échec des projets logiciels était incroyablement élevé, soulignant le besoin d'une approche différente pour gérer la flexibilité requise par les projets de développement logiciel.
Le Manifeste Agile a été introduit en 2001, et divers modèles de processus agiles ont été proposés depuis. Certains d'entre eux ont survécu jusqu'à aujourd'hui et sont encore très courants.
L'une des différences les plus significatives entre les modèles agiles et traditionnels réside dans la manière dont les développeurs interagissent avec le client. Le message derrière tous les modèles agiles est que plus vite vous livrez le logiciel à l'utilisateur, mieux c'est. Cette idée est parfois source de confusion pour les développeurs de logiciels qui l'interprètent comme suit : essayons simplement de coder, et c'est tout !
Cependant, il y a une observation critique du Manifeste Agile que beaucoup ne lisent pas lorsqu'ils commencent à travailler avec l'Agile :
Un architecte logiciel doit toujours se souvenir de cela. Les processus agiles ne signifient pas un manque de discipline. De plus, lorsque vous utilisez le processus agile, vous comprendrez rapidement qu'il est impossible de développer un bon logiciel sans discipline. D'autre part, en tant qu'architecte logiciel, vous devez comprendre que souplesse signifie flexibilité. Un projet logiciel qui refuse d'être flexible tend à se ruiner avec le temps.
Les 12 principes derrière l'agile sont fondamentaux pour cette approche flexible :
- La livraison continue de logiciels précieux pour satisfaire le client doit être la priorité la plus élevée de tout développeur.
- Les changements d'exigences doivent être une opportunité pour rendre le client plus compétitif.
- Utiliser une échelle de temps hebdomadaire pour livrer le logiciel.
- Une équipe logicielle doit être composée de personnes d'affaires et de développeurs.
- Une équipe logicielle a besoin d'être fiable et de disposer de l'environnement adéquat pour mener à bien le projet.
- La meilleure façon de communiquer avec une équipe logicielle est en face à face.
- La plus grande réalisation d'une équipe logicielle est visible lorsque le logiciel fonctionne en production.
- L'agile fonctionne correctement lorsqu'il permet un développement durable.
- Plus vous investissez dans des techniques et une conception solides, plus vous êtes agile.
- La simplicité est essentielle.
- Plus les équipes sont auto-organisées, meilleure est la qualité de la livraison.
- Les équipes logicielles tendent à améliorer leur comportement au fil du temps, en analysant et en ajustant leur processus.
Même 20 ans après le lancement du Manifeste Agile, son importance et sa connexion aux besoins actuels des équipes logicielles restent intactes. En effet, de nombreuses entreprises n'acceptent pas entièrement cette approche. Néanmoins, en tant qu'artisan du logiciel, vous devriez voir cela comme une opportunité de transformer les pratiques et d'évoluer avec l'équipe avec laquelle vous travaillez.
L'approche agile a présenté de nombreuses techniques et modèles à la communauté logicielle. Les sous-sections suivantes discuteront du développement logiciel Lean, de la programmation extrême et de Scrum, afin que vous, en tant qu'artisan du logiciel, puissiez décider lesquels utiliser pour améliorer la livraison de votre logiciel.
Développement Logiciel Lean
Après le Manifeste Agile, le développement logiciel Lean a été introduit dans la communauté comme une adaptation d'un mouvement bien connu en ingénierie automobile, le modèle de Toyota pour la construction de voitures. La méthode de fabrication Lean offre un haut niveau de qualité, même avec peu de ressources.
Mary et Tom Poppendieck ont défini sept principes Lean pour le développement logiciel, étroitement liés à l'agilité et à l'approche de nombreuses entreprises de ce siècle, qui sont énumérés ici :
- Éliminer le gaspillage : Le gaspillage peut être considéré comme tout ce qui interfère avec la capacité à répondre aux véritables besoins du client.
- Intégrer la qualité dès le départ : Une organisation qui souhaite garantir la qualité doit la promouvoir dans ses processus dès le début, plutôt que de ne la considérer que lors des tests de code.
- Créer du savoir : Toutes les entreprises ayant atteint l'excellence suivent un modèle typique de génération de nouvelles connaissances par l'expérimentation disciplinée, documentant ce savoir et garantissant sa diffusion dans toute l'organisation.
- Reporter l'engagement : Planifier les décisions au dernier moment possible sans nuire au projet.
- Livrer rapidement : Plus vous livrez le logiciel rapidement, plus vous éliminez de gaspillage. Les entreprises qui concurrencent sur la base de la fréquence de livraison ont un avantage significatif sur leurs concurrents.
- Respecter les personnes : Respecter les personnes avec lesquelles vous travaillez signifie donner des objectifs raisonnables à l'équipe et des plans qui les guideront pour s'auto-organiser dans leur routine.
- Optimiser l'ensemble : Une entreprise Lean améliore le cycle de valeur dès qu'elle reçoit une nouvelle exigence jusqu'au moment où elle livre le logiciel.
Suivre les principes Lean aide une équipe ou une entreprise à améliorer la qualité des fonctionnalités livrées au client. Cela réduit également le temps passé sur des fonctionnalités qui ne seront pas utilisées par le client. En Lean, le fait de décider des fonctionnalités importantes pour le client guide l'équipe dans la livraison d'un logiciel qui compte vraiment, et c'est exactement ce que le Manifeste Agile vise à promouvoir au sein des équipes logicielles.
L'adoption de ces principes Lean dans le développement logiciel non seulement améliore l'efficacité et la qualité des produits logiciels mais encourage également une culture de travail respectueuse et axée sur la valeur. En intégrant ces principes, les ingénieurs logiciels peuvent contribuer à la création de systèmes plus durables et plus adaptés aux besoins réels des utilisateurs, tout en optimisant les ressources disponibles. Cela représente une évolution significative dans la manière de concevoir et de développer des logiciels, s'éloignant des méthodes traditionnelles pour embrasser une approche plus agile et réactive face aux changements.
Programmation Extrême (XP)
Juste avant la publication du Manifeste Agile, certains des participants qui ont conçu le document, notamment Kent Beck, ont présenté au monde la méthodologie de développement logiciel appelée Programmation Extrême (XP).
XP repose sur la simplicité, la communication, le retour d'information, le respect et le courage. Selon Beck, dans son deuxième livre sur le sujet, elle a été considérée plus tard comme un changement social dans la programmation. Elle favorise certainement un changement considérable dans le flux de développement.
XP stipule que chaque équipe doit uniquement faire ce qui lui a été demandé, communiquer en face à face quotidiennement, montrer le logiciel tôt pour obtenir des retours, respecter l'expertise de chaque membre de l'équipe et avoir le courage de dire la vérité sur les progrès et les estimations, en considérant le travail de l'équipe dans son ensemble.
XP propose également un ensemble de règles. L'équipe peut modifier ces règles si elle détecte que quelque chose ne fonctionne pas correctement, mais il est important de toujours maintenir les valeurs de la méthodologie.
Ces règles sont divisées en planification, gestion, conception, codage et test. Don Wells a cartographié XP sur http://www.extremeprogramming.org/. Bien que certaines idées de la méthodologie aient été critiquées par de nombreuses entreprises et spécialistes, de nombreuses bonnes pratiques sont encore utilisées aujourd'hui :
- Rédaction des exigences logicielles à l'aide de User Story : Les user stories sont considérées comme une approche agile pour décrire les besoins des utilisateurs. Associées aux critères d'acceptation, elles garantissent la mise en œuvre correcte.
- Diviser le logiciel en itérations et livrer de petites versions : L'itération est une pratique de développement logiciel mise en œuvre par toutes les méthodologies à l'exception du modèle en cascade. Livrer des versions plus rapidement diminue le risque de ne pas répondre aux attentes des clients.
- Éviter les heures supplémentaires et garantir une vitesse de développement durable : Bien que cela puisse être l'une des tâches les plus complexes auxquelles un artisan du logiciel peut être confronté, les heures supplémentaires indiquent que quelque chose ne fonctionne pas correctement.
- Garder les choses simples : Lors du développement de solutions, il est assez courant d'anticiper les fonctionnalités que le client souhaiterait avoir. Cette approche augmente la complexité du développement et le temps de mise sur le marché de la solution. Une approche différente entraînera des coûts élevés et probablement un faible niveau de fonctionnalités utilisées dans votre système en développement.
- Refactoring : Le refactoring continu du code est bénéfique car il permet l'évolution de votre logiciel et garantit l'amélioration de la conception qui sera certainement nécessaire en raison des changements techniques habituels des plateformes que vous utilisez pour développer.
- Garder le client toujours disponible : Si vous suivez XP, vous devriez avoir un expert de domaine au sein de votre équipe. Cela peut être difficile à réaliser, mais l'idée principale de cette approche est de garantir que le client est impliqué dans toutes les parties du développement. En bonus, avoir le client proche de votre équipe signifie qu'ils comprennent les difficultés et l'expertise de l'équipe, permettant une augmentation de la confiance entre les parties. Cette pratique est également représentée dans le Domain-Driven Design par Eric Evans.
- Intégration continue : Cette pratique est l'une des bases de l'approche DevOps actuelle. Moins vous avez de différences entre vos dépôts de code personnels et centraux, mieux c'est.
- Coder le test unitaire en premier : Un test unitaire est une approche où vous programmez un code spécifique pour tester l'intention unique de votre projet. Cela est discuté dans une méthodologie de développement actuelle appelée Développement Piloté par les Tests (TDD). L'objectif principal est de garantir que chaque règle métier ait son propre cas de test unitaire.
- Le code doit être écrit selon des normes convenues : La nécessité de déterminer des normes pour le codage est liée à l'idée que, quel que soit le développeur travaillant sur une partie spécifique du projet, le code doit être écrit de manière à ce que tous puissent le comprendre.
- Programmation en binôme : La programmation en binôme est une autre approche complexe qui exige chaque minute d'un projet logiciel, mais la technique elle-même - un programmeur codant et l'autre observant activement et offrant des commentaires, des critiques et des conseils - est utile dans des scénarios critiques.
- Tests d'acceptation : Adopter des tests d'acceptation pour répondre aux user stories est un excellent moyen de garantir que le logiciel nouvellement publié ne nuit pas à ses besoins actuels. Une option encore meilleure est d'avoir ces tests d'acceptation automatisés.
Il convient de mentionner que nombre de ces règles sont aujourd'hui considérées comme des pratiques vitales dans différentes méthodologies de développement logiciel, y compris DevOps et Scrum.
Introduction au Modèle Scrum
Scrum est un modèle agile pour la gestion des produits de développement logiciel. Il repose sur les principes du Lean et constitue l'une des approches les plus largement utilisées dans le développement logiciel actuel.
Il est prévu d'appliquer Scrum avec une autre technique agile appelée Kanban, également développée par Toyota pour la fabrication de voitures et couramment utilisée pour la maintenance logicielle. Le but principal du Kanban est de permettre un système visuel pour assurer que tout le monde comprend ce qui se passe dans le produit en cours de développement. Le célèbre tableau Kanban est un moyen incroyable de le faire, où vous définissez ce que l'équipe doit faire, ce qu'elle est en train de faire et les choses qui sont déjà terminées.
Il est important de noter que le processus Scrum ne discute pas de la manière dont le logiciel doit être implémenté ou des activités qui seront réalisées. Encore une fois, il serait utile de se rappeler les bases du développement logiciel, abordées au début de ce chapitre ; Scrum doit être mis en œuvre conjointement avec un modèle de processus. DevOps est une approche qui peut vous aider à utiliser un modèle de processus de développement logiciel conjointement avec Scrum.
Étendre l'agilité à travers une entreprise
Aujourd'hui, il est assez courant de trouver des entreprises où l'agilité est pratiquée et évolue bien, compte tenu des résultats des techniques présentées dans les sections précédentes. La combinaison de Scrum, Kanban et XP, avec l'évolution de la maturité du processus de développement logiciel, a apporté de bons résultats pour les entreprises, et nous vivons dans un monde où le développement logiciel est l'une des stratégies clés pour le succès d'une entreprise.
Certaines entreprises ont naturellement besoin d'augmenter le nombre d'équipes, mais la question critique dans ce processus est de savoir comment évoluer sans perdre en agilité. Vous pouvez être sûr que cette question peut être abordée par vous en tant qu'artisan du logiciel.
Basé sur les valeurs fondamentales d'alignement, de qualité intégrée, de transparence et d'exécution de programme, le cadre fournit un chemin détaillé pour livrer des produits avec l'agilité nécessaire dans les entreprises où vous avez un ou plusieurs flux de valeur. Ses principes permettent l'agilité et la livraison incrémentielle, la pensée systémique, des décisions rapides et économiques, et principalement, l'organisation autour de la valeur.
Mais en tant qu'artisan du logiciel, comprendre comment étendre une entreprise peut être une bonne connaissance à avoir dans votre boîte à outils ! Maintenant que vous le savez, revenons aux étapes de conception d'un logiciel de haute qualité, en discutant de la manière de rassembler les informations correctes pour le créer.
Dans le prochain post, nous discuterons de la collecte des besoins métier.
