Changer la façon dont vos équipes planifient, construisent et livrent le logiciel
La transformation d'entreprise, telle que SEYA Group la pratique, consiste à changer la façon dont une organisation logicielle planifie, construit et met en production ses systèmes : qui est responsable de quoi, comment un changement atteint la production et quels outils l'y conduisent. Elle s'adresse aux organisations où le processus de mise en production est lui-même devenu la contrainte qui pèse sur l'activité.
À qui s'adresse ce service
Aux CIO qui parrainent un programme « DevOps » ou « digital » et ont besoin qu'il produise des changements dans la façon de travailler des équipes, avec une séquence que quelqu'un peut suivre. Aux directeurs informatiques qui voient des passages de relais, des tickets et des temps d'attente entre les équipes sans pouvoir dire lesquels sont nécessaires. Aux responsables d'ingénierie dont la chaîne d'outils s'est constituée achat après achat et ne correspond plus à la façon dont les gens livrent. Aux chefs de projet informatique à qui l'on a confié la transformation et qui ont besoin d'une feuille de route qui nomme ce qui vient en premier.
Si le problème est une application à reconstruire, c'est du développement cloud-native. S'il s'agit d'un ensemble connu de charges de travail à migrer, c'est plateforme cloud et migration. Cette page traite du modèle opérationnel à l'échelle des équipes.
Les problèmes que nous résolvons
- Du travail éclaté entre tickets et équipes, sans responsable unique pour le produit qu'il sert.
- Des mises en production qui exigent un comité de changement, un week-end et quelqu'un qui se souvient des étapes manuelles.
- Des outils de build et de déploiement choisis indépendamment du chemin de mise en production qu'ils sont censés servir.
- Aucune description partagée et honnête des pratiques de livraison réellement en usage.
- Un mandat de transformation venu d'en haut sans première étape convenue.
Ce que vous obtenez
- Revue de la livraison. Une comparaison de la façon dont vos équipes planifient, construisent, testent et mettent en production aujourd'hui avec un court ensemble de pratiques éprouvées, les écarts écrits clairement et les changements recommandés classés par priorité.
- Stratégie et feuille de route. Un plan séquencé de changements dans la livraison, lié aux contraintes que vous nommez, qui indique ce qui vient en premier et en consigne la raison.
- Modèle opérationnel. Qui est responsable d'un produit, comment une demande atteint la production et quels passages de relais peuvent être supprimés parce que la responsabilité est désormais claire. Rédigé pour que vos équipes le fassent vivre, dans leur langage.
- Conception et construction de la chaîne d'outils. Les outils servant à intégrer, tester et mettre en production les systèmes du périmètre, conçus pour suivre ces systèmes et construits lorsque le brief le prévoit.
- Session de conception. Lorsque le brief le demande, une session de travail animée qui transforme un problème produit en un backlog cadré sur lequel l'équipe peut démarrer.
Déroulement d'une mission
- Conversation avec le sponsor. Vous décrivez le mandat, les équipes du périmètre et la contrainte que vous voulez le plus voir disparaître.
- Revue de la livraison. Entretiens et observation dans les équipes, lecture de la chaîne d'outils actuelle et base de référence écrite que vous pouvez partager en interne.
- Feuille de route et modèle opérationnel. Nous rédigeons les deux, les revoyons avec les personnes qui devront vivre avec, et les révisons.
- Premiers changements. Les premiers éléments de la feuille de route sont mis en œuvre avec les équipes concernées, y compris la construction de la chaîne d'outils lorsque c'est convenu, pour que le plan soit confronté tôt à la réalité.
- Passation. Vos dirigeants sont propriétaires de la feuille de route et du modèle opérationnel, avec une revue répétée plus tard si vous souhaitez une seconde mesure.
Périmètre technique
Le travail sur la chaîne d'outils suit les systèmes que vous exploitez. SEYA a conçu et construit des pipelines de livraison sur des piles Microsoft (Team Foundation Server, Octopus Deploy, PowerShell) ainsi qu'avec Jenkins, GitHub Actions et Terraform sur AWS, Azure et Google Cloud. Le travail sur le modèle opérationnel est indépendant de la plateforme : la responsabilité produit, le flux de mise en production et la gestion des environnements s'appliquent quelle que soit la chaîne d'outils.
Ce dont vous avez besoin au départ
Un sponsor exécutif ayant autorité sur les équipes du périmètre, l'accès aux personnes qui font le travail pour les entretiens et l'observation, et la volonté de voir l'état actuel consigné honnêtement. Les changements sont faits par vos équipes ; SEYA conçoit, anime et construit lorsque c'est convenu, et ne prend pas en main votre processus de mise en production.
Hors périmètre ici : les postes de travail virtuels, les produits de digital workplace et la mise en place d'espaces de travail à distance ; les vérifications de sécurité dans le pipeline, ce qui relève de sécurité et DevSecOps ; et la décision d'adopter le cloud, ce qui relève de l'adoption du cloud. Si vous avez besoin de bras supplémentaires en ingénierie sur un travail défini, voyez ingénierie logicielle à grande échelle.
Sécurité
Les vérifications de sécurité dans le chemin de livraison constituent un périmètre distinct, décrit sur la page DevSecOps. Une feuille de route de transformation peut séquencer ce travail. Elle ne rend pas, à elle seule, le pipeline conforme à une norme donnée.
Réalisations associées
Questions fréquentes
S'agit-il d'une réorganisation ?
Cela y conduit parfois, et nous le dirons si la responsabilité ne peut pas être clarifiée avec la structure actuelle. Le point de départ est le flux de travail et qui en est responsable ; la structure en découle.
Allez-vous nous dire d'acheter de nouveaux outils ?
Seulement lorsque les outils actuels ne prennent pas en charge le chemin de mise en production dont vous avez besoin. La revue constate souvent que le problème tient à la façon dont les outils sont reliés entre eux plutôt qu'aux outils eux-mêmes.
Combien de temps dure la revue de la livraison ?
Elle est proportionnelle au nombre d'équipes et de systèmes dans le périmètre. Nous convenons de la liste lors de la conversation avec le sponsor, et la revue est rédigée autant pour les équipes qui y ont participé que pour la direction.
À qui appartient la feuille de route ensuite ?
À vous. La feuille de route, le modèle opérationnel et tout code de pipeline sont rédigés pour votre organisation et vivent dans vos systèmes.
Comment travaillez-vous avec nos équipes ?
En étant présents sur le terrain. Les entretiens, l'observation et les sessions de travail se font avec les personnes qui font le travail, et les premiers éléments de la feuille de route sont mis en œuvre avec elles.
Si votre processus de mise en production est devenu ce que tout le monde attend, réservez une conversation sur la revue de la livraison et nous vous dirons ce que la revue couvrirait pour vos équipes.
Contactez-nous
Envoyez une demande concernant un engagement cloud, plateforme, données ou fiabilité. L'e-mail marketing est une option distincte sur le formulaire.