Le mouvement DevOps permet de déployer des applications rapidement, mais ce qui fait son véritable succès c'est la qualité des décisions que prennent les membres des équipes. C'est possible grâce à l'autonomie et à la liberté apportée par cette philosophie, sans oublier la culture de l'amélioration continue.
Ne pas se tromper !
C'est ce que pense Mark Schwartz, stratège entreprise chez Amazon Web Services et auteur de WAR & PEACE & IT. Pour lui, les meilleurs résultats sont obtenus en cherchant à atteindre des objectifs, et non à suivre des exigences fixées par un pouvoir central lointain.
Souvent, les entreprises ont tendance à imposer des contraintes à une équipe pour répondre à un cas d’usage métier. Pourtant, c'est l’objectif global de l'entreprise que nous devrions chercher à atteindre ! En procédant ainsi, nous ajoutons souvent une étape de plus où il est possible de se tromper. Rappelons-le, plus la chaîne de décision est courte plus nous pouvons faire rapidement les bons choix.
Habituellement, les objectifs sont exposés en une série d’exigences et de cas d’usage métier. Les équipes techniques n'ont aucune prise sur les décisions ou l'amélioration des processus. Pourtant, c'est bien eux qui forgent les outils. C'est une sorte d’infantilisation, comme s'ils n'étaient pas capables de travailler à partir d'objectifs stratégiques. C'est d’autant plus problématique que souvent, dans un contexte agile, ce sont eux qui sont en relation avec les utilisateurs finaux. C'est même une des bases de l'agilité qui leur permet de s'adapter et d'être flexibles.
« C'est un peu étrange si l'on y réfléchit, parce que l'ajout de ces exigences augmente en fait le risque pour le projet. Vous avez maintenant ajouté le risque que vos exigences ne soient pas les bonnes. » - Mark Schwartz, keynote lors du DevOps Enterprise Summit 2018.
Chez AWS, ils ont pris des décisions stratégiques qui ont été directement transmises aux équipes. Ces équipes sont pluridisciplinaires, car elles regroupent des développeurs, des Ops, des testeurs, des experts de la sécurité ainsi que des exploitants opérationnels.
Selon lui, il faut comprendre que l'important n'est pas de faire plus vite, mais de faire mieux. Même si dans une démarche DevOps la réduction du Time-to-market est importante, cela ne doit pas être le but. Ce que nous devons trouver est comment l'entreprise peut conserver un contrôle sain. Et s’assurer qu’elle prend les bonnes décisions dans un contexte de compétition commerciale où tout va très vite.
🎓 DÉMARRE LA FORMATION | DEVOPS MINDSET | 🎓
Innovation et robustesse
Schwartz démolit aussi, avec raison, l'idée qu'il faut séparer les dépenses d'investissements, qui forgent l'innovation, et les dépenses de maintenance. En effet, en faisant cela nous pouvons être amenés à vouloir réduire les coûts de maintenance. Or, c'est bien parce que nous avons une infrastructure robuste et résiliente que nous pouvons nous permettre d'innover facilement et sans se poser de questions.
Cette séparation comptable renforce les frictions entre les équipes Dev et Ops, car le management a des contraintes et des objectifs divergents.
Comptabilité et I.T. ! À ce propos, je vous renvoie à l’excellente conférence que Quentin Adam a donnée aux Voxxed Days Luxembourg 2016 nommée Les comptables ont fucked-up la gestion de mon I.T. Je partage totalement sa vision de la comptabilité d'une entreprise qui suit les préceptes DevOps.
Sans compter que, comme le rappelle Schwartz, il y a également de l’innovation dans la maintenance de l'infrastructure ! C'est aussi là que l'entreprise peut progresser. Avoir une infrastructure qui suit les besoins de l'entreprise est porteur, alors qu'une entreprise réduisant les coûts risque d'avoir une infra vieillissante bien loin des besoins d'agilité des développeurs.
Un logiciel n'a pas besoin d'être entretenu. Puisqu'il s'agit de code, il continuera à fonctionner comme au premier jour. Cependant, comme les entreprises ont besoin d'évoluer, si elles ne veulent pas être rattrapées par leurs concurrents, elles doivent faire évoluer leurs logiciels. Or, les coûts de maintenance sont directement liés aux modifications à apporter dans les logiciels.
Et vous ? Comment transmettez-vous vos décisions stratégiques à vos équipes I.T. ?
Vous recherchez une communauté en ligne pour discuter autour de ce mouvement ?
Photo by Hendrik Morkel on Unsplash
