Améliorer les performances de développement

Voici une sélection de notes sur le livre Accelerate: Building and Scaling High Performing Technology Organizations.

Il présente les résultats d'une recherche sur les manières d'améliorer les performances des équipes de développement, notamment :

  • le leadership
  • les outils
  • l'automatisation
  • une culture d'apprentissage et d'amélioration continue

Pas grand-chose de fou dans ce livre si vous gravitez autour du monde des startups modernes, mais une manière rigoureuse de prouver les choses.

Même si la statistique est la première des sciences inexactes, ça fait du bien de se remettre en tête quelques évidences si souvent négligées.

Avant-propos

Foreword

Utilisez un backlog unique pour les nouvelles fonctionnalités et les tâches liées à la dette technique (NFR ou non-functional requirement) car :

  • les NFRs sont des fonctionnalités
  • résorber la dette technique améliore la stabilité du produit

Accélérer

Chap. 1 Accelerate

Les pratiques abordées dans ce livre sont issues du mouvement DevOps dont l'objectif initial est de pouvoir construire des systèmes distribués :

  • sécurisés
  • résilients
  • évoluant rapidement
  • pouvant passer à l'échelle

Les recherches montrent qu'aucun des facteurs suivants ne prédit des performances :

  • technologie utilisée ainsi que son âge
  • déploiements effectués par les équipes d'opérations ou de développement
  • présence d'un comité d'approbation des changements (CAB ou change advisory board)

Les recherches mettent en évidence 24 capacités clés qui favorisent l'amélioration des performances de livraison des logiciels et, par conséquent, des performances organisationnelles :

  1. utiliser un logiciel de gestion de versions (code, configuration, scripts etc.)
  2. automatiser le déploiement
  3. mettre en place l'intégration continue
  4. utiliser un modèle de développement à branche unique
  5. automatiser les tests
  6. gérer efficacement les données de test
  7. intégrer le processus de sécurité dans celui de développement
  8. mettre en place la livraison continue
  9. utiliser une architecture faiblement couplée
  10. laisser les équipes choisir les outils à utiliser
  11. recueillir et mettre en œuvre les retours des utilisateurs
  12. donner une bonne visibilité du statut des produits
  13. travailler en petits lots
  14. favoriser et permettre l'expérimentation au sein de l'équipe
  15. avoir un process léger d'approbation des modifications (revue de code)
  16. monitorer les applications/infrastructures pour orienter les décisions métier
  17. vérifier la santé du système de manière proactive
  18. améliorer les procédures et limiter la quantité de travail en cours (WIP)
  19. utiliser des tableaux de bord internes pour contrôler la qualité et communiquer au sein de l'équipe
  20. soutenir une culture générative
  21. encourager et soutenir l'apprentissage
  22. soutenir et faciliter la collaboration entre les équipes
  23. fournir des ressources et des outils qui donnent un sens au travail
  24. soutenir ou incarner un leadership "transformationnel"

Mesure des performances

Chap. 2 Measuring performance

La mesure des performances dans le domaine des logiciels est difficile, en partie parce qu'il n'y a pas d'inventaire visible.

Erreurs fréquentes :

  • mesurer les rendements (nombre de lignes de code etc…) plutôt que le résultat global
  • mesurer à l'échelle individuelle plutôt qu'à celle de l'équipe

Mesurer au niveau du résultat global permet de vérifier que les équipes ne sont pas opposées les unes aux autres.

Mesures pertinentes :

  • délai de livraison
  • fréquence de déploiement (déploiement continu)
  • délai de rétablissement du service
  • taux d'erreurs dans les nouvelles features

Les performances de livraison des logiciels sont tellement importantes qu'elles constituent un argument majeur contre la sous-traitance.

Changer la culture

Chap. 3 Measuring and changing culture

Qui fait partie de l'équipe importe moins que la façon dont ses membres interagissent, organisent leur travail et considèrent leurs contributions.

En d'autres termes, tout se résume à la dynamique de l'équipe.

Pratiques techniques

Chap. 4 Technical practices

Le travail imprévu et le fait de recommencer les choses sont des indicateurs utiles du niveau de qualité.

Leur profusion représente un échec dans l'intégration de la qualité dans les produits.

Architecture

Chap. 5 Architecture

Pour des performances de haut niveau, mettre le focus sur la facilité de déploiement et la testabilité.

Autres facteurs pour une haute performance de livraison :

  • architecture modulaire
  • culture générative orientée vers les résultats
  • livraison continue
  • leadership efficace

Ils permettent de faire croître les déploiements par développeur et par jour de façon linéaire.

Intégrer la sécurité de l'information dans le cycle de livraison

Chap. 6 Integrating infosec into the delivery lifecycle

Dans les équipes où la sécurité est une partie intégrante du travail quotidien des développeurs, les performances de livraison sont meilleures.

Prévoir des outils et des formations.

Voir :

Pratiques de management

Chap. 7 Management practices for software

Le mouvement lean découle du toyotisme, voir Lean Software Development.

Composantes du management lean appliquées au développement logiciel :

  • limiter le nombre de travaux en cours (WIP)
  • avoir sous forme visuelle
    • les principales mesures de qualité et de productivité
    • l'état actuel du travail (y compris les défauts)
    • les aligner sur les objectifs opérationnels
  • prendre des décisions métiers au quotidien sur la base des retours :
    • des données de performances et d'utilisation
    • des outils de monitoring de l'infrastructure
  • avoir un process léger d'approbation des modifications

Développement du produit

Chap. 8 Product development

Développement produit lean :

  • travailler par petits lots
  • rendre visible l'avancement des projets
  • recueillir et mettre en œuvre les retours utilisateurs
    • collecte régulière de la satisfaction (NPS)
    • recherche active d'informations auprès d'eux
    • utiliser les retours pour orienter la conception et les fonctionnalités
  • expérimenter en équipe

Objectifs :

  • éliminer le travail qui n'apporte aucune "valeur métier" (les pertes)
  • adopter une dynamique d'amélioration continue (tendre vers la perfection)

Faire que le travail soit confortable

Chap. 9 Making work sustainable

Problèmes ayant une influence sur la productivité :

  • difficultés de déploiement
  • épuisement professionnel (burnout)

Christina Maslach identifie 6 facteurs de risque organisationnels qui conduisent à l'épuisement :

  • surcharge de travail : les exigences dépassent les limites humaines
  • manque de contrôle : incapacité d'influencer sur les décisions qui affectent son travail
  • manque de récompenses : financières, institutionnelles ou sociales
  • problèmes dans la communauté de travail : incivilité, manque de soutien
  • absence d'équité : de salaires, de promotions ou de charge de travail
  • conflit entre ses valeurs personnelles et les exigences du travail

Satisfaction, identité et engagement des employés

Chap. 10 Employee satisfaction, identity, and engagement

Le NPS (Net Promoter Score) traditionnel est un score établi par les utilisateurs sur une échelle de 0 à 10 :

  • 9 ou 10, les promoteurs : ils ont tendance à acheter plus, à coûter moins cher à acquérir et à conserver, à rester plus longtemps et à générer du bouche-à-oreille positif
  • 7 ou 8, les passifs : ils sont satisfaits, mais beaucoup moins enthousiastes. Ils sont moins enclins à faire connaître le service et plus susceptibles de partir si quelque chose de mieux se présente
  • de 0 à 6, les détracteurs : ils coûtent plus cher à acquérir et à conserver, ils partent plus rapidement et peuvent nuire à l'entreprise par un bouche-à-oreille négatif

L'engagement des employés est mesuré par le eNPS (Employee Net Promoter Score).

Deux questions pour mesurer le eNPS :

  • recommanderiez-vous votre entreprise comme une entreprise où il fait bon travailler ?
  • recommanderiez-vous votre équipe comme une équipe dans laquelle il fait bon travailler ?

Quand les employés voient le lien entre leur travail et son impact positif sur les utilisateurs, ils s'identifient plus fortement à l'objectif de l'entreprise, ce qui conduit à une meilleure performance.

Leadership et management performants

Chap. 16 High-performance leadership and management

L'exemple du livre est la réorganisation des équipes IT d'ING.

Chacun des objectifs IT est lié à la stratégie de l'entreprise de façon mesurable.

Les équipes sont divisées en tribus (tribe) d'environ 150 personnes avec :

  • un lead de tribu qui :
    • établit les priorités
    • alloue les budgets
    • s'assure que la connaissance est partagée entre les tribus
  • un coach qui accompagne
    • les individus
    • les escouades

Les tribus sont divisées en escouades (squads) :

  • guidées par un chef de projet ou Product Owner (PO)
    • responsable de la coordination des activités
    • gère le backlog, la liste des tâches et fixe les priorités
  • conduites par un lead tech
  • composées de différents rôles alias équipes BizDevOps
  • dimensionnées selon la règle des deux pizzas : il faut pouvoir nourrir une équipe avec deux pizzas seulement
  • démantelées dès qu'une mission est terminée

Un des objectifs principaux du standup journalier est de réduire le temps que les gens passent en réunion.

Avant Notes sur The Manager's Path Après Le A3 japonais pour le management de l'information

Tag Kemar Joint