Release à la demande

Développer sur la cadence. Libération à la demande.

—Un mantra de SAFe

Release à la demande

La release à la demande est le processus par lequel les nouvelles fonctionnalités sont déployées en production et diffusées immédiatement ou de manière incrémentielle aux clients en fonction de la demande.

La libération sur demande est la dernière dimension du pipeline de distribution continue en quatre parties, précédée de l’exploration continue (CE), de l’intégration continue (CI) et du déploiement continu (CD), comme le montre la figure 1.

Figure 1. La release sur demande est le dernier élément du pipeline de livraison continue.

Les trois dimensions qui précèdent Release on Demand permettent de s’assurer que les nouvelles fonctionnalités sont continuellement préparées et vérifiées dans l’environnement de production. Toutefois, étant donné que la valeur de développement tangible ne se produit que lorsque les utilisateurs finaux exploitent la solution dans leur environnement, il est essentiel de libérer cette valeur au bon moment pour que l’entreprise puisse obtenir les avantages réels de l’agilité.

La décision quant au moment et aux éléments à publier est un facteur économique clé qui nécessite un examen attentif. Pour beaucoup, la livraison continue est l’état final souhaité. Une nouvelle fonctionnalité est publiée dès son développement. Mais pour d’autres, le lancement est le plus souvent une activité à la demande découplée, se produisant pour des utilisateurs spécifiques, programmée au moment où ils en ont besoin, ou qui convient le mieux à l’Entreprise.

Détails

L’article sur les compétences de base DevOps et Release on Demand décrit comment l’entreprise crée la capacité de fournir des solutions de plus en plus utiles aux utilisateurs finaux avec une fréquence optimale. La deuxième partie de cette compétence, la capacité de publication sur demande, soulève trois questions (qui servent également de rappel du principe 3, Assumer la variabilité et préserver les options). Ce sont:

• Quand une release devrait-elle avoir lieu?
• Quels éléments du système doivent être libérés?
• Quels utilisateurs finaux doivent recevoir la version?

Garder ces options ouvertes aussi longtemps que raisonnable permet une flexibilité dans la création de valeur. Mais seule la publication peut «boucler la boucle» lors de l’évaluation de l’hypothèse de bénéfice proposée lors de la phase d’exploration continue du pipeline. La publication fournit les données nécessaires pour décider si une exploration plus approfondie d’une idée est justifiée, ou si de nouvelles fonctionnalités doivent être ajoutées, ou si une approche différente est justifiée.

Les quatre sous-dimensions de la libération sur demande

Conformément aux autres dimensions du pipeline, SAFe décrit quatre sous-dimensions de la release sur demande, comme l’illustre la figure 2:

• Release – couvre les compétences nécessaires pour fournir la solution aux utilisateurs finaux, tout à la fois ou progressivement
• Stabilize and Operate – couvre les compétences nécessaires pour s’assurer que la solution fonctionne correctement du point de vue fonctionnel et non fonctionnel
• Measure – couvre les compétences nécessaires pour quantifier si la fonctionnalité nouvellement publiée fournit la valeur recherchée
• Learn – englobe les compétences nécessaires pour décider de ce qui doit être fait avec les informations collectées et préparer la prochaine boucle du pipeline de distribution continue avec de nouvelles hypothèses

Figure 2. Quatre sous-dimensions de la release à la demande

Libérer la valeur pour le client

Lorsque la solution est en production et que son bon fonctionnement a été vérifié, le moment est venu de le mettre à la disposition des clients. Il s’agit là d’une décision cruciale pour l’entreprise car céder de la valeur trop tôt ou trop tard peut avoir de graves répercussions économiques. Ceci est la porte manuelle. Une fois que les développeurs ont engagé le code dans le contrôle de source, tout peut être automatisé jusqu’à ce point. Des modifications peuvent s’implanter dans le pipeline via CI et CD, voire même être plus petites que les récits, mais à l’approche de la publication, elles doivent être agrégées pour devenir des fonctionnalités minimales négociables (MMF), qui sont les plus petits éléments qui apportent valeur pour les clients. Désormais, en collaboration avec les parties prenantes, la gestion des produits doit prendre la décision de publier quoi, à qui et quand.

Quatre compétences contribuent à la capacité de publication :

• Lancements invisibles – permettent de déployer dans un environnement de production sans libérer la fonctionnalité pour les utilisateurs finaux.
• Feature toggles – Il s’agit d’une technique permettant de faciliter les lancements dans l’obscurité en implémentant des basculements dans le code, ce qui permet de basculer entre les anciennes et les nouvelles fonctionnalités.
• Canary release – ils fournissent un mécanisme permettant de libérer la solution pour un segment de clientèle spécifique et de mesurer les résultats, avant de pouvoir être étendus et diffusés à un plus grand nombre de clients.
• Découpler les éléments de libération – La libération sur demande soulève une question et une opportunité: une «libération» est-elle un processus monolithique, tout ou rien? Si tel était le cas, la stratégie de publication serait limitée. Afin de libérer quoi que ce soit, vous devez tout libérer. Heureusement, ce n’est pas le cas. En fait, même les solutions simples auront plusieurs éléments de version, chacun fonctionnant avec des stratégies de version différentes, comme le montre la figure 3.

Figure 3. Élément de publication dissocié de la solution

Par exemple, le site Web SAFe hébergeant cet article comporte plusieurs cycles de publication quelque peu indépendants.

• Nous pouvons corriger une version déployée ou résoudre un problème de sécurité à tout moment (ad hoc, mais en mode accéléré).
• Nous pouvons mettre à jour n’importe quel article à tout moment et en informer simplement les lecteurs via un message de blog (haute fréquence).
• Nous pouvons ajouter de nouveaux articles à la section Sujets avancés chaque fois que du nouveau contenu important est disponible (moyenne fréquence).
• Toutefois, les révisions majeures du cadre ne sont effectuées que périodiquement, sur la base de nouveaux contenus, de nouvelles façons de donner une image globale et, surtout, lorsque le marché est prêt pour une nouvelle version du cadre complet (basse fréquence).

Nous appelons ces flux distincts «flux de valeur», car ils représentent un flux complet de valeur de bout en bout dans un flux de valeur. Chaque ruisseau peut et doit être géré pour générer de la valeur en fonction de ses propres besoins et de son rythme. L’identification des flux de données est essentielle pour permettre la diffusion à la demande, car elle permet de diffuser indépendamment les différents éléments de la solution dans une cadence distincte. Ils fournissent également des indications sur la manière d’organiser les équipes et les ART afin qu’ils puissent indépendamment faire des release à la demande.

Stabiliser et exploiter

Les modifications apportées à la solution ont été vérifiées après leur déploiement, mais une fois que les clients y ont accès, de nouveaux problèmes peuvent survenir. Ces nouveaux problèmes peuvent non seulement être dus à l’augmentation de l’utilisation, mais également à des modèles d’utilisation inattendus. Lorsque des incidents et des menaces pour la sécurité sont découverts, ils doivent être résolus rapidement et dans le respect des accords sur les niveaux de service (SLA) convenus. La solution repose sur quatre compétences principales:

• Collaboration inter-équipes – Un état d’esprit de coopération dans le flux de valeur pour identifier et résoudre les problèmes à mesure qu’ils surviennent est crucial. Cela implique la création de trains de version Agile capables d’exploiter la solution et de la développer.
• Reprise en ligne / reprise sur sinistre – Des échecs surviendront. Il est important de développer un mécanisme de basculement pour permettre au service de reprendre rapidement, voire d’éviter une interruption du service. La reprise après sinistre doit être planifiée, intégrée au service et mise en pratique.
• Surveillance continue de la sécurité – Les tests de sécurité et de code de sécurité visent avant tout à empêcher les vulnérabilités connues d’entrer en production. Mais il est également important de tester en permanence les services pour détecter les vulnérabilités récemment découvertes et signalées et de détecter les intrusions et les attaques contre les services et les infrastructures.
• Architecte des opérations – Les besoins opérationnels doivent être pris en compte. Intégrez des fonctionnalités de télémétrie et de journalisation dans chaque application et dans la solution dans son ensemble. Permettre aux services d’être déclassés ou même supprimés en période de forte charge ou en réponse à des incidents. Construisez des capacités pour une récupération rapide et pour la réparation de correctifs.
• Surveiller les besoins non fonctionnels (NFR) – Les attributs système tels que la fiabilité, les performances, la maintenabilité, l’évolutivité et la convivialité doivent être surveillés en permanence pour éviter les interruptions de service.

Mesurer la valeur commerciale

La première sous-dimension du pipeline est une hypothèse. Dès que la valeur est transmise aux clients, il est temps d’utiliser la télémétrie de l’application pour mesurer l’hypothèse et la valeur commerciale fournie. Deux compétences soutiennent cet effort:

• Comptabilité de l’innovation – L’hypothèse d’évaluation nécessite des métriques différentes de celles utilisées pour mesurer les solutions fonctionnelles à l’état final. La comptabilité des innovations met l’accent sur la manière de mesurer les résultats commerciaux intermédiaires et prévisionnels de l’hypothèse, à la fois lors du développement initial de la solution et lors de l’évaluation du produit minimal viable.
• Télémétrie d’application – La télémétrie d’application est le principal mécanisme permettant de suivre les données d’utilisation et de les mesurer par rapport à l’hypothèse.

Apprendre et réagir

Les informations recueillies au cours de la sous-dimension de mesure doivent être analysées, puis une décision doit être prise sur ce qu’il faut faire ensuite, pivoter ou persévérer – supprimer ou continuer à développer. C’est également là que l’apprentissage du processus entre en vigueur et que l’information sur la manière dont la valeur a été générée doit être utilisée pour améliorer le pipeline de distribution continue. Pour ce faire, trois compétences sont nécessaires:

• Lean stratup thinking – Si les hypothèses et les MVP sont évalués, et si la décision est de savoir si les hypothèses ont été prouvées ou réfutées, si les efforts se poursuivent dans la direction actuelle, si les travaux doivent cesser, ou si de nouvelles hypothèses être formé pour évaluer différentes approches d’une même stratégie.
• Cartographie du flux de valeur – Un outil clé pour améliorer le flux de valeur dans le pipeline est la cartographie du flux de valeur. Cet outil (expliqué dans l’article sur le pipeline de distribution continue) fournit la visibilité nécessaire pour identifier les goulots d’étranglement et les zones à traiter, ainsi que pour concevoir un état futur et créer des facilitateurs permettant d’améliorer le pipeline.
• Amélioration continue – Le flux de travail peut toujours être amélioré. Cet état d’esprit fait partie de la SAFe House of Lean et est essentiel pour obtenir des résultats.

Lorsque les fonctionnalités sont dans les clients pratiques, la valeur est finalement réalisée. Lorsque cette valeur est mesurée, les connaissances informent des efforts d’exploration continus en cours, qui relancent le cycle. C’est la fin du pipeline pour une fonctionnalité et, en même temps, le début pour une autre, le pipeline de distribution continue génère une nouvelle valeur pour les utilisateurs et un nouvel apprentissage pour l’organisation tout le temps.

Gouvernance des publications

La gouvernance des versions est le processus de planification, de gestion et de gouvernance des versions des solutions, qui aide à orienter le flux de valeur vers les objectifs de l’entreprise. Dans certaines entreprises, en particulier celles dont les critères de réglementation et de conformité sont importants, il s’agit d’une équipe ou d’une fonction centralisée au niveau du portefeuille (la gestion des mises à jour est un terme commun) qui assure que les mises à jour répondent à tous les critères commerciaux pertinents.

Dans d’autres circonstances, ART et Solution Train leadership et les parties prenantes des opérations de développement, de la qualité, des ventes et d’autres parties prenantes prennent part aux responsabilités de gestion des versions et de gouvernance.

Dans les deux cas, la gouvernance des versions facilite les activités nécessaires pour aider les parties prenantes internes et externes à recevoir et à déployer la nouvelle solution. Cela garantit également que les éléments les plus critiques de la qualité de la gouvernance sont correctement pris en compte avant le déploiement, en particulier les consignes de sécurité internes et externes, réglementaires et autres.

La planification des versions fait partie du processus de PI Planning. Mais c’est la partie facile; Le plus difficile est de coordonner l’implémentation de toutes les fonctionnalités et fonctionnalités sur plusieurs itérations d’une même version. Cela est particulièrement vrai lorsque de nouveaux problèmes, de nouveaux obstacles, des dépendances et des lacunes dans Vision et les backlogs sont découverts. En raison de ces défis, la portée de chaque publication doit être continuellement gérée, revalidée et communiquée. Les considérations principales incluent:

• Veiller à ce que la gouvernance de la publication de l’organisation soit comprise et respectée
• Communiquer le statut de la publication aux parties prenantes externes
• Veiller à ce qu’un plan de déploiement approprié soit en place
• Coordination avec le marketing et la gestion des produits et des solutions pour les communications internes et externes
• Vérification de la conformité de la solution aux critères de qualité et de conformité pertinents
• Participer à Inspect and Adapt (I&A) pour améliorer le processus de publication, la productivité et la qualité de la solution, ainsi que la qualité de la solution.
• Fournir l’autorisation finale pour la publication.
• Assurer la liaison avec Lean Portfolio Management (LPM), selon le cas.
• Participer et superviser les activités de publication finales.

De nombreuses entreprises organisent des réunions hebdomadaires sur la gouvernance des communiqués afin de répondre aux questions suivantes:

• La vision est-elle toujours comprise et les trains et les équipes sont-ils alignés à cette fin?
• Est-ce que tout le monde comprend ce qu’ils construisent et est-ce que cela concorde avec la compréhension de l’objectif du flux de valeur et des thèmes stratégiques actuels?
• Les trains suivent-ils les dates de sortie prévues?
• La qualité appropriée est-elle intégrée à la solution?
• Quels sont les obstacles à surmonter pour faciliter les progrès?

Cette réunion hebdomadaire offre aux membres de la haute direction une visibilité régulière sur les progrès de la publication. C’est également l’endroit pour approuver toute modification de portée, de calendrier, de personnel ou de ressources nécessaire pour assurer la publication. Dans un environnement de diffusion plus continu, les participants surveillent de près la section de publication du programme Kanban, s’assurant que les éléments sont diffusés lorsque cela est nécessaire pour le public cible approprié, gèrent les diffusions sombres et canaris, vérifient que les hypothèses sont évaluées et que les fonctionnalités sont supprimées après la vérification de la production.

Apprendre encore plus

[1] Ries, Eric. Lean Startup: comment les entrepreneurs d’aujourd’hui utilisent l’innovation continue pour créer des entreprises radicalement performantes. Random House, Inc.

[2] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc.

[3] Leffingwell, doyen. Configuration logicielle requise pour les logiciels agiles: pratiques de configuration simplifiée pour les équipes, les programmes et l’entreprise (série de développement logiciel agile). Pearson Education.

[4] http://www.innovationgames.com [5] Gothelf, Jeff et Josh Seiden. Lean UX: Concevoir des produits de qualité avec des équipes agiles. O’Reilly Media.

© Scaled Agile, Inc.