Le pourquoi de la gestion de la chaîne de valeur – –

Si vous êtes comme moi et que vous avez fait le tour de la technologie plus d’une fois, vous avez vu des acronymes à trois lettres aller et venir. Parfois, la technologie à laquelle ils se réfèrent est un flash dans la casserole; d’autres fois, il traîne un peu avant d’être subsumé dans les plates-formes sur lesquelles nous nous basons.

Et il en va de même avec la gestion de la chaîne de valeur (VSM), qui a gagné en popularité dans les cercles DevOps. La première question que j’ai tendance à poser à ce sujet est la suivante: pourquoi? Est-ce une nouvelle innovation qui a besoin d’un nom, ou quelqu’un a-t-il repéré une faiblesse dans les outils et méthodes existants?

En un mot, VSM fait référence au besoin – ou à la capacité – d’avoir une visibilité sur la façon dont le logiciel est construit. Au fur et à mesure que les unités fonctionnelles passent le long du pipeline, du concept au déploiement, les gestionnaires peuvent bénéficier de la compréhension de la façon dont cela se déroule, de la vitesse du développement, de la localisation des goulots d’étranglement, de la valeur fournie, etc.

La question de savoir si nous avons besoin de VSM est particulièrement pertinente dans le domaine du développement de logiciels, notamment parce que les gens créent des applications depuis très longtemps. On pourrait penser que nous savons comment faire cela et comment gérer le processus maintenant.

Alors, le monde DevOps a-t-il atteint une épiphanie où il a soudainement découvert le secret de la vie, de l’univers et comment développer des logiciels? Pas assez. VSM (qui a également un héritage) existe en réponse à un besoin actuel, alors jetons un coup d’œil aux causes.

Tout d’abord, regardons les choses en face: le développement de logiciels se court dans le sable depuis des décennies. À mesure que les systèmes devenaient plus grands et plus complexes, les processus linéaires ne pouvaient plus suivre ou, plus précisément, ralentissaient de plus en plus les choses. Il y a peut-être encore des partisans de la cascade, mais trop souvent, le processus lui-même a été le goulot d’étranglement, entravant l’innovation.

Lire aussi  Le travail de conservation des experts de la faune marine de Cornwall récompensé

Dans les années 90, des groupes de personnes se sont penchés sur différentes façons de faire les choses. Certains ont opté pour des approches de fabrication allégée et des techniques d’efficacité japonaises. D’autres se sont concentrés sur les résultats, avec une conception basée sur des cas d’utilisation et une programmation eXtreme, les deux étant simplement de faire avancer les choses. Pourtant, lorsque je formais des gens aux méthodologies de développement agiles telles que DSDM, ces approches étaient vraiment l’exception.

Et puis une nouvelle réalité est apparue, motivée par le Web, l’open source, les API RESTful, etc., où les enfants faisaient des choses et dépassaient les approches plus anciennes et plus croustillantes. Les sites et les applications devaient être développés rapidement; il fallait les assembler et les diffuser rapidement. Les gens ont commencé à dire: écoutez, pouvons-nous simplement obtenir ce site Web la semaine prochaine?

Le besoin de vitesse était très motivé par la peur, et nous le voyons encore aujourd’hui, car les organisations se font dire (à juste titre, mais de manière hyperbolique) comment elles doivent se transformer ou risquer de fermer leurs portes. Mais au fur et à mesure que le développement logiciel s’est accéléré, il s’est heurté à de nouveaux défis et goulots d’étranglement, notamment la nécessité de contrôler le changement (l’un des principes fondateurs de DevOps, en 2007).

Avance rapide jusqu’à aujourd’hui, et il y a une toute nouvelle série de défis. Le fait est que toute approche, si elle est appliquée universellement, finira par montrer des faiblesses. Dans ce cas, «juste» développer rapidement les choses se fera au détriment d’autres aspects, comme bien les développer (cf. qualité et sécurité de décalage à gauche), ou livrer des choses qui font une différence positive.

C’est là que VSM entre en jeu. Il sert essentiellement à combler une lacune: si vous ne vous demandez pas si vous faites les bonnes choses, de la bonne manière, alors il est probablement temps de commencer. Nous sommes maintenant à une époque où les pratiques agiles, qui étaient autrefois l’exception, sont devenues la norme. Mais l’agilité en elle-même n’est pas suffisante: «managé agile» est ce qu’il faut.

Lire aussi  Livraison logicielle évolutive avec gestion de la chaîne de valeur

Ce qui nous amène à un autre défi. Le monde est passé de scénarios où tout le monde construisait des choses de la même manière (en cascade) à l’utilisation de processus de développement flexibles en fonction de ce que les gens veulent faire. C’est génial quand vous commencez juste et que vous voulez vous concentrer sur la construction, mais pas si bien quand vous voulez, disons, changer d’équipe et craquer sans apprendre à nouveau comment tout fonctionne.

Franchement, les processus de développement sont devenus fragmentés, inefficaces, encombrants et coûteux. Ce qui n’est pas bon: les équipes ne veulent pas passer leur temps à gérer des processus et des outils, alors qu’elles pourraient créer de nouvelles applications intéressantes. Et c’est là que VSM entre en jeu.

Le terme chaîne de valeur vient de la fabrication. La façon la plus simple d’y penser, je pense, est de penser à ce que vous essayez de fournir en tant que flux d’activités qui créent de la valeur les unes sur les autres. Alors, commencez par penser au pipeline de développement comme une chaîne de valeur; rendez-le efficace et efficient, puis cherchez à standardiser les flux de valeur dans toute l’organisation.

Quelqu’un m’a récemment demandé: VSM n’applique-t-il pas seulement des techniques de modélisation et de gestion de processus métier aux logiciels maintenant? Et j’ai répondu: il s’agit simplement d’appliquer la modélisation et la gestion des processus métier au développement logiciel. Cela remonte à une bonne vieille définition de Hammer et Champy d’un processus métier: c’est une séquence d’activités qui apportent de la valeur à un client, et c’est ce que devrait être la livraison de logiciels.

La gestion de la chaîne de valeur existe parce qu’elle doit le faire maintenant, bien qu’elle n’existe pas dans de nombreux endroits qui tentent de mettre en œuvre des pratiques DevOps. Il s’agit donc vraiment de la réinsertion de principes de gouvernance et de visibilité de gestion éprouvés dans des environnements dynamiques, dynamiques et agiles.

VSM durera-t-il? C’est une autre bonne question. J’entends certaines organisations trouver que VSM est encore une autre surcharge (indice: elles le font probablement mal). Je suis également d’avis que si nous, en tant que groupe de défenseurs du développement et des opérations, pouvions convenir que nous n’avons pas besoin de chaque projet individuel pour réinventer les meilleures pratiques, nous pourrions probablement normaliser davantage nos pipelines, en laissant plus de temps pour avancer. avec, oui, les trucs sympas.

Lire aussi  Les taux de vaccination contre la rougeole et les autres vaccinations font trempette dans les jardins d'enfants

Je ne veux pas voir un retour à des méthodologies onéreuses telles que la cascade. Je veux voir les innovateurs innover, les développeurs se développer et les opérateurs fonctionner, le tout avec un minimum de stress. J’observe avec intérêt l’évolution du DevOps Institute vers l’évaluation des capacités, j’apprécie de voir l’adoption d’approches basées sur les produits dans le développement de logiciels, et je parle à plusieurs fournisseurs de la façon dont nous pourrions voir les pipelines sous forme de code dans un Terraform. -comme standard ouvert.

Tous ces fils alimentent une approche future plus cohérente. Il y a un catalyseur pour tout cela, à savoir les approches microservices, qui demandent de la franchise face à la complexité qu’elles créent. Cf. une conversation récente avec Tracy Regan de DeployHub sur la nécessité de gérer la configuration des applications.

Je me rends compte que je n’ai pas encore répondu à la question. Je pense que VSM prévaudra, mais en tant que fonctionnalité d’outils et de plates-formes de bout en bout plus complets, plutôt que comme une couche supplémentaire. Les chaînes de valeur gérées sont une bonne chose, mais vous ne devriez pas avoir besoin d’un outil séparé pour cela, isolé du reste de votre chaîne d’outils.

Donc, finalement, VSM n’est pas une épiphanie massive. C’est simplement un symptôme de notre situation, alors que nous cherchons à offrir une innovation logicielle à grande échelle. Le voyage est loin d’être terminé, mais il atteint un lieu de convergence basé sur les microservices (qui, ironiquement, remontent aux principes de conception modulaire de 1974). Les meilleures pratiques émergent et fourniront les normes et les plates-formes dont nous avons besoin à mesure que nous nous dirigeons vers l’avenir.

.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recent News

Editor's Pick