Voir la source de 24 capacités clés pour guider l'amélioration de la livraison logicielle

[[Category: Accelerate]]
[[Category: Pair Programming]]
[[Category: Culture]]
Auteur : IT Revolution<br />
Source : [https://itrevolution.com/articles/24-key-capabilities-to-drive-improvement-in-software-delivery/ 24 Key Capabilities to Drive Improvement in Software Delivery] et [https://octobench.octo.com/ OCTOBench]<br />
Date : 01/09/2020<br/>
----
Traducteurs : Fabrice Aimetti<br />
Date : 09/06/2023<br />
----
Traduction :<br />
<br />
Ce billet est adapté d'un extrait du livre [https://itrevolution.com/book/accelerate/ Accelerate] de Nicole Forsgren, PhD, Jez Humble et Gene Kim.<br/>
<br/>
Nos recherches, basées sur quatre années de publication du rapport State of DevOps, ont permis de découvrir 24 capacités clés qui améliorent les performances de livraison de logiciels de manière statistiquement significative. Le livre Accelerate détaille ces résultats. Ce article vous fournit une liste pratique de ces capacités.<br/>
<br/>
Nous avons classé ces capacités en cinq catégories. Dans chaque catégorie, les capacités sont présentées dans le désordre :
* Livraison continue (''Continuous Delivery'')
* Architecture (''Architecture'')
* Produit et processus (''Product & Process'')
* Lean Management et Monitoring (''Lean Management & Monitoring'')
* Culture (''Cultural'')
==Capacités de livraison continue==
'''Se donner visibilité et confiance :'''
* Objectif : obtenir une vision pipeline de l’ensemble de mon application jusqu’à la production.<br/>
* En pratique : sécurisation du pipeline, gestion automatique et maîtrisée de l’arrêt de la chaîne de delivery si des défauts sont repérés, versioning...
===Utiliser la gestion des versions pour tous les objets de production===
La gestion des versions consiste à utiliser un système de gestion des versions, tel que GitHub ou Subversion, pour tous les objets de production, y compris le code de l'application, les configurations de l'application, les configurations du système et les scripts d'automatisation de la construction et de la configuration de l'environnement.

===Automatiser votre processus de déploiement===
L'automatisation du déploiement correspond à un niveau de déploiement entièrement automatisé et ne nécessitant pas d'intervention manuelle.
===Mettre en place l'intégration continue===
L'intégration continue (CI) est la première étape vers la livraison continue. Il s'agit d'une pratique de développement dans laquelle le code est régulièrement vérifié, et chaque vérification déclenche une série de tests rapides pour découvrir les régressions les plus graves, que les développeurs corrigent immédiatement. Le processus d'intégration continue crée des builds et des paquets standards qui sont ensuite déployés et publiés.
===Utiliser les méthodes de développement basées sur les branches uniques===
Il a été démontré que le développement par branches est un facteur de haute performance dans le développement et la livraison de logiciels. Il se caractérise par moins de trois branches actives dans un entrepôt de code sources, des branches et des forks ayant une durée de vie très courte (par exemple, moins d'un jour) avant d'être fusionnés dans le master, et des équipes d'application ayant rarement ou jamais de périodes de "verrouillage du code" pendant lesquelles personne ne peut intégrer (check-in) du code ou faire des pull requests en raison de conflits de merge dans la branche principale, de gel du code ou de phases de stabilisation.
===Mettre en place l'automatisation des tests===
L'automatisation des tests est une pratique qui consiste à exécuter automatiquement (et non manuellement) des tests logiciels en continu tout au long du processus de développement. Les suites de tests efficaces sont fiables, c'est-à-dire que les tests détectent les défaillances réelles et ne laissent passer que le code pouvant être publié. Il est à noter que les développeurs doivent être les premiers responsables de la création et de la maintenance des suites de tests automatisés.
===Adoption de la gestion des données de test===
Les données de test nécessitent une maintenance rigoureuse, et la gestion des données de test devient une part de plus en plus importante des tests automatisés. Parmi les pratiques efficaces, citons le fait de disposer de données adéquates pour exécuter votre suite de tests, la capacité d'acquérir les données nécessaires à la demande, la capacité de conditionner vos données de test dans votre pipeline et le fait que les données ne limitent pas le nombre de tests que vous pouvez exécuter. Nous recommandons toutefois aux équipes de minimiser, dans la mesure du possible, la quantité de données de test nécessaires à l'exécution des tests automatisés.
===La sécurité au plus tôt===
L'intégration de la sécurité dans les phases de conception et de test du processus de développement des logiciels est essentielle pour améliorer les performances informatiques. Il s'agit notamment d'examiner la sécurité des applications, d'inclure l'équipe infosec (sécurité des données) dans le processus de conception et de démonstration des applications, d'utiliser des bibliothèques et des progiciels de sécurité agréés au préalable et de tester les fonctions de sécurité dans le cadre de la suite d'essais automatisés.
===Mettre en place la livraison continue (CD)===
La livraison continue (CD) est une pratique de développement où le logiciel est dans un état déployable tout au long de son cycle de vie, et l'équipe donne la priorité au maintien du logiciel dans un état déployable plutôt qu'au travail sur de nouvelles fonctionnalités. Tous les membres de l'équipe disposent d'un retour d'information rapide sur la qualité et la déployabilité du système, et lorsqu'ils reçoivent des rapports indiquant que le système n'est pas déployable, des correctifs sont rapidement apportés. Enfin, le système peut être déployé en production ou auprès des utilisateurs finaux à tout moment, à la demande.

==Capacités d’architecture==
'''Favoriser l’autonomie :'''
* Objectif : accompagner les équipes dans la maîtrise de leur périmètre en indépendance
* En pratique : identifier les domaines métier dans mon SI, responsabiliser les équipes quant à l'implémentation et le choix des outils...
===Utiliser une architecture faiblement couplée===
Cela affecte la mesure dans laquelle une équipe peut tester et déployer ses applications à la demande, sans nécessiter d'orchestration avec d'autres services. Une architecture faiblement couplée permet à vos équipes de travailler de manière indépendante, sans dépendre d'autres équipes pour le support et les services, ce qui leur permet de travailler rapidement et d'apporter de la valeur à l'organisation.
===Architecture pour des équipes autonomes===
Nos recherches montrent que les équipes qui peuvent choisir les outils à utiliser obtiennent de meilleurs résultats en matière de livraison continue et, à leur tour, améliorent les performances en matière de développement et de livraison de logiciels. Personne ne sait mieux que les praticiens ce dont ils ont besoin pour être efficaces.

==Capacités de produit et processus==
'''Valider itérativement le besoin :'''
* Objectif : garantir la visibilité jusqu’au client final et expérimenter rapidement
* En pratique : rendre le travail des équipes visible, recueillir rapidement les retours utilisateurs par des tests UX, travailler en petits lots...
===Recueillir et utiliser le feedback des clients===
Nos recherches ont montré que le fait que les organisations recherchent de façon proactive et régulière le feedback des clients et intègrent ce feedback dans la conception de leurs produits est important pour la performance de la livraison des logiciels.
===Rendre le flux de travail visible à travers la chaîne de valeur===
Les équipes devraient avoir une bonne compréhension et une bonne visibilité du flux de travail de l'entreprise jusqu'aux clients, y compris le statut des produits et des fonctionnalités. Nos recherches ont montré que cela avait un impact positif sur les performances IT.
===Travailler en petits lots===
Les équipes doivent découper le travail en petits éléments qui peuvent être réalisés en une semaine ou moins. La clé est de décomposer le travail en petites fonctionnalités qui permettent un développement rapide, au lieu de développer des fonctionnalités complexes sur des branches et de les publier peu fréquemment. Ce principe peut être appliqué au niveau de la fonctionnalité et du produit. (Un MVP est un prototype d'un produit comportant juste assez de fonctionnalités pour permettre un apprentissage validé du produit et de son modèle économique). Travailler en petits lots permet de raccourcir les délais et d'accélérer les boucles de rétroaction.
===Favoriser et permettre l'expérimentation en équipe===
L'expérimentation en équipe est la capacité des développeurs à tester de nouvelles idées et à créer et mettre à jour des spécifications au cours du processus de développement, sans avoir besoin de l'approbation d'une personne extérieure à l'équipe, ce qui leur permet d'innover rapidement et de créer de la valeur. Elle est particulièrement efficace lorsqu'elle est associée au travail en petits lots, à la prise en compte du feedback des clients et à la visibilité du flux de travail.

==Capacités de Lean Management et Monitoring==
'''Garantir la cohérence :'''
* Objectif : limiter les processus et piloter le produit avec une vue sur l’ensemble de la chaîne de valeur
* En pratique : fluidifier le processus de validation des changements, observer le système à l'aide de métriques, mettre en place une stratégie de notification...
===Avoir un processus simplifié de validation des changements===
Nos recherches montrent qu'un processus simplifié de validation des changements basé sur une revue par les pairs ("pair programming" ou revue de code dans l'équipe) permet d'obtenir de meilleures performances IT que le recours à des comités externes de validation des changements (CABs).
===Monitorer l'ensemble des applications et de l'infrastructure pour éclairer les décisions de l'entreprise===
Utiliser les données provenant des outils de surveillance des applications et de l'infrastructure pour prendre des mesures et des décisions métier. Cela ne se limite pas à appeler des personnes lorsque les choses tournent mal.
===Vérifier la santé du système de manière proactive===
Surveiller la santé du système, à l'aide de seuils et de messages d'alerte concernant le taux de changement, afin de permettre aux équipes de détecter et d'atténuer les problèmes de manière préventive.
===Améliorer les processus et gérer le travail avec des limites de travail en cours (WIP)===
L'utilisation de limites de travail en cours pour gérer le flux de travail est bien connue de la communauté Lean. Lorsqu'elle est utilisée efficacement, cette méthode permet d'améliorer les processus, d'augmenter le débit et de rendre les contraintes visibles dans le système.
===Visualiser le travail pour maîtriser la qualité et communiquer au sein de l'équipe===
Il a été démontré que les affichages visuels, tels que les tableaux de bord ou les sites web internes, utilisés pour maîtriser la qualité et les travaux en cours, contribuent aux performances de livraison des logiciels.

==Capacités culturelles==
'''Mesurer les signes :'''
* Objectif : agir sur les gestes quotidiens pour faire changer durablement la culture d’entreprise
* En pratique : encourager le partage, récompenser l'expérimentation, donner les moyens aux équipes pour réaliser leurs objectifs...
===Soutenir une culture générative===
Cette mesure de la culture organisationnelle est basée sur une [[Quelle_est_votre_culture_organisationnelle_:_Pathologique,_Bureaucratique_ou_Générative_%3F|classification élaborée par Ron Westrum]], un sociologue qui a étudié des systèmes complexes critiques pour la sécurité dans les domaines de l'aviation et des soins de santé. Nos recherches ont montré que cette mesure de la culture permet de prédire les performances de l'IT, les performances de l'organisation et la diminution de l'épuisement professionnel. Les signes distinctifs de cette mesure comprennent une bonne circulation de l'information, une coopération et une confiance élevées, ainsi que des passerelles entre les équipes et une démarche en conscience.
===Encourager et soutenir l'apprentissage===
Dans votre culture, l'apprentissage est-il considéré comme indispensable pour continuer à progresser ? L'apprentissage est-il considéré comme un coût ou un investissement ? Il s'agit d'une mesure de la culture d'apprentissage d'une organisation.
===Soutenir et faciliter la collaboration entre les équipes===
Cela reflète la qualité des interactions entre des équipes traditionnellement silotées, dans les domaines du développement, de l'exploitation et de la sécurité de l'information.
===Fournir des ressources et des outils qui donnent du sens au travail===
Cet indicateur spécifique de la satisfaction professionnelle concerne le fait d'effectuer un travail stimulant et utile, et d'être encouragé à exercer ses compétences et son discernement. Il s'agit également de disposer des outils et des ressources nécessaires pour bien faire son travail.
===Soutenir ou incarner le leadership transformationnel===
Le leadership transformationnel soutient et renforce le savoir-faire technique et les processus qui sont essentiels dans le cadre de DevOps. Il se compose de cinq facteurs : la vision, la stimulation intellectuelle, la communication inspirationnelle, le leadership soutenant et la reconnaissance personnelle.