Principes et valeurs agiles, par Jeff Sutherland

Jeff Sutherland a inventé Scrum en 1993 et a travaillé avec Ken Schwaber à la normalisation Scrum à la conférence OOPSLA'95. Ensemble, ils ont étendu et amélioré Scrum chez de nombreux éditeurs logiciels et ont contribué à l'écriture du Manifeste pour le développement Agile de logiciels (page éventuellement en anglais). Le blog de Jeff examine les origines et les meilleures pratiques de Scrum à l'adresse suivante : http://scrum.jeffsutherland.com.

Le développement agile est un terme issu du Manifeste agile écrit en 2001 par un groupe composé des créateurs de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), et Crystal, ainsi qu'un représentant du développement piloté par les fonctionnalités et plusieurs autres experts de l'industrie des logiciels. Le Manifeste agile définissait un jeu commun de valeurs et de principes « overarching » pour toutes les méthodologies agiles individuelles. Il définit en détail quatre valeurs principales pour mettre en place des équipes ultra-performantes.

• Individus et leurs interactions

• Distribution de logiciels éprouvés

• Collaboration avec le client

• Adaptation au changement

Ce valeurs principales reposent sur 12 principes que vous pouvez trouver sur le site Web à l'adresse suivante : Manifesto for Agile Software Development (éventuellement en anglais).

Pour les créateurs du Manifeste Agile, ces valeurs ne font pas seulement l'objet d'un soutien purement théorique que ces derniers oublieraient ensuite. Il s'agit de valeurs pratiques. Chaque méthodologie agile individuelle offre une approche légèrement différente de ces valeurs, mais toutes ces méthodologies ont des processus et des applications pratiques spécifiques qui encouragent une ou plusieurs de ces valeurs.

Personnes et interactions

Les personnes et les interactions sont essentielles aux équipes ultra-performantes. Des études sur la « saturation de la communication » au cours d'un projet révèle qu'en l'absence de tout problème de communication, les équipes obtiennent des résultats 50 fois supérieurs à la moyenne industrielle. Pour faciliter la communication, les méthodes agiles reposent sur des cycles examen-et-adaptation fréquents. Ces cycles peuvent varier de quelques minutes avec la programmation par paire, à plusieurs heures avec une intégration continue, à chaque jour avec une réunion quotidienne, à chaque itération avec un examen et une rétrospective.

La simple augmentation de la fréquence des commentaires et de la communication ne suffit pas toutefois à éliminer les problèmes de communication. Les cycles examen-et-adaptation fonctionnent bien uniquement lorsque les membres de l'équipe adoptent plusieurs comportements essentiels :

• le respect pour la valeur de chaque personne

• la vérité dans chaque communication

• la transparence de toutes les données, actions et décisions

• la confiance que chaque personne soutient l'équipe

• l'adhésion à l'équipe et aux objectifs de l'équipe

Pour stimuler ces types de comportement, la gestion agile doit fournir un environnement positif, les accompagnateurs doivent faciliter leur intégration, et les membres de l'équipe doivent en faire la démonstration. Ce n'est que dans ce cas que les équipes peuvent donner toute leur mesure.

L'adoption de ces types de comportement est plus difficile qu'il y parait. La plupart des équipes évitent la vérité, la transparence et la confiance en raison de critères culturels ou d'expériences négatives ayant trouvé leur source dans les conflits générés par des communications honnêtes. Pour combattre ces tendances, la direction et les membres de l'équipe doivent encourager le conflit positif. De cette manière, il est possible non seulement d'encourager des comportement productifs mais également de profiter d'autres avantages :

• L'amélioration des processus repose sur la capacité de l'équipe à générer une liste d'obstacles ou de problèmes dans l'organisation, qu'elle doit confronter directement pour ensuite l'éliminer systématiquement par ordre de priorité.

• L'innovation se produit uniquement au cours de l'échange libre d'idées conflictuelles, phénomène étudié et documenté par Takeuchi et Nonaka, les parrains de Scrum.

• L'adhésion de l'équipe à un objectif commun nécessite que l'équipe fasse ressortir les priorités conflictuelles et qu'elle les résolve.

• L'engagement à travailler ensemble ne peut se produire que lorsque les personnes acceptent des objectifs communs puis s'efforcent de s'améliorer aussi bien individuellement que collectivement.

Cette dernière puce, à propos de l'engagement, est particulièrement importante. Ce n'est que lorsque les personnes et les équipes sont motivées qu'elles s'engagent à produire de la qualité, ce qui est le socle des équipes de développement de logiciel. Les méthodologies agiles facilitent l'engagement en encourageant les équipes à travailler à partir d'une liste où les tâches sont classées par ordre de priorité, et à se concentrer sur l'amélioration de leurs méthodes de travail. Cette pratique est la base de l'auto-organisation qui est le moteur permettant d'obtenir des résultats dans une équipe agile.

Pour créer des équipes ultra-performantes, les méthodologies agiles donnent la priorité aux personnes et aux interactions par rapport aux processus et aux outils. D'un point de vue pratique, l'ensemble des méthodologies agiles cherchent à augmenter la communication et la collaboration au moyen de cycles examen-et-adaptation fréquents. Toutefois, ces cycles fonctionnent uniquement lorsque les leaders agiles encouragent le conflit positif nécessaire à la mise en place de principes solides de vérité, transparence, approbation, respect et engagement dans leurs équipes agiles.

Logiciel éprouvé et documentation complète

Un logiciel qui a fait ses preuves est une des grandes différences du développement agile. Toutes les méthodologies agiles représentées dans le Manifeste Agile insistent sur la livraison au client de composants individuels du logiciel à des intervalles définis.

Toutes les équipes agiles doivent établir ce qu'elles entendent par « logiciel ayant fait ses preuves », qui est souvent synonyme de terminé. À un niveau global, un composant est terminé uniquement lorsque ses fonctionnalités réussissent tous les tests et peuvent être utilisées par un utilisateur final. Au minimum, les équipes doivent aller au delà du niveau de test unitaire et tester au niveau du système. Les meilleures équipes incluent également le test d'intégration, le test des performances et le test d'acceptation du client dans leur définition d'un composant qu'elles jugent terminé.

Une entreprise de niveau CMMI 5 a montré, sur la base de nombreuses données portant sur un grand nombre de projets, que la définition simultanée des tests d'acceptation et de la fonctionnalité, de l'implémentation des fonctionnalités de façon sérielle et selon un ordre de priorité, de l'exécution immédiate des tests d'acceptation sur chaque fonctionnalité, et de la correction des bogues identifiés ayant la priorité la plus élevée, permettent de doubler systématiquement la vitesse de production et de réduire les défauts de 40 %. Et cette expérience est celle d'une entreprise qui connait un taux de défaut les plus bas au monde.

Le Manifeste Agile recommande que les équipes distribuent le logiciel éprouvé à des intervalles définis. L'acceptation d'une définition de la notion de « terminé » est une des méthodes pratiques permettant aux équipes agiles d'obtenir la qualité et les performances élevées nécessaires à la réalisation de cet objectif.

Collaboration client et négociation du contrat

Depuis ces vingt dernières années, les taux de réussite des projets ont plus que doublé au niveau mondial. Cela est à mettre au compte de projets plus petits et des livraisons fréquentes qui permettent au client d'apporter des commentaires sur le logiciel à des intervalles réguliers. Les rédacteurs du manifeste ont vraiment vu juste lorsqu'ils ont souligné que la participation du client dans le processus de développement du logiciel est essentielle à la réussite.

La méthodologie agile favorise cette valeur en établissant une collaboration étroite entre le client et l'équipe de développement. Par exemple, la première équipe de Scrum avait des milliers de clients. Comme il n'était pas envisageable de tous les impliquer dans le développement du produit, ils ont sélectionné un client intermédiaire, appelé un propriétaire de produit, pour représenter non seulement tous les clients du secteur, mais également la direction, les commerciaux, les services du support et de la clientèle, et les autres parties prenantes. Le propriétaire du produit était chargé de la mise à jour de la liste des spécifications toutes les quatre semaines au moment de la diffusion du logiciel par l'équipe et qui comprenait la situation actuelle et les commentaires à proprement dits des clients et des parties prenantes. De cette manière, le client pouvait participer à l'élaboration du logiciel en cours de création.

La première équipe XP a commencé par un projet d'informatique en interne. Ils ont pu s'offrir les services au quotidien d'un utilisateur final de l'entreprise au sein de leur d'équipe. Ce n'est que dans 10 % des cas que les cabinet-conseils et les équipes internes peuvent trouver un utilisateur final qui peut travailler au quotidien avec l'équipe. Les 90 % restants doivent nommer un intermédiaire. Ce client intermédiaire, que les équipes XP appellent le client, travaille avec les utilisateurs finaux pour fournir aux développeurs une liste claire de fonctionnalités classées par ordre de priorité à implémenter.

Collaborer avec le client (ou le client intermédiaire) au quotidien est l'une des raisons clés qui expliquent pourquoi les données d'industrie montrent que les projets agiles ont un taux de réussite plus de deux fois supérieur aux projets traditionnels en moyenne dans le monde. La méthodologie agile le reconnaît, et en tant que telle, a créé une place dans ses équipes de développement qui est réservée au représentant du client.

Adaptation au changement et suivi d'un plan

L'adaptation au changement est essentielle à la création d'un produit qui satisfera le client et lui donnera sa valeur commerciale. Les données d'industrie montrent que plus de 60 % des spécifications de produit ou de projet changent pendant le développement du logiciel. Même quand les projets traditionnels respectent les délais, le budget et englobent toutes les fonctionnalités prévues, les clients sont souvent insatisfaits parce que le résultat final ne correspond pas exactement à leurs attentes. " La « Loi de Humphrey » dit que les clients ne savent jamais ce qu'ils souhaitent jusqu'à ce qu'ils voient le logiciel fonctionner. Si les clients ne voient pas le logiciel fonctionner avant la fin d'un projet, il est trop tard pour inclure leurs commentaires. La méthodologie agile recherche les commentaires des clients au cours de l'ensemble du projet pour incorporer les commentaires et les nouvelles informations durant le développement du produit.

Toutes les méthodologies agiles ont des processus intégrés pour modifier à intervalles réguliers leurs plans en fonction des commentaires du client ou du client intermédiaire. Leurs plans sont conçus pour toujours fournir en priorité la valeur commerciale la plus élevée. Comme 80 % de la valeur réside dans les 20 % des fonctionnalités, les projets agiles bien gérés ont tendance à finir tôt, alors que la plupart des projets traditionnels finissent en retard. Par conséquent, les clients sont plus satisfaits, et les développeurs aiment davantage leur travail. Les méthodologies agiles reposent sur le fait que, pour réussir, elles doivent planifier le changement. C'est pourquoi elles ont des processus établis, tels que des examens et des rétrospectives, qui sont conçus spécifiquement pour modifier régulièrement les priorités en fonction des commentaires du client et de la valeur commerciale.

Agile est une structure - les méthodologies sont des implémentations

Le développement agile n'est pas une méthodologie en soi. Il s'agit d'un concept qui décrit plusieurs méthodologie agiles. À la signature du Manifeste Agile en 2001, ces méthodologies comprenaient Scrum, XP, Crystal, FDD et DSDM. Depuis, les pratiques allégées ont aussi fait leur apparition sous la forme d'une méthodologie agile utile et font aussi parti de la structure de développement agile dans l'illustration ci-après dans cette rubrique.

Chaque méthodologie agile offre une approche légèrement différente pour l'implémentation des valeurs principales du Manifeste Agile, comme les nombreux langages informatiques expriment les fonctionnalités principales de la programmation orientée objet de différentes façons. Une étude récente montre qu'environ 50 % des pratiquants agiles indiquent que leur équipe a choisi la méthode Scrum. 20 % indiquent qu'ils utilisent Scrum avec les composants XP. 12 % indiquent qu'ils n'utilisent que XP. Comme plus de 80 % des implémentations agiles dans le monde sont Scrum ou XP, MSF for Agile Software Development v5.0 se concentre sur les processus et les applications pratiques principales de Scrum et XP.

Scrum est une infrastructure pour les processus de développement agiles. Elle n'inclut pas d'applications pratiques d'ingénierie spécifiques. Inversement, XP se concentre sur l'élaboration d'applications pratiques mais n'inclut pas d'infrastructure « overarching » de processus de développement. Cela ne signifie pas que Scrum ne recommande pas certaines applications pratiques d'ingénierie ou que XP n'a aucun processus. Par exemple, la première Scrum a implémenté toutes les applications pratiques d'ingénierie que désigne désormais XP. Toutefois, l'infrastructure de Scrum pour le développement de logiciel est conçue pour faire démarrer une équipe en deux ou trois jours, alors que l'élaboration d'applications pratiques prend souvent de nombreux mois à implémenter. Par conséquent, il reste la question de savoir quand (et si nécessaire) implémenter des applications pratiques spécifiques à chaque équipe. Les cocréateurs de Scrum, Jeff Sutherland et Ken Schwaber, recommandent que les équipes de Scrum commencent immédiatement et créent une liste des obstacles et un plan d'amélioration du processus. Comme les applications pratiques d'ingénierie sont identifiées comme des obstacles, les équipes doivent envisager les pratiques XP comme un moyen de s'améliorer. Les meilleures équipes font appel à Scrum en sus des applications pratiques de XP. Scrum permet de mettre XP à l'échelle, et XP facilite le bon fonctionnement de Scrum.

Le tableau suivant montre comment les termes clés dans Scrum et XP peuvent être échangés.

Scrum	XP
propriétaire de produit	client
scrummaster	accompagnateur XP
équipe	équipe
sprint	itération
réunion sprint de planification	jeu de planification

Voir aussi

Concepts

Planification et suivi de projets

Autres ressources

MSF for Agile Software Development v5.0