Mis à jours 20 mars 2022 Les entreprises ont besoin de compétences en matière de logiciels pour offrir de bonnes expériences numériques. Le développement agile est le moyen pour les entreprises d’y arriver,
Chaque entreprise de développement logiciel semble aujourd’hui pratiquer la méthodologie de développement logiciel agile, ou une version de celui-ci. Ou du moins ces entreprises croient qu’elles le font. Que vous soyez débutant dans le développement d’applications ou que vous ayez appris le développement de logiciels il y a des décennies en utilisant la méthodologie de développement de logiciels Waterfall, votre travail est aujourd’hui au moins influencé par la méthodologie agile.
Mais, quelle est exactement la méthodologie agile ? Et comment devrait-on la pratiquer dans le développement de logiciels ?
Agile a été officiellement lancé en 2001 lorsque 17 technologues ont rédigé le Manifeste Agile. Ils ont écrit quatre grands principes pour développer des meilleurs logiciels :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
Avant agile : L’ère de la méthodologie de Waterfall
Les vieux développeurs se souviennent des jours où la méthodologie Waterfall était la norme d’excellence pour le développement de logiciel. Le processus de développement de logiciel a exigé une tonne de documentation avant que tout le codage ait été fait. Quelqu’un a d’abord rédigé un document sur les besoins de l’entreprise qui a capturé tout ce dont l’entreprise avait besoin dans l’application. Ces documents étaient longs, détaillant tout : les spécifications fonctionnelles et complètes de la stratégie, et les conceptions de l’interface utilisateur visuelle.
Cette documentation a été ensuite suivie d’une certaine forme de spécification technique qui documentait l’architecture de l’application, les structures de données, les conceptions fonctionnelles orientées objet, les interfaces utilisateur et d’autres exigences non fonctionnelles.
Ce processus de développement de logiciel Waterfall lancerait enfin le codage, puis l’intégration, et enfin le test avant qu’une application ne soit considérée comme prête pour la production. L’ensemble du processus pourrait facilement prendre quelques années.
Nous, les développeurs, étions censés connaître « la spécification », comme toute la documentation a été appelée, tout comme les auteurs des documents, et nous avons été souvent réprimandés si nous avions oublié d’implémenter correctement un détail clé décrit à la page 77 d’un document de 200 pages.
Le développement de logiciel lui-même n’était pas facile non plus à l’époque. Il y avait de nombreux outils de développement qui nécessitaient une formation spécialisée, et il n’existait pas d’outils logiciels, d’API et de services Web à code source ouvert ou commercial. Nous avons dû développer les choses de bas niveau telles que l’ouverture des connexions de base de données et le multithreading (exécution des threads en même temps) de notre traitement de données.
Pour les applications de base, les équipes étaient grandes et les outils de communication étaient limités. Les spécifications techniques étaient ce qui nous, anciens développeurs, a alignés, et nous les avons exploités comme la Bible. Si une exigence changeait, nous soumettrions les chefs d’entreprise à un long processus d’examen et de signature, car la communication des changements au sein de l’équipe et la correction du code coûtaient cher.
Parce que le logiciel a été développé sur la base de l’architecture technique, les artefacts de niveau inférieur ont été développés en premier et les artefacts dépendants par la suite. Les tâches étaient attribuées par compétence et il était courant que les ingénieurs de base de données construisent d’abord les tables et autres artefacts de base de données, puis les développeurs d’applications codant la fonctionnalité et la logique métier, puis l’interface utilisateur. Il a fallu des mois avant que quiconque ne voit l’application fonctionner et à ce moment-là, les intervenants devenaient anxieux et souvent plus intelligents sur ce qu’ils voulaient vraiment. Pas étonnant que les changements étaient si chers !
Tout ce que vous avez mis devant les utilisateurs ne doit pas forcément fonctionner comme prévu. Parfois, les utilisateurs n’utiliseraient aucune fonctionnalité, de sorte que cette fonctionnalité était un investissement inutile. D’autres fois, une fonctionnalité était largement couronnée de succès, mais nécessitait une réingénierie pour prendre en charge l’évolutivité et les performances requises. Dans le monde de Waterfall, vous n’avez appris ces choses qu’après le déploiement du logiciel, après tous ces efforts et dépenses.
Le pivot du développement de logiciel agile
Inventée en 1970, la méthodologie de Waterfall était révolutionnaire parce qu’elle permettait de discipliner le développement de logiciels pour s’assurer qu’il y avait une spécification claire à suivre. Elle était basée sur la méthode de fabrication Waterfall dérivée des innovations de la chaîne d’assemblage de 1913 de Henry Ford, qui fournissait la certitude que chaque étape du processus de production pour garantir le produit final était ce qui était spécifiée en premier lieu.
Lorsque la méthodologie de Waterfall est apparue au logiciel, les systèmes informatiques et leurs applications étaient généralement complexes et volumineux, ce qui nécessitait une discipline et un résultat clair. Les choses ont également changé lentement, si les efforts à grande échelle ne leur ont pas posé de problèmes comme ils le sont aujourd’hui. En fait, les systèmes ont été construits dans l’hypothèse qu’ils ne changeraient pas. Les calendriers pluriannuels étaient courants non seulement dans le développement de logiciels, mais aussi dans la fabrication et dans d’autres activités de l’entreprise. Mais, la rigidité de Waterfall est devenue un Achilles à l’ère d’Internet, où la vitesse et la flexibilité étaient exigées.
La méthodologie de Waterfall a commencé à changer lorsque les développeurs ont commencé à travailler sur des applications Internet. Une grande partie des premiers travaux ont été réalisés dans des startups où les équipes étaient plus petites, étaient colocalisées et n’avaient souvent pas de formation en informatique traditionnelle. Des pressions financières et concurrentielles ont été exercées pour commercialiser plus rapidement les sites Web, les applications et les nouvelles capacités. La technologie de développement et les plates-formes ont changé rapidement en réponse.
Cela a amené beaucoup d’entre nous à travailler dans des start-up pour remettre en question les processus de développement traditionnels et chercher des moyens d’être plus efficaces. Nous ne pouvions pas nous permettre de faire toute la documentation détaillée. Nous avons toujours débattu des modifications à apporter aux exigences, mais nos organisations étaient moins structurées et nos applications n’étaient pas aussi complexes que les systèmes hérités d’entreprise. Nous avons donc souvent soutenu le fait de les faire plutôt que de les acheter. Plus important encore, nous essayions de développer les entreprises, alors quand nos utilisateurs nous disaient que quelque chose ne fonctionnait pas, nous choisissions le plus souvent de les écouter.
Nos compétences et nos capacités d’innovation sont devenues stratégiquement importantes. Vous pouviez gagner tout l’argent que vous vouliez, mais vous ne pouviez pas attirer de talentueux développeurs de logiciels capables de travailler avec des technologies Internet en évolution rapide si vous les traitiez comme des programmeurs serviles qui suivaient servilement les « spécifications ». Nous avons rejeté les responsables de projet qui arrivaient avec des plannings de bout en bout décrivant ce que nous devions développer, quand les applications devraient être envoyées, et parfois même comment structurer le code. Nous avons horreurs de devoir accepter les calendriers de trois et six mois qu’ils ont rédigés et mis à jour sans cesse.
Par contre, nous avons commencé à leur dire comment les applications Internet devaient être conçues, et nous avons fourni des résultats selon un calendrier que nous avons établi de manière itérative. Il s’est avéré que nous n’avions pas si mal à livrer ce que nous disions que nous ferions lorsque nous nous y engagions en petites périodes d’une à quatre semaines.
En 2001, un groupe de développeurs de logiciels expérimentés se sont réunis et ont réalisé qu’ils pratiquaient collectivement le développement de logiciels différemment de la méthodologie classique de Waterfall. Et ils n’étaient pas tous dans les startups. Ce groupe a élaboré le Manifeste Agile qui documente leurs croyances communes sur la façon dont un processus de développement de logiciel moderne devrait fonctionner. Ils ont mis l’accent sur la collaboration plutôt que sur la documentation, l’auto-organisation plutôt que sur des pratiques de gestion rigides, et la capacité à gérer un changement constant plutôt que de s’enfermer dans un processus de développement rigoureux.
La méthodologie agile pour le développement de logiciels est née de ces principes.
Les rôles dans la méthodologie agile
Un processus de développement logiciel agile commence toujours par définir les utilisateurs et documenter une déclaration de vision sur l’étendue des problèmes, des opportunités et des valeurs à traiter. Le propriétaire du produit saisit cette vision et travaille avec une équipe multidisciplinaire (ou des équipes) pour réaliser cette vision. Voici les rôles dans ce processus.
L’utilisateur
Les processus agiles commencent toujours par l’utilisateur ou le client. Aujourd’hui, nous les définissons souvent avec des personas d’utilisateur pour illustrer différents rôles dans un workflow supporté par le logiciel ou différents types de besoins et de comportements des clients.
Le propriétaire du produit
Le processus de développement agile lui-même commence par quelqu’un qui doit être la voix du client, y compris les parties prenantes internes. Cette personne distille tous les points de vue, les idées et les commentaires pour créer une vision de produit. Ces visions sont souvent simples et courtes, mais elles donnent néanmoins une image de qui est le client, quelles valeurs sont abordées et une stratégie sur comment les aborder. La vision originale de Google ressemblait à quelque chose comme « Permettre à quiconque ayant accès à Internet de trouver des sites Web et des pages Web pertinents avec une interface simple axée sur les mots clés et un algorithme qui classe les sources fiables dans les résultats de recherche. »
Nous appelons cette personne le propriétaire du produit. Sa responsabilité est de définir cette vision et ensuite de travailler avec une équipe de développement pour la concrétiser.
Pour travailler avec l’équipe de développement, le propriétaire du produit décompose la vision en une série d’user stories expliquant plus en détail qui est l’utilisateur cible, quel problème est résolu pour eux, pourquoi c’est important pour eux, et quelles contraintes et critères d’acceptation définissent la solution. Ces histoires d’utilisateur sont priorisées par le propriétaire du produit, examinées par l’équipe pour s’assurer qu’ils ont une compréhension partagée de ce qui leur est demandé.
L’équipe de développement logiciel
En agile, l’équipe de développement et les responsabilités de ses membres diffèrent de celles du développement de logiciels traditionnels.
Les équipes sont multidisciplinaires, composées d’un groupe diversifié de personnes ayant les compétences pour faire le travail. Parce que l’accent est mis sur la fourniture de logiciels de travail, l’équipe doit terminer la création des applications opérationnelles de bout en bout. Ainsi, la base de données, la logique métier et l’interface utilisateur d’une partie de l’application – pas toute l’application – sont développées, pour ensuite démontrées. Pour ce faire, les membres de l’équipe doivent collaborer sur quoi et comment ils vont développer. Pour ce faire, ils se rencontrent fréquemment pour s’assurer que tout le monde est aligné sur qui fait quoi, et comment le logiciel est développé actuellement.
Outre les développeurs, les équipes de développement de logiciel peuvent inclure des ingénieurs d’assurance qualité, d’autres ingénieurs (bases de données et systèmes back-end, par exemple), des designers et des analystes, selon le type de projet du logiciel.
Scrum, Kanban et autres frameworks agiles
Il existe de nombreux frameworks agiles qui fournissent des détails sur les processus de développement et les pratiques de développement agiles, alignés sur un cycle de vie de développement du logiciel.
Le framework agile le plus populaire est appelé scrum. Il se concentre sur une cadence de livraison appelée un sprint et des structures de réunion qui incluent :
- La planification (où les priorités de sprint sont identifiées)
- L’engagement (où l’équipe examine une liste ou un arriéré d’histoires d’utilisateurs et décide combien de travail peut être fait pendant la durée du sprint)
- Les réunions quotidiennes de standup (afin que les équipes puissent communiquer des mises à jour sur leur statut et stratégies de développement)
Les sprints se terminent par une réunion de démonstration où la fonctionnalité est présentée au propriétaire du produit, suivie d’une réunion rétrospective où l’équipe discute de ce qui s’est bien passé et de ce qui doit être amélioré dans son processus.
De nombreuses entreprises emploient des maîtres de scrum ou des coaches pour aider les équipes à gérer le processus de scrum.
Bien que le scrum domine, il existe d’autres cadres agiles :
- Kanban fonctionne comme un processus de fan-in et de fan-out où l’équipe tire des user stories d’un conseil d’admission et les entonnant à travers un processus de développement par étapes jusqu’à ce qu’ils soient terminés.
- Certaines entreprises adoptent une approche hybride agile et waterfall, utilisant des processus agiles pour les nouvelles applications et waterfall pour les anciennes.
- Il existe également plusieurs frameworks permettant aux entreprises d’étendre la pratique à plusieurs équipes.
Alors que les frameworks agiles définissent les processus et la collaboration, les pratiques de développement agiles sont spécifiques aux tâches de développement de logiciels exécutées en alignement avec un framework agile.
Ainsi, par exemple :
- Certaines équipes adoptent la programmation par paires, où deux développeurs codent ensemble pour générer un code de meilleure qualité et permettre à des développeurs plus expérimentés d’encadrer des développeurs plus jeunes.
- Certaines équipes adoptent un développement piloté par les tests pour s’assurer que les fonctionnalités sous-jacentes fournissent les résultats attendus.
- De nombreuses équipes adoptent également des normes techniques, de sorte que l’interprétation par le développeur d’un user story n’aboutisse pas uniquement à la fonctionnalité souhaitée, mais répond également à la sécurité, à la qualité du code, aux conventions de dénomination et autres normes techniques.
Pourquoi la méthodologie agile est meilleure ?
Lorsque vous prenez l’ensemble des principes agiles, les mettez en œuvre dans un framework souple, utilisez des outils de collaboration et adoptez des pratiques de développement agiles, vous obtenez généralement des applications de meilleure qualité, des applications plus rapides et de meilleures pratiques techniques.
La raison principale est que agile est conçu pour la flexibilité et l’adaptabilité. Vous ne définissez pas toutes les réponses comme vous le faites dans la méthode Waterfall, mais divisez le problème en composants digestes que vous développez et testez ensuite avec les utilisateurs. Si quelque chose ne fonctionne pas correctement ou comme prévu, ou si l’effort révèle quelque chose qui n’a pas été pris en compte, vous pouvez adapter l’effort rapidement pour revenir rapidement sur la bonne voie – ou même changer de piste si c’est ce dont vous avez besoin. Agile permet à chaque membre de l’équipe de contribuer à la solution, et cela exige que chacun prenne la responsabilité personnelle de son travail.
Pour de nombreux problèmes, le développement agile est meilleur, car ses principes, ses frameworks et ses pratiques sont conçus en fonction des conditions d’exploitation actuelles. Des frameworks et des processus de développement agiles qui donnent la priorité à la livraison itérative de logiciels de travail et favorisent l’utilisation des commentaires pour améliorer l’application et le processus conviennent mieux au monde d’aujourd’hui, plus intelligent et plus rapide.
Les propriétaires de produits peuvent penser qu’ils savent exactement comment ils veulent développer une application qui correspond à leur vision, mais ils veulent rarement abandonner la possibilité d’améliorer cette vision lorsqu’ils parlent à plus d’utilisateurs et voient comment une application fonctionne réellement pour eux. De même, les équipes de développement pensent savoir comment concevoir l’application parfaite, mais elles ne peuvent la démontrer avant que l’ensemble de l’application ne soit intégré, que la fonctionnalité ne soit démontrée et que les changements d’exigences ne soient rationalisés.
Le développement agile est également meilleur, car il encourage un processus continu d’amélioration. Imaginez si Microsoft a mis fin au développement de Windows après la version 3.1 ou si Google a cessé d’améliorer ses algorithmes de recherche en 2002. Le logiciel a constamment besoin d’être mis à jour, soutenu et amélioré ; les processus agiles qui sont de nature itérative établissent à la fois un état d’esprit et un processus pour cette amélioration continue.
Enfin, le développement agile est meilleur, car les membres de l’équipe sont plus productifs et plus heureux de travailler avec ce processus. Les ingénieurs ont leur mot à dire sur le travail qu’ils accomplissent et ils sont fiers de montrer leurs résultats. Les propriétaires de produits aiment voir leur vision exprimée plus tôt dans le logiciel et être en mesure de modifier les priorités en fonction des dernières informations. Les utilisateurs aiment obtenir un logiciel qui fait ce dont ils ont réellement besoin, d’une manière qui respecte ou améliore leurs processus.
Aujourd’hui, les entreprises ont besoin de compétences en matière de logiciels pour offrir de bonnes expériences numériques dans un monde hyperconcurrentiel, d’excellentes expériences client. Ils ont besoin d’attirer et de garder un grand talent pour le faire. Le développement agile est le moyen pour les entreprises d’y parvenir.
