Agile vs DevOps : Lequel choisir et pourquoi
Lorsque vous pensez à une organisation à haute performance, vous êtes-vous déjà demandé quelles sont les meilleures pratiques qu'elle suit pour atteindre ce niveau ? S’orientent-elles vers des approches agiles ou DevOps ?
Pour atteindre leurs objectifs, ces organisations s’appuient souvent sur un mélange d’outils agiles pour gérer le développement itératif et la planification adaptative, ainsi que sur des outils DevOps qui rationalisent l’automatisation, l’intégration continue et le déploiement.
L’objectif d’un processus de développement et d’opérations est d’aider l’entreprise à satisfaire ses exigences, d’aider les membres d’équipe à collaborer et à briser les silos afin de lever les blocages, et enfin d’achever les projets ou fonctionnalités sur lesquels ils travaillent, afin d’augmenter le nombre d’utilisateurs actifs quotidiens ou mensuels – ou, dans le cas des applications d’entreprise, d’accroître les fonctionnalités de leurs applications.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Lorsque les équipes travaillent en silos, cela crée des lacunes dans la communication, ce qui conduit au chaos. Tandis que lorsque les équipes travaillent de concert, elles sont plus efficaces.
Dans le cadre de cet article, je couvrirai les approches agiles et DevOps, des exemples de cas où adopter des méthodologies spécifiques, et comment les tests sont impactés dans chacun de ces scénarios.
Pratiques de développement logiciel agile
Comparé au processus de développement en cascade, l’agile met l’accent sur l’un de ses principes fondamentaux, qui consiste à satisfaire les clients dès le début du processus et au moyen de livraisons continues. La livraison continue n’est possible que si l’on implique l’équipe qualité dès le début du processus et que l’on collabore fréquemment avec elle.
Actuellement, certaines petites et moyennes entreprises ne suivent ni l’approche agile, ni totalement la méthode en cascade, mais un mélange des deux. Ces membres d’équipes dites agiles consacrent tellement d’énergie à des processus très détaillés, comme des réunions de synchronisation de 30 minutes et des réunions de rétrospective de 60 minutes, qu’ils oublient le retour sur investissement qu’ils apportent réellement, ce qui aboutit à une situation où de nombreux bogues sont découverts en production.
L’industrie est-elle vraiment passée de la méthode en cascade ?
Avez-vous déjà fait partie d’une organisation (qui était censée suivre des processus de développement logiciel agile) pour vous rendre compte que l’équipe qualité n’est impliquée dans les tests qu’une fois le développement terminé ?
Dans cet exemple, ils appelaient toujours cela agile parce que les membres de l’équipe de développement travaillaient sur plusieurs branches (ou fonctionnalités) à la fois de façon itérative. Mais lorsque venait le moment de tester leurs fonctionnalités, ils attendaient que tout le développement soit terminé — ce qui est au cœur de la méthodologie en cascade. Cependant, comme les entreprises souhaitent avancer plus rapidement pour élargir leur clientèle, la plupart du temps, les équipes finissent par accumuler de la dette technique.
La meilleure façon de résoudre ce problème est de convertir l’organisation en mode entièrement agile et de travailler main dans la main avec l’équipe qualité, de façon itérative. Cela implique d’impliquer toutes les parties prenantes pour s’assurer qu’elles comprennent les conséquences de ne pas effectuer ce changement et comment cela peut affecter l’expérience utilisateur finale.
Les frameworks agiles et leurs variantes
Dans le cadre de cet article, je vais aborder deux des frameworks agiles les plus répandus :
- Scrum
- Kanban
Scrum est une méthodologie agile utilisée dans le développement logiciel basée sur des processus itératifs et incrémentaux. Elle consiste à suivre des phases de développement limitées dans le temps appelées sprints. La durée des sprints varie selon chaque organisation : cela peut aller d’une semaine à un mois, voire un trimestre.
Il y a une session de planification du sprint, suivie du sprint où se déroulent l’implémentation et les tests, incluant des réunions quotidiennes, puis se termine finalement par une session de rétrospective.
Scrum est généralement mis en place dans les équipes de développement de produits dont les membres doivent limiter le temps de leur travail pour respecter les délais du client. Cela s’applique principalement aux applications B2C, car si vous attendez trop longtemps, votre fonctionnalité n’est plus nouvelle, quelqu’un d’autre a déjà pu l’implémenter !
Dans les applications B2B, qui concernent principalement les entreprises, une version modifiée de la méthodologie agile, appelée SaFe – Scaled Agile framework, est couramment utilisée.
La plupart des projets dans les entreprises entrent dans l’une des catégories suivantes :
- Niveau équipe
- Niveau programme
- Niveau portefeuille
Les projets au niveau de l’équipe sont des développements basés sur les fonctionnalités, chaque membre étant responsable de son projet et de ses processus. Ces équipes utilisent généralement Scrum ou Kanban selon la nature de leur travail.
Si les équipes relèvent de l’organisation recherche & développement ou de l’automatisation des tests, il est impératif qu’elles adhèrent à Kanban, qui est moins rigide, l’objectif étant davantage de terminer la tâche en cours que de passer à la prochaine nouveauté séduisante ! Si les équipes font partie de l’organisation de développement produit, elles ont tendance à utiliser les processus Scrum.
Les projets au niveau du programme impliquent plusieurs équipes œuvrant vers un objectif spécifique, tel qu’une migration AWS. Même si ce projet pourrait relever du portefeuille, j’estime qu’il n’affectera pas nécessairement les équipes RH ou de comptabilité.
Dans ce cas, le projet de migration AWS peut durer plusieurs mois en raison de problèmes imprévus ; l’objectif est donc de réussir la migration AWS tout en la divisant en sprints justifiés.
Les projets au niveau du portefeuille impliquent différentes organisations au sein de l’entreprise ; un exemple serait la mise en œuvre de JIRA. Chaque organisation aurait besoin que les workflows JIRA soient implémentés différemment selon ses besoins. Les équipes RH n’ont pas besoin de tests ; le but est essentiellement de répondre à des demandes spécifiques des employés, et une fois celles-ci satisfaites, la tâche est marquée « terminée ».
Les méthodologies Agiles doivent être adoptées par les organisations qui connaissent des changements constants. Mais ces modifications doivent encore être testées et déboguées, et les tests ne sont pas nécessairement automatisés, ce qui augmente les délais des processus.
Enfin, une fois les fonctionnalités prêtes à être déployées, elles sont remises à l’équipe build/ops. Ainsi, les tests sont réalisés de manière itérative par rapport à l’approche en cascade, mais ils ne se déplacent pas radicalement vers la gauche, car la priorité n’est pas donnée aux tests ni à la livraison continue. D’où le besoin pour une démarche DevOps !
-
Tricentis qTest
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.3 -
Testiny
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.8 -
QA Wolf
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.8
Approche DevOps
L’approche DevOps va au-delà du développement et des tests et prône une pipeline CI/CD complètement automatisée ainsi que des capacités de surveillance. Alors que l’Agile favorise l’adaptabilité, la démarche DevOps mise sur les tests et la livraison continus afin d’assurer le succès des mises en production fréquentes auprès des utilisateurs finaux.
L’objectif de l’équipe IT Operations est de mettre à l’échelle le processus de développement afin d’accélérer la rédaction et la mise à jour du code responsable de la création de nouvelles applications/services et de la mise à jour des fonctionnalités au sein de l’équipe IT.
Même dans la structuration des équipes, de nos jours, les équipes qualité et opérations IT appartiennent à la même organisation pour collaborer efficacement. D’ailleurs, un nouveau rôle appelé TestOps a été créé afin de se consacrer à la mise en place des pipelines CI/CD où des tests automatisés sont exécutés sur les pull requests, offrant un retour immédiat aux équipes de développement.
Les tests automatisés sont essentiels pour étendre les efforts de test et leur valeur disparaît s’ils ne font pas partie d’un processus de test et de déploiement continu. Ainsi, le personnel TestOps est constamment occupé à la maintenance de l’infrastructure des tests automatisés.
Cela garantit que les membres de l’équipe opérations restent concentrés sur la livraison d’une infrastructure de développement de logiciels de classe mondiale, sans être détournés par la gestion de l’infrastructure de test.
Il existe aujourd’hui de nombreux outils et pratiques DevOps qui favorisent la rationalisation du processus global.
- Un fichier d’état Terraform fait référence à un ensemble d’infrastructures définies et gérées comme une seule unité—c’est la manière dont divers environnements de test et de développement sont définis et administrés. Terraform aide à configurer les serveurs, mais il nous faut une infrastructure pour exécuter ces serveurs.
- AWS fournit l’infrastructure via des instances EC2, qui représentent actuellement la solution la plus rentable pour configurer et exécuter ces serveurs. Pour aller plus loin, si votre stack technique compte beaucoup de microservices, avec docker compose, vous pouvez définir et exécuter plusieurs environnements docker en conteneurs.
- Ansible automatise le processus de configuration des machines pour exécuter tout type de processus ou de serveurs.
- Kubernetes aide à gérer un cluster de ces instances EC2 en tant que pod et planifie le lancement des conteneurs sur ce cluster en fonction des ressources de calcul disponibles.
Faut-il utiliser Agile ou DevOps ?
Alors que le débat Agile contre DevOps reste constant au sein des organisations, la meilleure façon d’aborder ce choix est de se poser les questions suivantes :
- Quelle est la capacité d’adaptation de notre organisation face aux nouvelles technologies ?
- Pouvons-nous rivaliser avec nos concurrents en termes de qualité de nos produits ?
- Les clients sont-ils susceptibles d’utiliser nos produits car ils répondent à leurs attentes ?
Si les réponses à ces questions incluent une certaine forme de négation, il est alors temps de se concentrer davantage sur une combinaison des deux approches et de l’adapter à nos besoins.
La méthodologie de développement logiciel idéale
La principale différence entre les processus de développement logiciel basés sur agile et DevOps réside dans le fait que le premier met l’accent sur l’acceptation des changements constants, tandis que le second se concentre sur les tests, la livraison et le déploiement continus. La collaboration entre les équipes de développement et d’exploitation est cruciale pour que l’équipe de dev ne soit pas bloquée.
À mon avis, un processus de développement de logiciel idéal devrait inclure les éléments suivants :
- Gérer les personas clients/utilisateurs et intégrer les retours des clients
- Se concentrer sur les meilleures pratiques pour éviter l’accumulation de dette technique
- Amélioration continue, tests continus, intégration continue, livraison continue, déploiement continu et surveillance continue
Voici à quoi ressemblerait le processus :
La gestion des différents types de clients n’est pas réservée aux équipes de gestion de produit. Au final, pourquoi développons-nous ces produits ? Quel est l’intérêt de ces produits s’ils ne sont pas utilisés par des clients ?
Prenons l’exemple classique de Nokia : ils ont accumulé de la dette technique à force de ne pas suivre les tendances du marché, notamment à cause de l’innovation de leur concurrent Apple. Ils se sont concentrés sur des cycles de sprint rigoureux pour finalement être oubliés !
Toutes les entreprises devraient comprendre pourquoi leurs fonctionnalités sont développées et à quel type de clients elles s’adressent. Cela garantira que nous développons des fonctionnalités centrées sur l’utilisateur.
Lorsqu’un nouveau produit est lancé, qu’il s’agisse d’une application mobile ou web, assurez-vous toujours qu’il existe un moyen pour les clients de laisser leur avis. Toutes les entreprises ne suivent pas un processus strict de collaboration étroite avec le support client.
CI/CD
Enfin, il est important de prôner l’intégration et la livraison continues basées sur l’IA/ML. Lorsqu’un projet échoue, cela ne signifie pas nécessairement un manque de compétences au niveau des membres de l’équipe ; c’est plutôt le manque de tests suffisants et l’incapacité à détecter les problèmes plus tôt dans le développement.
Mais parfois, même avec des tests et une automatisation adéquats, il arrive que les choses dérapent : si un système de recommandations était en place pour déterminer quand publier ou non, peut-être que de tels échecs catastrophiques pourraient être évités.
Des itérations fréquentes aident l’équipe de développement à comprendre ce qui fonctionne ou pas et à réfléchir à l’évolutivité. Le bémol est que cela prend du temps ! Si un autre système de recommandation ou de prédiction pouvait recueillir des informations sur les clients et prévoir si une fonctionnalité spécifique allait susciter de l’intérêt ou échouer avant même le début du développement, cela permettrait d’optimiser le processus de création d’un produit de qualité dès le premier jour !
L’objectif global est de faire en sorte que les impacts métiers se multiplient plus rapidement lorsque ces meilleures pratiques sont adoptées au cours du développement.
Need expert help selecting the right tool?
Réflexions finales
Pour finir, Agile et DevOps jouent tous deux un rôle crucial dans le développement logiciel moderne, mais le bon choix dépend des objectifs, de la structure d’équipe, des options tarifaires et des besoins de votre projet.
L'Agilité met l'accent sur le développement itératif et la flexibilité, tandis que DevOps insiste sur la livraison continue, l'automatisation et la collaboration entre le développement et les opérations. De nombreuses organisations réussissent à combiner ces deux approches afin de maximiser l'efficacité et la qualité. Quel que soit le chemin choisi, il est essentiel d’aligner vos outils et processus pour stimuler l’innovation et livrer de la valeur plus rapidement.
Pour plus d’informations sur l’optimisation de vos flux de travail de développement et pour garder une longueur d'avance sur les tendances du secteur, abonnez-vous à la newsletter du CTO Club.
