La confusion entre Agile, DevOps et l'ingénierie des plateformes freine les développeurs

L'objectif est le processus : améliorer la prestation dans des environnements d'entreprise complexes pour influencer le changement et parvenir à une véritable amélioration continue.

Traduit de Agile, DevOps, Platform Engineering Confusion Stalls Devs , auteur Charles Humble.

En tant que grande société de conseil mondiale, UST s'efforce d'aider les entreprises à innover et à améliorer la fourniture de technologies, une grande partie de son travail découlant des pratiques DevOps . Lorsqu'elle travaille avec des clients, l'entreprise est souvent confrontée à des questions telles que la manière de réduire les délais de commercialisation tout en améliorant la qualité du code et l'engagement des ingénieurs.

Eugene Sazhin , responsable de l'ingénierie, plates-formes et solutions agiles numériques chez UST Global, se retrouve souvent à penser : « Il devrait y avoir un ensemble de principes généraux que nous pouvons développer, respecter et conseiller à nos clients d'adhérer également, afin pour qu’ils réussissent leur parcours de transformation. De meilleurs résultats.

C'est exactement l'objectif du cadre d'amélioration de la livraison récemment publié par l'UST .

7 principes pour améliorer la livraison de logiciels

Le cadre combine Lean, Agile et DevOps avec des idées dérivées de la loi de Conway , de la topologie d'équipe , de DORA et de la propre expérience de l'UST. Il contient sept principes fondamentaux :

  1. Le flux vient en premier.
  2. La positivité stimule le flux.
  3. La topologie d'équipe orchestre le flux.
  4. Coacher les indicateurs de performance clés (KPI), pas gérer.
  5. Les principes Lean conduisent à l’optimisation.
  6. Suivre délibérément la loi de Conway]( https://thenewstack.io/context-reversing-conways-law-for-superior-service-management/). %E3%80%82)
  7. Valorisez la confiance plutôt que la performance et l’apprentissage plutôt que l’expertise.

Le concept de « flux » est une partie importante du cadre, et UST utilise le flux dans un sens lean/organisationnel plutôt que de faire référence à l'état de flux des développeurs individuels (bien que les deux concepts soient étroitement liés). En définissant le « flux », UST écrit :

« En nous inspirant des principes Lean, nous accordons la priorité à l'optimisation de l'ensemble de la chaîne de valeur, et pas seulement de certaines parties isolées. Nous éliminons le gaspillage, minimisons les changements de contexte et construisons un système qui permet au travail de développement de se dérouler de manière transparente, de l'idéation à la livraison.

L’ensemble du cadre est centré sur les employés. Le deuxième principe, « La positivité stimule le flux », parle de l’équilibre travail-vie personnelle, de l’autonomie, de la reconnaissance, de la croissance personnelle et de l’apprentissage. Des employés engagés et heureux sont plus productifs, mais un autre facteur est qu’une transformation organisationnelle réussie nécessite l’implication de toutes les personnes impliquées, de la haute direction aux employés de niveau inférieur. J'ai décrit ailleurs que trois des cinq transformations organisationnelles auxquelles j'ai participé ne se sont pas déroulées comme prévu. Dans chaque cas, le manque de soutien ou d’attention des dirigeants a été un facteur majeur de l’échec.

Exprimez vos principes fondamentaux

La logique de l'UST en publiant son cadre d'amélioration de la prestation s'appuie sur l'idée de Simon Sinek selon laquelle si vous exprimez publiquement vos principes fondamentaux, d'autres seront encouragés à vous rejoindre. En rendant le cadre public, le groupe consultatif invite également au dialogue, ce qui devrait lui permettre de réitérer et d'améliorer le cadre. Des boucles de rétroaction rapides sont essentielles dans toute organisation apprenante.

Sazhin a également déclaré que la publication du cadre aiderait les activités de conseil de l'entreprise. Si les clients de l'UST « comprennent d'où nous venons lorsqu'il s'agit de résoudre des problèmes de transformation, alors nous pouvons nous connecter et collaborer, et nous avons de plus grandes chances de succès », a-t-il déclaré. À l'inverse, si les clients ne sont pas d'accord avec les principes, alors « nous avons des différences fondamentales, cela ne fonctionnera tout simplement pas.

Si une entreprise déclare un ensemble de valeurs fondamentales mais que personne n’y prête beaucoup d’attention, elles ne veulent rien dire. "Si vous vous engagez envers les valeurs fondamentales du cadre", a déclaré Sazhin à The New Stack, "cela signifie que vous évaluez toutes vos actions et idées par rapport à ces valeurs fondamentales et que vous devez filtrer celles qui sont incohérentes. Par exemple, si vous êtes attaché à la valeur fondamentale de la positivité, vos communications avec les employés doivent donc suivre ce principe. Vous ne devez pas autoriser les RH à émettre des communications menaçantes, cela violerait l'un des principes fondamentaux que vous prétendez respecter, et vous le ferez. la confiance. Il est extrêmement difficile de restaurer la confiance perdue.

L’énigme de la productivité des développeurs

Dans les organisations, la confiance vient d’en haut. Il est également extrêmement facile de perdre la confiance ; une solution consiste à ne pas démontrer les valeurs que vous défendez, mais d'autres méthodes incluent des licenciements massifs lorsque l'entreprise est rentable ou lient les évaluations de performances à des statistiques facilement manipulables.

Je soupçonne qu’on a demandé à presque tout le monde de mettre en œuvre quelque chose dont ils croient fermement qu’il ne fonctionnera pas. En tant que partenaire responsable, vous devez parfois riposter, même si vous êtes un cabinet de conseil qui compte sur la satisfaction de ses clients. Par exemple, les clients d'UST demandent souvent un moyen de mesurer la productivité des développeurs et de l'intégrer dans leurs processus. Cependant, Sazhin a déclaré : « La productivité des développeurs est largement mal comprise et abusée dans la plupart des entreprises. »

McKinsey a été fortement critiqué pour son article sur la mesure de la productivité des développeurs . Mais l’attitude sous-jacente prévaut toujours : la programmation peut être réduite à la frappe, la productivité est donc assimilée à des commits Git, des lignes de code, des bugs corrigés ou d’autres statistiques dénuées de sens. La réalité est que la saisie n'est pas la partie la plus difficile de la programmation et, comme le souligne Sazhin, « ces choses n'ont rien à voir avec les objectifs commerciaux de l'équipe ».

Par exemple, un ingénieur senior qui passe du temps à aider les membres les plus jeunes de l’équipe à résoudre leurs problèmes est probablement la meilleure chose qu’il puisse faire pour améliorer les performances de l’équipe. Mais si son évaluation de performances est basée sur ses statistiques de commit Git, rien de tout cela ne sera visible.

Sazhin a déclaré que le désir de mesurer les développeurs de cette manière découle du désir de microgérer à la fois les membres de l'équipe et les individus. Cela vient d'un manque de confiance dans la capacité de l'équipe à s'organiser. Mais cette idée est incompatible avec les principes fondamentaux de l’UST. Au lieu de cela, les dirigeants devraient permettre à l’équipe d’identifier si quelqu’un ne fonctionne pas, permettre à l’équipe d’exprimer ses préoccupations en toute sécurité et aider la personne à s’améliorer (ou à apporter des changements plus radicaux).

Expérimentez et évitez la pensée magique

Sazhin estime qu'au lieu de faire de la microgestion, les managers doivent « s'assurer que l'équipe comprend quels sont les objectifs, éliminer les obstacles, puis mesurer si ce que l'équipe livre répond à ces objectifs commerciaux ». Cela se reflète dans le quatrième principe du cadre : « Coacher les KPI, pas gérer ».

C'est important car l'industrie technologique est encline à la pensée magique . Si rien n'est mis en production sans l'approbation d'un comité de contrôle des modifications (qui ne se réunit que deux fois par an), l'informatique ne peut pas évoluer plus rapidement, quel que soit le nombre de microservices. Mais de nombreuses organisations semblent penser que ce sera le cas.

« De la même manière, « les entreprises disent qu'elles veulent de l'agilité », mais elles adoptent ensuite SAFe [Scaled Agile Framework], ce qui me rend confus », a déclaré Sazhin. « Cela signifie qu'elles ont complètement mal compris ce qu'est l'agile. Vous pouvez mettre en œuvre SAFe Years sans aucun résultat - vous. On pourrait prétendre que c'est parce que vous n'avez pas implémenté SAFe correctement, mais ce n'est pas le cas."

Comme le dit le consultant Agile Dan North , « le modèle commercial déclaré de SAFe est « un fournisseur de cadres, de plates-formes, de contenu de formation professionnelle et de certifications ». Il ne dit rien sur la réussite des clients, rien sur la responsabilité et rien sur l'efficacité du cadre. " Tout cela est loin de la mission du Manifeste Agile consistant à " découvrir de meilleures façons de développer des logiciels ".

Néanmoins, l’industrie a fait des progrès, notamment en termes d’amélioration du délai de rentabilisation ou de promotion rapide d’idées à tester auprès des clients.

Des entreprises comme Amazon , Intuit et Netflix mènent des milliers d'expériences chaque année. "J'encourage les gens [chez Amazon] à se retrouver dans des impasses et à expérimenter", a déclaré Jeff Bezos . "Nous avons essayé de créer des outils pour réduire le coût de l'expérimentation afin de pouvoir réaliser davantage d'expériences. Si vous parvenez à augmenter le nombre d'expériences d'une centaine à un millier, vous augmenterez considérablement le nombre d'innovations que vous générerez."

Vous devez également garantir la sécurité des expérimentateurs en cas d'échec, car un grand nombre d'expériences ne donneront pas les résultats escomptés. À son tour, cela signifie que les employés doivent avoir une forte confiance et une sécurité psychologique au cœur de leur autonomie. Pour éviter une pensée monoculturelle, les entreprises doivent recruter de manière diversifiée, et le travail à distance flexible joue un rôle important en augmentant la diversité du vivier de talents disponibles.

Ce que cela signifie pour accélérer la livraison de logiciels

La fourniture de logiciels, en particulier, nécessite de petites équipes autonomes et interfonctionnelles pour créer des unités logicielles déployables de manière indépendante. En règle générale, cela signifie des microservices ou des fonctions en tant que service (FaaS), tels qu'AWS Lambda . Il est nécessaire de passer en production aussi souvent que nécessaire avec de faibles taux d'échec - et de se remettre rapidement de tout échec de déploiement. Nous le savons depuis vingt ans ou plus : l' étude sur l'accélération DORA , dirigée par l'experte Nicole Forsgren , fournit même un point de référence.

Sazhin souligne l'importance de valider vos idées et les progrès que vous avez réalisés afin que toute décision soit prise sur la base de données plutôt que d'intuition. "Il faut préciser une hypothèse, collecter autant de données que possible, puis utiliser la méthode scientifique pour l'affiner", a-t-il expliqué. "Il existe un état d'esprit commun selon lequel certaines choses sont trop difficiles ou impossibles à mesurer, et par conséquent, la collecte de données à des fins d'analyse scientifique est trop difficile ou tout simplement impossible. Cela ne pourrait pas être plus éloigné de la vérité. Il recommande le livre _Comment mesurer." Anything: Finding the Value of Intangible Assets in Business_, de Douglas W. Hubbard, montre comment procéder à l'aide d'estimations calibrées, d'analyses statistiques et de simulation.

Enfin, Sazhin recommande de disposer d'un réseau de personnes influentes qui soutiennent votre travail. « Si vous ne les avez pas, vous n’obtiendrez pas le changement culturel dont vous avez besoin pour vous améliorer continuellement », a-t-il déclaré. « Vous devez augmenter le nombre d'agents de changement dans votre organisation qui aident activement les équipes dans ce cheminement. Ils doivent être pleinement alignés et engagés, mais surtout, ils doivent être passionnés par ces changements.

Pour plus d'informations, téléchargez le livre blanc de l'UST Libérer le processus de développement : un cadre pour améliorer la fourniture de logiciels d'entreprise .

Cet article a été publié pour la première fois sur Yunyunzhongsheng ( https://yylives.cc/ ), tout le monde est invité à le visiter.

Un programmeur né dans les années 1990 a développé un logiciel de portage vidéo et en a réalisé plus de 7 millions en moins d'un an. La fin a été très éprouvante ! Des lycéens créent leur propre langage de programmation open source en guise de cérémonie de passage à l'âge adulte - commentaires acerbes des internautes : s'appuyant sur RustDesk en raison d'une fraude généralisée, le service domestique Taobao (taobao.com) a suspendu ses services domestiques et repris le travail d'optimisation de la version Web Java 17 est la version Java LTS la plus utilisée Part de marché de Windows 10 Atteignant 70 %, Windows 11 continue de décliner Open Source Daily | Google soutient Hongmeng pour prendre le relais des téléphones Android open source pris en charge par Docker ; Electric ferme la plate-forme ouverte Apple lance la puce M4 Google supprime le noyau universel Android (ACK) Prise en charge de l'architecture RISC-V Yunfeng a démissionné d'Alibaba et prévoit de produire des jeux indépendants pour les plates-formes Windows à l'avenir
{{o.name}}
{{m.nom}}

Je suppose que tu aimes

Origine my.oschina.net/u/6919515/blog/11102269
conseillé
Classement