Testing Talks est une série d'interviews mettant en avant des personnalités du monde de la qualité et des tests de logiciels. Dans ce nouvel épisode, nous avons eu le plaisir de nous entretenir avec Venkat Subramaniam. Voici un résumé de son site interview.
Pouvez-vous vous présenter et décrire votre parcours ?
Je m'appelle Venkat Subramania. Je me considère comme un programmeur. Je programme depuis quelques décennies maintenant. J'ai commencé à programmer en C++, principalement dans le domaine du génie chimique et des raffineries, et je me suis découvert une passion pour les langages de programmation en cours de route. À l'heure actuelle, je programme dans une quinzaine de langages différents. Je ne suis bon dans aucun d'entre eux, mais je suis vraiment passionné par les langages. Je consacre la majeure partie de mon temps à la formation, au conseil et au mentorat. Je me déplace dans le monde entier pour collaborer avec des équipes. Mon rôle consiste principalement à accroître la puissance des équipes. Et je crois fermement en ce que l'on appelle le développement agile durable. Je me concentre presque entièrement sur les pratiques techniques en matière de développement agile, qu'il s'agisse de tests automatisés ou de l'amélioration de la qualité du code, en me concentrant sur les équipes pour qu'elles travaillent mieux ensemble au niveau technique. Mon rôle consiste soit à former l'équipe pour qu'elle s'améliore en matière de tests automatisés, soit à la conseiller et à l'encadrer pour qu'elle mette la main à la pâte dans ses projets. L'objectif est de les aider à adopter certaines technologies.
Comment avez-vous découvert les méthodes agiles ?
J'ai découvert les méthodes agiles avant qu'elles ne soient inventées. Je me souviens, à la fin des années 90, avoir travaillé sur un projet de logiciel. J'ai vécu une expérience - avec un client important - qui m'a fait l'effet d'une ampoule. Mon patron m'a appelé et m'a dit : "Hé, ce projet est une priorité absolue et tu vas mener l'action". J'ai répondu : "Super, pouvez-vous m'en dire plus ?" Il m'a répondu : "C'est prévu pour le premier numéro et tu as intérêt à le faire". J'ai compris que la seule chance de réussir était de collaborer en permanence avec les clients. Je les ai donc appelés et leur ai demandé s'il leur était possible de tester nos versions chaque semaine et de partager leurs commentaires…
Ce faisant, nous l'avons livré avec quelques semaines d'avance sur le calendrier. Honnêtement, j'ai été un peu secoué parce que j'ai emprunté une voie complètement différente de celle qui était prévue.
Ce n'est que quelques années plus tard que j'ai réalisé que je pouvais écrire un livre sur cette expérience. Avec Andy Hunt, nous avons coécrit "The Practice of an Agile Developer" (La pratique d'un développeur agile).
Qu'aimez-vous le plus dans votre travail ?
J'aime à dire que je suis comme un enfant dans un magasin de bonbons. Chaque jour, je me réveille avec hâte parce que c'est une expérience merveilleuse. Nous vivons dans un monde où nous pouvons créer des abstractions dans notre esprit, nous pouvons trouver des idées, les tester, les voir… Lorsque j'ai commencé à programmer il y a quelques dizaines d'années, je l'ai fait comme beaucoup d'autres. Les mathématiques et les sciences m'ont attiré. Mais ce qui me passionne vraiment aujourd'hui, c'est l'art, l'excitation, la quantité de choses que nous pouvons créer en termes de valeur pour les clients. Dans la plupart des secteurs, nous n'avons pas le luxe de pouvoir nous asseoir devant une machine, de la conceptualiser, de créer quelque chose et d'être en mesure de le livrer. Ce qui m'enthousiasme, c'est que nous pouvons créer des choses. L'autre chose, c'est que je peux travailler avec des développeurs du monde entier, leur demander de réfléchir à des solutions et de se mettre au défi d'appliquer ces idées différemment et d'obtenir des résultats.
Ce qui est également passionnant, c'est qu'il n'existe pas de solution universelle. Nous devons prendre un problème, y réfléchir et identifier une solution simple qui nous permettra d'obtenir les résultats escomptés. Il s'agit d'une combinaison de travail en étroite collaboration avec les personnes et la technologie et les défis qui l'entourent, puis d'être capable d'avoir un impact et de produire des résultats. (...) C'est fantastique de vivre cette expérience très humble où l'on peut vraiment contribuer au quotidien tout en réalisant qu'il y a encore beaucoup à faire, beaucoup à apprendre, beaucoup à offrir ; et c'est absolument gratifiant. Je ne peux même pas imaginer être dans un domaine dans lequel il n'y a rien de nouveau à apprendre ou rien de nouveau à exceller.
(...)
Que pensez-vous de l'automatisation dans le développement de logiciels ?
Revenons un instant en arrière. Il y a 30 ans, c'était mon premier voyage au Grand Canyon. (...) Je suis monté dans une voiture, (...) j'ai roulé pendant deux heures, j'ai arrêté la voiture sur le bord de la route et j'ai demandé : "Est-ce que je vais dans la bonne direction ? Suis-je perdu ?" J'avais deux options. Je pouvais continuer à rouler, peut-être me perdre, ou retourner à la civilisation jusqu'à ce que je demande à quelqu'un la bonne direction.
Et vous pouvez dire : "Oh Venkat, n'avais-tu pas une carte pour connaître la direction ?" Bien sûr, j'avais une carte avec moi. Pour les jeunes enfants d'aujourd'hui et même pour les jeunes développeurs d'aujourd'hui, c'est un peu difficile à comprendre, parce que nous avions l'habitude d'avoir des cartes en papier à l'époque. J'ai donc pris cette énorme carte en papier, mais il ne lui manquait qu'une chose, un point bleu. Aujourd'hui, nous avons des cartes électroniques. La carte elle-même n'est pas vraiment utile, mais ce point bleu l'est.
Les questions étaient donc les suivantes :
- Où êtes-vous ?
- Dans quelle direction devez-vous aller ?
- Quelle est la distance à parcourir ?
En tant qu'êtres humains, nous nous épanouissons lorsque nous disposons de cette boucle de rétroaction.
Si je prends du recul et que je me demande ce qu'est le développement agile, ma définition s'appuierait sur un développement axé sur le retour d'expérience.
Si l'on supprime le retour d'information, l'efficacité est réduite. En ce qui concerne les projets de logiciels, il existe deux boucles de retour d'information différentes qui sont essentielles.
La première question est la suivante : est-ce que je crée quelque chose de pertinent ou est-ce que je me contente d'écrire du code ?
En fait, et à mon avis, j'ai l'impression qu'il manque un mot au Manifeste Agile. Ils ont dit que nous devrions créer des logiciels qui fonctionnent. Mais je pense que ce qu'ils voulaient vraiment dire, c'est que nous devrions créer des logiciels fonctionnels et pertinents. Parce que si vous ne créez pas quelque chose de pertinent, nos efforts n'ont pas d'importance. (...) C'est là que la boucle de rétroaction s'établit avec les interactions entre les unités commerciales, les analystes commerciaux et QA .
La deuxième boucle de rétroaction consiste à comprendre pourquoi un code a fonctionné hier et pas aujourd'hui. Il s'avère que les logiciels sont des systèmes non linéaires. Imaginez que vous ayez un bâtiment, que vous placiez un livre d'un côté de l'étagère et que quelque chose tombe de l'autre côté. Ce serait bizarre. Vous ne voulez pas que les choses se comportent de cette manière. Mais c'est une réalité dans le développement de logiciels. Ce n'est pas rentable. C'est frustrant. Cela nous empêche de produire de la valeur. La question est donc la suivante : "Comment puis-je m'assurer que les modifications que j'ai apportées n'affectent pas d'autres parties du code ?" C'est une boucle de rétroaction.
Dans le développement agile, nous voulons deux boucles de rétroaction en même temps. La boucle de pertinence, comme j'aime à l'appeler, et la boucle de régression... Si vous supprimez cette boucle de rétroaction, c'est comme si vous marchiez les yeux bandés dans la pièce. Oui, je peux éventuellement me frayer un chemin jusqu'à la destination, mais je ne suis pas efficace. C'est une perte de temps et d'argent.
Au lieu de cela, investissons proactivement ce temps et cet argent dans la mise en place d'une automatisation au bon degré, au bon niveau, afin de profiter des boucles de rétroaction et de réduire les coûts.
(...)
Préféreriez-vous enseigner à des débutants qui ne connaissent rien aux méthodes agiles, ou à des personnes expérimentées qui utilisent mal les méthodes agiles ?
J'aime apprendre avec les personnes à qui j'enseigne. Je dis souvent en plaisantant que je suis le premier élève des classes auxquelles je participe. Du point de vue de l'apprentissage, je pense que nous pouvons apprendre des deux groupes de personnes. La semaine dernière, j'ai enseigné à un groupe de personnes et parmi les 20 étudiants, certains avaient environ deux ans d'expérience dans l'industrie, voire moins. D'autres avaient littéralement 35 à 40 ans d'expérience. Ce qui est absolument fascinant, ce sont les questions que l'on vous pose. Les nouveaux arrivants peuvent demander : "Pourquoi faites-vous cela ? Les générations plus anciennes peuvent demander : "Je fais comme ça". Dans les deux cas, il faut donc repenser son raisonnement dans des contextes différents.
En fin de compte, vous apprenez davantage sur l'empathie, le pragmatisme, les situations réalistes et l'offre de solutions que différents groupes peuvent adopter. Le défi n'est pas seulement d'atteindre l'objectif, mais aussi d'évaluer où nous en sommes et où nous voulons aller. Ainsi, la même solution peut être facile pour certains, mais difficile pour d'autres en raison de leur environnement différent.
Un effort supplémentaire peut être nécessaire pour sortir de la situation actuelle afin d'assurer la transition. Lorsque nous traitons avec différents groupes, nous pouvons devenir dogmatiques, prescrire et décrire ce qu'il faut faire, laissant les autres se gratter la tête en disant que cela ne marchera pas. Imaginez que vous enseignez à un groupe et que vous êtes enthousiaste, mais que la réalité est que ce groupe ne fonctionne pas de manière isolée. Il doit travailler avec d'autres personnes. Et maintenant, nous répondons aux besoins d'un groupe, mais de manière naïve. Sans tenir compte du contexte holistique dans lequel ils travaillent. Je dirais donc que le processus consiste à aider les équipes à s'améliorer. Et si nous pouvons apprendre avec elles et comprendre leur situation, être réalistes et pragmatiques dans nos solutions, je pense que nous pourrons obtenir de meilleurs résultats, car après tout, tout ce processus et tout ce que nous faisons a pour but d'obtenir les résultats que nous souhaitons.
Donc, si nous pouvons nous demander "Comment pouvons-nous obtenir des résultats ?" Je pense qu'il est important de réunir ces équipes et d'apprendre avec elles.
J'aime enseigner à des groupes dont l'expérience et l'expertise sont variées. Et si la question est : "Comment convaincre quelqu'un qui n'est peut-être pas convaincu, et comment convaincre quelqu'un qui est désireux et assoiffé d'absorber tout cela, puis de les rassembler pour obtenir des résultats ?" C'est vraiment passionnant d'avoir cette opportunité. Et heureusement, c'est aussi une réalité.
Comment les entreprises devraient-elles organiser leurs équipes de développement ?
Ce que nous appelons la loi de Conway dit que la structure de communication de l'organisation influence la structure des applications que nous créons. Je suis intimement convaincu que la clé est la collaboration. Plus nous séparons les gens et rendons leur communication difficile, plus il nous est difficile de développer des logiciels adéquats. J'ai travaillé dans différentes équipes par le passé. Des équipes avec des sous-équipes travaillant en silos et se cachant derrière leur propre bureau pour développer des logiciels. Ils peuvent communiquer au sein d'un petit groupe de personnes, mais ils ont une barrière à franchir pour communiquer. J'ai vu des équipes qui séparaient les programmeurs de QA, non seulement par des pièces ou des bâtiments, mais aussi par des continents. Et il est absolument stupéfiant de constater à quel point ils rendent la communication entre ces personnes plus difficile. Mais c'est inefficace. Les organisations que je considère comme performantes sont les équipes dont les membres peuvent communiquer entre eux. Littéralement, un programmeur peut déplacer sa chaise et s'asseoir à côté d'un testeur pour parler de l'écriture de tests automatisés pour une fonctionnalité particulière.
Le testeur peut faire glisser la chaise, s'asseoir à côté d'un analyste commercial et d'un programmeur et discuter des détails de ce sur quoi ils se concentrent dans les tests. Je suis un grand fan de la programmation en binôme et de la programmation en équipe. Le logiciel est un jeu collectif. Il n'y a aucun plaisir à être le meilleur joueur d'une équipe qui ne gagne jamais. Et je préfère être un joueur moyen d'une équipe très performante plutôt que d'être la rock star d'une équipe qui ne livre jamais le logiciel.
Ce dont nous n'avons pas besoin, c'est d'un accord pour qu'une équipe réussisse. Ils ne peuvent pas être d'accord sur tout ce qu'ils font ensemble. (...) Nous avons des opinions différentes, des idées différentes, des pensées différentes. Ensuite, vous dites, d'accord, nous considérons ces différentes options, mais pour cette situation particulière, c'est ce que nous allons faire. Et maintenant, l'équipe est alignée sur cette direction. Et si nous ne communiquons pas efficacement, cet alignement fait défaut. (...)
L'alignement vient de la communication. La communication découle de la collaboration, et la collaboration découle de l'existence d'équipes qui ont la possibilité de démanteler toutes les barrières qui nous empêchent de communiquer et de travailler ensemble.
Racontez-nous l'histoire du meilleur cours que vous ayez jamais donné ?
Honnêtement, le meilleur cours que j'ai jamais donné n'est jamais celui auquel j'ai pensé au début ou à la fin du cours. Lorsque j'enseigne à un groupe, je peux avoir le sentiment que ces personnes sont formidables, qu'elles sont interactives, qu'elles communiquent, qu'elles écoutent, qu'elles participent, qu'elles font des laboratoires, qu'elles sont formidables. Et j'ai aussi des équipes qui sont indifférentes ou qui ne participent pas, ce qui est plutôt frustrant. Mais en toute honnêteté, même si tout le monde aimerait avoir une équipe qui interagit et communique, je dirais que la meilleure équipe est celle qui peut montrer les résultats de l'apprentissage. Je vais vous donner un exemple. Une équipe du Royaume-Uni m'a appelé et m'a dit qu'elle voulait que vous veniez faire une formation sur le TDD. J'ai parlé à leur directeur et je lui ai demandé : "Pourquoi voulez-vous faire une formation TDD ?" Il m'a répondu qu'il voulait améliorer son travail. Ensuite, je lui ai recommandé de changer de méthode, alors qu'il m'avait dit que cela lui coûtait un million de dollars.
Il m'a répondu : "Pourquoi ne voudrais-je pas changer les choses alors que vous perdez un million de dollars ?" Avec tout le respect que je vous dois, je vous explique que si je marche sur la route et qu'un billet de 10 dollars s'envole de ma main, avec tout le respect que je vous dois, je ne vais pas courir derrière le billet de 10 dollars parce que pour moi, le billet de 10 dollars est un montant insignifiant par rapport à la richesse que j'ai pour votre entreprise. Mes 10 dollars représentent un million de dollars. Il voulait savoir pourquoi ils voulaient vraiment faire des tests automatisés, et je lui ai donné le vrai raisonnement. Mais au lieu de cela, j'ai dit : "Si vous me donnez deux semaines, je m'assoirai côte à côte et je ferai de la programmation en binôme pour écrire des tests automatisés avec votre équipe".
Je les enseigne, mais pas de manière traditionnelle. Permettez-moi de me tenir debout ici et d'en parler à l'aide de diapositives, mais asseyez-vous et faites de la programmation avec votre équipe. Il m'a répondu que ce n'était pas pour cela que nous vous avions appelé, mais laissez-moi y réfléchir et je reviendrai vers vous. Un mois plus tard, il m'a appelé et m'a dit : "D'accord, nous en avons parlé dans mon équipe. Nous avons décidé d'essayer. Alors pourquoi ne viendrais-tu pas, sans formation officielle, mais en faisant du jumelage, pour que tu puisses nous apprendre comment faire des tests automatisés sur les projets logiciels. J'y suis donc allé, et j'ai passé deux semaines à tourner littéralement avec les développeurs et à faire des tests automatisés sur le projet. Comment cela s'est-il passé ? Eh bien, du point de vue de l'excitation, je dirais que c'était génial. Les développeurs étaient interactifs, ils me mettaient au défi, me posaient constamment des questions. Nous avons pris des problèmes vraiment difficiles, et nous avons été capables de les redéfinir et d'écrire le test correspondant. Mais était-ce un succès ou un échec ? Était-ce le meilleur cours ou la meilleure formation que j'aie jamais suivie ? Non.
Mais le moment décisif pour moi s'est produit six mois plus tard, lorsque j'ai reçu un courriel du directeur m'informant qu'il avait réalisé que j'étais au Royaume-Uni pour prendre la parole lors d'une conférence. Ils m'ont demandé de venir passer une demi-journée avec leur équipe. Ils étaient très enthousiastes à l'idée de me revoir. Ils m'ont montré le test automatisé qu'ils avaient effectué sur leur produit, et j'ai été époustouflé. C'est un exemple de la meilleure formation que j'ai jamais suivie.
La formation la plus inefficace est celle où les équipes se montrent enthousiastes et où, dès que je sors du bâtiment, elles n'intègrent aucun changement.
Un dernier mot pour cette interview?
Je recommande aux développeurs de logiciels d'être absolument sans vergogne. C'est l'une des recommandations que je fais aux développeurs débutants et aux développeurs expérimentés. Nous travaillons dans un domaine où il s'agit d'un processus d'apprentissage quotidien. Les idées nous font avancer, mais les idées que nous apprenons sont celles qui vont changer notre façon d'avancer à l'avenir. Donc, pour être tout à fait impudique, et si vous voulez mon avis, l'un des points de basculement pour moi a été lorsque j'ai commencé à écrire mes livres. Demandez aux gens de critiquer votre livre. C'est une grande leçon d'humilité quand ils reviennent et signalent tant de choses dans chaque chapitre qui doivent être modifiées, améliorées ou réécrites. Ce qui est étonnant, c'est que vous arrivez ici avec des choses que vous savez, mais que vous pouvez aller de l'avant grâce aux choses que vous pouvez apprendre des autres et apprendre avec les autres. Mais cette expérience de parapluie n'est possible que si l'on est prêt à faire preuve d'impudeur. Si nous essayons de protéger ce que nous savons, cela nous empêche en fait de devenir le meilleur de nous-mêmes demain.
N'hésitez donc pas à demander ce retour d'information et à dire : "Je travaille avec des gens extraordinaires que je respecte beaucoup, mais ce qui a vraiment renforcé mon respect pour eux, c'est qu'ils venaient voir l'équipe et disaient : "J'ai mis en œuvre ceci, et je voudrais que vous l'examiniez et que vous me disiez ce que je peux améliorer sur ce point". Lorsque j'entends cela, je considère cette personne comme un expert. Je sais maintenant comment cette personne est devenue un expert en étant prête à écouter les idées des autres et à venir dire : "J'ai mis cela en œuvre. Je vais tenir le fort et le défendre. Ce n'est pas une bonne solution pour aller de l'avant, mais pour dire : "J'ai mis cela en œuvre, mais je veux que vous me disiez comment je peux l'améliorer". Dans ce genre de situation, on ne peut que gagner. En effet, lorsque vous allez voir quelqu'un et que vous lui demandez de revoir et d'obtenir un retour d'information, il vous dit que ce que vous avez fait est formidable, ce qui valide parfaitement vos idées. Ou bien il vous dit, voici les choses que vous pouvez changer et améliorer, ce qui vous donne l'occasion d'apprendre des choses, de faire mieux à l'avenir.
.png)
