BT

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

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles La vraie question est Pourquoi ?

La vraie question est Pourquoi ?

Favoris

Dans les années 90, nous étions au plus bas jamais atteint dans l'industrie du développement logiciel. La programmation commençait à devenir une profession courante et nous étions majoritairement très mauvais. Un rassemblement des esprits les plus brillants de l'industrie fut organisé en 2001 et bien que je soupçonne qu'ils aient été incapables de s'accorder sur une méthodologie, ce qu'ils décidèrent a eut un impact jamais égalé à ce jour dans l'histoire de l'industrie. Le résultat a été la résolution des problèmes des années 90. Ainsi ils créèrent une communauté de personnes partageant les mêmes idées pour débattre de la meilleure façon de livrer un logiciel. Maintenant que l'Agilité est devenue courante et que nous avons beaucoup progressé dans la création logicielle, un nouveau problème commence à émerger.

Une grande citation que j'ai (Gordon) entendu une fois, “ne jamais confondre la composition d'une symphonie avec l'écriture de la partition”. Il n'y a que quelques rares génies capables de créer une symphonie digne de ce nom et qui lorsqu'elles sont jouées, touchent invariablement la sensibilité des spectateurs et excitent l'inspiration et la joie.

Je pousse probablement l'analogie trop loin mais, je crois que cela est également vrai pour le logiciel. Le problème tel que je le vois est que nous avons compris comment avoir du beau code, comment bien l'écrire et même comment évaluer si le langage choisi est adapté, avec la bonne conception et les bonnes méthodes. Je m'explique, toutes ces choses sont extrêmement importantes mais malheureusement ce sont uniquement ces choses sur lesquelles la plupart des des ingénieurs logiciels se concentrent.

La chose qui a nuit au développement logiciel et à la livraison de produits pendant des années a été de décider quoi construire. La réponse est souvent, “ce que l'utilisateur a demandé”, mais ce n'est pas satisfaisant car si vous demandez aux utilisateurs ce qu'ils souhaitent, ils ne le savent généralement pas eux-mêmes.

À l'université un intervenant a raconté à Gordon une histoire de constructeur automobile aux États-Unis qui a mené une étude en demandant aux gens ce qu'ils voulaient dans une voiture et se basa simplement sur le résultat pour créer la voiture américaine idéale. Le résultat ? Un échec. Pourquoi ? La réponse à ce genre de questions est souvent complexe, mais dans ce cas la cause principale peut, je crois, revenir au fait que les utilisateurs de voitures ne sont pas des concepteurs de voitures.

Cela s'observe aussi chez les utilisateurs d'ordinateurs ; ils peuvent dire avec une grande certitude ce qu'ils n'aiment pas à propos de quelque chose mais la plupart d'entre eux ne peut pas vous aider à mettre au point un système à partir de rien. Ils sont comme la plupart des gens qui fonctionnent mieux avec quelque chose qui fait appel à de multiples canaux, presque viscérales, qu'ils soient sensoriels ou auditifs. Nous sommes aussi fondamentalement meilleurs à travailler à partir d'un point final qu'à essayer d'en atteindre un inconnu. Essayer de définir les exigences sans être capable de faire appel aux retours de ces différents canaux sera presque impossible pour eux.

L'étude du Standish Group en 2002 sur le succès du modèle en cascade a montré que 80% des fonctionnalités livrées ne sont jamais utilisées ou presque. Même si ce n'est pas parfaitement précis, car je ne suis pas sûr de comment cela a été mesuré, je suis convaincu qu'il y a des fonctionnalités dans le logiciel que j'utilise pour écrire cet article que je n'utiliserai jamais ou que je ne connais pas et dont je n'aurai jamais besoin. Mon ami et collègue en innovation de livraison logicielle, Russ Miles, a déclaré publiquement qu'il possède “une version de Microsoft Word v1.04b sur un Mac circa de 1987 qui a toutes les fonctionnalités dont j'ai besoin pour faire la majorité de mon travail”. Ce n'est pas simplement du ‘bloatware’, c'est du gaspillage à grande échelle. Gâchis d'argent, gâchis de capacité de production et, surtout, gâchis de cette ressource si précieuse : La vie humaine. Imaginez tout ce qui aurait pu être construit si toutes ces heures passées sur Clippy (pour prendre une cible facile) avaient été passées à construire quelque chose d'utile et de nécessaire !

Pour prendre un autre exemple, certaines fonctionnalités de mon téléphone mobile sont tout aussi inutiles. Le but n'est pas de critiquer le matériel ou le logiciel lui-même, c'est surtout pour montrer que quelqu'un l'a défini, l'a écrit et l'a testé. Sur les sommes extravagantes dépensées en développement logiciel ces 10 dernières années, quelle part l'a été inutilement ou n'est pas utilisée ou même pas adaptée ? Imaginez seulement si tout cela avait été utile ? Peut être que 2010 : L'Odyssée de l'espace aurait pu devenir une réalité.

Je ne dis pas qu'il n'y a pas vraiment de grandes choses produites tout le temps et qu'on ne progesse pas à une vitesse ahurissante. Mais le soucis est que la majorité des fonctionnalités de logiciels produites aujourd'hui ne sera probablement pas utilisée. Je dirais que c'est particulièrement déprimant, voir même carrément irritant, et certainement encore plus pour la personne composant la sympohonie.

L'Agilité devient courante également, ce qui est fantastique, et j'espère que cela signifie que nous pouvons commencer à privilégier les individus et intéractions avant les procédures et les outils. Le manifeste Agile est une concertation de quelques-uns des plus grands esprits et des meilleurs systèmes de production dans l'industrie du développement logiciel. Ce qu'ils ont essayé de faire était de distiller la recette du succès de la production logicielle, c'est à dire : beaucoup de collaboration, de petits lots, des révisions régulières d'un logiciel fonctionnel. Tous ces éléments permettent d'assurer que la livraison du logiciel a toutes les chances d'être un succès, par opposition aux risques énormes des gros lots et grands projets.

Ce qui m'inquiète est ce qui va se passer après ? Supposons que le développement agile a finalement attaché le moteur à la chaîne de transmission... et c'est parti ! Nous pouvons maintenant produire à un rythme effarant, excellent ! Pendant des décennies c'est ce que nous avons essayé de faire, donc nous avons accompli beaucoup. Mais, comme Russ le faisait remarquer lors de sa présentation à la QCon Londres 2013, maintenant que nous avons atteint l'objectif de “produire régulièrement du logiciel de qualité”, la prochaine cible ne devrait-elle pas être “produire du changement régulièrement”. Que se passe-t-il si le logiciel à l'air d'avoir de la valeur et se révèle inutile ? Que faire si le logiciel n'est qu'une pièce du puzzle ? Nous pourrions bien avoir passé 10 ans à perdre notre temps.

Il y a un vrai danger que nous commencions à produire efficacement quelque chose d'inadapté plus rapidement et plus fréquemment qu'auparavant. Effectivement, les chances d'obtenir le bon résultat sont nettement améliorées via ces techniques à haut niveau de collaborations mais il est naïf de croire qu'en adoptant les méthodes agiles on se met tout à coup à produire les bonnes choses correctement. Après tout, ça reste le même groupe de personnes.

Nous avons participé à un extraordinaire rassemblement en février, organisé par notre ami et gourou Gojko Adzic. Il avait réussi à faire venir quelques-uns des plus grands noms de l'industrie du développement logiciel pour une journée d'ateliers de travail intenses. Nous nous sommes attelés à la tâche et Gojko a publié les résultats sur son blog.

Durant cette session nous avons travaillé avec des techniques que nous avions déjà rencontrées auparavant et d'autres, nouvelles que nous n'avions jamais vues en action ; toutes étaient particulièrement bien pensées et essayant toutes de nous aider à comprendre pourquoi la question fondamentale soulevée en 2001 par les membres du manifeste Agile avait peu de chance de permettre de tomber d'accord sur "LA" bonne méthode de produire du logiciel, il était également peu probable que nous tombions d'accord. Chaque technique est en elle-même très puissante et chacune est idéale dans un certain contexte, et chacune cible précisément la question du "pourquoi" nous développons ce logiciel.

Une idée qui frappa Gordon est que nous, techniciens, devons aider les chefs d'entreprise à expliquer pourquoi ils ont besoin d'une solution utilisant des méthodes visuelles car ceci est très difficile.

Ce sont de vraies pratiques qui marchent dans le monde réel de la même manière qu'XP ou Scum permettent d'aider les équipes à devenir Agile, avec tout ce que ce terme implique. Ces techniques sont faites pour nous aider à atteindre ce but.

Un des résultats important de cette journée d'ateliers a été les principes suivants pour le bon développement logiciel :

  1. Les organisations se concentrent sur l'obtention de résultats et les impacts plutôt que les fonctionnalités.
  2. Les équipes décident quoi faire ensuite en se basant sur les retours immédiats de l'utilisation de leur travail.
  3. Les gens savent pourquoi ils font leur travail.
  4. Tout le monde s'implique.

Nous les avons réordonné différemment de ce que nous avions fait lors de la session car cet ordre me parait plus naturel.

Ces principes raisonnent parfaitement en rythme avec une nouvelle emphase, voir même comme un appel aux armes, que nous tentons de faire passer à l'industrie. Pour reprendre une phrase tant utilisée qu'elle pourrait devenir un cliché : tout en s'appuyant sur les concepts posés par les auteurs du manifeste agile, nous, en tant qu'industrie, commençons à accomplir une partie de ce message. Nous délivrons de plus en plus, ce qui est une bonne chose.

Et maintenant il est temps de livrer ce qu'il faut. Cela commence en se demandant pourquoi nous livrons du logiciel. Comme Russ le dit, “Nous ne sommes pas (seulement) des développeurs logiciels ; nous délivrons du changement de qualité”. C'est la réalité de ces 10 prochaines années pour notre industrie. Faire marcher cela sera probablement aussi difficile que ce que ça a été de rendre l'Agile à la mode, mais c'est critique pour notre futur.

Bienvenu dans le futur de la livraison logicielle réussie, tout va tourner autour du Pourquoi ?

À propos des auteurs

Russ Miles est un consultant senior chez Simplicity Itself et travaille avec ses clients pour livrer du logiciel de qualité en continu et de manière durable. L'expérience de Russ couvre presque toutes les facettes de la livraison logicielle du fait qu'il ait travaillé dans de nombreux domaines comme les services financiers, la publication, la défense, les assurances et la recherche. Avec plus de 16 ans d'expérience dans le conseil, le coaching et la formation, Russ utilise une vue holistique du processus de livraison logicielle dans le but de créer des programmes multi-facettes en amélioration continue faisant appel à toutes les compétences des développeurs, pour créer et faire évoluer les meilleures architectures et design pour un domaine donné, à travers le conseil en management de différentes sociétés sur comment appliquer la pensée et les méthodes lean et agiles pour mieux gérer le retour sur investissement de leur effort de développement logiciel. Russ est aussi conférencier international sur les techniques d'amélioration de la livraison logicielle et un auteur publié, dont l'ouvrage le plus récent est "Head First Software Development" chez O'Reilly Media. Il travaille actuellement sur deux nouveaux livres ; "Programming Spring" chez O'Reilly Media qui propulse la méthode de Simplicity Itself de "Test Driven Learning" au premier plan pour la première fois, et un autre livre, dont le titre de travail est "Field Guide to Continuous Improvement for Software Delivery Team Members" et qui capture les différents outils de réflexion et techniques qu'un développeur professionnel peut appliquer concrètement pour améliorer ses propres objectifs continuellement.

Gordon Weir est un expert en méthodes lean et agiles et la gestion du changement dans les organisations. Il a roulé sa bosse depuis le jeune ingéneur néo-zélandais de 1998, travaillant pour la Royal New Zealand Navy, à la tête du département technologique de la Bank of America Merrill Lynch à New York, un changement qu'il fit après avoir vécu au Royaume Uni pendant 14 ans comme consultant d'abord puis dans une banque d'investissement. Grâce à ce parcours, il a développé une connaissance approfondie et une compréhension de diverses cultures, et donc ce qui est nécessaire pour les aider à changer.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT