Le développement agile est un terme dérivé du Manifeste agile, rédigé en 2001 par un groupe comprenant les créateurs de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) et Crystal, un représentant du développement axé sur les fonctionnalités et plusieurs autres leaders d'opinion de l'industrie du logiciel. Le Manifeste Agile a établi un ensemble commun de valeurs et de principes primordiaux pour toutes les méthodologies agiles de l'époque. Il détaille quatre valeurs fondamentales pour permettre aux équipes d'être très performantes.

• Les individus et leurs interactions
• Fournir un logiciel fonctionnel
• Collaboration avec les clients
• Répondre au changement

Ces valeurs fondamentales sont soutenues par 12 principes, que vous pouvez consulter sur le site web suivant : Manifeste pour le développement agile de logiciels.

Ces valeurs ne sont pas simplement une chose que les créateurs du Manifeste Agile avaient l'intention d'exprimer du bout des lèvres, puis d'oublier. Ce sont des valeurs de travail. Chaque méthodologie agile aborde ces valeurs d'une manière légèrement différente, mais toutes ces méthodologies ont des processus et des pratiques spécifiques qui favorisent une ou plusieurs de ces valeurs.

Un logiciel fonctionnel et une documentation complète

Un logiciel fonctionnel est l'une des grandes différences qu'apporte le développement agile. Toutes les méthodologies agiles représentées dans le Manifeste Agile mettent l'accent sur la livraison au client, à intervalles réguliers, de petits morceaux de logiciels fonctionnels.

Toutes les équipes agiles doivent définir ce qu'elles entendent par "logiciel fonctionnel", ce qui est souvent connu comme la définition de "terminé". À un niveau élevé, un élément de fonctionnalité n'est complet que lorsque ses caractéristiques passent tous les tests et peuvent être exploitées par un utilisateur final. Au minimum, les équipes doivent dépasser le niveau des tests unitaires et tester au niveau du système. Les meilleures équipes incluent également les tests d'intégration, les tests de performance et les tests d'acceptation par le client dans leur définition de ce que signifie avoir terminé un élément de fonctionnalité.

Une entreprise CMMI de niveau 5 a démontré, grâce à des données exhaustives sur de nombreux projets, que le fait de définir des tests d'acceptation en même temps que la fonctionnalité, de mettre en œuvre les fonctionnalités en série et par ordre de priorité, d'exécuter immédiatement des tests d'acceptation sur chaque fonctionnalité et de corriger tous les bogues identifiés comme étant les plus prioritaires permet de doubler systématiquement la vitesse de production et de réduire les défauts de 40 pour cent. Ces résultats sont obtenus par une entreprise dont le taux de défauts est déjà l'un des plus bas au monde.

Le Manifeste Agile recommande que les équipes livrent des logiciels fonctionnels à des intervalles déterminés. Se mettre d'accord sur une définition de ce qui est fait est l'une des façons pratiques pour les équipes agiles d'obtenir la haute performance et la haute qualité nécessaires pour atteindre cet objectif.

La collaboration avec les clients plutôt que la négociation de contrats

Au cours des deux dernières décennies, le taux de réussite des projets a plus que doublé dans le monde entier. Cela est dû à des projets plus petits et à des livraisons fréquentes, qui permettent au client de fournir à intervalles réguliers un retour d'information sur le logiciel en cours d'utilisation. Les auteurs du manifeste avaient manifestement raison lorsqu'ils ont souligné que l'implication du client dans le processus de développement du logiciel est essentielle à la réussite.

Les méthodologies agiles favorisent cette valeur en permettant à un défenseur du client de travailler main dans la main avec l'équipe de développement. La première équipe Scrum, par exemple, comptait des milliers de clients. Comme il n'était pas possible de les impliquer tous dans le développement du produit, elle a choisi un représentant des clients, appelé propriétaire du produit, pour représenter non seulement tous les clients sur le terrain, mais aussi la direction, les ventes, l'assistance, les services clients et d'autres parties prenantes. Le propriétaire du produit était chargé de mettre à jour la liste des exigences toutes les quatre semaines, au fur et à mesure que l'équipe mettait sur le marché un logiciel opérationnel, en tenant compte de la réalité actuelle et du retour d'information des clients et des parties prenantes. Le client a ainsi pu contribuer à façonner le logiciel en cours de création.

La première équipe XP a commencé par un projet informatique interne. Elle a pu compter sur la collaboration quotidienne d'un utilisateur final de l'entreprise. Dans environ 10 % des cas, les cabinets de conseil et les équipes internes peuvent trouver un utilisateur final capable de travailler avec l'équipe au quotidien. Dans les 90 % restants, ils doivent désigner un mandataire. Ce mandataire, que les équipes XP appellent le client, travaille avec les utilisateurs finaux pour fournir une liste claire et prioritaire de fonctionnalités à mettre en œuvre par les développeurs.

La collaboration quotidienne avec le client (ou son représentant) est l'une des principales raisons pour lesquelles les données de l'industrie montrent que les projets agiles ont un taux de réussite plus de deux fois supérieur à celui des projets traditionnels, en moyenne dans le monde entier. Les méthodologies agiles en sont conscientes et, à ce titre, ont créé au sein de leurs équipes de développement une place spécifique pour le représentant du client.

Répondre au changement plutôt que suivre un plan

Il est essentiel de réagir au changement pour créer un produit qui plaira au client et apportera une valeur ajoutée à l'entreprise. Les données de l'industrie montrent que plus de 60 % des exigences d'un produit ou d'un projet changent au cours du développement d'un logiciel. Même lorsque les projets traditionnels se terminent dans les délais, dans le budget et avec toutes les fonctionnalités prévues, les clients sont souvent mécontents parce que ce qu'ils trouvent n'est pas exactement ce qu'ils voulaient. La "loi de Humphrey" stipule que les clients ne savent jamais ce qu'ils veulent tant qu'ils n'ont pas vu un logiciel fonctionnel. Si les clients ne voient le logiciel fonctionnel qu'à la fin du projet, il est trop tard pour intégrer leurs commentaires. Les méthodologies agiles recherchent le retour d'information des clients tout au long du projet afin d'intégrer les commentaires et les nouvelles informations au fur et à mesure du développement du produit.

Toutes les méthodologies agiles intègrent des processus permettant de modifier leurs plans à intervalles réguliers sur la base du retour d'information du client ou du proxy du client. Leurs plans sont conçus pour toujours fournir en premier la valeur commerciale la plus élevée. Étant donné que 80 % de la valeur réside dans 20 % des fonctionnalités, les projets agiles bien menés ont tendance à se terminer tôt, alors que la plupart des projets traditionnels se terminent tard. En conséquence, les clients sont plus heureux et les développeurs apprécient davantage leur travail. Les méthodologies agiles sont fondées sur le fait que, pour réussir, elles doivent s'adapter au changement. C'est pourquoi elles ont mis en place des processus, tels que des révisions et des rétrospectives, qui sont spécifiquement conçus pour modifier régulièrement les priorités en fonction des réactions des clients et de la valeur commerciale.

Agile est un parapluie - les méthodologies sont des implémentations

Le développement agile n'est pas une méthodologie en soi. Il s'agit d'un terme générique qui décrit plusieurs méthodologies agiles. Lors de la signature du Manifeste Agile en 2001, ces méthodologies comprenaient Scrum, XP, Crystal, FDD et DSDM. Depuis lors, les pratiques allégées se sont également imposées comme une méthodologie agile valable et sont donc incluses dans le cadre du développement agile dans l'illustration plus loin dans ce sujet.

Chaque méthodologie agile a une approche légèrement différente pour mettre en œuvre les valeurs fondamentales du Manifeste agile, tout comme de nombreux langages informatiques manifestent les caractéristiques fondamentales de la programmation orientée objet de différentes manières. Une enquête récente montre qu'environ 50 % des praticiens agiles déclarent que leur équipe fait du Scrum. Vingt autres pour cent disent qu'ils font du Scrum avec des composants XP. Enfin, 12 % des praticiens affirment qu'ils utilisent uniquement XP. Étant donné que plus de 80 % des implémentations agiles dans le monde sont Scrum ou XP, le MSF pour le développement agile de logiciels v5.0 se concentre sur les processus et pratiques de base de Scrum et XP.

Scrum est un cadre pour les processus de développement agile. Il ne comprend pas de pratiques d'ingénierie spécifiques. À l'inverse, XP se concentre sur les pratiques d'ingénierie mais n'inclut pas de cadre général de processus de développement. Cela ne signifie pas que Scrum ne recommande pas certaines pratiques d'ingénierie ou que XP n'a pas de processus. Par exemple, le premier Scrum a mis en œuvre toutes les pratiques d'ingénierie qui sont aujourd'hui connues sous le nom de XP. Cependant, le cadre de Scrum pour le développement de logiciels a été conçu pour permettre à une équipe de démarrer en deux ou trois jours, alors que la mise en œuvre des pratiques d'ingénierie prend souvent de nombreux mois. Par conséquent, il laissait à chaque équipe le soin de décider quand (et si) elle devait mettre en œuvre des pratiques spécifiques. Les co-créateurs de Scrum, Jeff Sutherland et Ken Schwaber, recommandent aux équipes de Scrum de démarrer immédiatement et de dresser une liste des obstacles et un plan d'amélioration des processus. Au fur et à mesure que les pratiques d'ingénierie sont identifiées comme des obstacles, les équipes devraient se tourner vers les pratiques XP comme moyen d'amélioration. Les meilleures équipes utilisent Scrum en complément des pratiques XP. Scrum aide XP à s'étendre et XP aide Scrum à bien fonctionner.