BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Q&R Auteur Continuous Digital et Project Myopia

Q&R Auteur Continuous Digital et Project Myopia

Favoris

Points Clés

  • À notre époque, toute entreprise est numérique
  • Les organisations ont besoin de passer à un modèle continu où les développements technologiques sont le moteur de l’entreprise et l’entreprise celui de la technologie
  • De nombreux problèmes existent quand on essaie d’appliquer le modèle projet au développement logiciel, d’où le #NoProjects
  • Les produits ont une durée de vie longue et ont besoin d’être maintenus ; les projets ont une durée de vie courte et sont destinés à se terminer
  • Une très grande proportion des projets IT échoue (quelque-chose entre 30% et 70%), non pas pour cause d’incompétence ou de mauvaise intention, mais parce que le modèle est erroné

Auteur, praticien et consultant, Allan Kelly a récemment publié deux ouvrages complémentaires sur les façons de travailler dans les entreprises numériques modernes.

Le premier, « Continuous Digital » (« Numérique continu »), se concentre sur la façon dont les organisations ont besoin de se structurer quand « toute entreprise est numérique ». Il y présente un « Modèle Continu, un monde où les développements technologiques sont le moteur de l’entreprise et l’entreprise celui de la technologie ».

Le second, « Project Myopia » (« Projet Myopie »), en est le compagnon puisqu’il explore la théorie sous-jacente du #NoProjects et explique pourquoi la culture continue est importante.

Un extrait est téléchargeable ici. « Continuous Digital » peut être acheté ici et « Project Myopia » ici.

InfoQ s’est entretenu avec Allan au sujet de ces livres.

InfoQ : Pourquoi avez-vous écrit ces livres ? Quelle problématique sous-jacente, quelle opportunité abordez-vous ?

Allan Kelly : L’écriture de ces deux livres a un peu été un accident. J’avais depuis longtemps cette idée en tête que le fait de travailler sur des « projets » était source de problème. Je me souviens d’ailleurs de conversations avec Mary Poppendieck à ce sujet déjà en 2011.

Puis il y a de cela environ cinq ans, Steve Smith, Joshua Arnold et moi-même avons commencé à tweeter sur #NoProjects. Twitter est un média horrible pour débattre, mais merveilleux pour faire émerger les idées. Il est vite devenu évident qu’il y avait de nombreux problèmes avec le modèle projet et son application au développement logiciel. Il était clair aussi que d’autres personnes les avaient vus.

Vasco Duarte (M. #NoEstimates) m’a demandé de rassembler les arguments. Ce long essai a grandi pour devenir Project Myopia, qui montre les problèmes associés aux projets.

Cependant, il n’est pas suffisant d’identifier les problèmes, encore faut-il montrer une meilleure voie, proposer une solution alternative. Beaucoup de gens sur Twitter demandaient « Alors qu’est-ce qu’on fait à la place ? »

J’ai alors commencé à mettre en place une alternative. Au début, cela ressemblait beaucoup à ma méthode Xanpan, mais, libéré de la pensée projet, deux forces très puissantes me sont apparues.

Tout d’abord, nous vivons dans une époque continue : amélioration continue, intégration continue, livraison continue… Alors que l’entreprise est obsédée par le changement, ce dont elle a réellement envie, c’est de longévité. Vous ne voulez pas que votre employeur fasse faillite. Les logiciels à succès perdurent : les gens s’en servent et le logiciel doit s’adapter. Les logiciels qui échouent, ceux que personne n’utilise, ne changent pas et meurent.

Ensuite, l’entreprise devient de plus en plus numérique. La technologie n’est plus limitée au back-office, elle est au cœur de l’offre. Pour les gens du business, ce n’est pas rien. Le business et la technologie sont maintenant inséparables. Dans ce monde-là, la nature temporaire des projets n’est plus de mise.

InfoQ : À qui ces livres sont-ils destinés ? Comment vous assurez-vous de ne pas « prêcher des convertis » ?

Kelly : Il est fort possible que Project Myopia prêche les convertis… Je connais beaucoup de développeurs qui l’apprécient parce qu’il fait écho à leurs frustrations. Malgré tout, je pense que celles et ceux qui croient au modèle projet devraient lire ce livre pour trouver leurs propres réponses aux critiques.

Continuous Digital est différent. Ce livre établit un nouveau modèle alternatif pour l’entreprise numérique continue. Il s’adresse à deux publics.

Celui qui a des responsabilités managériales, et j’y inclue les managers non mandatés comme les Scrum Masters et les analystes opérationnels. Ils y trouveront matière à apprentissage, puisque c’est le modèle mental auquel ils se réfèrent qui dirige leur processus décisionnel.

Le second public est celui des leaders et managers de demain : les développeurs, testeurs et analystes d’aujourd’hui qui bénéficieront d’un nouveau modèle managérial.

Ce public est aussi important pour une autre raison. Puisque nous nous dirigeons vers plus d’auto-organisation avec moins de managers, il y a plus de décisions organisationnelles à prendre et de travail « de gestion » à faire. Au final, plus de personnes doivent comprendre les problématiques du management. Curieusement, avoir moins de managers mandatés signifie que plus de personnes doivent s’intéresser au travail de management.

InfoQ : Pourquoi avez-vous écrit ces deux livres ? Qu’est-ce qui les différencie entre eux ? Dans quel ordre doivent-ils être lus ?

Kelly : Vous pouvez lire ces livres dans n’importe quel ordre, mais si vous ne deviez en lire qu’un seul, ce serait Continuous Digital, même si c’est le plus long.

Project Myopia montre pourquoi le modèle projet n’est pas adapté au développement logiciel, et comment il endommage ce logiciel. Vous pouvez le voir comme le déclencheur pour arrêter d’utiliser des projets.

Continuous Digital montre une meilleure façon de travailler. Ce livre est autonome, en ce sens qu’il ne se base pas sur l’échec du modèle projet, mais présente la nature de l’entreprise moderne numérique. De telles entreprises sont intrinsèquement basées sur la technologie. L’entreprise est la technologie, et la technologie est l’entreprise.

Les gens se demandent si Uber est une entreprise de technologie ou de transport, mais Uber est bien autre chose. Uber est une entreprise numérique où la technologie et le produit sont indissociables. Il en est de même pour Spotify, JustEat, AirBnB et bien d’autres entreprises du vingt-et-unième siècle.

InfoQ : Qu’est-ce qui est si différent dans l’économie moderne ? Pourquoi le « digital » est-il si prédominant ? Ne s’agit-il pas d’un mot à la mode ?

Kelly : J’ai grandi dans un monde numérique, ou « digital » pour reprendre ce mot. J’ai eu mon premier ordinateur à douze ans, c’était un ZX81 avec un processeur Z80 et 1 ko de RAM. Pendant longtemps, j’ai simplement ignoré le mot « numérique ». Ces ordinateurs analogiques n’allaient pas très loin, et ce mot n’apportait rien.

Mais pour les gens qui n’ont jamais eu cette expérience, le « digital » signifie quelque-chose. Des gens qui n’ont pas grandi avec Facebook, ni même avec MySpace. Pour ces gens, l’IT, ce sont des interfaces compliquées, des terminaux trop lents, Word qui plante et l’IT institutionnel. Pour ces gens, le « monde digital » est complètement différent : l’iPhone, Twitter, le GPS, les capteurs et toutes ces choses rendues possibles par le faible coût du cycle de processeur.

C’est toujours de la technologie, mais complètement différente. Prenez Amazon. C’est la version numérique du catalogue de Sears ou de Littlewood, mais la technologie a modifié l’expérience utilisateur de telle façon qu’elle a changé de nature.

InfoQ : Vous posez l’argument selon lequel les équipes sont la source de la valeur et le point de focus du travail. Pourquoi les équipes et non pas les contributeurs individuels ?

Kelly : C’est une question d’échelle. Il y a des époques où des individus peuvent faire une énorme différence. En général, cela arrive à un point de rupture technologique. Pensez à cet adolescent qui s’est enrichi en écrivant des jeux pour le Commodore 64, ou les premières applications pour iPhone.

Dans l’ensemble, nos systèmes sont trop imposants pour que des individus puissent les défier de nos jours. Il y a aussi plus de technologies impliquées, donc plus de compétences nécessaires. Connaître le C n’est plus suffisant, vous avez besoin du JavaScript, des CSS, de Jenkins, de pipelines, mais aussi des compétences de design, de test, de liaison avec les parties prenantes, d’analyse. Viennent ensuite les compétences non techniques : marketing, vente, support, etc.

Même quand une personne est capable d’écrire un système valorisable de bonne taille, travailler en équipe permet de produire ce système plus tôt, de débloquer la valeur plus vite. Beaucoup de choses changent quand vous intégrez le coût du délai dans votre mode de pensée.

InfoQ : Pourquoi le NoProjects ? De nombreuses organisations n’ont-elles pas rencontré le succès en utilisant le modèle projet ?

Kelly : Il est clair que le développement technologique fonctionne : l’iPhone, les voitures autonomes, Netflix. Mais est-ce parce que ces organisations maîtrisent bien leurs projets, ou en dépit de ceux-ci ?

On entend régulièrement des gens dire que 40%, parfois même 70% des projets IT échouent. Je ne connais pas les chiffres réels, mais quand tellement d’entre eux échouent, on doit se poser la question : est-ce que ce ne serait pas le modèle lui-même qui est en échec ?

Pour ceux qui réussissent, je dirais que beaucoup le font en dépit du modèle projet et non grâce à lui. Ils réussissent parce que quelqu’un n’a pas suivi les règles ou le processus, ou a triché avec les objectifs.

Il y a aussi tous ces coûts qui ne sont pas comptabilisés : la dette technique, les bugs, les heures supplémentaires non payées, la valeur perdue pour cause de livraison tardive… Beaucoup de ces succès perdent alors de leur éclat.

Tout ceci nous vient du passé. Nous vivons à une époque différente. Nous avons besoin d’un modèle qui fonctionne plus souvent qu’il n’échoue.

InfoQ : Vous parlez aussi de déséconomies d’échelle. Cela semble contre-intuitif. Avez-vous des explications, des exemples ?

Kelly : Quand vous achetez du lait, vous vous attendez à ce que deux bouteilles d’un demi-litre coûtent plus cher qu’une seule d’un litre. Et qu’une bouteille de deux litres coûte moins cher que deux bouteilles d’un litre. C’est ce qu’on appelle une économie d’échelle. C’est ce qu’Henry Ford faisait en construisant un million de modèles identiques de la Ford T.

Les économies d’échelle fonctionnent pour le lait et bien d’autres choses, mais pas pour le développement logiciel. Quand vous développez du logiciel, les déséconomies d’échelle prévalent. Pour être efficace, vous devez être bon sur de nombreux points de taille réduite.

Corriger un bug dans un programme de 1 000 lignes est bien plus facile (et rapide) que corriger un bug dans 10 000 lignes, ce qui reste plus facile que dans un programme de 100 000 lignes. Les programmes plus gros sont plus difficiles à maintenir, d’où l’approche des micro-services.

Les équipes de petite taille surperforment celles de grande taille. Une équipe de 4 personnes livre plus par personne qu’une équipe de 14, sans parler d’une équipe de 40. Plus les équipes augmentent, plus les coûts de communication explosent. Il est alors plus difficile de créer une vision partagée qui permette à un individu de comprendre l’ensemble.

Les tests en sont un autre exemple, notamment lorsqu’une société livre des modifications lors d’une montée de version majeure pour profiter de l’économie d’échelle. Tester une version comprenant 100 modifications est d’un ordre de magnitude plus difficile que de tester 100 versions mineures avec une seule modification chacune.

Imaginez que vous publiiez une version par an avec 100 modifications. Imaginez qu’un bug passe à travers et qu’il plante la machine des utilisateurs. Ils verront que 100% des versions plantent. Maintenant, imaginez que vous ayez publié 100 versions avec une modification chacune. Le même bug passe à travers et affecte les utilisateurs. Ils verront alors que seulement 1% des livraisons échouent, et que 99% réussissent.

Maintenant, imaginez que vous êtes la personne chargée de corriger ce bug. Quel scénario préférez-vous ?

Ajoutez-y encore le coût du délai, et vous découvrirez le bénéfice financier que les 100 petites mises-à-jour auront sur le retour sur investissement.

Une dernière chose. Une fois que vous avez livré, une fois que vous avez terminé, tout change. Car une fois que le logiciel est utilisé, il montre la plus grande économie d’échelle connue.

InfoQ : Comment cette approche impacte-t-elle la finance et la gouvernance ?

Kelly : C’est la même histoire. Nous avons besoin d’optimiser pour ce qui est petit. Arrêter de distribuer de larges sommes d’argent, et commencer à donner des sommes réduites avec un bilan régulier.

C’est essentiellement le modèle du capital risque de la Silicon Valley. Bien sûr que le capital risque a ses inconvénients, mais le modèle de financement basique fonctionne. Les équipes touchent un petit montant, et si elles peuvent démontrer leur progrès, qu’il s’agisse de logiciel opérationnel ou de validation par le marché, elles obtiennent plus. C’est un modèle de portefeuille où vous faites de nombreux petits paris et vous éliminez ceux qui sous-performent.

De nouveau, vous avez besoin d’être bon sur de nombreux items de petite taille, afin que le processus de portefeuille puisse avoir lieu de manière régulière et efficace.

InfoQ : Dans Project Myopia, vous opposez la livraison continue aux approches basées sur le projet. Ces deux approches peuvent-elles coexister ?

Kelly : Oui, de nombreuses organisations tentent l’aventure aujourd’hui, mais c’est un mariage délicat, et je me dois de demander : Pourquoi ? Quels sont les bénéfices qu’on en tire au lieu d’appliquer l’une ou l’autre de ces approches séparément ?

Les groupes appliquent la livraison continue au sein du modèle projet, ce qui finit par créer des tensions. Quand vous y réfléchissez, ces deux approches sont incompatibles. Le continu est continu : les équipes trouvent du travail à faire et livrent quelque-chose. Les projets sont des structures temporaires créées pour faire quelque-chose de spécifique, connu par avance.

Utiliser les deux rend difficile la compréhension de ce qui se passe, ainsi que l’établissement de buts clairs. C’est déjà en soi un problème, en particulier quand on parle de gouvernance : appliquer les critères de succès du projet à une équipe continue est illogique.

InfoQ : Pourquoi ce mot « myopie » ? Qu’est-ce qui fait que les organisations ont une vision à court terme dans leur façon de travailler ?

Kelly : Quand les sociétés mettent en œuvre des projets, elles se disent que le travail va se terminer. Elles ignorent le fait que la technologie et le changement ne s’arrêtent jamais. De nouvelles opportunités surviennent. En utilisant la technologie, les gens trouvent de nouvelles façons de l’utiliser, découvrent de nouveaux usages et de nouvelles opportunités.

Dire « Non, nous avons terminé ce projet » laisse de la valeur sur la table.

Dire « D’accord, nous allons commencer de nouveaux projets » reconnaît cette valeur, mais ajoute les coûts de mise en place du projet, fait perdre du temps (rappelez-vous le coût du délai), et présume que vous connaissez les besoins à l’avance.

InfoQ : La pensée et les pratiques de développement agiles existent depuis bientôt 20 ans. Pourquoi faut-il si longtemps pour que ces idées deviennent prévalentes ? Le sont-elles ?

Kelly : Ces idées ont toujours été présentes dans l’agilité, mais alors que l’agilité se répandait, le mouvement de la gestion de projet en faisait tout autant. Nombre d’entre nous au sein de l’agilité se sont abstenus de défier cela, peut-être parce que cela aurait été risqué pour nos carrières.

Ce qui pousse ces changements maintenant, c’est la mutation vers l’entreprise numérique. La technologie dirige la croissance. L’enfermer dans le modèle projet neutralise son potentiel.

InfoQ : Cela a du sens pour les nouvelles sociétés comme AirBnB et Uber, mais qu’en est-il des sociétés existantes qui ont livré des projets pendant des années ?

Kelly : Les entreprises traditionnelles avec des département IT voient le monde via le prisme de projets qui seront « terminés ». Pouvez-vous imaginer AirBnB annoncer que son système est terminé ? Au moment où une entreprises numérique déclare qu’elle a « terminé », elle abandonne sa place dominante et invite ses compétiteurs à la curée.

Les entreprises traditionnelles ne peuvent pas garder cette myopie, ni le coût additionnel qu’elle apporte, ni l’ambiguïté de ses buts. Les entreprises qui le font lancent une invitation à leurs adversaires. Une entreprise numérique ne peut pas traiter le développement technologique comme quelque-chose d’indépendant à l’entreprise, de préférence pas cher et éloigné, qui sera terminé un jour.

Regardez les banques traditionnelles. Malgré toutes leurs belles paroles, elles traitent la technologie comme un citoyen de seconde classe. Elles ont rogné sur les dépenses, accumulé de la dette technique, exploité leurs employés et déclarent leur succès depuis plus de 30 ans. Maintenant, elles découvrent que leur technologie et leur système d’entreprise ne peuvent rivaliser avec les FinTechs.

Les pratiques et processus qui ont porté cette réussite auparavant (gestion de projet forte, analyses extensives, externalisation, délocalisation, travail en lots de grande taille) sont dorénavant une entrave. Si, de façon superficielle, le « digital » ressemble à de l’IT à l’ancienne (le Java remplacé par le JavaScript, l’automatisation des tests, etc), il est complètement différent.

Nous avons ici au Royaume-Uni une banque qui s’appelle la TSB. Il y a six mois, la TSB a procédé à une mise-à-jour globale de son système. Alors que la banque tweetait des photos de célébration, les clients se plaignaient qu’ils ne pouvaient plus accéder à leurs comptes ni payer leurs factures. Six mois plus tard, ils n’ont toujours pas résolu tous les problèmes. La TSB peut prétendre être agile, elle ne l’est clairement pas, et ses managers ne savent pas non plus comment gérer la technologie. De telles banques sont déjà mortes, elles ne le savent juste pas encore.

Les banques ont raison de dire qu’elles sont « des sociétés technologiques qui font de l’argent en offrant des services bancaires ». Mais elles ont accumulé une abominable dette technique et la loi inverse de Conway limite ce qu’elles peuvent faire. Quelques-unes s’en sortiront, la plupart échoueront, mais elles doivent toutes essayer.

Les banques sont des cibles faciles pour les FinTechs. Je soupçonne beaucoup de leurs cadres supérieurs de le savoir, c’est pourquoi nombreux sont ceux qui se protègent en investissant dans leurs rivales FinTech.

Au sujet de l’auteur de ces livres

Allan Kelly est un spécialiste de l’amélioration agile. Il aide les petites et les grandes entreprises à améliorer leurs processus agiles et leurs produits numériques. Il compte parmi ses clients passés Virgin Atlantic, Qualcomm, The Bank of England, Reed Elsevier et de nombreuses petites sociétés innovantes dont vous n’entendrez jamais parler. Il a inventé le poker de valeur, les profils temps-valeur et les feuilles de dialogue de rétrospective. Il est l’auteur de « Dear Customer, the truth about IT » et d’ouvrages incluant « Project Myopia », « Continuous Digital », « Xanpan » et « Business Patterns for Software Developers ». Son blog se trouve à l’adresse https://www.allankellyassociates.co.uk/blog/ et c'est @allankellynet sur Twitter.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT