Le framework en trois étapes pour adopter une plateforme de développement interne

Une plateforme de développement interne (IDP) peut aider vos développeurs à se consacrer pleinement au développement de logiciels, sans avoir à se soucier des pipelines de déploiement, de la gestion des configurations ou du provisionnement des environnements. En tant qu'engineering manager, c'est peut-être exactement ce que vous recherchez. Mais savoir que vous avez besoin d'une plateforme de développement interne et en adopter une sont deux choses bien différentes.

Même si la mise en place et la gestion des différentes plateformes nécessitent des moyens variables, une approche méthodique de leur adoption permettra à votre organisation de prendre le meilleur départ possible. Le choix d'une plateforme de développement interne adaptée et sa mise en œuvre réussie permettront de libérer un temps et des ressources considérables pour les développeurs.

Dans cet article, nous proposons un framework en trois étapes destiné aux engineering managers qui souhaitent passer de l'IDP à des mesures concrètes.

Nous allons vous expliquer comment :

  • Lancer un appel d'offres afin d'identifier des fournisseurs potentiels

  • Déployer l'outil de votre choix pour garantir son adoption

  • Mesurer la performance et suivre les progrès en matière d'expérience développeur

La rédaction d'un appel d'offres pour une plateforme de développement interne

La première étape pour adopter une solution IDP consiste à rédiger un appel d'offres. Un appel d'offres précise exactement ce que votre organisation attend d'une plateforme de développement interne. Les prestataires répondront par des propositions démontrant comment ils peuvent répondre à ces besoins, par exemple au moyen de démonstrations guidées et d'essais gratuits de logiciels. Votre équipe disposera ainsi d'une grille d'évaluation claire pour évaluer les propositions.

N'hésitez pas à inclure tout ce dont vous avez besoin dans une solution IDP

Il existe trois domaines principaux à prendre en compte dans vos appels d'offres :

  1. Défis : quels sont les défis auxquels vos équipes d'ingénieurs sont actuellement confrontées et auxquels une plateforme de développement interne pourrait contribuer à apporter une solution ? Vous aurez sans doute plusieurs défis majeurs à relever.

  2. Objectifs : quels résultats souhaitez-vous obtenir en adoptant une plateforme de développement interne ?

  3. Exigences produit : de quelles fonctionnalités et capacités avez-vous besoin pour atteindre ces objectifs ?

Par exemple :

Si vous constatez une perte des connaissances lorsque des développeurs rejoignent votre équipe ou changent d'équipe, votre objectif pourrait être d'accélérer leur intégration. Vous pourriez privilégier les fonctionnalités qui favorisent l'autogestion et réduisent les étapes de configuration manuelle, par exemple grâce à des workflows en libre-service et à l'intégration d'une base de connaissances.

Si votre service d'ingénierie est en pleine expansion et doit se conformer à davantage de bonnes pratiques et de normes, votre objectif pourrait être d'améliorer la sécurité et de réduire les vulnérabilités. Vous pourriez avoir besoin de fonctionnalités permettant l'intégration à des plateformes de sécurité et le suivi de la conformité à l'aide de tableaux de bord.

Si vous avez du mal à donner à vos ingénieurs les moyens d'être plus productifs et de consacrer davantage de temps aux tâches pour lesquelles ils excellent, votre objectif pourrait consister à réduire les délais de configuration afin que les équipes puissent mettre rapidement en place des services. Vous pourriez avoir besoin d'automatiser votre infrastructure et d'utiliser des modèles.

Faites le point sur votre situation actuelle

Pour mieux cerner vos défis et définir vos objectifs, évaluez la situation actuelle en matière d'expérience développeur au sein de votre entreprise. Ne partez pas du principe que vous connaissez déjà la situation actuelle ; essayez plutôt de mener des enquêtes auprès des développeurs, d'auditer les processus existants et d'organiser des groupes de discussion avec les développeurs afin d'identifier les points à améliorer. Veillez à expliquer les prochaines étapes que vous allez mettre en œuvre et à tenir les équipes informées de l'avancement de votre solution IDP.

Notre rapport sur l'état de l'expérience des développeurs a révélé que moins de la moitié des développeurs estiment que leur entreprise accorde la priorité à l'expérience des développeurs. Ce n'est pas surprenant quand on sait que deux développeurs sur trois perdent encore plus de 8 heures par semaine à cause d'un manque d'efficacité dans leur travail.

La mise en place d'une plateforme de développement interne

Une fois que vous aurez choisi une plateforme de développement interne, planifiez le processus de déploiement de manière collaborative et suivez son adoption. Une plateforme de développement interne prête à l'emploi réduira l'effort que le déploiement exigera de la part des membres de votre équipe. Par exemple, Compass nécessite bien moins de ressources techniques qu’une plateforme open source telle que Backstage, dont la mise en place et la maintenance requièrent quatre ingénieurs full-stack. Avec Compass, vous pouvez connecter vos outils de gestion de code source et importer vos dépôts pour alimenter votre catalogue de composants logiciels en seulement 10 minutes.

Formez un comité de pilotage

Pour que le déploiement se déroule encore plus harmonieusement, constituez un comité de pilotage composé de quelques parties prenantes clés. Ces experts apporteront leur soutien, suivront le processus et prendront les décisions nécessaires pour l'adapter si besoin.

Nous vous recommandons de contacter :

  • Un sponsor exécutif : la personne la plus haut placée qui dirigera les initiatives liées à la plateforme de développement. Le Chief Technology Officer, le VP of Engineering ou le Head of Platforms pourrait tout à fait convenir à ce rôle.

  • Des développeurs influents : choisissez un petit groupe de développeurs influents issus de l'ensemble de votre organisation pour qu'ils participent à la conception de votre plateforme de développement interne, ou pour qu'ils soient au moins tenus informés de vos plans de déploiement.

  • Une équipe plateforme ou des ingénieurs DevOps : les intégrations étant essentielles à la capacité des plateformes de développement internes à apporter de la valeur ajoutée, les responsables de ces outils doivent être des partenaires clés dans le cadre du déploiement.

  • Les propriétaires de politiques ou équipes de gouvernance : les plateformes de développement internes permettent aux équipes d'ingénierie de se conformer plus facilement aux normes et aux bonnes pratiques ; il peut donc être utile, lors de la planification, de collaborer avec les responsables de ces normes.

Créez un calendrier de déploiement

Une fois votre comité de pilotage mis en place, établissez un calendrier pour le déploiement de votre plateforme de développement interne. Communiquez ce calendrier à toutes les équipes qui utiliseront la nouvelle plateforme de développement interne et sollicitez davantage de feedback sur la faisabilité de votre projet afin de l'adapter si nécessaire. Au fur et à mesure que vous avancez dans le programme, faites régulièrement le point pour évaluer les progrès et le niveau d'adoption, et apporter votre aide.

Nous avons élaboré un guide d'implémentation pour Compass, afin de vous aider à vous lancer encore plus facilement.

Évaluer le succès d'une plateforme de développement interne

Pour évaluer vos progrès, revenez aux objectifs que vous aviez définis lorsque vous avez rédigé votre appel d'offres. Définissez des indicateurs de performance clés (KPI) tant qualitatifs que quantitatifs qui vous permettront d'évaluer de manière globale si votre plateforme de développement interne apporte bien la valeur ajoutée que vous recherchiez. Avec Compass, vous pouvez créer des tableaux de bord personnalisés pour définir vos indicateurs de performance clés (KPI) et vous assurer que vos équipes ingénierie visent toutes les mêmes objectifs.

La plupart des gens considèrent les KPI comme des « chiffres concrets » ou des « mesures objectives », ce qui est valable pour les concepts quantitatifs tels que le chiffre d'affaires ou les taux d'échec. Cependant, l'expérience des développeurs est subjective, ce qui signifie que les indicateurs de performance clés (KPI) seront plutôt qualitatifs, tels que la facilité perçue de mise en production des logiciels, la productivité perçue, ainsi que l'engagement ou la satisfaction des employés.

Trouvez les bonnes mesures pour votre organisation

Voici quelques exemples d'éléments que vous pourriez surveiller, en fonction de vos objectifs :

  • Si votre objectif était d'améliorer la sécurité, vous pourriez vous fixer comme but de réduire le nombre de vulnérabilités non corrigées d'un certain pourcentage chaque trimestre.

  • Si vous vous fixez pour objectif d'améliorer la productivité, votre indicateur de performance clé (KPI) pourrait être de réduire le délai d'exécution pour provisionner l'infrastructure de 5 jours à 2 heures.

  • Si votre objectif était d'accélérer l'intégration, vous pourriez mesurer le délai nécessaire aux nouveaux développeurs pour devenir opérationnels et vous efforcer de le réduire.

  • Si l'amélioration de l'expérience des développeurs est la priorité absolue, vous pourriez vous fixer pour objectif d'obtenir de meilleurs scores de satisfaction dans les enquêtes menées auprès des développeurs.

Continuez le suivi au fil du temps

Il faudra peut-être un certain temps avant que vous puissiez constater les effets de votre plateforme de développement interne. Continuez à suivre les progrès et organisez des points réguliers et des rétrospectives avec vos équipes afin de déterminer si la plateforme de développement interne produit les résultats escomptés au fil du temps.

Les rétrospectives d'équipe régulières donnent aux développeurs et aux dirigeants l'occasion de réfléchir à ce qui fonctionne bien et à ce qui ne fonctionne pas. Vous trouverez des instructions et des modèles de base pour les rétrospectives, ainsi que des variantes pour des situations spécifiques, dans le playbook Atlassian des équipes : scénario Rétrospective.