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. Les informations de manifeste quatre valeurs principales pour activer les é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éthodologies agiles reposent examen-et-adaptation fréquents sur des cycles. 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.

Pour que les équipes il est plus difficile d'obtenir ces types de comportement qu'il peut apparaître. 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. Lorsque les équipes s'engagent en conflit positif, elles permettent non seulement un comportement plus productif, mais fonctionnent également pour atteindre plusieurs 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 avec l'échange libre des idées conflictuelles, un phénomène qui a été étudié et documenté par Hirotaka Takeuchi et Ikujiro Nonaka, les parrains de scrum.

• La résolution des commandes du jour en conflit se produit lorsque les équipes s'alignent autour de les objectifs communs la surface et leurs problèmes et conflits potentiels.

• 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 et l'auto-organisation par les membres de l'équipe d'une manière encourageante pour récupérer des éléments d'une liste des travaux classée par ordre de priorité, gérer leur travail, et le focus sur l'amélioration leurs méthodes de travail. Ces pratiques forment la base de l'auto-organisation, qui est la force de lecteur pour 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 société CMMI de niveau 5, qui possède déjà une des plus insuffisantes taux de défaut dans le monde, a indiqué par le biais de données étendues sur de nombreux projets des avantages des pratiques agiles. Spécifiquement, ils étaient systématiquement la double la vitesse capable de production et de réduire les erreurs de 40 % en prenant les actions suivantes :. Cela d'une société.

• Définir des tests d'acceptation en définissant la fonctionnalité.

• Implémentez les fonctionnalités de travail séquentiels et par ordre de priorité.

• Exécutez les tests d'acceptation sur chaque fonctionnalité dès qu'elles seront implémentés.

• Corrigez les bogues identifiés dès que possible que la plus élevée.

Le Manifeste Agile recommande que les équipes distribuent le logiciel éprouvé à des intervalles définis. En acceptant en équipe sur lequel succès signifie est l'une des façons dont pratiques les équipes agiles provoquent à la haute performance et la qualité nécessaires pour atteindre 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. Ces améliorations se sont produites à la suite de projets plus petits et des livraisons plus fréquentes, qui ont permis aux clients de fournir des commentaires sur le logiciel fonctionnel à 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. Étant donné qu'il n'était pas possible de les impliquer toutes dans le développement de produit, ils ont sélectionné un client intermédiaire, appelé un propriétaire de produit. Le propriétaire du produit a représenté non seulement tous les clients dans le champ, mais également la gestion, sales, la prise en charge, les services clients, 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. Forme activement aidée de clients le logiciel qui a été créé.

La première équipe XP a commencé par un projet d'informatique en interne. L'équipe XP a avoir un utilisateur final de société dans leur travail d'équipe avec eux quotidiens. Environ 10 % du temps, les consultants et les équipes internes peuvent rechercher un utilisateur final qui peut fonctionner avec l'équipe sur une base quotidienne. 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.

Il est par la collaboration quotidienne de client (ou client intermédiaire) que les données d'industrie montrent que les projets agiles ont plus de deux fois l'indice de réussite de projets traditionnels sur mondial méthode. Étant donné que les méthodologies agiles identifient la valeur de l'engagement de client, il a créé un emplacement sur leurs équipes de développement qui est spécialement pour le représentant client.

Adaptation au changement et suivi d'un plan

Pour que les équipes créent des produits qui satisferont des clients et fourniront la valeur commerciale, les équipes doivent répondre à la modification. 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. Commentaires client d'accès de méthodologies agiles dans tout le projet afin que les équipes puissent incorporer les commentaires et les nouvelles informations à mesure que le produit est développé.

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

Suivre un travail avec Visual Studio ALM et TFS

Autres ressources

Modèle de processus Agile pour Visual Studio ALM