Construire une culture agile

La chute de la méthodologie de gestion de projet en cascade

Il y a de nombreuses années, j'ai été témoin d'un énorme projet informatique "en cascade" visant à remplacer une application métier entière. Le projet avait 3 ans de retard et des millions de dépassement de budget, et lorsqu'il a finalement été livré, les clients internes et externes ont rejeté la solution. Ils n'avaient pas participé à l'effort d'ingénierie, peut-être que les exigences avaient changé au cours des 5 années qu'il a fallu pour le construire, et plus important encore, ils n'avaient pas du tout vu le produit jusqu'à ce que tout soit terminé.

De nombreuses organisations ont partagé la même expérience et, par conséquent, ont commencé à adopter la méthodologie agile. Le principe est simple, montrer la progression au fur et à mesure que les fonctionnalités sont progressivement codées et ajoutées à la solution au fil du temps dans les versions. Le design est fluide et n'a pas à être défini complètement au début de l'effort. Et, plus important encore, les parties prenantes sont en mesure d'utiliser le logiciel dès le début et sont en mesure de fournir des commentaires et d'influencer la conception et l'ingénierie de la solution avant qu'elle ne soit terminée. Agile est une méthodologie de gestion de projet, mais c'est surtout une philosophie et une culture.

Agile a également cédé la place à la culture DevOps, le conflit séculaire entre les développeurs, qui veulent pousser le logiciel en production avant qu'il ne soit complètement cuit, et les équipes d'exploitation (Ops) qui veulent préserver un environnement de production stable avec le moins de changements possible. . Plus qu'un problème de fréquence de publication, l'objectif de DevOps est également de mettre fin au problème persistant de "Je l'ai construit, vous l'exécutez", qui obligeait les équipes Ops à être responsables du déploiement et du support de solutions logicielles dont elles n'avaient que peu ou pas de connaissances. . Non seulement DevOps permet aux équipes de développement de créer et de déployer rapidement des solutions, mais il leur confie également la responsabilité du support et de la disponibilité, ce qui à son tour tend à améliorer la qualité et la stabilité du produit logiciel. Les pipelines d'intégration continue et de déploiement continu (CI/CD) ont poussé l'agilité à l'extrême, chaque validation de code peut désormais être automatiquement construite, déployée, testée et finalement promue à travers les environnements jusqu'à la production. De nombreuses grandes entreprises informatiques sont désormais habituées à plusieurs centaines de déploiements de production par jour, bien loin de l'ancien temps.

Maintenir une "séparation des tâches" est également important pour de nombreuses organisations, un seul employé mécontent (ou un développeur junior maladroit) ne devrait jamais être autorisé à écrire du mauvais code et à le déployer jusqu'à l'environnement de production. En conséquence, dans de nombreux cas, les équipes de développement ne sont pas en mesure de déployer des solutions en production, les équipes d' ingénierie de la fiabilité du site (SRE) servent de « gardiens de la production » et offrent également un soulagement aux équipes de développement en prenant des fonctions de garde si une documentation de dépannage appropriée est fournie.

Parallèlement à la culture agile et DevOps, le concept de microservices a également gagné en popularité, comme le décrit la méthodologie à douze facteurs . L'idée n'est pas nouvelle, l'architecture orientée services (SOA) a également promu bon nombre des mêmes concepts, mais JSON et les progrès des langages de programmation modernes ont rendu son application beaucoup plus facile. Au lieu de créer d'énormes applications monolithiques, chaque fonction distincte peut être divisée en son propre microservice, qui peut être réutilisé par d'autres applications. Considérez-le comme des fonctions rendues disponibles via un appel API. Pour que ce concept fonctionne, les microservices doivent être découplés et indépendants les uns des autres. Le concept de microservices, une fonction commerciale distincte au sein de la solution globale, a également renforcé la notion de propriété du produit, par opposition à la gestion du produit. Les équipes DevOps sont responsables de cette fonction commerciale globale du début à la fin, elles possèdent cette solution et, à ce titre, ont la liberté et l'indépendance de faire des choix tels que les outils à utiliser et parfois les langages de programmation et les cadres à utiliser.

Livraison agile et continue - la culture d'ingénierie de Spotify

Ces vidéos sont un peu datées maintenant, mais toujours magnifiquement exécutées et toujours très pertinentes pour de nombreuses entreprises, grandes et petites.

La structure organisationnelle de Spotify est devenue populaire après qu'Henrik Kniberg a publié une vidéo détaillant le fonctionnement de la structure interne de l'entreprise, qui est divisée en équipes, tribus et guildes.

Leçons de Spotify : Créer une entreprise agile. Les normes culturelles de Spotify, décrites dans leurs vidéos sur la culture de l'ingénierie (Partie 1 et Partie 2), maintiennent l'alignement de l'équipe. 

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

La propriété de produit agile en bref

Une autre superbe vidéo également par Henrik Kniberg.