Qu'est-ce que la méthodologie agile? Développement de logiciel moderne expliqué

Chaque organisation technologique semble aujourd'hui pratiquer la méthodologie agile pour le développement de logiciels, ou une version de celle-ci. Ou du moins, ils le croient. Que vous soyez novice dans le développement d'applications agiles ou que vous ayez appris le développement logiciel il y a des décennies en utilisant la méthodologie de développement logiciel en cascade, votre travail est aujourd'hui au moins influencé par la méthodologie agile.

Mais qu'est-ce qu'une méthodologie agile et comment la mettre en pratique dans le développement de logiciels? En quoi le développement agile diffère-t-il de la cascade dans la pratique? Quel est le cycle de vie du développement logiciel agile ou SDLC agile? Et qu'est-ce que Scrum Agile par rapport à Kanban et à d'autres modèles agiles? 

Agile a été officiellement lancé en 2001 lorsque 17 technologues ont rédigé le Manifeste Agile. Ils ont écrit quatre principes majeurs pour la gestion de projet agile, dans le but de développer de meilleurs logiciels:

  • Individus et interactions sur processus et outils
  • Logiciel de travail sur une documentation complète
  • Collaboration client plutôt que négociation de contrat
  • Répondre au changement au sujet d'un plan

Avant agile: l'ère de la méthodologie en cascade

Les vieux comme moi se souviennent de l'époque où la méthodologie en cascade était la référence en matière de développement logiciel. Le processus de développement logiciel nécessitait une tonne de documentation avant le début de tout codage. Quelqu'un, généralement l'analyste commercial, a d'abord rédigé un document sur les exigences commerciales qui capturait tout ce dont l'entreprise avait besoin dans l'application. Ces documents sur les exigences commerciales étaient longs, détaillant tout: stratégie globale, spécifications fonctionnelles complètes et conception d'interface utilisateur visuelle.

Les technologues ont pris le document sur les exigences opérationnelles et ont élaboré leur propre document sur les exigences techniques. Ce document définit 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 logiciels en cascade lancerait enfin le codage, puis l'intégration et enfin les tests 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.

On s'attendait à ce que nous, les développeurs, connaissions «la spécification», comme la documentation complète était appelée, tout aussi bien que les auteurs des documents, et nous étions souvent réprimandés si nous avions oublié de mettre en œuvre correctement un détail clé décrit à la page 77 d'un document de page.

À l'époque, le développement de logiciels lui-même n'était pas non plus facile. De nombreux outils de développement nécessitaient une formation spécialisée et il n'y avait nulle part près des composants logiciels open source ou commerciaux, des API et des services Web qui existent aujourd'hui. Nous avons dû développer des éléments de bas niveau tels que l'ouverture de connexions de base de données et le multithreading de notre traitement de données.

Même pour les applications basiques, les équipes étaient nombreuses et les outils de communication limités. Nos spécifications techniques étaient ce qui nous alignait, et nous les avons exploitées comme la Bible. Si une exigence changeait, nous soumettions les chefs d'entreprise à un long processus d'examen et d'approbation, 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 pour les ingénieurs de base de données de construire d'abord les tables et autres artefacts de base de données, suivis par les développeurs d'applications codant la fonctionnalité et la logique métier, puis finalement l'interface utilisateur était superposée. Il a fallu des mois avant que quiconque ne voie l'application fonctionner et à ce moment-là, les parties prenantes devenaient anxieuses et souvent plus intelligentes quant à ce qu'elles voulaient vraiment. Pas étonnant que la mise en œuvre des changements coûte si cher!

Tout ce que vous avez présenté aux utilisateurs n'a pas fonctionné comme prévu. Parfois, les utilisateurs n'utilisent pas du tout une fonctionnalité. D'autres fois, une capacité a été largement réussie mais a nécessité une réingénierie pour prendre en charge l'évolutivité et les performances nécessaires. Dans le monde de la cascade, vous n'avez appris ces choses qu'après le déploiement du logiciel, après un long cycle de développement.

Vidéo connexe: Comment fonctionne vraiment la méthodologie agile

Tout le monde semble parler de développement logiciel agile, mais de nombreuses organisations n'ont pas une idée précise du fonctionnement du processus. Regardez cette vidéo de cinq minutes pour vous mettre rapidement à niveau.

Le pivot du développement logiciel agile

Inventée en 1970, la méthodologie de la cascade était révolutionnaire car elle apportait de la discipline au développement logiciel pour s'assurer qu'il y avait une spécification claire à suivre. Il était basé sur la méthode de fabrication en cascade dérivée des innovations de la chaîne d'assemblage de Henry Ford en 1913, qui fournissaient une certitude quant à chaque étape du processus de production pour garantir que le produit final correspondait à ce qui avait été spécifié en premier lieu.

Lorsque la méthodologie en cascade est arrivée dans le monde du logiciel, les systèmes informatiques et leurs applications étaient généralement complexes et monolithiques, exigeant une discipline et des résultats clairs. Les exigences changeaient également lentement par rapport à aujourd'hui, de sorte que les efforts à grande échelle étaient moins problématiques. En fait, les systèmes ont été construits sous l'hypothèse qu'ils ne changeraient pas mais seraient des cuirassés perpétuels. Les délais pluriannuels étaient courants non seulement dans le développement de logiciels, mais aussi dans la fabrication et d'autres activités d'entreprise. Mais la rigidité de la cascade est devenue un talon d'Achille à l'ère d'Internet, où la vitesse et la flexibilité étaient nécessaires.

La méthodologie de développement logiciel a commencé à changer lorsque les développeurs ont commencé à travailler sur des applications Internet. Une grande partie du travail initial a été effectuée dans des startups où les équipes étaient plus petites, étaient colocalisées et n'avaient souvent pas de formation en informatique traditionnelle. Il y avait des pressions financières et concurrentielles pour commercialiser plus rapidement les sites Web, les applications et les nouvelles capacités. Les outils de développement et les plates-formes ont changé rapidement en réponse.

Cela a conduit beaucoup d'entre nous travaillant dans des startups à remettre en question la méthodologie de la cascade et à chercher des moyens d'être plus efficaces. Nous ne pouvions pas nous permettre de faire toute la documentation détaillée à l'avance, et nous avions besoin d'un processus plus itératif et collaboratif. Nous avons encore débattu des modifications des exigences, mais nous étions plus ouverts à l'expérimentation et à l'adaptation aux besoins des utilisateurs finaux. Nos organisations étaient moins structurées et nos applications étaient moins complexes que les anciens systèmes d'entreprise, nous étions donc beaucoup plus ouverts à la création d'applications plutôt qu'à l'achat. Plus important encore, nous essayions de développer des entreprises, donc lorsque nos utilisateurs nous ont dit que quelque chose ne fonctionnait pas, nous avons le plus souvent choisi de les écouter.

Nos compétences et notre capacité à innover sont devenues stratégiquement importantes. Vous pourriez collecter tout l'argent que vous vouliez, mais vous ne pourriez pas attirer des développeurs de logiciels talentueux capables de travailler avec des technologies Internet en évolution rapide si vous deviez les traiter comme des codeurs subordonnés suivant servilement «les spécifications». Nous avons refusé que les chefs de projet arrivent avec des calendriers de bout en bout décrivant ce que nous devrions développer, quand les applications devraient être expédiées et parfois même comment structurer le code. Nous avons été terribles à atteindre les calendriers de trois et six mois que les chefs de projet de la cascade ont rédigés et mis à jour sans cesse.

Au lieu de cela, nous avons commencé à leur dire comment les applications Internet devaient être conçues, et nous avons livré des résultats selon un calendrier que nous avons établi de manière itérative. Il s'avère que nous n'avons pas été si mal à livrer ce que nous avions promis lorsque nous nous y étions engagés à de petits intervalles d'une semaine à quatre semaines.

En 2001, un groupe de développeurs de logiciels expérimentés s'est réuni et s'est rendu compte qu'ils pratiquaient collectivement le développement de logiciels différemment de la méthodologie classique en cascade. Et ils n'étaient pas tous dans les startups. Ce groupe, qui comprenait des sommités technologiques Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber et Jeff Sutherland, a proposé le Manifeste Agile qui documentait leurs croyances communes sur la manière dont un processus de développement 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é de gérer un changement constant plutôt que de s'enfermer dans un processus de développement en cascade rigide.

De ces principes est née la méthodologie agile de développement logiciel.

Les rôles dans la méthodologie agile

Un processus de développement logiciel agile commence toujours par définir les utilisateurs et documenter un énoncé de vision sur un éventail de problèmes, d'opportunités et de valeurs à traiter. Le Product Owner saisit cette vision et travaille avec une ou plusieurs équipes multidisciplinaires pour concrétiser cette vision. Voici les rôles dans ce processus.

Utilisateur

Les processus agiles commencent toujours par l'utilisateur ou le client à l'esprit. Aujourd'hui, nous les définissons souvent avec des personas d'utilisateurs pour illustrer différents rôles dans un flux de travail pris en charge par le logiciel ou différents types de besoins et de comportements des clients.

Propriétaire du produit

Le processus de développement agile lui-même commence par une personne qui doit être la voix du client, y compris les parties prenantes internes. Cette personne distille toutes les idées, les idées et les commentaires pour créer une vision du produit. Ces visions de produits sont souvent brèves et simples, mais elles brossent néanmoins un tableau de qui est le client, quelles valeurs sont abordées et une stratégie pour y répondre. J'imagine que la vision originale de Google ressemblait à quelque chose comme "Facilitons la tâche à toute personne ayant accès à Internet pour trouver des sites Web et des pages Web pertinents avec une interface simple basée sur des mots clés et un algorithme qui classe les sources réputées plus haut dans les résultats de recherche."

Nous appelons cette personne le propriétaire du produit . Sa responsabilité est de définir cette vision, puis de travailler avec une équipe de développement pour la concrétiser.

Pour travailler avec l'équipe de développement, le product owner décompose la vision du produit en une série de user stories qui expliquent plus en détail qui est l'utilisateur cible, quel problème est résolu pour lui, pourquoi la solution est importante pour lui, et quelles contraintes et critères d'acceptation définissent la solution. Ces user stories sont hiérarchisées par le product owner, revues par l'équipe pour s'assurer qu'ils ont une compréhension commune de ce qui leur est demandé.

Équipe de développement logiciel

En agile, les responsabilités de l'équipe de développement et de ses membres diffèrent de celles du développement logiciel traditionnel.

Les équipes sont multidisciplinaires, composées d'un groupe diversifié de personnes ayant les compétences nécessaires pour faire le travail. Parce que l'accent est mis sur la fourniture de logiciels fonctionnels, l'équipe doit compléter des applications fonctionnelles de bout en bout. Ainsi, la base de données, la logique métier et l'interface utilisateur d'une partie de l'application sont développées puis démo - pas l'ensemble de l'application. Pour ce faire, les membres de l'équipe doivent collaborer. Ils se rencontrent fréquemment pour s'assurer que tout le monde est aligné sur ce qu'ils construisent, sur qui fait quoi et sur la manière exacte dont le logiciel est développé.

En plus des développeurs, les équipes de développement logiciel peuvent inclure des ingénieurs d'assurance qualité (AQ), d'autres ingénieurs (comme pour les bases de données et les systèmes back-end), des concepteurs et des analystes, selon le type de projet logiciel.

Scrum, Kanban et autres frameworks agiles

De nombreux cadres 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 logiciel.

Le framework agile le plus populaire est appelé Scrum . Il se concentre sur une cadence de livraison appelée sprint et des structures de réunion qui incluent les éléments suivants:

  • Planification - où les priorités de sprint sont identifiées
  • Engagement - où l'équipe examine une liste ou un backlog de user stories et décide de la quantité de travail qui peut être effectuée pendant la durée du sprint 
  • Réunions debout quotidiennes - afin que les équipes puissent communiquer des mises à jour sur leur statut de développement et leurs stratégies)

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 organisations emploient des Scrum Master ou des coachs pour aider les équipes à gérer le processus Scrum.

Bien que Scrum domine, il existe d'autres frameworks agiles:

  • Kanban fonctionne comme un processus de fan-in et de fan-out dans lequel l'équipe extrait les user stories d'un tableau d'admission et les achemine à travers un processus de développement par étapes jusqu'à ce qu'elles soient terminées.
  • Certaines organisations adoptent une approche hybride agile et en cascade, utilisant des processus agiles pour les nouvelles applications et une cascade pour les anciennes.
  • Il existe également plusieurs cadres permettant aux organisations d'adapter la pratique à plusieurs équipes.

Alors que les cadres agiles définissent le processus et la collaboration, les pratiques de développement agiles sont spécifiques pour traiter les tâches de développement logiciel effectuées en alignement avec un cadre agile.

Ainsi, par exemple:

  • Certaines équipes adoptent la programmation en binôme, dans laquelle deux développeurs codent ensemble pour générer un code de meilleure qualité et pour permettre aux développeurs plus expérimentés d'encadrer les plus jeunes.
  • Les équipes plus avancées adoptent un développement et une automatisation pilotés par les tests pour garantir que la fonctionnalité sous-jacente produit les résultats attendus.
  • De nombreuses équipes adoptent également des normes techniques afin que l'interprétation par le développeur d'une user story ne mène pas uniquement à la fonctionnalité souhaitée, mais réponde également à la sécurité, à la qualité du code, aux conventions de dénomination et à d'autres normes techniques.

Pourquoi la méthodologie agile est meilleure