Agile as if you meant it - Maaret Pyhajarvi at FlowCon France 2019

[00:00:04] Bonjour à tous. Bonjour.
[00:00:09] J'entends dire qu'il y a une grève ici et c'est super de voir que vous avez réussi à venir si nombreux. On m'avait dit que ce serait probablement vide, et ça n'a pas l'air vide du tout pour moi. J'ai tendance à croire que ceux qui viennent sont toujours les bonnes personnes. Donc, même si c'est un peu plus intime que ça ne le serait sans grève. Au moins, ça nous donne une chance, vous savez, d'être plus proches et plus intimes avec ce sujet. Alors, euh, ce matin, nous allons parler d'Agile. Agile comme si vous le pensiez est le titre. Et ce à quoi j'en arrive, c'est que, euh, ces trois dernières années, et plus tôt dans ma carrière, il y a environ 10 ans, pendant trois ans et demi, j'ai travaillé dans une entreprise de produits appelée FCure. Et pendant très, très, très longtemps, je savais que là-bas, nous faisions ce qu'on appelle l'Agile. Et je me sentais vraiment honteux d'aller à des conférences pour parler d'Agile, parce que quand j'allais écouter des discussions sur l'Agile, j'avais l'impression qu'il devait y avoir quelque chose que nous ne faisions pas encore et qui définissait en quelque sorte l'Agile. Comme si j'avais cette incertitude que je ressentais toujours. Et puis, l'entreprise, après avoir fait de l'Agile pendant environ 15 ans, a décidé à un moment donné que l'Agile était un mot interdit. Vous n'êtes pas censé le mentionner. Si vous le mentionnez, surtout à des managers de niveau supérieur, cela signifie généralement que vous êtes en quelque sorte un peu particulier, probablement un peu trop, euh, euh, je dirais même religieux autour de ce genre de choses, d'une certaine manière. Et, euh, euh, il est toujours préférable de l'appeler autrement. Beaucoup d'entre nous ont fini par l'appeler DevOps. Euh, beaucoup d'entre nous ont fini par l'appeler, vous savez, on travaille juste ici. Euh, on fait juste des logiciels. Euh, on n'en parle pas vraiment en tant que tel. Et euh, la raison pour laquelle je veux en parler aujourd'hui est double. La première est que c'est ma 400e conférence de ma vie. C'est plutôt cool d'avoir l'occasion d'en faire autant. Et la deuxième raison est que lorsque j'écrivais un article sur la façon dont nous travaillons, JB Reignsburger l'a lu, l'a posté sur LinkedIn et a dit Agile comme si vous le pensiez. C'est de là que j'ai tiré le titre, donc j'ai juste, en quelque sorte, pris ça comme un, ok, il semble que nous ne fassions peut-être pas tout de manière si étrange et si éloignée que je le pensais. Alors, la façon dont nous travaillons est plus ou moins résumée dans cette image. Dans mon équipe, qui compte 11 personnes, nous avons 11 personnes qui s'identifient toutes comme des développeurs de différentes sortes. Nous avons des spécialités, nous avons des choses qui rendent chacun de nous unique, mais la façon dont les choses fonctionnent est que chaque développeur est au centre du processus de développement logiciel, parce que rien ne change en production. Si un développeur ne crée pas une partie de code, un changement, une configuration, quelle que soit la finalité de ce code, crée une pull request, la fait approuver, et la voit tourner en production. C'est un peu la simplicité de la vie quotidienne. Il suffit qu'une personne écrive quelque chose dans un fichier, et, vous savez, les choses se passent autour et les choses sont différentes pour les utilisateurs. L'équipe de 11 personnes est responsable d'un grand nombre d'utilisateurs. Mon équipe travaille sur les clients de sécurité de point de terminaison Windows pour une ligne d'affaires particulière. Donc, je suis plutôt contente de voir que nos appareils actifs mensuels, la semaine dernière, nous avons célébré 1,5 million d'utilisateurs. Ils nous envoient des cas de maintenance. Tous ces cas de maintenance arrivent à mon équipe, les 11 personnes, et nous sommes toujours heureux, nous allons toujours bien. Parce que, vous savez, vous prenez un cas de maintenance, vous le traitez, vous faites quelques changements dans le code et, voilà, 1,5 million d'utilisateurs n'auront, espérons-le, plus ce problème. Alors, les choses semblent très faciles et très pratiques. Et j'ai d'adorables collègues, j'aime aller travailler, et ça semble vraiment, vraiment simple, mais je sais que ce n'est pas si simple que ça. Il nous a fallu beaucoup d'efforts pour construire cette euh machinerie là-bas. Cette machinerie ici. C'est un système d'automatisation des tests. Il tourne de nos jours pour nous du côté client Windows. Il exécute environ 14 000 machines virtuelles Windows par jour, juste pour, vous savez, tester des choses. Mais ce sont des machines, je ne les compte plus vraiment comme telles. Et juste du point de vue de mon équipe, maintenant que nous avons eu pendant environ un mois une télémétrie d'automatisation des tests étendue, je sais qu'il s'agit d'environ 200 à 220 000 tests par jour. Et encore une fois, tout cela revient à ces 11 personnes qui doivent gérer toutes les pannes qui se produisent dans ce cadre. Donc, euh, les choses fonctionnent euh avec cette machinerie, avec le fait qu'il y a des gens sympas qui collaborent ensemble et l'idée centrale que les développeurs sont mis au centre. Ils sont intelligents, ils sont capables et ils grandissent chaque jour en parlant à d'autres personnes intelligentes. Pas tous développeurs, mais aussi d'autres développeurs. Et les choses autour de l'écriture de tickets Jira et de la prise de travail à partir d'un backlog. Nous ne nous soucions pas vraiment de ce genre de choses. Tant que nous créons cette pull request, nous nous assurons qu'elle nous fait avancer plutôt que reculer, et nous faisons cela encore et encore. Donc, c'est plutôt agréable d'être ici dans ce genre de situation. J'ai eu l'occasion de travailler dans d'autres types d'organisations également. Et euh, ce n'est pas la même chose partout chez FCure. Mon équipe est très, très spéciale et très unique dans beaucoup des choses que nous avons faites. Et j'essayais de penser à ce que sont les trois choses que nous devions apprendre pour que nous soyons heureux ensemble et capables de gérer un bon nombre de choses. Et je pense qu'il y a eu trois changements majeurs pour nous. Le premier, la fréquence de publication, l'idée que vous n'avez pas à essayer de planifier quelque chose très loin dans le futur, mais quand vous faites un changement, vous supposez en quelque sorte qu'il sera déployé assez facilement et relativement vite. C'est le premier. Le second, euh, chez nous, c'est sous le nom de pas de product owner, nous en reparlerons. Mais le sens de l'appropriation, le sentiment que vous n'avez pas à respecter une sorte de hiérarchie autre que le fait que les développeurs seront au centre. Parce qu'en retirant les développeurs, il n'y aura rien de mieux pour les utilisateurs. Si personne ne change le code, rien ne changera. Et comme troisième aspect, l'apprentissage, même s'il existe des moyens qui pourraient encore être meilleurs, nous ne les connaissons probablement pas tous. Donc cette curiosité et cette motivation à aller de l'avant est la troisième partie dont je parlerai aujourd'hui. Est-ce que ça sonne ? D'accord. Alors commençons par la fréquence de publication. Et avec la fréquence de publication, ce par quoi je veux commencer est cette idée qu'il est peut-être utile de penser à des exemples d'ailleurs que du logiciel afin que nous comprenions quel type de changement cela apporte et pourquoi cela pourrait être nécessaire. Alors, récemment, j'ai fait du shopping. Euh ma fille voulait avoir une baignoire. Alors j'ai acheté ce euh relativement grand euh euh conteneur d'eau. Euh il n'est pas normalement rempli d'eau. Il est en fait pliable pour que je puisse le ranger proprement. Et et quand il est sorti, il remplit toute notre salle de bain. C'est une chose plutôt agréable à avoir, car elle peut le ranger toute seule. J'ai parlé d'elle parce qu'aujourd'hui c'est son 11e anniversaire et elle n'est pas excessivement heureuse que je sois en France et qu'elle ne soit pas ici. C'était notre plan initial, mais ça ne s'est pas tout à fait passé comme ça. Mais la baignoire nous procure beaucoup de joie. En tant que contenant d'eau, c'est, vous savez, c'est presque comme sa piscine privée. Mais ce n'est pas une piscine. Donc si vous pensez à une piscine, c'est toujours un récipient d'eau. Euh vous pouvez y faire rentrer quelques personnes de plus. En fait, dans cette baignoire que nous avons, vous pouvez faire rentrer quelques enfants. Peut-être même si vous vous serrez, vous pouvez y mettre plus de deux enfants. Mais quand même, vous ne pouvez pas faire toutes les mêmes choses dans cette baignoire que vous pouvez faire dans une piscine. Donc, si vous sortez, quelque part où il fait chaud, espérons-le, et que vous allez dans une piscine, vous pouvez vous attendre à voir des choses comme un maître-nageur. Euh, même dans le cas des enfants, je n'ai plus besoin d'aller regarder mes enfants prendre leur bain. Ils sont assez grands pour ça. Donc, ils n'ont pas besoin de maître-nageur de bain, et si vous pensez à un adulte dans cette baignoire, encore moins vous penseriez à avoir besoin d'un, ou à avoir un maître-nageur de bain. Si vous pensez à un truc à sauter, comme le, ou peut-être un toboggan, un truc à toboggan d'où vous pouvez sauter dans l'eau, vous pouvez vous attendre à voir quelque chose comme ça dans une piscine. Mais vous ne vous attendriez pas à voir ces choses dans une baignoire. Et si vous organisez une fête pour tous vos amis, une fête au bord de la piscine, une pool party, c'est un peu une chose à faire. Mais si vous finissiez par inviter tous vos amis à votre bath party, cela vous rendrait probablement plus particulier que d'avoir un comportement réellement attendu. La raison pour laquelle je vous parle de ces piscines et de ces baignoires, c'est que ce sont toutes deux des conteneurs d'eau. C'est un peu comme, vous savez, faire des versions, vous savez, vous les faites juste plus vite. Quelle est la différence là ? Si vous faites des versions 20 fois par jour, pourquoi est-ce différent de faire des versions tous les trois mois ou deux fois par an ? Parce que, tout comme avec les conteneurs d'eau, avec des cycles de version différents, vous pouvez faire des choses différentes. Et c'est quelque chose que j'ai mis du temps à comprendre.
[00:11:31] Donc, vous verrez que lorsque votre cycle de publication est plus court, les choses que vous aviez l'habitude de faire avec ce cadre temporel au travail, ce n'est plus exactement la même chose, comme si vous commenciez à énumérer ces choses et que vous essayiez de les expliquer à quelqu'un d'externe. Vous savez, ça sonne toujours comme, oui, vous faites des publications. Oui, vous faites des changements de code. Oui, vous faites des tests. Oh, vous faites aussi de l'automatisation des tests. Tout cela, ce sont des choses que nous faisons depuis toujours et à jamais. Mais quand vous faites les choses plusieurs fois par jour, tout l'univers de la façon dont vous entrelacez ces choses change. Et vous pouvez voir que les pratiques sont très différentes à cette fin. J'aime beaucoup cette illustration de Paul Hamant. Euh, elle dit en quelque sorte joliment que même la façon dont nous pensons l'architecture, même la façon dont nous pensons à brancher notre code, même la façon dont nous gérons nos bases de données. Tout cela change quand vous voulez prendre un chemin plus rapide. Donc, cette fréquence de publication a été la chose sur laquelle nous avons le plus travaillé. Sur certains de nos composants, euh, euh, le monde nous a naturellement menés à cet endroit où, probablement depuis déjà 10, 15 ans, nous faisons 20 et quelques publications par jour. Parce qu'avec l'antivirus, les mises à jour, euh, vous devez en quelque sorte le faire. Il n'y a pas d'autre option, sinon les logiciels malveillants sont partout dans le monde si vous n'avez pas quelque chose pour les supprimer assez rapidement. Mais l'idée de publications rapides se propageant jusqu'aux équipes produit comme la mienne, les niveaux supérieurs, les choses avec lesquelles l'utilisateur interagit directement, c'est une chose un peu plus nouvelle. Donc, la façon dont je vois cela du point de vue de FCQ est que nous nous retrouvons avec un monde très mélangé. Euh, nous avons ce que j'appelle le bon endroit. Évidemment, je suis un peu biaisée ici. J'appelle le bon endroit, l'endroit où je suis. Et j'utilise le mot bon endroit ayant vu la série le bon endroit et pensant ironiquement que nous ne réalisons peut-être pas ce qui se passe autour de nous, mais, vous savez, apprendre cela éventuellement est toujours une possibilité. Ensuite, j'ai parfois l'occasion de faire d'autres choses que celles de ma propre équipe. Et certaines d'entre elles, je les appelle l'endroit qui aspire l'âme. Les mêmes composants techniques, des pratiques de publication différentes, un monde complètement différent. Et puis parfois, certains des managers de très haut niveau de l'organisation décident que nous allons faire un produit entièrement nouveau. Cela arrive aussi. Et d'une manière ou d'une autre, ils oublient toutes les leçons que certains d'entre nous ont sur les choses quotidiennes en cours, sur le déploiement continu, et ils mettent en place un projet de six mois ou un projet d'un an. Et c'est ce que j'appelle généralement l'asile de fous, quand tout revient à ce que c'était et que vous vous battez juste, vous savez, pour arriver quelque part de plus sensé. Et la différence dans ces trois endroits vient en grande partie du cycle de publication. Donc, dans le bon endroit, les versions sont quotidiennes ou hebdomadaires, un peu par nécessité. Euh, s'il s'agit d'un système back-end, euh, vous pouvez mettre des choses en production dès qu'elles sont disponibles, tout le temps. Mais dans mon cas, nous travaillons, comme je l'ai dit, avec 1,5 million de clients finaux. Cela signifie 1,5 million d'ordinateurs dont quelqu'un d'autre a décidé ce qu'il y avait dessus et comment ils étaient configurés. Et ce sont tous des ordinateurs individuels, et le logiciel que nous créons pourrait casser ces ordinateurs de manières surprenantes que nous ne pouvons pas toujours tester entièrement en interne. Cela signifie donc généralement que nous faisons les choses plus lentement, même si nous avons rendu la version disponible, nous surveillons pendant un certain temps avant de la rendre disponible pour l'ensemble des clients afin d'éviter des erreurs à grande échelle. Dans l'endroit qui aspire l'âme, euh c'est le type de chose la plus traditionnelle Agile que ma compagnie semble faire. Nous avons une cadence de deux semaines, donc toutes les deux semaines il y a une version. Mais la raison pour laquelle je l'appelle qui aspire l'âme tend à être liée au fait que vous savez exactement quand la version est terminée, mais vous n'avez pas le même genre de joie à remplir un but parce que la cadence ne vous donne pas un but comme le pense le client. Et dans l'asile de fous, euh quelqu'un espère encore que ça marchera par magie quand on le livrera à la fin du projet.
[00:16:30] L'attitude envers la qualité est aussi un peu différente. Euh, pour le bon endroit, euh, nous disons généralement des choses comme, oh, je me soucie beaucoup de la production. Genre, tout ce qui se passe en production, c'est ça, c'est en fait la chose que nous devrions rechercher. Dans les endroits avec une cadence de deux semaines, euh les gens euh parlent de, analysons un peu plus. On peut encore, vous savez, planifier un peu plus, vous savez, pendant ces deux semaines, voyons si c'est le bon changement. Faisons un changement plus petit d'abord. Et avançons lentement pour que nous puissions toujours euh contrôler le risque. Donc il y a une petite différence dans cette attitude. Et dans l'asile de fous, euh ils disent généralement des choses comme, je me soucie de ma fonctionnalité jusqu'à la production. Et c'est probablement la plus grande différence là-bas. Donc la production est le seul monde réel qui existe pour nous. Mais ça n'existe pas encore pour eux, donc ils font généralement les choses différemment. Comment livrer dans un bon endroit, vous commencez ensemble, vous finissez ensemble, et vous n'avez pas besoin d'un ticket Jira pour commencer quelque chose. Vous n'avez pas besoin d'un ticket Jira pour être là au milieu, euh vous pouvez simplement faire un changement. Et quand les choses sont documentées, pour nous, c'est avec les pull requests, c'est avec une documentation orientée utilisateur final, et c'est avec l'automatisation des tests qui empêche les choses de se casser plus tard dans la vie. Dans l'endroit qui aspire l'âme, euh quand j'y vais, euh c'est peut-être mon cheval de bataille. On me dit, non, non, non, tu ne peux pas faire ce changement. Tu ne peux pas parler à cette personne, euh sans un ticket Jira. Donc c'est bon que tu le fasses. Mais tu dois d'abord écrire ce ticket Jira. Genre, non, je ne veux pas écrire ce ticket Jira. Quand j'y vais et que je dois mettre à jour le ticket Jira parce que j'apprends et que je dois retourner au ticket Jira, ça me vide vraiment de mon âme. Et dans l'asile de fous, tout le monde écrit des tickets Jira, personne ne discute même de savoir si cela a du sens ou non. Mais ensuite, il y a un groupe distinct de managers qui font une sorte de jonglerie sur qui prend quoi et vous ne savez même pas si les choses sont faites ou non. Donc même au sein d'une seule entreprise. La maintenance, pour nous, c'est réparer, oublier, euh réparer et oublier, puis échouer en avant. Donc, quand nous voyons un nouveau problème, il est déjà là. Nous aidons d'abord les clients à arriver à un endroit où cela ne leur coûte pas tant de problèmes. Donc, généralement, nous n'avons pas à revenir en arrière. Et euh nous livrons ensuite le correctif aussi vite que possible. Donc c'est la réputation que nous sommes en train de construire. Dans l'endroit qui aspire l'âme, c'est plus une question de sélection minutieuse. Vous savez, vous regardez la liste de centaines et de centaines de cas de maintenance. J'ai juste aidé l'un de nos coins d'endroit qui aspire l'âme cette semaine. J'ai automatiquement fermé 3 300 tickets Jira pour eux. Tous des bugs de production, critère unique, ouverts depuis plus de six mois. Donc si pendant six mois cela pouvait être en production, vous savez, ça reviendra. Il reste encore d'autres choses plus récentes et sur lesquelles les gens ont travaillé et ont essayé de faire avancer au cours des six derniers mois. là-bas. Nous avons d'abord aidé les clients à arriver à un point où cela ne leur coûte pas tant de problèmes, donc généralement nous n'avons pas à annuler les choses. Et euh nous livrons ensuite le correctif aussi vite que possible. C'est donc la réputation que nous sommes en train de construire. Dans le lieu qui aspire l'âme, il s'agit davantage d'une sélection minutieuse. Vous savez, quand vous regardez la liste de centaines et de centaines de cas de maintenance. J'ai juste aidé l'un de nos coins qui aspirent l'âme cette semaine, euh, j'ai automatiquement fermé 3 300 tickets zéro pour eux. Tous des bugs de critères de production, ouverts depuis plus de six mois. Donc si pendant six mois cela pouvait être en production, vous savez, ça reviendra. Il reste encore d'autres choses plus récentes et quelque chose sur lequel les gens ont travaillé et essayé de faire avancer au cours des six derniers mois. Donc plutôt que des estimations d'effort, j'ai tendance à croire en cette idée, nous, dans mon équipe, avons tendance à croire généralement en cette idée que euh, avec le temps que vous utilisez pour prioriser, vous pourriez déjà réparer quelque chose. J'ai vérifié ce matin, nous avons actuellement quatre tickets de maintenance ouverts pour 1,5 million d'utilisateurs. Donc c'est le Vous pouvez les lire n'importe quel jour. Vous n'avez pas à prioriser, débarrassez-vous-en aussi vite que possible. Et dans un asile de vente, vous mettez vraiment en place de nouveaux projets parce que cela n'a pas fonctionné quand vous l'avez livré. Et je ne veux vraiment pas penser que ce monde existerait même, mais il existe au sein de la même entreprise. Et il est bon de se rappeler que nous avons ce genre de différences. Euh, en ce qui concerne l'incertitude, nous abordons aussi les choses différemment, donc cela est lié au fait de euh, de vraiment euh, euh, planifier soigneusement et de s'inquiéter et de vérifier deux fois et de vérifier trois fois. Euh, au lieu de faire cela, nous pensons que si nous faisons une erreur, apprenons-en. Euh, donc si c'est une erreur tolérable, c'est un lot, c'est à plus petite échelle quand vous livrez des morceaux plus petits, c'est mieux. Euh, dans l'endroit qui aspire l'âme, ça demande des efforts, en fait pas mal d'efforts. Et dans un asile d'aliénés, je ne peux même pas dire s'ils ont un système autre que voyons voir si ça revient euh, d'une manière ou d'une autre sur notre table euh, étonnamment. Donc je voulais juste montrer ces choses comme des éléments qui créent très clairement une attitude différente même autour des choses, et l'attitude se manifeste dans les pratiques. Cela se voit dans la façon dont les choses sont gérées, cela se voit dans la façon dont le produit est géré, cela se voit dans la façon dont le développement est fait et cela se voit dans la façon dont les tests sont faits. Et ce genre de choses nous amène au deuxième point, qui concerne le sentiment d'appropriation dont nous devrions parler. Donc, en étant dans ce soi-disant bon endroit, nous nous sommes retrouvés avec des règles comme celles-ci. Nous livrons continuellement, une sorte de chose de base. Euh, nous euh, disons pas de Jira, mais cela ne signifie pas absolument pas de Jira. Cela signifie que si vous pouvez éviter d'utiliser Jira, peut-être devriez-vous essayer cela. Peut-être qu'au lieu d'écrire un rapport de bug, vous devriez aller voir, vous savez, votre collègue développeur et parler de ce bug. Peut-être devriez-vous corriger ce bug ensemble ou peut-être devriez-vous corriger ce bug seul en le trouvant si vous avez les compétences pour cela. Trouvez un moyen de plutôt échouer en avançant, de faire réparer cette chose et ensuite de faire documenter cette chose dans l'automatisation des tests, généralement au niveau des tests unitaires si possible. Donc, ce n'est pas que vous n'auriez pas Jira. Chaque autre équipe de mon entreprise aime Jira. C'est ce que j'ai le plus détesté dans mon entreprise, de ne pas utiliser Jira. Euh, mais euh, c'est essayer de trouver des moyens euh qui nous aideraient à ne pas en dépendre. Parce que c'est en quelque sorte devenu le centre de nombreux problèmes. Ensuite, euh, nous ne faisons pas les estimations. Donc, de nos jours, quand quelqu'un demande combien de temps cela va prendre ? genre, eh bien, nous allons commencer à travailler dessus, voyons voir. Et c'est comme, oh, ça nous a pris deux heures. Ça aurait pu nous prendre deux heures de commencer à deviner combien de temps ça nous prend, mais au lieu d'essayer de donner l'estimation, nous essayons de le faire si c'est assez important pour être discuté. Nous n'avons plus de propriétaire de produit, donc pas de propriétaire de produit. Chaque développeur individuel a le droit de faire les choix de ce qui est livré à ces 1,5 million d'utilisateurs. Et bien sûr, ils ne le font pas individuellement. Ils parlent aux autres développeurs, ils parlent aux autres personnes intelligentes, ils recueillent des informations parce que qui voudrait faire des choses stupides à cette échelle.
[00:23:41] Donc ils apprennent très activement. Nous n'avons pas de projets. Donc euh je n'ai pas eu de projet à gérer depuis un certain temps. Et nous ne faisons pas de Scrum parce que Scrum crée cette cadence de deux semaines ou d'une semaine et euh c'est juste beaucoup mieux de, vous savez, prendre un ticket, prendre une chose, prendre une idée et et et la mettre en œuvre. Euh ça n'a même pas besoin d'être physique. Donc la partie intéressante ici dont je voulais parler concernant la propriété est le fait qu'il n'y a pas de propriétaire de produit. Il y a environ deux, deux ans et demi, nous avons lu cet article de euh Joshua Karievsky qui écrit habituellement sur l'Agile moderne, ce qui est un excellent matériel avec lequel je m'identifie beaucoup. Mais euh ce qu'il disait alors, c'est que euh si vous avez des équipes obsédées par le client, elles n'ont souvent pas de propriétaires de produits. Et nous nous sommes dit, hmm, nous avons un propriétaire de produit. Euh nous avons en fait eu quelques problèmes avec notre propriétaire de produit à l'époque.
[00:24:42] Et le problème principal était que euh le propriétaire du produit au début, il était assis dans la salle de l'équipe. Ça sonne comme une bonne pratique, n'est-ce pas ? Très proche, très bien emballé. Mais d'une manière ou d'une autre, quand l'équipe était principalement composée de développeurs russes, je ne sais pas si cela a vraiment un sens, mais j'en suis venue à croire que cela pourrait en avoir un. Euh ce que le fait d'avoir un propriétaire de produit dans la salle signifiait, c'est que chaque développeur avait l'impression que lorsqu'il avait quelque chose dont il voulait se réjouir et se vanter, j'ai fait ça. Maintenant, vous savez, regardez ça. J'ai appris ce petit morceau. Ils allaient voir ce propriétaire de produit et lui racontaient ce qui les excitait. Et c'était un peu horrible d'être un deuxième développeur dans cette équipe parce qu'ils ne disaient rien au deuxième développeur. Et c'était encore pire d'être un testeur dans cette équipe quand on essayait de contribuer d'une manière ou d'une autre et la seule personne qui savait ce qui se passait était les personnes individuelles et ensuite le propriétaire du produit qui était trop occupé à écouter tout le monde pour ne jamais vraiment résumer cela de manière agréable pour nous et ne pensait pas vraiment que c'était leur tâche principale de toute façon. Alors j'ai commencé comme une nouvelle personne rejoignant cette équipe. J'étais à l'époque l'un des testeurs de l'équipe. J'ai commencé à régler ça en allant voir le manager du product owner et en disant, faisons une petite expérience. Au début, je n'avais pas ça en tête, mais c'était un peu en arrière-plan. Ce que j'ai demandé, c'est : pouvez-vous juste éloigner le product owner de la salle d'équipe afin que, si nous faisons ce que nous avons l'habitude de faire, cela nous prenne au moins un étage de plus à parcourir avant que cela n'arrive, peut-être que cela nous aiderait à nous parler les uns aux autres à la place et à régler ça. Donc, vous savez, changer l'environnement, c'est une idée de base. Et, vous savez, beaucoup de choses ont changé, comme tout le monde se disait au début : à qui je raconte ces moments joyeux maintenant ? Et tout d'un coup, ils se les racontaient les uns aux autres. Mais ils se sentaient encore souvent, ils exprimaient d'une manière ou d'une autre ces sentiments d'être piégés ou comme, oh, je dois décider, par exemple, de quelle manière nous allons faire notre pare-feu, de cette façon ou de cette autre ? Devons-nous maintenant demander au propriétaire du produit de venir ici ? Et bien sûr, il venait chaque fois que nous l'appelions. Il venait et avait cette discussion. Mais il disait souvent, hmm, je dois y réfléchir. Hmm, je dois aller me renseigner à ce sujet. Donc nous n'avions pas toutes les réponses tout de suite. Et euh cela signifiait que vous feriez autre chose plutôt que la chose que vous saviez être vraiment importante à ce moment-là.
[00:27:17] Donc, nos développeurs avaient vraiment l'impression que euh euh au lieu d'être un très bon groupe de personnes intelligentes, ils prenaient des ordres d'une seule personne. Et cette seule personne en tant que goulot d'étranglement ne nous rendait pas service à tous. Euh les décisions étaient une fois où l'analyse ne vous donnerait pas toutes les réponses. Il fallait juste faire un acte de foi, voir où vous aboutissiez. Et vous savez, il valait mieux faire cet acte de foi que de se tourner les pouces pendant quelques semaines que l'acte de foi vous mènerait là où vous ne faisiez aucun progrès en attendant quelqu'un d'autre. Donc, euh, nous avons examiné euh ce que fait le propriétaire du produit. Et nous avons eu une petite discussion avec l'équipe sur toutes sortes de choses que nous attendons d'un propriétaire de produit. C'était donc un effort conjoint euh avec le propriétaire du produit. Et et nous avons créé, je pense que c'était au moins comme quelque chose de 200 et quelques euh types de tâches, des perspectives dans lesquelles le propriétaire du produit contribue habituellement. Et et nous réalisions que la plupart de ces choses qu'un propriétaire de produit Nokia, à l'époque, décrivait comme le propriétaire de produit complet, nous ne les reconnaissions même pas comme un travail à faire. Il y avait donc encore plus que ce que nous pouvions faire dans le domaine du propriétaire du produit. C'est donc définitivement beaucoup de travail. Mais ce que nous suggérions, c'est, selon l'article de Joshua Karievsky, que nous n'aurions plus de propriétaire de produit. C'était une idée un peu intimidante pour les développeurs, c'était une idée un peu intimidante pour un propriétaire de produit parce que, eh bien, quand vous avez une coopération un peu plus grande, même si nous sommes de taille moyenne. Il y aura une réorganisation qui arrivera un jour. Et si votre équipe vous a laissé tomber en tant que propriétaire de produit au moment où la réorganisation arrive, cela ne signifie pas que vous êtes en sécurité. Cela signifie généralement que vous devez travailler davantage pour montrer que vous êtes toujours utile. Nous avons donc commencé une expérience. Nous avons d'abord convenu d'une expérience de trois mois. Nous pensions que cela changerait la façon dont les choses fonctionnent pour nous si nous passions trois mois à faire les choses différemment. Donc, euh, nous avons convenu que la personne que nous connaissions comme propriétaire de produit serait maintenant, eh bien, j'ai d'abord suggéré PMS, spécialiste en gestion de produit. Il n'a pas aimé ça. Je je ne peux pas comprendre. Pourquoi PMS serait-il bizarre pour quelqu'un ? Mais nous nous sommes retrouvés avec PME, expert en gestion de produit, vous savez, en trouvant un acronyme avec lequel il était à l'aise. Et nous lui avons laissé une seule tâche sur cette liste de centaines de choses qu'il faisait pour nous. Il était censé assister à toutes ces réunions orientées client qui rempliraient complètement la semaine de travail de quelqu'un. Auxquelles il assistait déjà. Et il était censé aller pêcher. Il allait chercher des choses à rapporter à l'équipe. Pas de décisions, juste si tu entends quelque chose d'intéressant, rentre à la maison avec cette information et nous verrons ce que nous en ferons. S'ils demandent des fonctionnalités, dis-nous. S'ils nous font savoir que quelque chose ne va pas, dis-nous. Et nous prendrons les décisions sur ce genre de choses qui se produiront.
[00:30:38] Donc après trois mois, nous avons fait une petite rétrospective. Euh le premier point des conclusions de la rétrospective était pour l'équipe que rien n'avait changé. Nous avons retiré un propriétaire de produit, rien n'était différent. Ensuite, nous avons parlé un peu plus, euh nous avons comparé euh la période de trois mois aux cinq dernières périodes de trois mois. Et nous avons remarqué que, étonnamment, nous avons livré beaucoup plus de choses. Beaucoup plus de choses que les clients voulaient et valorisaient. De plus, ce que je dis ici, c'est que des choses magiques se sont produites. Nous avons livré des choses parce que les vendeurs les demandaient directement dans les couloirs parce que nous osions. Nous avons résolu les problèmes de manière moins chère parce que nous comprenions les problèmes au lieu des solutions. Et cela ne nous a pas pris d'énergie supplémentaire pour ré-ingénier le problème à partir de la solution, ce qui était un problème majeur que nous avions l'habitude d'avoir.
[00:31:33] Et puis euh le propriétaire du produit, euh leur conclusion était que, oh, ils avaient tellement plus de temps maintenant pour la pensée stratégique. Mais d'un autre côté, nous avons remarqué que pendant trois mois, ils n'ont rien rapporté à l'équipe, que ce soit des choses tactiques, quotidiennes, ou rien de stratégique qui nous ferait penser différemment. Et nous avons passé une demi-heure ensemble à essayer d'identifier sur les choses quotidiennes. S'il y avait un impact sur les choses que nous faisions de la part de cette personne. Donc ça pourrait être comme un vieil impact parce que nous avions travaillé longtemps ensemble, nous savions comment ils penseraient. Mais euh ils ne nous ont vraiment rien rapporté. Et maintenant nous faisons ça depuis deux ans. Ils ont rapporté une chose en deux ans. Une.
[00:32:25] Il semble donc que nous n'ayons peut-être pas autant besoin de cet expert en gestion de produit. Ce que nous avons appris en deux ans, c'est que les développeurs aiment vraiment résoudre les problèmes. C'est de là que vient la joie. Quand vous vous sentez habilité à faire quelque chose à propos de ce que vous venez d'apprendre et à ne pas attendre que quelqu'un d'autre prenne une décision pour vous. Il n'y a rien qui rende un développeur plus heureux. Mais cela aussi, lorsque le développeur est content de cela, les utilisateurs finaux sont contents de cela. Nous avons donc remarqué que euh nous avions l'habitude d'avoir des centaines de bugs. Ils ont disparu. Ils ont été corrigés. Donc comme je l'ai dit, nous en avions quatre hier. C'est une chose normale euh pour chaque période de deux semaines euh ou chaque euh période que je regarde. Nous avons une règle selon laquelle si cela atteint 20, nous arrêtons de faire autre chose et nous le ramenons à moins de 10.
[00:33:17] C'est ainsi que nous gérons ça pour nous-mêmes. Euh, nous avons commencé à nous parler beaucoup plus parce que les gens que vous avez le plus proches de vous sont euh euh de belles choses à faire. Donc nous avons partagé la propriété beaucoup plus au sein de l'équipe, mais nous avons aussi commencé à faire des fonctionnalités vraiment de bout en bout. Donc pour nous, de bout en bout signifie trois piles complètes. Il y a un système backend avec Java et JavaScript. Il y a les choses que nous faisons avec C#, C++ et Python. Et puis il y a une toute autre pile avec C++ et Python aussi. Donc tout ce que les clients comprennent, pas seulement les choses qui étaient habituellement dans notre équipe, mais dans les autres équipes. Nous avons donc commencé à parler aux autres équipes et à faire les choses au niveau du développeur à développeur. Nous avons commencé à rédiger de la documentation destinée aux clients. Avant, nous pensions que, vous savez, quelqu'un d'autre devait le faire, nous sommes des gens tellement occupés. Maintenant, tout d'un coup, nous ne sommes pas trop occupés pour penser au client et nous assurer qu'ils savent comment profiter de tout ce que nous faisons. Toutes les solutions que nous devions livrer ont commencé à se produire plus rapidement. Et au lieu de parler de cette livraison incrémentale que nous aimions beaucoup, nous avons commencé à parler de flux. Nous avons donc commencé à parler de l'obtention continue d'un petit quelque chose, en faisant toujours des pas dans la bonne direction pour le mieux et nous avons commencé à apprécier le fait que nous avions quelque chose qui fonctionnait pour des millions d'utilisateurs, et que c'était déjà quelque chose qui était une belle réalisation à maintenir et tout ce que nous pouvions ajouter par-dessus serait formidable.
[00:34:59] Euh, nous avons parlé à tous ceux que nous sentions devoir, ce qui signifiait aussi de vrais clients finaux. Je suis allé aux ventes et j'ai dit : je veux rencontrer un vrai client, je veux présenter quelqu'un à notre équipe. Je veux présenter quelqu'un à notre équipe chaque mois. Nous avons donc commencé à avoir euh de petites réunions conçues par l'équipe avec le client pour parler avec le client du genre de choses qu'ils avaient vraiment. Et cela a également amélioré les relations clients en général. C'est plutôt cool pour les clients apparemment de rencontrer les développeurs au lieu de simplement les les les euh les gens du support entre-temps. Et la toute première chose que les gens ont introduite, c'est que les propriétaires de produits avaient l'habitude d'être heureux de faire euh, eh bien, ils étaient forcés de faire des choses euh à l'aveuglette. Mais nous, non. Nous avions le pouvoir sur le produit. Donc, la première semaine de cette expérience, euh nous avons commencé la télémétrie produit et il y a une semaine, nous avons ajouté la télémétrie d'automatisation des tests. Nous voyons ce qui se passe. Nous connaissons euh le vrai euh euh statut de production plutôt que de deviner ce que les utilisateurs à grande échelle pourraient vouloir.
[00:36:10] Donc, après deux ans sans propriétaire de produit, euh c'est plutôt drôle. Euh mon équipe, d'ailleurs, a envoyé ses salutations en disant qu'ils ont honte que je fasse cela, mais je le ferai quand même. Je cite le genre de mails que nous recevons. Vous êtes la meilleure équipe de R&D. Ne vous touchons pas. Ce qui fonctionne, nous ne devrions pas le casser. Nous ne comprenons pas ce que vous faites. Nous passons une semaine à parler de vous donner un propriétaire de produit, mais il semble que ce soit trop risqué.
[00:36:39] Recevoir plusieurs e-mails comme celui-ci au fil du temps, ça ne prouve peut-être rien, mais c'est au moins agréable et motivant. Euh d'autres équipes ont examiné et ont fait les choses de la même manière. Et l'équipe qui s'est le plus rapprochée est arrivée à cette conclusion. Eh bien, vous n'êtes qu'une seule équipe. Vous n'êtes pas une preuve suffisante que cette approche est meilleure. Et aussi, euh notre équipe euh manque vraiment d'ancienneté et de compétences en communication pour tenter le coup. Sans remarquer que la personne la plus jeune de mon équipe était un junior de 16 ans qui faisait également cela et qui faisait également ses propres choix sur la façon dont ils changeraient euh les statuts pour la production. Mais vous savez, peut-être que les plus de 30 ans euh et les plus de 50 ans sont plus jeunes que nous avec le jeune de 17 ou 16 ans, il vient d'avoir 17 ans il y a quelque temps, donc il vieillit aussi. Il avait 16 ans quand nous avons commencé. Je pense en fait qu'il aura bientôt 18 ans.
[00:37:45] Euh, la façon dont nous travaillions a vraiment survécu à la réorganisation. C'était il y a un mois et demi. Euh, des moments excitants. Mais nous sommes toujours sans propriétaire de produit. Et c'était un grand sujet de discussion. Mais apparemment, euh, casser quelque chose qui fonctionne euh, n'a pas de sens.
[00:38:08] Et dans tout cela, nous sommes toujours arrivés à la conclusion que si vous ne changez rien, même si vous êtes déjà agile, rien ne s'améliorera.
[00:38:19] Donc ce sont un peu les choses autour de l'absence de propriétaire de produit. Donc nous n'avons toujours pas de propriétaire de produit. Nous avons des développeurs qui font des erreurs liées au produit, mais aussi les très bonnes choses. Il y a plusieurs fonctionnalités en ce moment dans ce produit créées de bout en bout dans cette période de deux ans. Et même si je ne peux pas prédire l'avenir, je suis très convaincue qu'avec le recul, ces fonctionnalités seraient un point de discussion où nous les comprendrions très bien, si nous ne nous étions pas éloignés du modèle très centré. Et ce n'était pas, cela je dois toujours le dire, ce n'était pas le propriétaire du produit qui était le problème. C'était les développeurs qui étaient le problème. Ils ont en quelque sorte imaginé qu'il y avait une hiérarchie. Et la seule façon pour eux de se défaire de cette hiérarchie est de jouer à ce jeu de faire semblant d'avoir le pouvoir qu'ils ont toujours eu, mais ils avaient besoin de quelque chose pour que cette réalité devienne réelle pour eux. Et peut-être que c'était lié au fait d'avoir beaucoup de développeurs russes dans l'équipe.
[00:39:41] Alors nous allons passer au troisième point, qui concerne l'apprentissage.
[00:39:46] Et toutes ces choses quand j'essaie de décrire la façon dont nous travaillons. Elles sont le résultat de plusieurs jours passés au bureau, à faire les choses un peu différemment et à toujours dire que nous ne sommes pas satisfaits de ce que nous avons aujourd'hui. Nous sommes satisfaits de ce que nous avons aujourd'hui, mais cela pourrait encore être mieux. propriétaire. C'était ça le problème. Ce sont les développeurs qui étaient le problème.
[00:39:11] Ils ont en quelque sorte imaginé qu'il y avait une hiérarchie. Et la seule façon pour eux de lâcher prise sur cette hiérarchie est de jouer à ce jeu de faire semblant qu'ils avaient le pouvoir qu'ils avaient toujours eu, mais qu'ils avaient besoin de quelque chose pour que cette réalité devienne réelle pour eux. Et peut-être que c'était lié au fait d'avoir beaucoup de développeurs russes dans l'équipe.
[00:39:40] Ensuite, nous passerons au troisième point, qui concerne l'apprentissage. Et toutes ces choses, quand j'essaie de décrire la façon dont nous travaillons, elles sont le résultat de plusieurs jours passés au bureau, à faire les choses un peu différemment, et à toujours dire que nous ne sommes pas satisfaits de ce que nous avons aujourd'hui, enfin, nous sommes satisfaits de ce que nous avons aujourd'hui, mais cela pourrait encore être mieux. Et nous voulons vraiment apprendre. Et l'apprentissage fonctionne de cette façon, si vous pensez à un individu qui est à 1.00, vous savez, c'est la valeur que vous pouvez donner. 1.00 et vous n'apprenez pas et vous n'ajoutez pas à cette capacité que vous avez.
[00:40:29] À la fin d'une année, chaque jour si vous n'apprenez pas, vous seriez toujours la même personne excellente, absolument merveilleuse, charmante, offrant 1,00. Mais si votre attitude sur un plan personnel était qu'aujourd'hui je suis un 1,00, mais demain je serai 1% meilleur.
[00:40:54] Et chaque jour de l'année, vous allez être 1% meilleur. Cela se multiplie au fil de l'année de sorte que chacun d'entre nous puisse faire les choses plus intelligemment, comme si nous les faisions plus vite, nous les faisions plus correctement, et nous les faisions mieux avec les autres. Et c'est ce que nous devons faire. Nous devons continuer à apprendre, à comprendre comment emballer les choses dans nos méthodes de développement de produits. Nous devons trouver comment ne pas avoir à utiliser notre charge cognitive sur des choses où nous ne voulons pas qu'elle aille. J'écoutais justement une présentation qui parlait de trois types de charge cognitive. Il y a le genre intrinsèque ou euh euh le genre interne, le genre de compétences, puis il y a le genre externe, qui est le package dans les méthodologies et les processus que nous utilisons. Et puis il y a le genre pertinent, qui est la connaissance du domaine se concentrant sur de nouveaux problèmes uniques. Et lorsque notre capacité pour ces trois choses est limitée, nous devons continuer à apprendre les bases de nos compétences afin de pouvoir libérer notre concentration sur les connaissances pertinentes, du domaine.
[00:42:11] Donc nous avons fini comme nous avons commencé cette discussion avec. Nous avons fini avec cette façon de travailler centrée sur le développeur.
[00:42:23] Pour une raison quelconque, ça ne bouge pas correctement. une façon de travailler centrée sur le développeur. Donc, en allant vraiment dans l'idée, tout cela menait à l'idée que si vous faites confiance à votre développeur pour être intelligent et si vous faites confiance à vos développeurs pour apprendre continuellement, vous ne les surveillez pas sur leurs erreurs. Vous les laissez faire des erreurs, vous vous assurez qu'ils reçoivent des retours sur ces erreurs. Et parfois, le coût de s'assurer qu'il n'y a absolument aucune erreur est ce qui nous empêche d'arriver jusqu'à la production et d'apprendre quelque chose de vraiment très important. Ce qui est : comment faisons-nous réellement plus d'argent avec ce système que nous sommes en train de créer ? Comment rendons-nous ce client suffisamment heureux pour qu'il ne nous lâche pas, mais qu'il développe plutôt l'utilisation de notre produit ?
[00:43:28] Cela a abouti pour nous à la compréhension des pratiques fondamentales.
[00:43:34] L'une des pratiques fondamentales est l'utilisation de l'open source interne. Chaque composant que nous avons est disponible non seulement pour les développeurs de mon équipe, mais aussi pour les développeurs de toutes les autres équipes. Et il en va de même pour les autres équipes. Cela a également permis à mon équipe d'aller effectuer des changements de bout en bout. Et l'open source interne signifie, en gros, que vous faites une demande de tirage là où elle doit être, afin qu'elle finisse par être livrée aux clients. Et cela aide dans l'écosystème global que nous créons autour de notre produit.
[00:44:17] Les requêtes de tirage sont une pratique courante ici, euh parler euh avant de faire des choses est une pratique courante ici. Et il semble que résoudre les conflits est aussi parfois une pratique courante ici. surtout quand votre requête de tirage est refusée, vous vous retrouverez avec des discussions sur ce que nous avons appris ici et si ces leçons nous font réellement avancer ou reculer dans ce que nous avons dans notre organisation.
[00:44:49] Ensuite, une autre pratique que nous ne semblons pas toujours pouvoir suffisamment souligner est que nous utilisons très fortement une poule comme idée. Donc au lieu que quelqu'un nous demande ou nous pousse quelque chose, ils nous fournissent des informations et quand une partie de ces informations nous intrigue, nous les tirons à nous. Nous commençons à y travailler, la décision appartient à celui qui effectue le travail, donc la planification, et toutes les informations fonctionnent de cette manière. Et c'est la chose principale que nous devons toujours enseigner aux nouvelles personnes rejoignant notre équipe : que lorsque les gens ne vous parlent pas et ne vous poussent pas d'informations, ils ne vous racontent pas toutes les choses qu'ils ont apprises au cours des 25 dernières années. C'est par respect, pas parce qu'ils ne vous aiment pas. Ils sont heureux de partager chaque fois que vous le demandez. Mais ils cherchent le moment où vous avez besoin de cette information afin de ne pas faire en sorte que vous ne puissiez pas réellement commencer à fournir de la valeur dès le premier jour avec les informations que vous avez déjà. Donc nous faisons généralement grandir les nouvelles personnes dans l'équipe en leur donnant du travail, et cela permet ce genre de chose. Le double suivi de la découverte et de la livraison est également assez important. Ainsi, le travail que nous tirons pourrait consister à comprendre ce problème si nous nous en soucions. Ou il pourrait s'agir de livrer ceci. S'il s'agit de découverte, nous le limitons généralement très, très fortement dans le temps.
[00:46:25] Pour que nous ne nous retrouvions pas dans ces discussions sans fin sur : osons-nous. Si nous commençons à nous demander si nous osons, il vaut mieux oser et en parler plus tard.
[00:46:39] L'ensemble du processus est centré sur la transformation des idées en code, ce qui signifie ensuite obtenir les bonnes idées auprès de chaque développeur. Cela a été un énorme changement pour les personnes de l'équipe d'expérience utilisateur, pensant qu'elles avaient ces idées et qu'elles ne pouvaient pas trouver un backlog de produit à travers lequel elles pourraient pousser les choses. Donc, essayer de les impliquer dans le travail, d'avoir ces discussions avec eux, de trouver nos nouvelles façons de travailler avec eux a également été nécessaire. Et j'ai en quelque sorte abordé tout cela avec l'idée que j'ai été moi-même, j'ai été testeur pendant 23 ans maintenant. C'est mon truc, c'est ce dont je parle le plus souvent, c'est ce que j'apprécie le plus souvent. Je suis aussi programmeur, je fais aussi des changements, des corrections dans le produit. Mais en tant que testeur, j'en suis venu à apprécier ce que je fais, c'est-à-dire briser les illusions. Que ce soit à propos des bugs, ou à propos des processus et des choses que nous pensons être la façon dont nous sommes censés travailler. Nous pensions avoir besoin d'un chef de produit. Eh bien, non, il s'avère que non. Nous pensions devoir avoir une configuration particulière parce que tout le monde l'a. Eh bien, il s'avère que nous ne l'avons pas fait. Donc je suis arrivée à la conclusion qu'en tant que testeuse, je ne brise pas seulement les illusions concernant le code, mais je brise les illusions concernant tout ce qui est nécessaire. Et pour nous, en revenant au thème de la conférence, l'agilité comme si vous le pensiez vraiment, Je ne me soucie plus de savoir si c'est agile. C'est probablement le cas. Mais c'est plus amusant que je n'ai jamais eu au travail de ma vie. C'est plus productif et apprécié que je n'ai jamais été capable d'aller et de livrer dans toute ma carrière. 23 ans dans toute cette affaire.
[00:48:48] Et j'espère que ma contribution dans le monde pourrait être d'aider d'autres personnes dans mon entreprise et peut-être même dans d'autres entreprises à intégrer ce genre d'idées et d'expériences dans leur quotidien, afin que ce soit une expérience joyeuse de construire des logiciels à nouveau pour nous tous, c'est en quelque sorte ce que j'avais en tête. Donc ma règle pour savoir si ma conférence est un succès est triple. La première est que je continue à vous regarder et je vois certains d'entre vous hocher la tête, donc je suis assez contente de cela. Ma deuxième règle est que j'ai l'impression d'avoir gaspillé mes heures de voyage si vous ne me parlez pas après cela, car nous ne pouvons pas trop parler pendant cette session. Alors s'il vous plaît, je suis là toute la journée, parlez-moi.
[00:49:33] Je veux aider à résoudre vos problèmes, pas seulement parler de mes affaires. Mais je ne peux pas imaginer ce qu'ils sont sans que vous parliez. Et la troisième chose que je peux vous demander maintenant, c'est que j'ai toujours rêvé qu'un jour je donnerais une conférence qui se terminerait par une standing ovation. Alors s'il vous plaît, merci.
[00:50:03] D'accord, merci.
[00:50:08] Ouais. C'était un peu embarrassant pour moi, d'ailleurs, parce que je n'avais jamais fait ça avant. C'était mon numéro 400. Oui, nous avons une période de questions.
[00:50:28] Salut, euh merci beaucoup. Félicitations pour votre 400ème conférence également. Euh je voulais juste savoir ce qui est arrivé à votre chef de produit.
[00:50:37] Oh, oui, j'ai oublié de mentionner. Donc, dans la réorganisation, il est toujours en sécurité. Il a changé d'équipe, passant de l'équipe de propriétaire de produit à une équipe axée sur le commerce, et il est maintenant responsable de pratiquement toutes les réunions avec les clients, plusieurs jours par semaine. Donc c'est maintenant son travail. Donc il est toujours là et il sera toujours en sécurité.
[00:51:05] Donc nous en avons un ici. Il y a une sorte d'excuse courante.
[00:51:14] Bonjour et merci. Comment gérez-vous les priorités si chaque développeur peut revenir avec n'importe quelle fonctionnalité à développer sans priorités de backlog par appel ?
[00:51:27] Donc les développeurs se soucient, étonnamment, de faire des choses qui ont réellement de la valeur. Donc ils discutent de ce qu'ils considéreraient comme important et ils font assez naturellement des choses qui sont prioritaires. Il se peut que certains développeurs soient dans le domaine depuis assez longtemps pour ne plus être très enthousiastes à l'idée d'écrire tout le code possible, mais qu'ils veuillent réellement faire quelque chose d'utile. Donc, il arrive très naturellement que, tant que nous avons, eh bien, toutes les deux semaines, nous avons un espace où nous nous réunissons pour discuter de, en gros, visualiser nos priorités actuelles. Nous ne faisons pas de plan en tant que tel, nous visualisons juste nos priorités actuelles, ce que chacun apporte à la table des priorités. Et c'est notre chance d'en discuter ensemble et de lui donner une structure. Mais nous n'avons pas eu besoin d'un mécanisme au-delà de cela.
[00:52:27] Il y en a un de plus là, là.
[00:52:41] Salut, et merci encore pour la discussion. J'ai une question concernant le fait de savoir si vous devez synchroniser votre équipe avec d'autres équipes et si oui, comment le faites-vous ?
[00:52:52] Alors oui, j'ai compté le nombre d'équipes avec lesquelles nous interagissons, mais j'ai oublié de le mentionner. 36 équipes. C'est donc le nombre d'équipes avec lesquelles nous travaillons. Nous avons une méthode de travail en réseau avec eux. En gros, ce que nous avons fait au sein de l'équipe de 11 personnes, c'est que différentes personnes parlent à des représentants d'autres équipes. Et cela signifie généralement pour nous de ne pas avoir de réunion mais d'aller prendre un café. Et cela nous aide à nous synchroniser. Ainsi, nous avons conscience de qui nous dépendons et nous assurons une communication de développeur à développeur sur les choses qui se passent à ce moment-là ou qui nous préoccupent afin que d'autres personnes en soient conscientes. Donc, cela vient de nous, cela vient d'un lieu d'empathie, nous ne voulons pas rendre la vie des autres plus misérable, ils vivent déjà soit dans un asile, soit dans un endroit par ailleurs vraiment mauvais. Donc ou un endroit qui aspire l'âme. Donc, prendre soin pour que les autres développeurs ne souffrent pas est la façon dont nous faisons la majeure partie de ce travail.
[00:54:03] Donc encore une fois, je pense que même si je ne
[00:54:06] Oui, il y a une question.
[00:54:06] il y en avait encore, je ne l'ai pas vue celle-là.
[00:54:08] Désolé. Alors, j'ai une question parce que vous avez dit que vous parliez d'open source interne. Faites-vous aussi le vrai, l'open source externe ? Je pense que c'est assez intéressant de montrer votre code au monde parce que ça vous force vraiment, n'est-ce pas, à faire un meilleur code et produit.
[00:54:23] Oui, donc le véritable open source externe est très fascinant, mais euh quand vous euh créez des mécanismes, essayant de euh travailler contre les soi-disant "méchants" en sécurité, euh ouvrir votre base de code n'a pas été la chose principale que nous voulions ou pouvions faire. Nous avons beaucoup partagé des outils pour apprendre de ce côté-là. Mais nous avons appris que partager ouvertement nos outils aboutit à très peu de personnes intéressées, à moins que quelqu'un ne le promeuve. Donc l'open source, l'open source externe fonctionne de telle sorte que votre matériel est généralement très sûr en ligne à moins que quelqu'un ne travaille très, très dur pour le commercialiser.
[00:55:15] C'est donc une conclusion à laquelle nous sommes parvenus. Donc avoir plutôt le sien. Je sais. Certaines personnes sont très douées pour promouvoir cela, d'autres sont très douées pour le faire et nous avons vu que le côté outil est plus susceptible de susciter l'intérêt des autres pour nous. Donc il y a un outil appelé Mitins qui concerne la sécurité que nous avons mis en open source, l'environnement de virtualisation que nous utilisons pour faire fonctionner 14 000 machines virtuelles par jour, appelé DVMPS, il est en open source. Mais euh le

Transcription (Traduit)