Licence CC BY

[Livre] "Accelerate" : la science derrière DevOps et le Lean Software

Une approche scientifique rigoureuse des bonnes pratiques de développement

Récemment, mes lectures m’ont fait tomber sur cet ouvrage, paru en 2018 :

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, par Nicole Forsgren, Jez Humble, et Gene Kim.

Il s’agit du résultat de 4 ans d’études de la performance des équipes de développement logiciel de plus de 1000 entreprises différentes, et d’analyse des principaux facteurs qui l’affectent. Ce qui rend ce livre vraiment intéressant, c’est que les auteurs ne se contentent pas d’y raconter leurs conclusions, mais également leur méthode d’analyse. Autrement dit, les auteurs ne se contentent pas de nous dire quelles pratiques fonctionnent ou non, ils nous donnent également les outils pour vérifier que cela fonctionne également dans le contexte de notre boîte et de notre équipe, et surtout des métriques à observer pour nous y aider au quotidien.

C’est un ouvrage assez long, qui aborde de très nombreux aspects du métier, et le fait que ses conclusions soient le fruit d’une étude scientifique rigoureuse me donne envie de pouvoir m’y référer facilement à l’avenir.

Dans ce billet je vais résumer les points qui me semblent importants à retenir des premiers chapitres.

Mesurer les performances de la production du logiciel

Comment NE PAS mesurer la performance d’une équipe

Le livre mentionne trois exemples de mesure de performances qui sont couramment utilisées et qui sont en réalité contre-productives.

  • Le nombre de lignes de code produites : cet indicateur pousse les développeurs à produire du code en quantité plutôt qu’en qualité, et a un impact très négatif sur la maintenabilité des projets,
  • La vélocité : la vélocité d’une équipe est à l’origine un outil d'aide à la planification basé sur une estimation a priori de la complexité du travail à accomplir. Cette grandeur est spécifique à chaque équipe (elle ne peut pas servir de point de comparaison), et s’en servir comme un KPI incite les équipes à surestimer leurs tâches et à abattre le plus possible de user stories pour gonfler la vélocité au détriment de la qualité, ce qui détruit tout l’intérêt de mesurer leur vélocité à l’origine.
  • L'utilisation, c’est-à-dire la proportion de leur temps que les ingénieurs passent à travailler sur des tâches planifiées. Le problème de cette mesure est que plus l’utilisation des ingénieurs s’approche du 100%, plus les équipes mettent de temps à accomplir quoi que ce soit car elles n’ont alors simplement plus le temps de s’occuper d’améliorer le logiciel, de réagir à des changements de plans ou d’absorber des tâches non planifiées.

Choisir de bons indicateurs de performances

Pour mesurer efficacement la performance, il faut utiliser des indicateurs qui représentent des résultats globaux (global outcomes), afin d’éviter que les indicateurs ne poussent les équipes à se tirer dans les pattes : l’exemple le plus classique de ce problème, c’est de mesurer les performances d’une équipe de développement en fonction de la quantité de logiciel écrite et celles de l’équipe opérationnelle par la stabilité du système.

Le second critère d’un bon KPI est qu’il doit refléter un résultat (outcome) et non "la quantité produite" (output), de manière à ce qu’il n’encourage pas les gens à s’agiter pour produire de grandes quantité de travail qui ne sert à rien.

Les auteurs proposent quatre mesures de performances qui satisfont ces critères :

Delivery Lead Time

Le "Lead Time" est une métrique caractéristique de l’approche Lean, qui consiste à mesurer le temps entre le moment où un client exprime un besoin et celui où ce besoin est satisfait. Le cas particulier du logiciel impose quelques adaptations : un ticket pour une nouvelle fonctionnalité peut être créé longtemps avant qu’un développeur ne travaille dessus, et les tâches en question ont une complexité très variable, et c’est normal.

Dans ce contexte, le Delivery Lead Time mesure le temps entre le moment où le code d’une fonctionnalité est commité, et celui où la fonctionnalité tourne correctement en production. Le temps de design et de production du code (qui dépendent en premier lieu de la complexité des tâches à accomplir et sont extrêmement variables) n’est donc pas pris en compte.

Plus ce temps est court, plus le feedback de la part des utilisateurs est rapide, plus il devient facile de s’adapter aux changements de plan et, évidemment, de réagir lorsque l’on constate un bug ou une panne.

Dans leur étude, cette mesure pouvait prendre les valeurs suivantes :

  • Moins d’une heure,
  • Moins d’une journée,
  • Entre une journée et une semaine,
  • Entre une semaine et un mois,
  • Entre un mois et six mois,
  • Plus de six mois.

Deployment Frequency

Une autre métrique caractéristique de l’approche Lean, c’est la taille des "batches" de travail. Autrement dit, il vaut mieux morceler le travail pour le produire en petites quantités régulières. Transposer cette notion à la production de logiciel où il n’existe ni stock ni inventaire n’est pas aisé, et les auteurs proposent d’utiliser la fréquence des déploiements comme un proxy pour cette grandeur : plus une équipe déploie fréquemment, plus les déploiements représentent de petites quantités de travail livrées.

L’étude classifiait les résultats selon les valeurs suivantes :

  • À la demande (plusieurs déploiements par jour),
  • Entre une fois par heure et une fois par jour,
  • Entre une fois par jour et une fois par semaine,
  • Entre une fois par semaine et une fois par mois,
  • Entre une fois par mois et une fois tous les six mois,
  • Moins d’une fois tous les six mois.

Time To Restore

Les deux indicateurs précédents mesurent le tempo auquel le logiciel est produit et déployé, mais il importe que l’amélioration de ce tempo ne se fasse pas au détriment de la qualité et de la fiabilité du logiciel.

En général, la fiabilité se mesure comme le temps qui sépare deux défaillances. Dans le contexte du logiciel, c’est un peu plus compliqué : la complexité des systèmes modernes et la vitesse à laquelle ils changent font que les défaillances sont inévitables. Autrement dit, la question "à quelle fréquence observons-nous des défaillances" n’est pas aussi intéressante que de savoir "à quelle vitesse le service est rétabli en cas de défaillance".

Autrement dit, cet indicateur mesure le temps moyen que mettent les incidents à être résolus et les bugs à être corrigés, avec les mêmes valeurs types que pour le Delivery Lead Time.

Change Fail Rate

Ce dernier indicateur mesure également l’aspect qualité de la performance. Il s’agit de répondre à la question "quelle proportion de changements apportés au produit résultent en une défaillance lorsqu’ils sont déployés ?".

Il s’agit donc de quantifier la confiance avec laquelle on déploie des changements.

Résultats

Pendant plusieurs années consécutives, les auteurs ont étudié les caractéristiques de nombreuses organisations qui produisaient du logiciel, de toutes tailles (de la startup de 5 personnes aux mastodontes d’Internet) et de tous types (en incluant par exemple des agences gouvernementales américaines). Je vous laisse vous plonger dans le livre pour avoir leur méthodologie exacte.

Les premiers résultats intéressants sont les valeurs que prennent ces 4 indicateurs dans les organisations qui sont les plus performantes :

  • Deployment Frequency : à la demande (plus d’une fois par jour),
  • Delivery Lead Time : moins d’une heure,
  • Time To Restore : moins d’une heure,
  • Change Failure Rate : entre 0 et 15%

Ce qui est peut-être plus intéressant, c’est le reste de l’analyse. D’abord, l’étude confirme qu'il n’y a aucun compromis à faire entre la vitesse à laquelle on livre le logiciel et sa qualité : les organisations qui réussissent le mieux excellent sur les deux, ce qui confirme les prédictions des philosophies Agile et DevOps. D’ailleurs, les organisations qui ont tendance à favoriser la vitesse à laquelle le logiciel est livré au détriment de sa qualité forment un cluster clairement identifiable aux performances médiocres. Autrement dit faire les choses vite, c’est les faire rigoureusement bien, tout le temps.

Mais ce qui est encore plus intéressant, c’est que la performance de production du logiciel telle que mesurée ici est un prédicteur des performances organisationnelles (commerciales) et non-commerciales de l’organisation. Autrement dit, les quatre indicateurs de performance que nous venons de définir ont une influence directe, indiscutable, sur la réussite d’une entreprise ou d’une organisation, et donc il est important d’y accorder la plus grande attention.

En somme, non seulement mettre la qualité logicielle au centre du développement est la seule manière de le produire rapidement et d’en tirer rapidement un retour sur investissement, mais cette hausse de performance a également un impact direct sur le résultat de l’entreprise. Cet impact est bien souvent le chaînon manquant lorsque l’on discute de mesures pour améliorer la qualité du code avec des décideurs qui en sont déconnectés : le voici, on ne peut plus clairement caractérisé ici.

Ces résultats fournissent également un argument de poids contre le fait d’outsourcer le développement de logiciel quand celui-ci revêt une importance stratégique pour l’entreprise : il y a tout à gagner à le développer en interne afin de maîtriser ces indicateurs.

Mesurer et changer la culture d'une organisation

Attends.. quoi ?! o_O

Afin de mesurer l’impact de la culture des organisations sur leur performances, il est nécessaire de trouver un moyen de la quantifier. Pour cela, les auteurs ont utilisé une typologie développée par le sociologue Ron Westrum en 1988, qui permet de classifier la culture d’une entreprise selon trois grandes catégories (les extrémités et le centre d’un continuum) :

  • Pathologique ("orientée pouvoir") : il s’agit d’organisations qui marchent à la "peur" ou la "menace", où l’information est souvent retenue ou distordue pour des raisons politiques.
    • Peu de coopération,
    • Le "messager" est puni en cas de mauvaises nouvelles,
    • Les responsabilités sont esquivées,
    • La transversalité ("bridging") est découragée,
    • Un échec/une défaillance conduit à la recherche d’un coupable,
    • La nouveauté est rejetée,
  • Bureaucratique ("orientée règles") : ces organisations se composent généralement de divers "départements" indépendants qui tiennent leur "terrain" et sont poussées par le respect des règles et des procédures.
    • Coopération modeste,
    • Le "messager" est négligé,
    • Les responsabilités sont finement ajustées et limitées,
    • La transversalité est tolérée,
    • Un échec/une défaillance conduit à "la justice",
    • La nouveauté apporte des problèmes,
  • Générative ("orientée performances") : il s’agit des organisations concentrées sur leur mission où chaque décision est subordonnée à l’atteinte des objectifs et aux bonnes performances.
    • Haut niveau de coopération,
    • Le "messager" est formé,
    • Les risques sont partagés,
    • La transversalité est encouragée,
    • Un échec/une défaillance conduit à une "enquête" pour en comprendre les causes,
    • La nouveauté est implémentée,

Il est à noter que la bureaucratie n’est pas nécessairement mauvaise : le but de la bureaucratie est d’établir des règles qui contribuent à l’équité et à supprimer l’arbitraire dans toute l’organisation. Par ailleurs, cette notion de culture est totalement orthogonale au fait que l’organisation soit une startup ou une grosse société ou fasse même partie de la fonction publique :

Westrum’s description of a rule-oriented culture is perhaps best thought of as one where following the rules is considered more important than achieving the mission—and we have worked with teams in the US Federal Government we would have no issue describing as generative, as well as startups that are clearly pathological.

Les auteurs détaillent la façon dont ils ont construit et validé une mesure quantifiable de la culture "Westrum". Il n’est pas utile que je m’étende plus là-dessus ici.

Résultats

L’étude confirme les deux hypothèses suivantes :

  • La "culture Westrum" est un prédicteur tant de la performance de production du logiciel que de la performance commerciale/organisationnelle des entreprises,
  • La "culture Westrum" est un prédicteur de la satisfaction au travail.

Les conclusions que les auteurs tirent de ce résultat sont nombreuses et enfoncent ce qui me semble être des portes ouvertes : la qualité de la coopération et de la communication entre les gens, influencée par la culture de l’organisation, se reflète sur la production du logiciel et donc sur la performance organisationnelle. Ce n’est rien de nouveau, mais c’est irréfutable.

Une conclusion peut-être moins triviale porte sur la réaction que l’on devrait avoir face à une défaillance ou une panne : au-delà du fait qu’il est contre-productif de chercher un bouc-émissaire, l’investigation d’une panne ne devrait jamais s’arrêter à "cause: erreur humaine". Cela devrait plutôt être le point de départ de l’investigation, puisque le but est d’améliorer la façon dont l’information circule dans l’organisation, ou se doter d’outils plus efficaces pour éviter que les défaillances ne puissent se produire à nouveau.

Mais le résultat vraiment intéressant ici, c’est celui qui vise à répondre à la question "comment changer la culture de mon organisation ?". Les auteurs prouvent que le moyen le plus efficace n’est pas de s’attaquer à ce que pensent les gens, mais à leur comportement. Pour ce faire, ils ont établi que l’adoption de pratiques de management Lean d’une part, et des pratiques associées au Continuous Delivery d’autre part, sont deux prédicteurs de la "culture Westrum".

Autrement dit : la meilleure chance dont on dispose pour changer la culture d’une organisation, c’est de changer ses pratiques et de laisser les flux de communication entre les gens s’adapter en conséquence.

Avis perso

J’aurais tendance à vouloir tempérer cette conclusion : ça a l’air facile, dit comme ça.

Dans la réalité, il ne suffit pas de changer n’importe quoi ni de jeter du Agile sur une équipe de développement pour que tout aille mieux dans le meilleur des mondes.

Encore faut-il s’assurer que ces pratiques sont adoptées dans un but clair et précis (améliorer les performances de la production du logiciel), dans un effort de la part de toute l’organisation, et pas pour des raisons purement politiques ou idéologiques ("définir des nouvelles règles qui marcheront peut-être mieux"). C’est un changement radical que l’on ne peut pas se permettre de faire à moitié, sous peine de résultats potentiellement désastreux pour l’organisation.


11 commentaires

Merci pour ce retour de lecture détaillé !

Pour qui chercherait le livre, il ne semble pas voir été traduit, mais est disponible en version électronique en France pour un prix tout à fait raisonnable pour ce genre d’ouvrage (10,12 €).

L’ISBN de la version électronique est 978–1942788355 ; celui de la version papier est 978–1942788331.

À noter qu’une réédition mise à jour est déjà prévue pour octobre 2022, ISBN 978–1950508648 pour la future version papier (je n’ai pas celui de la version numérique).

Je vais sûrement écrire d’autres billets qui prennent ce livre comme source.

Là, je dois avoir résumé environ 20% de la première partie (deux-trois chapitres).

Il reste énormément de contenu, notamment sur les pratiques (d’architecture, de management, de développement…) qui fonctionnent et celles qui ne marchent pas, qui vaut le coup qu’on puisse le citer facilement comme une source fiable.

Les autres parties du livre portent plus sur l’étude elle-même, elles sont très intéressantes à lire mais certainement pas aussi punchy que la première.

+2 -0

Un truc qui me perturbe dans les métriques choisies, c’est qu’elles ne s’appliquent à ma connaissance à aucun des logiciels dont j’ai connaissance des pratiques de développement, soit dans mon milieu professionnel (qui n’est pas le web ou du SaaS) soit en tant que contributeur libre. On travaille sur du logiciel, quand on est satisfait des nouvelles fonctionnalités accumulées on fait une nouvelle version (certains projets ont un rythme régulier, typiquement "tous les six mois", parfois "tous les trois mois"). Ça donne des trucs du genre:

  • Delivery lead time (temps du commit à la production): impossible à dire car nos utilisateurs mettent à jour leurs systèmes à des rythmes différents. Un utilisateur expert avec des besoins poussés peut essayer la version "dev" qui apporte une fonctionnalité importante le lendemain de son intégration, ou en amont pour nous aider à tester une proposition de changement; mais c’est très rare. Le cas typique, c’est qu’on a une release 3 mois après le merge (ou plus), et nos utilisateurs l’adoptent très vite sur certains projets, des mois ou années après sur des projets qui évoluent plus lentement selon leurs contraintes internes.

  • Deployment frequency: qu’est-ce qu’un déploiement pour un logiciel libre ? La sortie d’une nouvelle version ? Donc, ben, "tous les six mois" en gros.

  • Time to restore: le temps entre un rapport de bug et le correctif. Ça dépend si on attend la release qui corrige le bug (là c’est "des mois" en général, et dans quelques cas rares "des jours/semaines" quand c’est un bug de sécurité qui conduit à une release en urgence), ou alors le temps entre le rapport et l’intégration du fix, et là c’est "quelques jours si c’est un bug facile et un contributeur est motivé, souvent des mois, 'jamais’ souvent car le bug n’est pas important". Dans les projets dont je connais le développement, aucun n’essaie de corriger les bugs signalés dans la journée, ce serait plutôt considéré comme une mauvaise pratique, stressante pour les contributeurs. Et "10 à 15 minutes", ça n’a juste pas de sens.

  • Change Fail Rate: ce critère pour le coup est pertinent, mais à ma connaissance pas mesuré (c’est une plus-value du travail décrit que de faire un effort de mesure).

Donc bon: ce document couvre peut-être 1000 entreprises différentes, mais elles décrivent des processus de développement qui manquent de diversité, avec du SaaS. C’est naturel si le but est d’étudier le DevOps, qui est un rôle qui n’existe pas forcément en-dehors de ce contexte. Mais c’est aussi une partie du développement logiciel parmi d’autres. Dans les composants logiciels que j’utilise tous les jours, aucun de ceux que j’utilise en local ne suivent ce modèle (par exemple: Linux, Firefox, Emacs, OCaml, gcc, LLVM, Python, Coq, Latex, Thunderbird, VLC, Gnome, quelques jeux vidéos, etc.). (Quoique Firefix déploie automatiquement chez la plupart de ses utilisateurs maintenant.) En ligne c’est plus courant (GMail, Github, Reddit) il n’est pas non plus omniprésent (ZdS, Lobsters, LinuxFR, etc.).

Du coup je suis curieux:

  • Est-ce que la façon de mesurer ne s’applique qu’à un type très particulier de "technology organization" qui évolue dans un monde différent du mien ?
  • Ou est-ce que les auteurs pensent qu’à priori, toute organisation produisant du logiciel devrait essayer de s’améliorer selon leurs métriques (en… passant en mode SaaS), et comment est-ce argumenté ?

Dans ton billet tu dis que les entreprises "les plus performantes" ont les métriques les plus courtes, mais comment est-ce que la performance est mesurée ? (Si c’est mesuré par "elles ont de bonnes métriques", on se mord un peu la queue.) Est-ce que le raisonnement peut faire espérer que faire passer, par exemple, Python à ce modèle apporterait quelque chose à sa communauté d’utilisateurs ? (Je ne comprends pas trop comment ce serait possible en pratique, mais rêvons.)

+3 -0

Salut.

Je pense qu’il y a une confusion sur la signification des métriques. Ça ne concerne évidemment pas que le Web et le SaaS. C’est vrai que le vocabulaire que j’emploie est biaisé vers ce que je connais :

Delivery lead time (temps du commit à la production): impossible à dire car nos utilisateurs mettent à jour leurs systèmes à des rythmes différents.

Dans le cas d’une application que les utilisateurs installent, le delivery s’arrête quand il y a une nouvelle version disponible du logiciel que des utilisateurs peuvent installer.

En gros, quand l’app est publiée sur un app-store, ou quand le lien pour télécharger l’archive est mis à jour sur le site. C’est le temps qui sépare le moment où tu as commité ton code et celui où des utilisateurs ont la possibilité de te faire des retours.

Tu ne maîtrises bien évidemment pas le moment auquel les utilisateurs vont utiliser ton code. Ce que tu maîtrises, c’est celui où ta fonctionnalité est disponible. Dans le cas d’un logiciel open source, je suppose que c’est le temps entre le merge de la pull-request et la publication d’une nouvelle "nightly".

Deployment frequency: qu’est-ce qu’un déploiement pour un logiciel libre ? La sortie d’une nouvelle version ? Donc, ben, "tous les six mois" en gros.

Pas forcément. Si je prends Go, par exemple, il y a bien une nouvelle release tous les 6 mois, mais en attendant la nouvelle release on peut toujours utiliser les nouvelles features en installant gotip et commencer à faire des retours aux développeurs.

Dans ton billet tu dis que les entreprises "les plus performantes" ont les métriques les plus courtes, mais comment est-ce que la performance est mesurée ?

Ici il s’agit de la performance organisationnelle, qui inclut la performance commerciale d’une part (profitabilité, parts de marché, productivité, etc.), ainsi que la performance non-commerciale (satisfaction des utilisateurs, etc.) des organisations.

Pour les indicateurs utilisés pour mesurer la performance commerciale, ils mentionnent ce papier, et pour la performance non-commerciale, ce papier.

Si c’est mesuré par "elles ont de bonnes métriques", on se mord un peu la queue.

Il y a deux aspects : d’abord ils ont fait une analyse par cluster sur les métriques obtenues, et d’autre part ils ont établi que leur mesure de performance est un prédicteur de la performance organisationnelle.

+0 -0

Si on prend comme mesure du "delivery lead time" le temps nécessaire entre l’intégration d’un changement dans la branche de développement, et le moment où un utilisateur motivé peut techniquement essayer ce changement, la mesure dit "0 secondes" plutôt que "6 mois", mais ça ne m’a pas vraiment l’air d’avoir du sens non plus.

Pareil pour "déployment frequency", si tu comptes le nombre de merges dans la branche de développement par jour, ben c’est proportionnel au volume d’activité du projet et ça ne dit pas grand chose d’autre.

Edit: mais donc dans le cas de Go par exemple que tu mentionnes, tu mesures comment ces métriques et ça nous dit quoi ?

+2 -0

Si on prend comme mesure du "delivery lead time" le temps nécessaire entre l’intégration d’un changement dans la branche de développement, et le moment où un utilisateur motivé peut techniquement essayer ce changement, la mesure dit "0 secondes" plutôt que "6 mois",

Donc "moins d’une heure".

Pareil pour "déployment frequency", si tu comptes le nombre de merges dans la branche de développement par jour, ben c’est proportionnel au volume d’activité du projet et ça ne dit pas grand chose d’autre.

Donc "à la demande", soit la meilleure valeur possible.

Ce que ça nous dit c’est que les pratiques courantes des projets open source ont tendance à naturellement maximiser ces indicateurs, parce que l’open source est typiquement un contexte organisationnel complexe où l’automatisation est importante, voire juste vitale.

Évidemment, cela nous en dit moins long que dans le cas de logiciels sur lesquels des gens travaillent et collaborent à temps plein, où ce genre de KPI permet de détecter et caractériser une situation problématique à résoudre.

+0 -0

J’ai quand même l’impression que les adaptations des définitions à ce contexte sont assez acrobatiques. Et il reste la question du "time to restore", dans un contexte où la notion de "rupture de service" est très mal définie, mais les bugs mettent des jours, semaines, mois à être corrigés (comme chez tout le monde, je pense, y compris les GAFAM, les startups, etc.).

mais les bugs mettent des jours, semaines, mois à être corrigés (comme chez tout le monde, je pense, y compris les GAFAM, les startups, etc.)

Sauf si le bug est critique et rend le service ou le logiciel inutilisable, auquel cas il devient urgent de déployer un correctif/une mise à jour. Dans mon cas perso au boulot, le Time To Restore est inférieur à une heure.

Ça veut dire qu’en moins d’une heure après la découverte du problème :

  • si c’était un service d’API qui faisait n’importe quoi, il est corrigé et redéployé,
  • si c’était un outil qui ne se comporte pas comme prévu, il est rebuildé et les nouveaux binaires peuvent être téléchargés.

Edit: Toutes ces métriques se mettent à la place de l’utilisateur en fait. À quelle vitesse il peut espérer utiliser une nouvelle fonctionnalité une fois qu’elle a été développée ? À quelle vitesse c’est réparé et de nouveau utilisable quand ça tombe en panne ? etc.

Bien sûr, ça part du principe que le but du logiciel (donc l’objectif de l’organisation) est de répondre au besoin de ses utilisateurs de façon prompte et adaptée.

+1 -0

Autrement dit : la meilleure chance dont on dispose pour changer la culture d’une organisation, c’est de changer ses pratiques et de laisser les flux de communication entre les gens s’adapter en conséquence.

Un petit soucis, c’est que la culture d’une boîte peut être un frein au changement des pratiques. Ça peut être très lent dans une entreprise du type bureaucratique : ce qu’on fait n’est clairement pas bon, plein de monde sait quoi mettre en place pour être meilleur, mais il faut faire évoluer le process, ce qui peut prendre des mois, voire des années.

Autrement dit : la meilleure chance dont on dispose pour changer la culture d’une organisation, c’est de changer ses pratiques et de laisser les flux de communication entre les gens s’adapter en conséquence.

Un petit soucis, c’est que la culture d’une boîte peut être un frein au changement des pratiques. Ça peut être très lent dans une entreprise du type bureaucratique : ce qu’on fait n’est clairement pas bon, plein de monde sait quoi mettre en place pour être meilleur, mais il faut faire évoluer le process, ce qui peut prendre des mois, voire des années.

Aabu

Je suis complètement d’accord avec toi. Pour avoir tenté ce genre de transition dans une startup dont la culture était, pour des raisons historiques, de type bureaucratique, c’est même très délicat.

Dans ce genre de cas, c’est soit on le fait à fond en se donnant les moyens pour réussir, soit on ne change rien, parce que rater cette transition et faire les choses a moitié ou au petit bonheur la chance a le pouvoir d’empirer la situation.

C’est à accompagner (aider à anticiper, planifier, mesurer l’impact humain de…) ce genre de changements que peuvent aider des psychologues du travail, typiquement.

+1 -0

Donc bon: ce document couvre peut-être 1000 entreprises différentes, mais elles décrivent des processus de développement qui manquent de diversité, avec du SaaS. C’est naturel si le but est d’étudier le DevOps, qui est un rôle qui n’existe pas forcément en-dehors de ce contexte. Mais c’est aussi une partie du développement logiciel parmi d’autres.

gasche

De mon point de vue, Accelerate est un (excellent) bouquin qui s’adresse à des structures Agile dans le sens puriste du terme (comprendre pas uniquement des équipes avec des daily et un backlog).

Je pense que ce livre est surtout destiné aux personnes déjà convaincues par son contenu et qui chercheraient de la matière pour appuyer leurs arguments (du moins, c’est comme ça que je m’en sers).

De façon plus générale, je pense qu’avant d’essayer de tendre vers ce que présente Accelerate, beaucoup d’organisations ont déjà pas mal de choses à mettre en place ou corriger pour devenir agile ; voire prendre conscience qu’elles ne sont pas en mesure de s’y mettre (le cargo cult fait de très gros dégâts).

Delivery lead time (temps du commit à la production): impossible à dire car nos utilisateurs mettent à jour leurs systèmes à des rythmes différents.

Dans le cas d’une application que les utilisateurs installent, le delivery s’arrête quand il y a une nouvelle version disponible du logiciel que des utilisateurs peuvent installer.

En gros, quand l’app est publiée sur un app-store, ou quand le lien pour télécharger l’archive est mis à jour sur le site. C’est le temps qui sépare le moment où tu as commité ton code et celui où des utilisateurs ont la possibilité de te faire des retours.

Tu ne maîtrises bien évidemment pas le moment auquel les utilisateurs vont utiliser ton code. Ce que tu maîtrises, c’est celui où ta fonctionnalité est disponible. Dans le cas d’un logiciel open source, je suppose que c’est le temps entre le merge de la pull-request et la publication d’une nouvelle "nightly".

nohar

Dans un contexte où les équipes n’ont pas la main sur le delivery time (contraintes du marché, management, techniques, etc.), il y a souvent moyen de s’adapter un minimum. En fait, le plus important, c’est de réduire au maximum la boucle de feedback1

Dans un de mes anciens projets (déploiements tous les 2 à 3 ans), on s’appuyait sur une plateforme iso-prod et des tests réguliers avec les utilisateurs (au pire, d’anciens opérateurs). Ce n’est pas aussi efficace que la prod en elle-même. Mais ça permettait d’avoir des retours sur lesquels travaillés.

Je dois admettre qu’avec le recul, les déploiements annuels se basaient sur des contraintes qu’il était plus facile d’accepter que de chercher à résoudre, cela dit…

1 le temps qu’il faut pour valider la valeur utilisateur d’un développement

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte