Qu’est-ce qu’Agile ?

Agile est un terme qui décrit les approches du développement logiciel qui mettent l’accent sur la prestation incrémentielle, la collaboration d’équipe, la planification continue et l’apprentissage continu. Le terme Agile a été créé en 2001 dans le Manifeste Agile. Le manifeste a établi des principes pour guider une meilleure approche du développement logiciel. Au fond, le manifeste déclare quatre déclarations de valeur qui représentent la base du mouvement Agile. Comme écrit, le manifeste déclare :

Nous avons appris à apprécier :

• Les individus et les interactions plutôt que les processus et les outils
• Les logiciels opérationnels plutôt qu’une documentation exhaustive.
• La collaboration avec les clients plutôt que la négociation de contrat.
• L’adaptation au changement plutôt que le respect des plans

Le manifeste n’implique pas que les éléments du côté droit de ces déclarations ne sont pas importants ou nécessaires. Au lieu de cela, les éléments de gauche sont simplement plus appréciés.

Méthodes et pratiques agiles

Il est important de comprendre que Agile n’est pas une chose. Vous n'utilisez pas Agile. Au lieu de cela, Agile est un état d’esprit qui favorise une approche du développement logiciel. Étant donné qu’il n’existe aucune approche unique qui fonctionne pour toutes les situations, le terme Agile est venu représenter différentes méthodes et pratiques qui s’alignent sur les déclarations de valeur dans le manifeste.

Les méthodes agiles, souvent appelées frameworks, sont des approches complètes des phases du cycle de vie devOps : planification, développement, livraison et opérations. Ils prescrivent une méthode pour accomplir le travail, avec des conseils et des principes clairs.

Scrum est le framework Agile le plus courant, et celui que la plupart des gens commencent par. Les pratiques agiles, d’autre part, sont des techniques qui sont appliquées pendant les phases du cycle de vie du développement logiciel.

• Planning Poker est une pratique d’estimation collaborative conçue pour encourager les membres de l’équipe à partager leur compréhension de ce que fait signifie. Beaucoup de gens trouvent le processus amusant, et il s’est avéré pour aider à favoriser le travail d’équipe et de meilleures estimations.
• L’intégration continue (CI) est une pratique d’ingénierie Agile courante qui implique l’intégration de modifications de code dans la branche principale fréquemment. Une compilation automatisée vérifie les modifications. Par conséquent, il y a une réduction de la dette d'intégration et une branche principale livrable en continu.

Ces pratiques, comme toutes les pratiques Agiles , portent l’étiquette Agile, car elles sont cohérentes avec les principes du manifeste Agile.

Qu’est-ce qu’Agile n’est pas

Comme Agile a gagné en popularité, de nombreux stéréotypes et mauvaises interprétations ont jeté une ombre négative sur son efficacité. Il est facile de dire « Oui, nous faisons Agile », sans aucune responsabilité. Gardez ce point à l’esprit, et considérez quelques éléments que l'Agile n’est pas.

• Agile n’est pas un codage de cowboy. Agile ne doit pas être confondu avec une approche « nous allons le comprendre à mesure que nous allons » à l’approche du développement logiciel. Une telle idée ne pouvait pas être plus loin de la vérité. Agile nécessite à la fois une définition de terminé et de la valeur explicite livrée aux clients dans chaque sprint. Bien que les valeurs de l'Agilité accordent de l'autonomie aux individus et aux équipes, elles mettent l'accent sur une autonomie coordonnée pour garantir que l'autonomie accrue se traduise par une valeur accrue.
• Agile n’est pas sans rigueur et planification. Au contraire, les méthodologies et pratiques Agile mettent généralement l’accent sur la discipline dans la planification. La clé consiste à planifier continuellement tout au long du projet, et non pas seulement à planifier à l’avance. La planification continue garantit que l’équipe peut apprendre du travail qu’elle exécute. Grâce à cette approche, ils optimisent le retour sur investissement (ROI) de la planification.

« Les plans sont sans valeur, mais la planification est tout. » — Dwight D. Eisenhower

• Agile n’est pas une excuse pour l’absence de feuille de route. Cette idée fausse a probablement fait le plus de mal au mouvement Agile dans l’ensemble. Les organisations et les équipes qui suivent une approche Agile savent absolument où ils vont et les résultats qu’ils souhaitent atteindre. Reconnaître le changement comme faisant partie du processus est différent de changer de direction chaque semaine, sprint ou mois.
• Agile n’est pas un développement sans spécifications. Il est nécessaire dans n’importe quel projet de maintenir l’alignement de votre équipe sur la raison et la façon dont le travail se produit. Une approche agile des spécifications inclut la garantie que les spécifications sont de bonne taille et qu’elles reflètent de manière appropriée la façon dont l’équipe séquence et fournit du travail.
• Agile n’est pas capable d’accueillir des travaux non planifiés et d’autres interruptions. Il est important d’effectuer des sprints selon la planification. Mais ce n'est pas parce qu'un problème surgit et détourne le développement qu'un sprint doit échouer. Les équipes peuvent planifier les interruptions en désignant des ressources à l’avance pour des problèmes et des imprévus. Ils peuvent ensuite résoudre ces problèmes, mais suivre le développement.
• Agile n’est pas inapproprié pour les grandes organisations. Une plainte courante est que la collaboration, un composant clé des méthodologies Agile, est difficile dans les grandes équipes. Un autre reproche est que les approches adaptatives dans Agile introduisent des structures et des méthodes qui compromettent la flexibilité. Malgré ces idées fausses, il est possible de mettre à l’échelle les principes Agile avec succès. Pour plus d’informations sur la résolution de ces difficultés, consultez Mise à l’échelle agile vers de grandes équipes.
• Agile n’est pas inefficace. Pour s’adapter aux besoins changeants des clients, les développeurs investissent du temps chaque itération pour illustrer un produit fonctionnel et recueillir des commentaires. Il est vrai que ces efforts réduisent le temps qu’ils consacrent au développement. Toutefois, l’incorporation de demandes de clients dès le début de l’opération permet de gagner beaucoup de temps plus tard. Lorsque les fonctionnalités restent alignées sur la vision du client, les développeurs évitent les révisions majeures en ligne.
• Agile n’est pas un mauvais ajustement pour les applications d’aujourd’hui, qui centrent souvent sur le streaming de données. Ces projets impliquent généralement davantage de charges de travail de modélisation des données et d’extraction de transformation (ETL) que les interfaces utilisateur. Ce fait rend difficile la démonstration de logiciels utilisables selon un calendrier cohérent et serré. Mais en ajustant les objectifs, les développeurs peuvent toujours utiliser une approche Agile. Au lieu de travailler pour accomplir des tâches chaque itération, les développeurs peuvent se concentrer sur l’exécution d’expériences de données. Au lieu de présenter un produit opérationnel toutes les semaines, ils peuvent mieux comprendre les données.

Pourquoi Agile ?

Pourquoi quelqu’un envisagerait-il une approche Agile ? Il est clair que les règles d’engagement autour de la création de logiciels ont fondamentalement changé au cours des 10-15 dernières années. La plupart des activités ressemblent, mais le paysage et les environnements où nous les appliquons sont sensiblement différents.

• Comparez ce que c'est d'acheter des logiciels aujourd'hui par rapport au début des années 2000. À quelle fréquence les gens se rendent-ils au magasin pour acheter des logiciels professionnels ?
• Réfléchissez à la façon dont les commentaires sont collectés auprès des clients sur les produits. Comment une équipe a-t-elle compris ce que les gens pensaient de leur logiciel avant les médias sociaux ?
• Réfléchissez à la fréquence à laquelle une équipe souhaite mettre à jour et améliorer le logiciel qu’elle fournit. Les mises à jour annuelles ne sont plus réalisables contre la concurrence moderne.

Diego Lo Guidice de Forrester le dit bien dans son blog, Transforming Application Delivery (octobre 2020).

"Tout a changé considérablement. La durabilité, en plus du vert et du propre, signifie que ce que nous construisons aujourd’hui doit être facilement et rapidement changé demain. Les plans stratégiques sont à court terme et la planification et les changements sont continus. — Diego Lo Guidice, Forrester

Les règles ont changé et les organisations du monde entier s’adaptent désormais à leur approche du développement logiciel en conséquence. Les méthodes et pratiques agiles ne promettent pas de résoudre chaque problème. Mais ils promettent d’établir une culture et un environnement où les solutions émergent par la collaboration, la planification et l’apprentissage continus, et un désir d’expédier plus souvent des logiciels de haute qualité.

Étapes suivantes

Décider de prendre l’itinéraire Agile vers le développement logiciel peut introduire des opportunités intéressantes pour améliorer votre processus DevOps. Un ensemble de considérations clés se concentre sur la façon dont le développement Agile compare et contraste avec l’approche actuelle d’une organisation.