Mettez le l'Ops dans vos Devs !

DevOps est plus qu'un buzzword. C'est une tendance de fond, basée sur le lean IT, qui touche aujourd'hui la DSI. En effet, la plupart doivent optimiser leurs processus delivery afin de répondre en temps réel aux besoins digitaux du business, tout en maintenant la qualité de la construction et la sûreté de fonctionnement de la production.

Quelque part, DevOps est la suite logique de l’agilité. L’agilité, quand elle fonctionne bien, a déjà réussi un grand challenge : faire en sorte que le métier et les études se parlent et se comprennent. Mais la valeur produite par une équipe agile n’a réellement de sens que lorsqu'elle est en production, et que son utilisation est fiable. DevOps étend donc le cercle de l’agilité à la prod.

Facile à dire, car c’est une démarche d’organisation globale, qui dépasse les seules équipes agiles. En revanche, rien n’empêche une équipe agile de faire un pas vers DevOps, voir d’être force de proposition dans cette transformation. 

Le but de ce billet n'est donc pas de décrire ce qu'est DevOps, il existe déjà beaucoup de littérature sur ce sujet. Le but est ici de donner quelques tips permettant à une équipe agile de faire un pas vers DevOps, sans révolutionner la DSI !

Tips 1 : l’Ops est un utilisateur du produit

Et de fait, l’opérateur est un utilisateur à part entière. Il installe, il met à jour, il vérifie, il diagnostique l’application et son état.  Il n’a peut-être pas d’IHM dernier cri à l’Angular.js, mais il a besoin de manipuler l’application pour la rendre opérationnelle et en extraire de l'information pertinente en cas de problème.

Dans le processus de construction, l’équipe agile doit donc s’enquérir des besoins des opérateurs, et ce dès l’élaboration initiale du Product Backlog. Il s'agit notamment d'identifier les besoins en termes d'installation à chaud, de retour-arrière, ou encore de diagnostique d'incident ou de bonne santé. Sans aller jusqu’à l’approche extrême d’Amazon « you build it, you run it », les Ops doivent pouvoir dire aux Devs : « you build it, you know how to run it ». Certains besoins Ops se traduiront alors naturellement en User Stories (que l'on peut appeler Ops Stories).

Tips 2 : les exigences non fonctionnelles sont mortes, vive les exigences trans-fonctionnelles 

Dans un contexte agile piloté par la valeur business, il existe une tendance à sous-estimer les exigences non directement issues du métier. Pourtant, quelle est la valeur d’une fonctionnalité si ses performances sont mauvaises ou sa sécurité non assurée ? Quelle est sa valeur résiduelle lorsqu’il faut attendre plusieurs mois pour pouvoir déployer un fix en production ?

Exploitabilité, maintenabilité, fiabilité, sécurité,... le terme "non fonctionnelles" associé à ce type d'exigences induit en erreur. Ces exigences sont le pilier de la qualité opérationnelle d'une fonctionnalité en production, mais aussi de la bonne vélocité de ses déploiements.

Parler plutôt d’exigences trans-fonctionnelles permet d'associer la notion de valeur métier à des besoins souvent considérés à tord comme purement techniques. Ces exigences entreront alors plus facilement dans la grille d'élaboration des critères d'acceptation des User Stories, et les négociations avec le Product Owner pour leur introduction dans le Product Backlog seront facilitées. 

Tips 3 : faire un produit "operation-ready"

L’intégration continue n’est plus un sujet, c’est désormais une pratique acquise de l’ingénierie logicielle. Mais souvent, l’automatisation se limite justement à l’intégration, avec les quelques tests unitaires qui vont avec. Et c’est une limitation à faire tomber si on veut avancer vers DevOps.

Le déploiement automatisé, et uniforme quelque soit l'environnement cible (intégration, recette, production), doit être un livrable associé au produit lui-même. Et la référence unique, c'est l'environnement de production. On peut progresser vers cet objectif Sprint après Sprint, mais l'important est l'alignement des outils et des process entre Devs et Ops que cela va automatiquement nécessiter. D'une manière ou d'une autre, ce qui est utilisé pour construire le produit doit être le reflet de ce qui est utilisé pour l'exploiter.

Le déploiement continu est un pilier important de DevOps,  même s'il ne s'agit pas forcément d'automatiser jusqu'en production. En revanche, "operation-ready" signifie que l'automatisation ne doit pas se limiter aux tests unitaires. Il faut enrichir progressivement une suite automatisée de tests fonctionnels afin de s'assurer de la non régression, mais aussi créer des smoke tests qui viendront s'assurer que l’application est opérationnelle dans son environnement une fois déployée.

Tips 4 : étendre le cercle de l'agilité 

Si les tips précédents sont mis en place, ça veut déjà dire que Devs et Ops se parlent et sont alignés en termes de besoins (US, AC), d'outils (CI/CD, VCS), et partagent un objectif de fiabilité des déploiements (Smoke Tests). Pourquoi ne pas officialiser et renforcer cette collaboration et faire des Ops de véritables stakeholders du process agile ?

• Backlog Grooming / Epic Review : lorsqu'il faut discuter des besoins Ops de l'application et les insérer dans le Product Backlog ou le Release Planning
• Sprint Planning : lorsqu'il est nécessaire d'identifier les tâches pour l'implémentation et la validation des besoins Ops
• Retrospective : lorsqu'il faut discuter des expériences de déploiement ou des incidents de production et s'améliorer collectivement
• Daily Meeting : lorsqu'il est nécessaire d’apporter des réponses rapides aux éventuelles questions des développeurs en cours d'implémentation
• Sprint Review : lorsqu'il est nécessaire que les Ops s'approprient le produit avant une nouvelle release 

Tips 5 : ce qu’il se passe en prod, ne reste pas en prod

Le feedback est une notion importante de l'agile, notamment dans XP. On doit pouvoir ajuster le produit en permanence avec les retours de ses utilisateurs. Mais pas que. 

Généralement, il existe des métriques de production liées au monitoring technique, plus ou moins bien partagées avec les Devs, mais qui peuvent déjà engendrer un feedback sur l'usage réel du produit dans son écosystème et sur l'expérience que peuvent en avoir ses utilisateurs. Cela peut concerner les temps de réponses, l’occurrence d’exceptions dans les logs, l’usage des ressources physiques (mémoire, processeurs, file-systems, pool de ressources, ...). Mais les Devs agiles, qui possèdent une relation privilégiée avec le métier (Product Owner), doivent pouvoir influer sur les besoins de métriques et orienter l'outillage de prod afin de superviser fonctionnellement le produit.

Le comportement des utilisateurs au travers des IHM de l'application, le taux d'usage de ses différentes fonctions ou encore l’impact d'une nouvelle release sur le business (hausse ou baisse du taux de transformation par exemple) sont autant d'éléments qui peuvent être trackés et partagés, et permettre d’identifier de nouvelles Stories, ou d'en ajuster les critères d'acceptation. L'objectif reste bien de maintenir les caractéristiques d'un produit au plus proche des besoins réels de ses promoteurs et de ses utilisateurs. 

Tips 6 : vers la prod agile

L'agilité n'est pas rentrée naturellement et simplement dans les équipes de Devs. Il y a eu sensibilisations, formations, expérimentations. Si cela a été bien compris et accompagné, cela fonctionne et l'amélioration continue est en place. Pourquoi ne pas capitaliser sur ces expériences et aider la prod à faire de même ?

Il est cependant évident que le caractère continu de l'activité de la production se prête mal à une approche de type Scrum (généralement en oeuvre coté Devs), qui doit définir une certaine quantité de travail à fournir sur un laps de temps fini (Sprint).

En revanche, elle se prête tout à fait au système Kanban, dont l'approche en flux continu de petits éléments de travail (ou classes de service) correspond déjà à une certaine réalité de l'activité des Ops. Il sera néanmoins nécessaire de passer d'un flux souvent poussé par les urgences à un flux tiré par le besoin et la capacité à faire. Le reste n'est que de la technique Kanban à mettre en place et à accompagner dans la durée (mapping des flux et des activités, management visuel, WIP et files d'attente, collaboration quotidienne, ...).

Conclusion

Des managements séparés, des outils différents, des process parallèles, de la défiance. Dans un contexte de transformation digitale où le business devient si étroitement lié à l'IT, ces murs, souvent établit par le passé entre Etudes et Production, doivent tomber. Le temps de cycle entre un concept et son apport de valeur doit être le plus court possible. L’agilité est légitime pour œuvrer dans ce sens, et les équipes agiles possèdent en elles beaucoup de leviers pour agir efficacement dans cette transformation. Alors qu'attendez-vous ?