Qu’est-ce qu’Agile ?

  • Article

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

Agile est un terme qui décrit les approches du développement logiciel mettant l'accent sur la livraison incrémentale, la collaboration entre équipes, la planification continue et l’apprentissage continue. Le terme Agile a été employé pour la première fois en 2001 dans le manifeste Agile. Le manifeste visait à établir 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 en sommes venus à valoriser :

  • 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 contraire, les éléments de gauche sont simplement plus valorisés.

Méthodes et pratiques Agile

Il est important de comprendre qu'Agile n’est pas une chose. On ne fait pas Agile. Agile est plutôt un état d'esprit qui favorise une approche du développement logiciel. Parce qu’il n’existe pas d'approche unique qui fonctionne pour toutes les situations, le terme Agile en 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 Agile, 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 directives et des principes clairs.

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

  • La planification Poker est une pratique d’estimation collaborative conçue pour encourager les membres de l’équipe à partager leur compréhension de ce que signifie faire means. Beaucoup de gens trouvent le processus amusant, et il a été prouvé qu'il aide à 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 build 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 continuellement expédiable.

Ces pratiques, comme toutes les pratiques Agile, 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 responsabilisation. En gardant ce point à l’esprit, considérez quelques choses qu'Agile n’est pas.

  • Agile n'est pas un codage de cowboy. Agile ne doit pas être confondu avec une approche du développement logiciel « nous le découvrirons au fur et à mesure que nous allons ». Une telle idée ne pourrait pas être plus éloignée de la vérité. Agile nécessite à la fois une définition de valeur effectuée et explicite fournie aux clients dans chaque sprint. Bien que'Agile valorise l'autonomie pour les individus et les équipes, elle met l’accent sur l’autonomie alignée pour garantir que l’autonomie accrue produit 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é est la planification continue tout au long du projet, pas seulement la planification à l’avance. La planification continue garantit que l’équipe peut apprendre du travail qu’elle exécute. Grâce à cette approche, elles 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ù elles vont et les résultats qu'elles souhaitent atteindre. La reconnaissance du changement dans le cadre du processus est différente de la rotation dans une nouvelle direction chaque semaine, sprint ou mois.
  • Agile n’est pas un développement sans spécifications. Il est nécessaire dans tout projet de garder votre équipe alignée sur pourquoi et comment le travail se déroule. 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 livre 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 survient qui déroute le développement qu’un sprint doit échouer. Les équipes peut planifier les interruptions en désignant des ressources à l’avance pour des problèmes et des problèmes inattendus. Elles peuvent ensuite résoudre ces problèmes tout en restant sur la bonne voie du 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. Une autre reproche est que les approches évolutives d'Agile introduisent une structure et des méthodes qui compromettent la flexibilité. Malgré ces idées fausses, il est possible de faire évoluer les principes Agile avec succès. Pour plus d’informations sur la résolution de ces difficultés, consultez Adapter Agile aux 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 démontrer un produit fonctionnel et recueillir des commentaires. Il est vrai que ces efforts réduisent le temps qu'ils consacrent au développement. Mais l’intégration précoce des demandes des clients permet de gagner beaucoup de temps par la suite. Lorsque les fonctionnalités restent alignées sur la vision du client, les développeurs évitent les révisions majeures au bout du compte.
  • Agile n'est pas mal adapté aux applications d'aujourd’hui, qui se concentrent souvent sur le streaming de données. De tels projets impliquent généralement plus de charges de travail de modélisation des données et d’extraction-transformation-chargement (ETL) que d'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 fonctionnel toutes les quelques semaines, elles peuvent viser à mieux comprendre les données.

Pourquoi Agile ?

Alors 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 se ressemblent, mais le paysage et les environnements où nous les appliquons sont sensiblement différents.

  • Comparez ce que c'est que d'acheter des logiciels aujourd'hui avec le début des années 2000. À quelle fréquence les gens se rendent-il en magasin pour acheter des logiciels d'entreprise ?
  • Considérez comment les commentaires des clients sur les produits sont collectés. Comment une équipe comprenait-elle ce que les gens pensaient de leur logiciel avant les médias sociaux ?
  • Pensez à 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 face à la concurrence moderne.

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

« Tout a radicalement changé. La durabilité, outre l'aspect vert et 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 adaptent désormais leur approche du développement logiciel en conséquence. Les méthodes et pratiques Agile ne promettent pas de résoudre chaque problème. Mais elles promettent d'établir une culture et un environnement où les solutions émergent grâce à 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.