Alors finalement, la différence entre Agilité et DevOps, c’est quoi ?

Dans le monde informatique, deux mots se détachent particulièrement : « agilité » et « DevOps ».
Si vous cherchez ces deux mots sur Internet, vous obtenez des titres d’articles comme :
« Agilité et DevOps : la combinaison gagnante »
« DevOps ou la nouvelle Agilité »
« Le “DevOps” : porter l’agilité jusqu’au déploiement et au-delà »
« Le Devops ou comment rendre la DSI plus agile »
« DevOps, la méthode agile pour réconcilier développement et exploitation »
D’emblée un doute naît :
« L’agilité et le DevOps ce sont deux choses séparées, l’un découle-t-il de l’autre, l’un est-il une sous partie de l’autre ? »

Vous vous dîtes que pour mieux comprendre, le plus simple est d’aller dans des conférences dédiées.
Vous en sortirez probablement avec l’idée qu’il faut mettre du Docker sur les postes de développeurs et déployer vos applications sur Kubernetes sur votre infrastructure gérée par Puppet ou Ansible, tout comme vous finirez par croire que Scrum c’est l’agilité.

Retour aux origines

L’agilité est née « officiellement » avec la publication du manifeste agile en 2001.
Vous entendrez et lirez souvent les 4 valeurs et les 12 principes.
Si à l’origine ce manifeste a été écrit par des experts en développement, aujourd’hui on voit l’agilité toucher d’autres domaines (recrutement, RH…).
Il y a pourtant une chose qui est oubliée du manifeste agile, c’est la première phrase :

« Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. »

Cette phase est d’autant plus importante qu’elle rappelle que l’agilité est indissociable du Craftsmanship et qu’elle nous invite à bien creuser les valeurs et principes.

Naissance du DevOps

En 2007, Patrick Debois (administrateur système et consultant) s’interroge sur la relation entre les développeurs et les administrateurs systèmes et réseaux.
Andrew Shafer propose une conférence « Agile Infrastructure » à la conférence Agile Tour de Toronto de 2008.
Lors du velocity O’Reilly en 2009, John Allspaw et Paul Hammond font un retour d’expérience intitulé: 10+ Deploys a Day: Dev and Ops Cooperation at Flickr.  Cette conférence vante les bénéfices productifs de la collaboration entre les Dev et les Ops pour le projet FlickR.
Quand on lit le manifeste agile, on trouve ces 3 principes :

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »
« Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. »
« Un logiciel opérationnel est la principale mesure d’avancement. »

Bien que ces principes n’indiquent pas explicitement les « exploitants », ils sont forcément intégrés, tout comme les équipes sécurités et métiers.
Comment serait-il possible de répondre à ces principes sans eux ?
Qu’on parle d’agilité, de DevOps, de BizDevOps, de DevSecOps parle-t-on de la même chose ?
Dans le DevOps, on parle d’automatisation, d’infra as code, déploiement continue, tests automatisés, de collaboration…, le manifeste agile en parlait déjà :

« Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »
« Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. »

Car livrer fréquemment sans tout ce qu’on met en place dans une démarche DevOps relève de la gageure.
Mais attention, il faut éviter le piège de : « C’est aux devs de comprendre/adhérer à l’ops ». C’est bien tout le monde qui doit s’intéresser aux autres, les comprendre et partager des objectifs communs.

DevOps, une agilité plus mature ?

Le manifeste agile parle des développeurs, des utilisateurs ou représentants ce qui peut donner l’impression que les exploitants, les équipes de sécurité… sont exclus.
Ce même effet se produit avec le DevOps, les gens pensant que cela se limite aux développeurs et exploitants (d’où la création de BizDevOps et SecDevOps) et se limite à quelques briques techniques.
Le DevOps apporte le modèle CALMS (Culture, Automation, Lean, Measurement, Sharing).

Culture

Avec le temps, des divergences entre équipes sont apparues dans les organisations travaillant pourtant dans un but commun, aussi bien en termes d’outils ou de processus.
Le DevOps va permettre de rappeler qu’une culture commune est facteur de succès.

Automation

Ce point nous rappelle que la technique est importante. Comment ?
Et bien pour automatiser une chaîne complète d’un logiciel, il faudra atteindre la qualité des processus industriels qu’on peut voir pour construire une voiture par exemple.
Ainsi, les pièces (d’une voiture ou d’un logiciel) doivent être d’une qualité constante et suivre un standard (interne ou mondiale).
Avec l’automatisation, on tire toute la chaîne de fabrication, de livraison et de production.

Lean

Il va y avoir une remise en question, suivie surement d’une remise en cause, total de l’organisation afin de simplifier et optimiser la chaîne de la vie de l’application afin de supprimer les gaspillages (financier, humain, temporel…).
On retrouvera ainsi les principes d’améliorations continues, de petits incréments, de produit minimum viable… qu’on retrouve aussi dans l’agilité.

Measurement

Afin de savoir où on va, ce qui a été fait, seule la mesure permet d’avoir un regard le plus objectif possible et aider à la décision.
Là aussi, mesurer pourra se faire si le point automatisation est appliqué (sinon le risque est plus grand d’être subjectif).

Sharing

Le partage, la collaboration, la transparence… tout cela va permettre une boucle de feedback riche qui pourra nourrir les itérations.
C’est d’ailleurs une des bases de l’agilité, confronté le plus rapidement le produit au monde réel, la production et le client afin de s’adapter en permanence.
Alors finalement, la différence en agilité et DevOps, c’est quoi ?
Les deux visent le même objectif, la valeur ajoutée pour l’utilisateur. Le tout construit sur un processus itératif, via de petits incréments.
Le DevOps va permettre de préciser les directions à suivre (l’automatisation va permettre de répondre au manifeste agile “être capables de maintenir indéfiniment un rythme constant”), afin de tirer au maximum du bénéfice de l’agilité, sans pour autant imposer un choix.

Merci à Pierre-Yves Aillet, Antoine Carpier-Jouan, Guillaume Membré, Nicolas Bouron, Johan Bonneau, Sylvain Revereault, Jean-Louis Jouannic pour avoir contribué.