Sander Hoogendoorn
Durée :
Vues : 488
7 likes
Publié : décembre 3, 2020

Transcription (Traduit)

[00:00:14] Alors, euh, bienvenue à tous. Et, euh, j'espère que vous m'entendez tous. J'ai mis mes écouteurs, surtout parce que le micro est bien meilleur que celui de mon ordinateur portable. Euh, donc, l'histoire que j'ai avec moi aujourd'hui est une histoire qui a évolué au cours, disons, des sept, huit dernières années, voire même neuf ans déjà. Euh, et ça a commencé avec moi, euh, euh, ou plutôt j'ai commencé à faire de l'Agile, euh, au milieu et à la fin des années 90, et ça ne s'appelait pas Agile à l'époque, euh, et ça ne s'est appelé Agile qu'en 2001. Mais, euh, ces approches itératives étaient déjà là, et, euh, nous avons continué à évoluer à partir de là, euh, depuis. Cela signifie que nous avons en quelque sorte dépassé le point où les approches Scrum traditionnelles ou les approches de type Scrum fonctionnent, mais, euh, nous sommes passés à une approche beaucoup plus continue. Et, euh, je vais vous montrer où nous en sommes arrivés avec les entreprises pour lesquelles j'ai travaillé, euh, et, euh, ce que nous faisons actuellement. Donc, tout cela vient, euh, de la pratique réelle, de ma propre pratique quotidienne de, euh, travailler avec, euh, euh, des startups et des scale-ups ces jours-ci. J'ai travaillé pour de grandes entreprises, mais je vous raconterai tout cela plus tard. C'est une histoire dense, elle contient beaucoup d'informations, euh, elle a aussi beaucoup de diapositives. Euh, je ne vais pas raconter toute l'histoire parce que ça me prendrait toute la journée, je suppose. Euh, et nous avons environ une heure. Alors, euh, commençons. Alors, euh, de retour dans, oh attendez, je dois d'abord réparer ici. De retour dans, euh, les années 60, euh, il y avait ce, euh, un magnifique type appelé Bob Dylan qui a écrit une chanson intitulée "The Times They Are a-Changin'". Eh bien, il ne savait pas que les temps changeaient très vite et, et continuaient, euh, euh, euh, d'évoluer de plus en plus vite, euh, euh, ces derniers temps. Donc, il prédisait en fait l'avenir assez bien, mais la vitesse à laquelle nous voyageons et la vitesse à laquelle nous, euh, euh, allons de plus en plus vite augmente également. Euh, et probablement la façon la plus simple d'illustrer cela est une petite, une petite histoire d'où nous venons et où nous allons. Donc, voici une diapositive que vous avez probablement tous vue auparavant, c'est ce qu'on appelle la loi de Moore. Maintenant, la loi de Moore dit que le nombre de transistors dans un circuit intégré dense double approximativement tous les deux ans. Et vous pouvez le voir sur la ligne et le graphique sur le côté droit de ma diapositive. Mais le fait est que ce n'est pas une ligne linéaire, ça ressemble à une ligne linéaire. Mais c'est en fait une ligne exponentielle, si vous regardez l'échelle sur l'échelle verticale, vous pouvez en fait voir que c'est une, euh, euh, une ligne exponentielle. Et, et depuis Corona, nous sommes tous très habitués aux lignes exponentielles, donc je n'ai pas besoin d'expliquer cela. Mais cela signifie que les possibilités que nous avons avec notre puissance de calcul doublent en fait tous les deux ans. Maintenant, c'est une, euh, euh, une augmentation considérable de ce que nous pouvons faire dans cette industrie. Et pour vous donner un peu d'histoire, un peu de perspective, si vous aviez commandé un ordinateur en 1954, euh, euh, probablement en ligne, non, pas encore parce qu'Internet n'existait pas à l'époque, n'est-ce pas ? Euh, euh, il est arrivé à votre porte comme ça, n'est-ce pas ? Maintenant, ce très grand ordinateur, il a moins de puissance de calcul que le téléphone que j'ai en main. En fait, le téléphone dans ma main a beaucoup plus de puissance de calcul que ce gros ordinateur de 1954. Quand je suis entré, en quelque sorte, dans le domaine du développement logiciel, j'ai eu un ordinateur comme celui-ci. C'est l'IBM 5150, c'est un ordinateur personnel. Maintenant, cela a en quelque sorte beaucoup changé la façon dont nous voyons notre industrie, car cela nous a permis de ne pas apporter le code à un ordinateur qui se trouve dans un, euh, dans un centre de données quelque part, mais cela nous a permis de faire du calcul et de construire des logiciels, euh, sur notre lieu de travail ou même à la maison. Euh, et en fait, si j'explique cette image à des personnes plus jeunes, euh, euh, ils demandent toujours, à quoi sert la lumière rouge ? Et là je dis, eh bien, c'est là que tu mettais la disquette. Et là les gens me demandent, qu'est-ce qu'une disquette ? N'est-ce pas ? Les gens n'ont aucune idée de ce qu'est une disquette de nos jours. C'est à quelle vitesse nous avons évolué.
[00:04:24] Maintenant, une prochaine étape vraiment importante est, euh, quand en 2006, Amazon, euh, alors encore une librairie, a décidé de rendre sa puissance de calcul disponible à d'autres personnes. Ils ouvraient en fait leurs ordinateurs et leurs centres de données à d'autres personnes pour qu'elles puissent faire leurs calculs. Cela signifiait que nous n'avions plus besoin d'avoir de gros ordinateurs dans les sous-sols des entreprises pour lesquelles nous travaillions pour faire tous les calculs, mais nous pouvions en quelque sorte les envoyer à Amazon, puis à, euh, Microsoft et Google et Oracle et IBM et tous les autres qui ont suivi. Mais Amazon a été le premier à avoir cette idée. Maintenant, cela a beaucoup changé tout le domaine du développement logiciel parce que cela a permis, euh, aux entreprises qui n'ont pas le matériel dans le sous-sol de commencer à concurrencer les entreprises qui ont de grands ordinateurs et de grands mainframes dans leurs sous-sols. Et je vous montrerai quelques exemples plus tard. Euh, donc, en gros, parce que les choses évoluent si vite, cela signifie que beaucoup de choses que nous avions l'habitude de faire ont en fait beaucoup changé. Cela signifie donc, le modèle en cascade, tel qu'il est apparu pour la première fois, disons, en 1970, n'était plus vraiment applicable parce qu'il, euh, il a pour hypothèse d'être un processus prévisible. Et si tout change très, très vite, ce n'est plus prévisible, n'est-ce pas ? Donc, cela signifie, c'est une, euh, euh, une page du livre blanc "Managing the Development of Large Software Systems" par un homme appelé Winston Royce, qui était, euh, un technologue chez Lockheed, euh, le constructeur d'avions, et il a essentiellement écrit un livre blanc en 1970 qui essayait déjà d'expliquer, euh, le fonctionnement de, euh, la méthode en cascade. Ceci est une image du livre blanc. Et ce qu'il a fait, déjà en 1970, parce que même à cette époque les temps changeaient déjà, euh, euh, il a en fait écrit dans son article que ce n'était pas la bonne voie à suivre car il n'y avait pas de boucles de rétroaction. Et, euh, en fait, ceci est la figure deux de son livre blanc. La figure trois du même livre blanc a l'air vraiment, vraiment différente. Il dit en fait, eh bien, ce processus unidirectionnel de cascade ne fonctionne pas vraiment si vous avez besoin de boucles de rétroaction, et vous avez bien besoin de boucles de rétroaction si vous faites du développement logiciel, parce que tout change si vite. Donc, en gros, il dit, euh, euh, il dit en fait que notez que c'est simplement le processus entier fait en miniature, en fait les boucles de rétroaction qu'il mentionne, à une échelle de temps relativement petite par rapport à l'effort global. Il décrit déjà ce que nous appelons aujourd'hui l'Agile. Mais il l'a décrit en 1970, n'est-ce pas ? Et c'est, euh, euh, il était en avance sur son temps, en gros. Mais revenons aux temps qui changeaient. Cela signifiait en fait que si nous sommes capables de doubler la puissance de calcul tous les deux ans, et que nous pouvons le faire sur l'ordinateur de quelqu'un d'autre, beaucoup de choses seront en fait perturbées. Pour vous donner une idée de cela, euh, nous pourrions examiner le temps qu'il a fallu avant que la technologie n'atteigne 50 millions d'utilisateurs. Par exemple, avant que 50 millions de personnes ne prennent l'avion, cela a pris 68 ans, n'est-ce pas ? Avant que 8, 50 millions de personnes n'utilisent un distributeur automatique, cela a pris 18 ans. Et cette période de temps, en raison de ce que nous sommes capables de faire en technologie, change et devient plus rapide à chaque fois. Donc, Twitter a mis deux ans pour atteindre 50 millions d'utilisateurs, n'est-ce pas ? Même Donald Trump a déjà 19 millions d'abonnés sur Twitter. Et c'est l'ampleur des choses que nous faisons. Et ça s'améliore encore, n'est-ce pas ? Si vous regardez Pokémon Go, il a fallu 19 jours pour atteindre 50 millions d'utilisateurs, n'est-ce pas ? Et ces utilisateurs étaient tous, enfin, la plupart des enfants sur leur téléphone. Or, cela signifiait que nous devions avoir une ligne d'infrastructure qui n'existait pas auparavant. Donc, les possibilités grandissent, grandissent et grandissent. En conséquence, si vous regardez ce graphique par exemple, c'est, euh, un graphique de toutes les startups FinTech aux Pays-Bas, et c'est cette diapositive de 2018 déjà. Et le nombre a augmenté énormément. Et si, et si vous disiez que l'une de ces startups FinTech était en fait capable de créer une banque en ligne ? Et la question est, pourraient-ils le faire ? Pourraient-ils réussir avec, disons, 10 développeurs et deux personnes de QA et un product owner et quelques designers pour construire une banque et la faire fonctionner sur l'ordinateur de quelqu'un d'autre, le cloud, et concurrencer de grands acteurs comme, euh, euh, toutes les banques internationales que nous avons. Eh bien, oui, on peut, n'est-ce pas ? Et des entreprises l'ont fait, comme Monzo au Royaume-Uni, ou N26 en Allemagne l'a fait aussi. Et ils ont fait un travail vraiment cool parce qu'ils ont des cartes de crédit transparentes, n'est-ce pas ? Comme exemple. Ou, euh, et puis si vous regardez comment les grandes banques actuelles, euh, réagissent à cela, malheureusement c'est en néerlandais, mais je vais vous le traduire. C'est que c'est le PDG de la banque ING, qui est une grande banque internationale, et il dit, eh bien, en gros, nous ne sommes pas vraiment effrayés par toutes ces startups. Nous avons peur d'entreprises comme Apple et Amazon, qui pourraient effectuer des paiements tout aussi bien que nous, n'est-ce pas ? C'est là qu'un autre angle entre en jeu, n'est-ce pas ? Comme, Apple présente son Apple Card, et c'est encore plus cool parce qu'elle n'a pas, eh bien, juste votre nom dessus, elle n'a même pas de numéro dessus, n'est-ce pas ? C'est plutôt cool. Ou, euh, eh bien, on pourrait dire que les entreprises qui font aussi beaucoup de paiements, comme les compagnies aériennes, enfin, pas pendant la période Corona, bien sûr, mais les compagnies aériennes avaient l'habitude de faire beaucoup de paiements. Vous achetez des billets, vous achetez des choses à bord. Donc, elles font beaucoup de paiements. Et voici AirAsia qui dit, vous savez quoi ? Nous allons devenir, euh, nous allons entrer dans le monde de la banque internationale aussi parce que, eh bien, nous le pouvons, n'est-ce pas ? La technologie est là. Ou Facebook qui tente d'introduire sa nouvelle monnaie. Ils ont leur propre monnaie, ce qui est fondamentalement, euh, traditionnellement le domaine des nations d'avoir leurs propres monnaies, ou même l'Euro par exemple, mais une entreprise qui a sa propre, euh, euh, monnaie, c'est un peu spécial, n'est-ce pas ? Bien sûr, Facebook a maintenant d'autres problèmes, mais, euh, donc nous allons un peu passer Facebook. Et je vais vous montrer, euh, l'une des entreprises pour lesquelles je travaille est une entreprise, euh, qui opère dans l'énergie intelligente. Ils ont construit un thermostat intelligent, euh, et ils l'ont introduit sur le marché. C'est celui de droite ici, le Tone. Il est bien connu aux Pays-Bas. Euh, et, euh, ils l'ont introduit il y a environ 10 ans. Ils y ont travaillé très longtemps, et ils l'ont introduit sur le marché, et il a eu beaucoup de succès. Mais, si vous regardez 10 ans plus tard ce qu'ils font, ils sont toujours une scale-up, et, euh, sur ce marché, ils ont beaucoup de défis. Parce que le marché de l'énergie intelligente est quelque chose qui est vraiment, vraiment en plein essor, et cela signifie que tout le monde entre sur ce marché. Et c'est un gros problème si vous êtes une petite entreprise. Donc, la perturbation est un gros problème. C'est le Tone, c'est l'appareil qu'ils ont mis sur le marché il y a environ 10 ans. Mais de nos jours, euh, vous pouvez trouver un Google Home au supermarché, et un thermostat Google, le thermostat Nest, est un magnifique petit appareil que vous pouvez acheter partout. Ou IKEA fait toutes sortes de choses avec les, euh, les appareils ménagers intelligents, et ils, ils auront probablement aussi un thermostat. Ou même des supermarchés comme Action, qui est un supermarché à bas prix, a son propre thermostat intelligent de nos jours. Donc, et, et, et puis toutes les grandes entreprises entrent en jeu parce que les compagnies pétrolières doivent aussi changer leur perspective, donc elles se lancent aussi sur le marché de l'énergie. Les constructeurs automobiles s'y mettent aussi. Euh, l'automobile et, euh, les grands géants de la technologie comme Amazon et Apple et, euh, et Google se lancent tous sur ce marché. Alors, où allez-vous en tant que petite entreprise, n'est-ce pas ? Vous devez vous réinventer. Car nous vivons dans un monde où n'importe qui peut entrer sur n'importe quel marché, de n'importe où, à n'importe quel moment. Et c'est un marché très, très difficile, n'est-ce pas ? Le second problème que beaucoup d'entreprises ont, et que mon client actuel a également, est appelé l'héritage. C'est un de mes, euh, bâtiments préférés au monde. C'est le Panthéon à Rome, qui a presque 2 000 ans. Eh bien, ce, je pense qu'il est construit, oui, littéralement vieux de 2 000 ans l'année prochaine, je pense. Et, euh, euh, il tient toujours. Il a des murs de six mètres, et il a le plus grand dôme en béton non supporté du monde, encore. Euh, mais tout ce que nous construisons de nos jours n'a pas la même longévité que le Panthéon, n'est-ce pas ? La plupart des choses que nous faisons disparaîtront en fait d'ici 15 à 20 ans. Elles deviendront des héritages, n'est-ce pas ? Maintenant, l'héritage est un problème que vous n'avez pas lorsque vous commencez, mais qui grandit et grandit avec le temps parce que, eh bien, finalement, tout va grandir organiquement, et les gens ajouteront de nouvelles fonctionnalités à votre environnement logiciel continuellement et, et ne se soucieront pas toujours de la qualité, n'est-ce pas ? Et puis il y a cette chose que Neil Ford décrit très bien quand il dit que les développeurs sont attirés par la complexité comme des papillons de nuit par une flamme, souvent avec le même résultat. Nous nous brûlons, n'est-ce pas ?
[00:13:31] Et, euh, ce n'est pas au premier jour que vous, euh, que vous échouez. C'est beaucoup plus tard dans l'existence de votre entreprise que vous commencerez à voir la complexité. Ceci est le résultat d'une enquête que j'ai menée lorsque j'ai rejoint mon client actuel appelé QB, et c'est la pile technologique qu'ils ont dans l'entreprise. Cette diapositive a un an et demi, n'est-ce pas ? Aujourd'hui, je manque probablement déjà pas mal de technologies qui ne sont pas sur cette diapositive que nous avons et utilisons. Maintenant, si vous devez maintenir tout cela avec un nombre de personnes assez limité, vous êtes en difficulté, n'est-ce pas ? Cela signifie qu'à un certain moment, vous arriverez à ce que l'on appelle la zone de dilemme. C'est une diapositive intéressante. C'est ce qu'on appelle le dilemme de l'innovateur. Ce qui illustre essentiellement que si vous avez un produit que vous avez construit, que ce soit un logiciel ou un matériel, peu importe. Qu'il, euh, qu'il mûrit, et pendant qu'il mûrit, il atteint toutes les, euh, euh, possibilités du marché. Et à partir de là, ce que les entreprises font généralement, c'est, lorsqu'elles ont du succès avec un produit particulier, elles continuent à travailler dessus. Jusqu'à ce que, euh, le marché ne se développe plus, et ils continueront à construire par-dessus. Nous construisons toujours chez QB sur le thermostat actuel. Ce que nous aurions dû faire, c'est construire quelque chose de nouveau et, et recommencer, et recommencer petit, et en quelque sorte nous réinventer. Maintenant, c'est un dilemme auquel beaucoup d'entreprises sont confrontées, et je, je travaille avec beaucoup de, euh, euh, startups et de scale-ups et d'entreprises allant jusqu'à environ 500, euh, employés, euh, comme les compagnies d'assurance. Et ils viennent tous avec ce dilemme, n'est-ce pas ? Ils ont tous le même problème. Ils se retrouvent dans ce qu'on appelle la zone de dilemme.
[00:15:17] Maintenant, le problème est ce que nous avons fait avec le logiciel, c'est que, euh, nous avons l'envie d'ajouter continuellement de nouvelles fonctionnalités à nos produits et à nos logiciels. Et finalement, vous arrivez à une situation où vous ajoutez continuellement fonctionnalité après fonctionnalité, mais en même temps, parce que vous ne pouvez dépenser votre temps qu'une seule fois, euh, la qualité diminue de plus en plus. Et le nombre de dépendances que nous avons dans notre code, il augmente, augmente, augmente et augmente. Maintenant, c'est un problème. Le problème est ce que j'appelle le développement piloté par le Product Owner. C'est là que, euh, nous écoutons continuellement les parties prenantes, les Product Owners, les managers, les clients, euh, les clients des clients, selon ce que vous faites, et ajoutons continuellement de nouvelles fonctionnalités, mais ne passons pas de temps à, euh, maintenir la qualité de nos bases de code, de notre architecture et de nos tests. Beaucoup de bases de code traditionnelles et plus anciennes n'ont même pas de tests automatisés, n'est-ce pas ? Ce n'était pas possible lorsque nous avons commencé à les construire. En conséquence, eh bien, c'est une bonne métaphore pour cela. Ce que vous voyez, c'est que nous commençons chaque produit, chaque projet que nous faisons, euh, euh, plein de bonnes intentions et avec une bonne architecture et très propre, et cetera, et cetera. Ceci, d'ailleurs, est un très beau, euh, euh, euh,
[00:16:35] dessin animé de la République tchèque qui est assez célèbre là où nous vivons. Euh, à chaque épisode, ils commencent un nouveau projet, euh, et pendant l'épisode, ils voient que beaucoup de problèmes surgissent, alors ils ajoutent de nouvelles choses, ils y ajoutent de nouvelles fonctionnalités, de nouvelles bosses, de nouvelles fermetures éclair, tout ce qu'ils y ajoutent. Et finalement, à la fin de chaque épisode, ça explose en quelque sorte et ça tombe en panne. Ceci est typiquement, euh, le cycle de vie du logiciel, n'est-ce pas ? En fin de compte, il tombera en panne à cause de toutes les complexités. Donc, votre logiciel ne tombe pas en panne quand vous commencez, plein de bonnes intentions. C'est généralement plutôt bon. Il tombe en panne plus tard. Comme 15 ans plus tard, quand vous réalisez que le nombre de dépendances que vous avez ou la pile technologique que vous avez a tellement grandi qu'elle vous empêche d'évoluer et d'innover sur ce que vous devriez réellement faire. Donc, pendant que vous atteignez le dilemme de l'innovateur, vous atteignez le point où vous devez tout recommencer, votre pile a explosé en même temps. C'est un problème que je rencontre dans beaucoup d'entreprises. Et la question est, où allez-vous ? Que faites-vous maintenant ?
[00:17:43] Et, euh, et encore une fois, il n'y a pas, vous ne pouvez pas juste vous arrêter là. Vous ne pouvez pas juste continuer à faire ce que vous faites. Car si vous faites cela, et que vous ne prenez pas les décisions de vous en détacher et de recommencer, vous finirez par ce qu'on appelle la Loi de Hope de nos jours. Nommée d'après Graham Hope, qui a dit qu'une complexité excessive est la punition de la nature pour les organisations incapables de prendre des décisions, n'est-ce pas ? Et, euh, et c'est typiquement ce qui se passe, n'est-ce pas ? Si vous continuez à faire ce que vous avez toujours fait, à construire sur le produit qui a déjà atteint sa maturité sur le marché, et que vous ne recommencez pas, et que vous êtes bloqué en même temps avec ce vaste et complexe paysage logiciel, vous êtes condamné. À ce moment-là, vous devez repenser votre façon de travailler. Vous devez repenser votre processus de pensée, la façon dont votre innovation fonctionne. Et il n'y a qu'une seule solution à cela : vous devez apprendre en faisant. Et je vais illustrer pourquoi, et je vais aussi essayer d'illustrer comment nous l'avons fait dans un certain nombre d'entreprises, euh, pour lesquelles j'ai travaillé au cours des sept à huit dernières années.
[00:18:48] Alors, euh, c'est le moment où je vais vous présenter ce que j'appelle le monde des petites pièces mobiles. Euh, je vais vous faire une courte présentation de moi-même. Euh, je m'appelle Sander, euh, je suis candidat en informatique. Euh, j'ai trois enfants adultes, enfin, deux adultes et un qui a presque 16 ans. Euh, ils sont tous musiciens, de gentils enfants. Euh, euh, et, euh, je donne des conférences, j'écris des livres et, euh, euh, beaucoup d'articles. Je voyage quand j'ai le temps, malheureusement cette année, il y a eu très peu de voyages. Je suis freelance, je fais des postes de CTO, je forme des gens, j'écris beaucoup de code, j'ai écrit du code pendant les 40 dernières années et encore aujourd'hui je le fais. Euh, euh, mon poste actuel est celui d'architecte en chef pour cette startup IoT, euh, que je quitterai car l'entreprise cesse d'exister, ayant été rachetée par une plus grande entreprise. Euh, elle ou bit, n'est-ce pas ? Et je commencerai comme CTO pour, euh, euh, euh, cette entreprise de commerce électronique appelée Ibut, qui est aussi une scale-up, et ils ont des défis similaires à ceux que nous avons actuellement. Euh, donc, mon site web est là, euh, aussi mon compte LinkedIn, mon compte Twitter, euh, même mon compte GitHub, mon adresse e-mail sont là. Si vous avez des questions après, n'hésitez pas à me contacter de la manière que vous voulez. Donc. Par où commencer ? Eh bien, nous commençons par dire ceci, n'est-ce pas ? Il n'y a qu'une seule façon de percer la complexité. Et c'est de prendre du recul et d'essayer d'identifier que si vous essayez de passer de la complexité à la simplicité, vous devez commencer à réaliser que Je suis actuellement l'architecte en chef de cette startup IoT, que je quitterai car l'entreprise a cessé d'exister, ayant été rachetée par une plus grande entreprise. Euh, soit l'un, soit l'autre, n'est-ce pas ? Et je commencerai en tant que CTO pour cette entreprise de commerce électronique appelée Ibut, qui est également une scaleup, et ils ont des défis similaires à ceux que nous avons actuellement. Euh, donc mon site web est là-haut, euh, aussi mon compte LinkedIn, mon compte Twitter, euh, même mon compte GitHub, et mon adresse e-mail sont là. Si vous avez des questions après, n'hésitez pas à me contacter de quelque manière que ce soit. Alors, par où commençons-nous ?
[00:20:01] Eh bien, nous commençons par dire ceci, n'est-ce pas ? Il n'y a qu'une seule façon de percer la complexité, et c'est de prendre du recul et d'essayer d'identifier que si vous essayez de passer de la complexité à la simplicité, vous devez commencer à réaliser qu'il n'y a qu'un seul adage et c'est un magnifique bâtiment d'un architecte appelé Mies van der Rohe, euh, et c'est une maison d'architecte très, très minimale. C'est une très belle maison, mais elle est si simple qu'il est presque inimaginable à quel point on peut simplifier les choses. Et avoir toujours un beau code, ou de beaux bâtiments d'ailleurs, n'est-ce pas ? Alors, voici de quoi il s'agit, moins c'est plus. Et la question est, comment en arrive-t-on à moins ? Eh bien, euh, j'ai résumé ce monde de petites pièces mobiles en quatre parties. Premièrement, il s'agit de livrer des fonctionnalités plus petites et d'arrêter de faire des projets. Deuxièmement, il s'agit de réaliser des cycles plus courts. Encore plus courts que les cycles agiles auxquels nous nous sommes habitués au cours des 20 dernières années. Et je vais vous montrer comment et comment vous pouvez faire cela. Et la troisième chose est que nous allons travailler en équipes plus petites. Parce que les équipes, telles que nous les avons identifiées dans, euh, euh, ce que j'appelle les approches agiles traditionnelles, comme Scrum, où les équipes ont une taille comprise entre, disons, 6 et 10, euh, et, euh, euh, cela ne correspond pas vraiment à notre situation actuelle avec la technologie. Et ce n'est pas, euh, euh, ce n'est pas un problème car, euh, euh, avec le temps, tout évolue. Cela signifie aussi que la façon de travailler et la façon dont nous voyons l'Agile, cela évolue aussi. La quatrième partie, que je n'aborderai pas aujourd'hui, concerne la construction de votre logiciel en composants beaucoup plus petits que ce à quoi vous êtes habitués actuellement. Maintenant, tous ces quatre éléments contribuent à, euh, pouvoir percer la complexité et recommencer. Euh, et, et c'est en quelque sorte l'histoire que j'ai aujourd'hui, n'est-ce pas ? Commençons donc par le premier. Le premier est, euh, arrêtez de faire des projets et livrez des fonctionnalités plus petites.
[00:22:07] Maintenant, c'est un cadre qui est très connu ou un modèle, si vous voulez l'appeler ainsi. Euh, c'est le cadre de Canefin, euh, euh, écrit par Dave Snowden, euh, qui a travaillé pour IBM pendant longtemps, et il est professeur dans une université au Pays de Galles, et il vient de terminer son livre sur le sujet aussi. Et il dit, eh bien, il y a बेसिकली quatre zones, n'est-ce pas ? Il y a la zone évidente où vous avez un problème, et pour ce problème, il existe la meilleure pratique. C'est le plus facile. Ce sont ceux que vous pouvez résoudre, n'est-ce pas ? Donc si mon évier est plein de vaisselle, je la mets dans le lave-vaisselle. Solution simple, il n'y a pas de meilleure solution, c'est tout, n'est-ce pas ? Ce sont les problèmes les plus faciles, les problèmes faciles. Ceux-là sont dans une zone de confort, nous pouvons gérer cela. Vous pouvez même faire du waterfall là-bas. Oui, je sais qu'il était aussi un orateur. Oui, euh, il est un très bon orateur d'ailleurs. Il dit aussi, euh, la zone compliquée est celle où vous avez un certain nombre de bonnes pratiques qui s'adaptent toutes au problème. Dans ce cas, vous devez faire une analyse et vous pouvez déterminer ce que c'est. Euh, et vous pouvez choisir l'une des meilleures bonnes pratiques, l'appliquer et faire le travail. C'est typiquement encore, disons, le domaine de la cascade. Mais ensuite vous arrivez de l'autre côté du diagramme et vous avez les zones complexes et chaotiques. Maintenant, dans les zones complexes et chaotiques, il n'y a pas de bonnes ou meilleures pratiques. Soit elles émergent, soit elles ne sont tout simplement pas là. Personne ne l'a fait avant, n'est-ce pas ? C'est vraiment un nouveau territoire. Par exemple, si vous êtes sur le marché de l'énergie intelligente et que vous devez survivre et que vous êtes l'inventeur d'un thermostat intelligent, comment continuer ? Ceci est typiquement dans la zone chaotique, n'est-ce pas ? Maintenant, euh, euh, le fait est que ces quatre zones exigent des approches très différentes quant à la manière dont vous effectuez le travail. N'est-ce pas ? C'est un peu résumé par Ella Kelly, une amie à moi. Il dit, eh bien, c'est le, c'est évident, n'est-ce pas ? Et, euh, la zone compliquée, vous pouvez dire, ah, c'est ça. C'est la solution que j'utiliserai, la direction que je prendrai. Eh bien, ça marchera parce que d'autres l'ont fait avant. Si vous êtes dans la zone complexe, c'est un peu comme, d'accord, nous espérons que quelque chose sortira de ce que nous faisons. Si vous apprenez tout le temps, si vous expérimentez, car c'est la voie à suivre, et que vous trouvez les pratiques que vous pouvez utiliser, vous passerez lentement des pratiques émergentes dans la zone complexe à la zone plus compliquée, et cela rend les choses plus faciles, n'est-ce pas ? Mais si vous êtes dans la zone chaotique, c'est un peu comme si je n'avais aucune idée où aller. Il n'y a pas d'horizon pointillé, nous n'avons pas de direction. Comment continuons-nous ? Et c'est là que se trouvent de nombreuses entreprises. En fait, en raison de la rapidité avec laquelle tout change, la plupart des organisations se retrouveront soit dans des zones complexes, soit dans des zones chaotiques, ce qui signifie qu'ils sont tenus d'expérimenter. Vous ne pouvez pas anticiper si vous êtes dans cette situation. Et il est vraiment difficile de faire prendre conscience de ce fait aux personnes des, euh, euh, des conseils d'administration et, euh, des équipes de direction. Ils sont très souvent encore dans une position où ils pensent pouvoir planifier le monde. Ils se disent : pourquoi le développement de logiciels n'est-il pas prévisible ? Il devrait être prévisible. C'est juste, c'est très facile, n'est-ce pas ? Cela pourrait être des choses que personne n'a faites auparavant, n'est-ce pas ? Et le manager a dit, eh bien, c'est facile, tu devrais le faire en environ une semaine. Je n'ai aucune idée de comment faire cela, n'est-ce pas ? C'est le dilemme auquel nous sommes continuellement confrontés dans les organisations. Maintenant, Day Snowden dit en gros que si vous êtes dans un contexte chaotique, chercher les bonnes réponses, et c'est un bon résumé, est inutile. Parce qu'il n'y a pas de relations apparentes entre la cause et l'effet. Cela signifie que vous devez commencer à innover, vous devez expérimenter, n'est-ce pas ? Et il dit, eh bien, fondamentalement, le domaine chaotique est presque toujours le meilleur endroit pour les leaders afin de stimuler l'innovation. C'est là que vous devriez être. Si vous êtes dans une zone complexe ou chaotique, vous devez innover, vous devez vous réinventer. Alors, la plupart des organisations se retrouveront de nos jours dans des zones complexes et chaotiques. Par conséquent, le monde n'est pas planifiable. Donc la cascade est hors de question. Il en va de même pour, euh, euh, euh, euh, le, euh, euh, le Triangle de Fer, n'est-ce pas ? Il était assez populaire auprès des chefs de projet. Il a disparu. Même les chefs de projet ont en grande partie disparu. Je n'ai pas vu de chef de projet depuis des années dans les entreprises pour lesquelles je travaille. C'est assez intéressant, n'est-ce pas ? Tout le poste a disparu, ils sont devenus des propriétaires de produits ou même des scrum masters, d'ailleurs, n'est-ce pas ? Une planification détaillée est impossible à réaliser si vous êtes dans une zone complexe ou chaotique. Ce n'est vraiment pas faisable. Donc vous devez arrêter de faire ça. Encore mieux, vous pourriez dire que toute l'idée de réaliser des projets dans le domaine du développement logiciel, à cause des changements rapides et des changements de plus en plus importants que nous connaissons, le monde de la gestion de projets ne s'applique pas vraiment à ce que nous faisons. Au lieu de cela, vous devez passer à un flux de travail beaucoup plus continu. Maintenant, bien sûr, les approches agiles ont fait beaucoup de chemin avec ça. Mais nous allons aller au-delà des approches agiles traditionnelles lorsque nous ferons du développement logiciel. Euh, pour vous donner un exemple encore, c'est la vitesse de changement, si vous avez un grand système monolithique ou un grand paysage monolithique, et que vous ne pouvez publier, disons, qu'une fois par trimestre, cela signifie que vous avez une grande quantité de, euh, de changements reflétés dans la flèche orange ici, euh, que vous devez faire passer. Mais plus vous avez de changements, plus il est complexe de poser le paysage. En conséquence, ce qui se passera avec le temps, c'est que plus vous aurez de changements, plus vous ralentirez. Euh, j'ai travaillé pour cette entreprise, une entreprise de transport public aux Pays-Bas, qui pouvait à peine publier tous les trois mois. Et il n'a pas fallu beaucoup plus d'efforts pour en fait, le rendre encore plus lent. Donc plus ils pouvaient introduire de changements, plus ils ralentissaient. En conséquence, euh, ils voulaient publier tous les trois mois, donc le nombre de changements qu'ils pouvaient gérer est devenu de plus en plus lent et de moins en moins nombreux. À un certain moment, ils se sont littéralement arrêtés, ce qui, si vous êtes une entreprise de transport public, n'est pas une bonne idée. Comme alternative, que se passerait-il si vous pouviez décomposer, euh, toute votre architecture, votre paysage et votre code en petites parties, et être capable de publier ces parties individuellement, n'est-ce pas ? Vous pourriez publier toutes ces parties individuellement en petits changements. Et si vous pouviez faire ça ? Et si l'ensemble combiné de ces petits services et de ces petits, euh, morceaux de logiciel continuait à faire le travail, n'est-ce pas ? Cela signifie que vous pourriez publier à tout moment, à tout moment que vous voulez vraiment le faire. Et par conséquent, vous êtes devenu beaucoup plus agile, et vous pouvez changer beaucoup plus rapidement, vous pouvez évoluer et vous pouvez expérimenter. Maintenant, en conséquence, vous obtenez, euh, euh, eh bien, fondamentalement un paysage de petits services. Ceci est une capture d'écran de notre pipeline Jenkins, euh, euh, ou du paysage Jenkins, eh bien, Jenkins, et nous avons maintenant décomposé le logiciel de mon client actuel en 60 à 70 pièces différentes. Chez l'un de mes anciens clients, j'étais le CTO d'une compagnie d'assurance, nous avons décomposé le tout en, euh, euh, je crois que c'était environ 158 petites pièces. Nous avons donc décomposé tout le paysage, et nous pouvions publier chacun d'eux individuellement. Faire cela, cela vous permet de faire de très, très petits pas. Nous pourrions littéralement ajouter une toute petite fonctionnalité à n'importe laquelle de ces parties, puis la mettre en production avec un pipeline entièrement automatisé. Maintenant, euh, si vous faites cela, euh, et je le répéterai, vous pouvez le faire sans avoir de projets. Donc toute la métaphore du projet, elle doit disparaître, n'est-ce pas ? Alors, quelle est la deuxième étape ? Maintenant, la deuxième étape concerne les cycles. Maintenant, nous sommes probablement tous très conscients, euh, des approches agiles et la plupart des gens que je rencontre, et la plupart des équipes et des entreprises que je rencontre, ils ont des cycles de deux, trois, voire quatre semaines, euh, ce qui est assez courant si vous utilisez Scrum et des approches similaires à Scrum. La question est, sont-ils assez courts ?
[00:30:23] Parce que plus les cycles deviennent courts, euh, plus il est facile d'obtenir des retours et plus il est facile d'apporter de petits changements au paysage. Cela signifie donc que si vous pouviez raccourcir encore plus vos cycles, euh, euh, au-delà de ce que disent les approches agiles comme Scrum, euh, vous pourriez être encore plus rapide, n'est-ce pas ? Et, euh, et plus agile aussi. Alors, avons-nous vraiment, vraiment besoin de ces sprints de deux à quatre semaines ? Maintenant, il y a plusieurs choses que je vais dire à ce sujet. La réponse courte à cette question est : vous n'avez pas besoin de sprints. La réponse plus longue est que vous n'avez pas besoin de sprints si vous avez déjà atteint cette phase, n'est-ce pas ? Si vous êtes toujours dans une situation en cascade, veuillez passer par des cycles plus courts, de quatre mois à trois mois, à deux mois, à des cycles de deux semaines, puis allez au-delà, n'est-ce pas ? Mais si vous avez fait cela pendant longtemps, l'utilisation et les, euh, euh, les avantages de l'application de Scrum à ce que vous faites, ils diminuent en fait de plus en plus. Même lorsqu'ils ont une nouvelle version du Guide Scrum, qui est à peu près la même chose, fondamentalement, mais, euh, enfin, vous pouvez donc supprimer les sprints de ce que vous faites. Et pour être tout à fait honnête, Scrum ne signifie pas que vous faites de l'Agile. Je vois beaucoup d'entreprises implémenter Scrum qui ne sont pas agiles du tout. Aussi, l'inverse est également valable, n'est-ce pas ? On peut être agile sans faire de Scrum, en fait. Je fais de l'Agile depuis pas mal de temps, et je ne participe presque jamais à des projets Scrum traditionnels. Alors, la question est : pourquoi toutes ces personnes pensent-elles que l'Agile est Scrum ? Et c'est essentiellement parce que nous avons baissé nos barrières. Maintenant, disons que vous faites du karaté, n'est-ce pas ? Et vous faites du karaté très bien. Normalement, si vous êtes profond en Agile, si en karaté, si vous êtes devenu un maître, il vous faudra au moins 10 ans ou 15 ans avec beaucoup de pratique, comme 20 à 30 à 40 heures par semaine pour devenir un maître de karaté. Et même alors, les gens que je connais qui sont réellement maîtres de karaté, ils ne se considèrent pas comme maîtres de karaté, bien qu'ils le fassent depuis 15 ans et 40 heures par semaine. D'un autre côté, pour être Scrum, Scrum Master, il faut suivre un cours de formation de deux jours et un examen à choix multiples de 30 minutes. Maintenant, c'est typiquement là que le problème surgit. Parce que cela signifie que n'importe qui peut entrer dans le domaine du développement logiciel, faire des choses de type Scrum et, euh, euh, et être embauché pour résoudre des problèmes. En conséquence, les personnes ayant moins d'expérience et de formation, ce qu'elles feront, c'est qu'elles appliqueront cet apprentissage, cette croyance ou cette doctrine de manière très dogmatique. Et, et la citation ici est vraiment bonne. Il dit, eh bien, fondamentalement un dogme est autoritaire et ne doit pas être contesté, mis en doute ou s'en écarter par les pétitionnaires protecteurs ou les croyants ou, pardon, les partitionneurs ou les croyants, n'est-ce pas ? Cela signifie que beaucoup de gens viennent ici et font exactement ce qui est dit dans le Guide Scrum. Et vous avez ces discussions comme, non, vous ne pouvez pas faire ça. Ce n'est pas dans le guide Scrum. Et pour être honnête, je m'en fiche complètement. Parce que si vous allez, si vous avez fait de l'Agile assez longtemps, vous irez au-delà de ce point. Mais le problème, c'est, euh, euh, et c'est un bon problème, et ce sont mes enfants sur, euh, mon, l'un de mes fils et ma petite amie en fait. Euh, et ils ont essayé le snowboard l'année dernière, en fait, euh, l'année dernière, il y a deux semaines, euh, pour la première fois. Et ils se disaient, à quel point ça peut être difficile, n'est-ce pas ? Nous, nous savons skier, donc nous devrions probablement aussi pouvoir faire du snowboard. Euh, et ils ont passé une semaine entière sans admettre que c'était, c'était beaucoup plus difficile qu'ils ne le pensaient. Euh, parce qu'on ne peut pas simplement faire quelque chose de complexe, euh, juste en suivant un cours de formation de deux jours et un examen de 30 minutes et penser qu'on peut réellement le faire. Parce que cela demande beaucoup d'apprentissage et beaucoup de pratique. Cela signifie donc que, lentement, avec le temps, les gens s'amélioreront et apprendront davantage, et de là arriveront à un point où ils pourront dire, eh bien, maintenant nous revenons au cœur du Manifeste Agile. Et le cœur du Manifeste Agile dit ceci, n'est-ce pas ? Il dit : satisfaire le client par la livraison précoce et continue de logiciels de valeur. Il ne dit pas de livrer toutes les quatre semaines ou toutes les deux semaines, il dit en continu. Donc, plus vous pouvez être continu, plus vous êtes agile. Cela signifie que si vous pouvez abandonner les sprints, vous êtes beaucoup plus rapide que si vous vous en tenez à ce qu'est Scrum. Donc je ne dis pas que Scrum est mauvais. Scrum n'est pas mauvais, Scrum est vraiment très bon si vous venez d'approches plus traditionnelles. Si vous avez fait du Scrum assez longtemps, vous devriez voir et vous devriez rétrospecter de manière à dépasser ce qui est dans le Scrum traditionnel. Cela signifie que je vais sauter quelques diapositives, donc celle-ci je la sauterai. Cela signifie que vos cycles deviennent de plus en plus courts. Et c'est fondamentalement l'évolution des approches de développement logiciel. Nous avons commencé à, eh bien, nous avons commencé avec rien fondamentalement, puis nous sommes passés à la cascade, qui a un cycle unique, dans les années 90 où nous avions des choses comme le processus unifié rationnel avec des cycles de quatre à six mois. Et puis nous sommes arrivés au DSDM dans les années 90 et les premières années de ce siècle où nous avons eu des cycles de quatre à six semaines, puis sont arrivées les approches Agiles et Scrum principalement.
[00:35:43] Et nous sommes passés à deux à quatre semaines, mais maintenant nous passons à, euh, livraison le même jour, n'est-ce pas ? Quelqu'un propose une fonctionnalité, vous l'intégrez, vous la vérifiez, vous la testez automatiquement, elle passe par votre pipeline, et elle est déployée. Ou même autant de fois que vous le souhaitez par jour. Avec les infrastructures que nous avons mises en place chez mon client actuel, nous pourrions littéralement aller en production, et nous l'avons probablement fait plusieurs fois, euh, euh, euh, d'aller en production aujourd'hui, euh, autant de fois que vous le souhaitez, n'est-ce pas ? C'est la brièveté que les cycles atteindront dans le domaine du développement logiciel une fois que vous l'aurez professionnalisé. Le seul problème est que pour ce faire, vous devez être capable de tout automatiser. Il n'y a plus beaucoup de travail manuel là-dedans. Les tests traditionnels, le remplissage de feuilles de calcul, le clic sur des boutons, tout cela disparaît. Tout doit être testé automatiquement, tout doit être mis dans des pipelines automatiques pour chaque petit morceau de logiciel que vous avez, n'est-ce pas ? Et cela ressemble-t-il à une approche plus proche de Kanban ? Oui, tout à fait. Parce que ce que vous faites, c'est, si vous avez encore un tableau, en fait nous avons arrêté d'utiliser des tableaux chez mon client actuel. c'est que vous déplacez les éléments de gauche à droite sur le tableau aussi vite que possible. C'est fondamentalement la seule métrique qui reste. À quelle vitesse mes éléments vont-ils de gauche à droite sur le tableau ? Il ne s'agit pas de savoir combien de points vous pouvez marquer dans un sprint ? Parce que personne ne sait de toute façon la taille d'un point, n'est-ce pas ? Alors, euh, est-ce que ça ressemble à Kanban ? Oui, ça ressemble à Kanban. Mais pour faire cela, Kanban ne dit pas grand-chose à ce sujet, il ne dit pas comment le faire. Il dit simplement : regardez les goulots d'étranglement de votre processus et optimisez les goulots d'étranglement. Maintenant, dans le développement logiciel, cela signifie que vous devez tout automatiser. N'est-ce pas ? C'est une photo du lieu de travail chez mon client actuel, et l'écran de télévision vert que vous voyez signifie que tous les pipelines étaient verts. J'ai pris cette photo parce que c'est vraiment rare que cela se produise. Habituellement, ils ne sont pas tous verts. Mais cela signifie que vous devez automatiser, vous devez configurer vos pipelines. Et vous devez commencer petit, encore une fois, faire des petits pas ici aussi. N'est-ce pas ? Euh, c'est l'une des premières fois que nous avons mis en place le pipeline, euh, sur Jenkins, euh, euh, euh, sur Jenkins, et il comportait environ six étapes. Plus tard, nous y avons ajouté d'autres étapes, et nous avons ajouté plus de déploiements et plus de tests de performance et de tests de scénarios et toutes sortes de choses dans le pipeline. Et nous avons automatisé, euh, euh, nous l'avons automatisé de manière assez intensive. Jusqu'à ce que nous arrivions au point où nous faisions tout de manière entièrement automatique, depuis le moment où nous soumettions le code jusqu'à son exécution en production, littéralement, n'est-ce pas ? Et cela a pris environ cinq minutes finalement pour passer par le pipeline. à partir de ce moment-là, d'ailleurs, nous avons changé la technologie de pipeline. Nous sommes passés de Jenkins à GitLab parce que, eh bien, nous avions des problèmes d'infrastructure avec Jenkins. Donc, c'est là que vous allez, vous devez automatiser. Cela signifie aussi que vous devez tout tester dès le premier jour, n'est-ce pas ? Cela signifie que la façon dont beaucoup d'entreprises effectuent les tests et font, euh, euh, euh, les tests traditionnels, c'est généralement beaucoup de tests manuels qui sont effectués. Et s'il y a de l'automatisation, c'est généralement, euh, de l'automatisation qui clique automatiquement sur le site web ou l'application ou l'application mobile, euh, à un niveau élevé, ce sont des tests de scénario. Le truc, c'est que si vous voulez passer à des cycles plus courts et tout automatiser, cela signifie que vous devez commencer par le bas. Cela signifie que vous devez avoir des tests unitaires pour tout votre code. Et c'est un gros problème chez de nombreux clients que je rencontre, c'est qu'ils n'ont pas ça, n'est-ce pas ? Et ils doivent s'améliorer sur ce point. L'un de mes clients actuels a une application mobile avec une base de code assez large qui est très peu testée, ce qui signifie que l'équipe mobile, chaque fois que je leur parle, ils disent, eh bien, nous espérons que cette fonctionnalité fonctionnera en production. Et je dis, l'espoir n'est pas une très bonne stratégie, n'est-ce pas ? Vous devez savoir. Donc vous devez tester. Et nous sommes en train de mettre en place des tests unitaires, euh, euh, sur cette base de code et de la refactoriser lentement à partir de là, n'est-ce pas ? Euh, donc oui, vous devez avoir des tests automatisés partout. Je vais sauter celle-ci. Ainsi, la plupart des tests que vous exécutez devraient se trouver sur votre pipeline. Le seul test manuel que vous faites encore est le test occasionnel que vous effectuez lorsque vous construisez le code, n'est-ce pas ? Le reste, les tests de sécurité, la validation, la validation syntaxique, euh, les tests unitaires, l'analyse de code statique, les tests de bout en bout, euh, les tests de performance, les tests de sécurité, la surveillance, tout cela fait partie de votre pipeline, n'est-ce pas ? À titre d'exemple, je vais vous montrer une capture d'écran de, euh, Sonar Cube, qui est le, euh, l'outil d'analyse de code statique open source le plus connu qui existe. Euh, et ici vous voyez une base de code qui a une couverture de code de 90% avec plus de 245 tests unitaires sur environ 1600 lignes de code, n'est-ce pas ? C'est beaucoup de tests. Mais si vous avez ces tests, ce que nous avons découvert au fil du temps, c'est que, eh bien, cela donne, en ayant essentiellement des tests unitaires pour tout, cela vous donne beaucoup de confiance dans ce que vous faites. Cela vous permet en fait de refactoriser continuellement tout votre code et même votre architecture, n'est-ce pas ? Et c'est un grand avantage parce que si vous vous souvenez de cette diapositive que j'avais avec toute la technologie dessus, si votre paysage est comme ça, vous n'avez aucune confiance pour avancer. Si vous avez de grandes bases de code non testées, des bibliothèques ou des architectures, il n'y a aucun moyen d'avancer avec confiance. Et le fait est que si vous avez des tests automatisés pour tout, cela vous donne la confiance nécessaire pour modifier votre code, modifier votre architecture et la maintenir à jour. Ne pas entrer dans le domaine où vous empilez fonctionnalité sur fonctionnalité sans pouvoir modifier votre architecture. C'est votre porte de sortie en fait si vous êtes dans cette situation. En fait, nous avons récemment découvert que nous ne déboguons même plus notre code. Je n'ai pas touché à un débogueur depuis des mois, je suppose, n'est-ce pas ? C'est, c'est fondamentalement parce que je travaille à partir de mes tests unitaires tout le temps, n'est-ce pas ? Et tous ces tests manuels, les tests d'acceptation utilisateur et toutes ces étapes que les gens avaient habituellement dans les projets, ils sont éliminés, n'est-ce pas ? Et cela signifie que vous pouvez arrêter de faire des projets.
[00:41:54] Alors, je vais prendre une gorgée de mon thé. pour changer votre architecture et la maintenir à jour, pour ne pas vous retrouver dans la situation où vous empilez fonctionnalité sur fonctionnalité sans pouvoir changer votre architecture. C'est votre porte de sortie en fait si vous êtes dans cette situation. En fait, nous avons découvert récemment que nous ne débuggons même plus notre code. Je n'ai pas touché le débogueur depuis des mois, je suppose, n'est-ce pas ? C'est essentiellement parce que Je travaille avec mes tests unitaires tout le temps, n'est-ce pas ? Et tout ce test manuel et les tests d'acceptation utilisateur et toutes ces étapes que les gens avaient habituellement dans les projets, ils sont éliminés, n'est-ce pas ? Et cela signifie que vous pouvez arrêter de faire des projets. Donc, je vais prendre une gorgée de mon thé. Et nous allons passer à une partie sur les équipes, n'est-ce pas ? Donc, comme j'ai essayé de le dire, euh la façon dont nous travaillons avec les équipes, euh a changé aussi avec le temps. Donc, la façon dont cela a été prédit ou écrit il y a 25 ans, quand la plupart des approches agiles sont apparues, le monde a changé depuis, n'est-ce pas ? Cela signifie que, à mon avis, à mon humble avis, la plupart de ces approches traditionnelles ne résolvent pas vraiment les problèmes modernes. N'est-ce pas ? Alors, par exemple, Corona est un bel, enfin, ce n'est pas un bel exemple, c'est un bon exemple de la façon dont nous nous sommes adaptés à notre manière de travailler, euh, euh, ce que personne n'aurait pu prédire quand ils ont écrit, il y a 25 ans, toutes ces approches agiles, n'est-ce pas ? Donc, voici un certain nombre de problèmes que nous rencontrons ces jours-ci. Tout d'abord, il y a une faible disponibilité de ce que les managers aiment appeler des ressources, n'est-ce pas ? Les ressources sont fondamentalement les personnes qui font le travail, ce sont les développeurs, les personnes de l'assurance qualité, les testeurs, les designers, euh, toute personne impliquée dans la production du produit. Et il y a une faible disponibilité. Nous sommes rares. Cela signifie qu'il est difficile de trouver des spécialistes pour des choses spécifiques dont vous avez besoin pour construire un produit particulier. Maintenant, euh, euh, et fondamentalement, malheureusement, ceci est en néerlandais. Cette diapositive dit essentiellement, euh, dans tous les secteurs, si toutes les, euh, de toutes les industries, l'informatique est partout, fondamentalement. Et en conséquence, cela signifie que si vous êtes un spécialiste, ou si vous avez besoin d'un spécialiste pour effectuer un type de travail particulier, vous êtes condamné. Parce que ces spécialistes ne sont plus là. Cela signifie que vous ne pouvez plus avoir le rôle de quelqu'un qui est un testeur Cypress ou un testeur web ou tout ce que vous avez, n'est-ce pas ? Cela signifie que vous devez élargir vos compétences. Vous devez en savoir plus car euh, euh, c'est rare. Cela signifie que les compétences sont devenues plus importantes que les rôles. Donc, si vous avez une compétence en tant que programmeur, je suis fondamentalement un programmeur, euh mais par coïncidence, je suis aussi assez profond en architecture. Cela signifie que j'ai deux compétences, n'est-ce pas ? Et nous devons nous élargir pour pouvoir toujours livrer tout le travail dont nous avons besoin. Cela signifie que nous devons tous devenir beaucoup plus en forme de T. Le deuxième problème moderne est que travailler au bureau de 9h à 17h, ça ne correspond plus aux besoins, n'est-ce pas ? Cette diapositive est dans ma présentation depuis, euh, je pense au moins deux ans et demi déjà, euh, et je protestais déjà contre le fait de travailler de 9h à 17h hors des bureaux, euh, parce qu'aux Pays-Bas, nous avons beaucoup de trafic, n'est-ce pas ? C'est une photo que j'ai prise sur l'A2, voici des gens qui voyagent d'Amsterdam, d'Utrecht à Amsterdam le matin. Et vous savez, de l'autre côté de la route, ils voyagent en sens inverse, n'est-ce pas ? Cela signifie que nous sommes coincés tout le temps et pourquoi ? Parce que nous voulons lire nos e-mails à 9 heures du matin au bureau. Pourquoi ? Pourquoi faisons-nous cela, n'est-ce pas ? Eh bien, par coïncidence, depuis Corona, nous avons un peu changé cela. Le 9 à 5 est un paradigme qui va disparaître. Cela signifie que nous devons être capables de fournir, euh, des modes de travail pour des situations qui sont très différentes maintenant. Euh, et euh, et bien, je l'ai ajouté dans certains virus, mais des choses comme être parent ou devoir aller chez le médecin ou devoir s'occuper de sa vieille mère pour l'emmener à l'hôpital, quelque chose que j'ai dû faire la semaine dernière, euh, euh, il n'y a pas de modèle 9h-17h unique qui convienne à la société actuelle. Donc, vous devez vous éloigner de ce modèle. Aussi, nous sommes des gens créatifs, n'est-ce pas ? Le développement logiciel est un domaine très créatif. Cela signifie que vous avez des personnes créatives à bord. Euh, généralement légèrement autistes, mais aussi très, très et hautement créatifs. Les esprits des personnes créatives ne travaillent pas de 9h à 17h. Ils travaillent tout le temps. J'ai les meilleures idées quand je suis sous la douche, quand je suis dans ma voiture, quand je suis dans les transports en commun, pendant que je me promène, euh, ou ou vous guérissez au milieu de la nuit, je me réveille et je me dis, attendez. C'est comme ça que je peux résoudre ce problème particulier, n'est-ce pas ? Et nous devons être capables de travailler avec cela. Cela signifie que nous devons être capables de travailler au moment précis où nous voulons travailler. N'est-ce pas ? Et puis la communication est difficile. Euh, euh, nous savons tous, nous sommes un peu autistes dans cette industrie, la moyenne des, euh, euh, personnes légèrement autistes, les personnes sur le spectre, qui sont vraiment des gens formidables. Je suis aussi sur le spectre, comme vous l'imaginez. Et, euh, euh, nous trouvons que la communication n'est pas toujours facile. Alors, que font ces approches agiles ? Et les entreprises, elles nous donnent beaucoup de rituels et de réunions à suivre.
[00:46:37] Nous devons assister aux planifications de sprint, aux affinages, aux stand-up quotidiens, aux réunions OKR, aux démos, aux rétrospectives, aux réunions plénières pour cela, et nous faisons tout cela, n'est-ce pas ? Et cela signifie
[00:46:49] les gens de mon équipe actuelle, ils passent au moins la moitié de leur temps en réunions. Ce sont les meilleurs développeurs que cette entreprise possède, n'est-ce pas ? Et et et ils disent continuellement, oh désolé, je ne peux pas continuer ce que je fais maintenant, je dois être en réunion. C'est terrible, n'est-ce pas ?
[00:47:03] Alors, comment prévenir cela ? Eh bien, vous pouvez commencer à l'éviter en disant, attendez, euh, euh, si nous devons communiquer, la communication est beaucoup plus efficace si vous devez communiquer avec moins de personnes. Donc, devoir communiquer avec trois personnes est beaucoup plus facile et beaucoup plus rapide en fait que d'être dans une pièce pleine avec 10 personnes car le nombre de façons dont les gens peuvent communiquer entre eux est de plus en plus, euh, euh, de plus en plus grand, n'est-ce pas ? Cela signifie qu'au lieu de dire que nous avons besoin de plus de communication, nous avons besoin d'une meilleure collaboration. Comme ces deux orateurs lors d'une conférence quand nous étions encore en direct, euh, en train de se rencontrer, n'est-ce pas ? Ce qui était d'ailleurs très figé, donc c'était vraiment difficile à couper. Alors, Il s'agit de travailler en petites équipes, n'est-ce pas ? Et comment arrivez-vous à des équipes plus petites ? Cela signifie que les sessions de raffinement d'une journée entière, surtout lorsqu'elles sont en ligne, sont vraiment nulles. Je détestais être en réunion tout le temps et pendant une journée entière. Vous devez donc trouver d'autres moyens de dire que vous devez être en session de raffinement ou en rétrospective de quatre heures ou en réunion de planification de sprint. L'une des équipes de mon client actuel a des sprints de deux semaines, mais ils ont des réunions de planification de sprint chaque semaine, n'est-ce pas ? Cela prend environ une journée complète à toutes ces personnes toutes les deux semaines. Ce n'est pas vraiment efficace, n'est-ce pas ? Et les gens n'aiment pas ça, alors arrêtez de faire ça. Aussi,
[00:48:29] tous les plans d'étage ouverts que nous sommes si heureux d'avoir dans nos bureaux très modernes, ils ne fonctionnent vraiment pas. Parce que ce qui se passe, c'est que et il y a beaucoup d'études à ce stade, c'est que euh, euh, toutes ces conversations que vous avez autour de vous, elles deviennent un bruit insignifiant. C'est pourquoi les gens portent constamment ces casques antibruit parce qu'ils doivent pouvoir se concentrer. Et la concentration ne fonctionne pas toujours très bien dans ces espaces ouverts. Donc, nous nous éloignons de cela aussi, je suppose. Et puis il y a le point de l'autonomie. L'autonomie est une grande partie, n'est-ce pas ? C'est une photo d'un de mes fils, il est batteur. Il lui a fallu deux ans pour découvrir ce qu'il voulait faire après avoir obtenu son diplôme de lycée. Euh, et nous lui avons donné cet espace, n'est-ce pas ? Nous sommes comme, d'accord, va comprendre. C'est ta vie, n'est-ce pas ? Euh, c'est ton autonomie. Décide par toi-même ce que tu veux devenir. Cela lui a pris deux ans, puis il a pratiqué la batterie de manière vraiment fanatique et il étudie maintenant au conservatoire. Donc, il devient en fait assez bon. Mais il s'agit de pouvoir prendre ses propres décisions. C'est de cela qu'il s'agit fondamentalement de l'autonomie. Il s'agit de décider quoi faire, quand le faire et comment le faire, et aussi avec qui le faire, n'est-ce pas ? C'est l'auto-organisation. L'auto-organisation, enseigner l'auto-organisation et les organisations. C'est extrêmement difficile. J'ai essayé de faire cela pendant très longtemps. Euh, et c'est fondamentalement difficile. Parce que pour la plupart des gens qui doivent devenir auto-organisés, euh, c'est vraiment difficile parce que c'est en dehors de leur zone de confort. Euh, c'est comme, si je dis aux gens, vous pouvez maintenant vous auto-organiser, vous pouvez vous auto-structurer et travailler de la manière qui vous convient et faire les choses que vous voulez faire. Euh, et la plupart des gens se diront, qu'est-ce que tu veux qu'on fasse ? Et comment veux-tu qu'on le fasse ? Et bien, c'est à toi de voir. Vous décidez ce qui vous convient le mieux. Maintenant, c'est vraiment difficile. Et aussi, vous ne pouvez pas donner, euh, des directives exhaustives à ce sujet parce que c'est comme, c'est fondamentalement comme dessiner un hibou, n'est-ce pas ? Je peux vous dire, eh bien, vous commencez avec deux cercles, mais le reste du hibou, vous devez le dessiner vous-même.
[00:50:33] Et je vois des entreprises qui poussent l'autonomie à un niveau tel que cela devient en quelque sorte ridicule. Comme, comme cette image, c'est un exemple des États-Unis. Euh, c'est euh, euh, je trouve ça vraiment une image terrible, n'est-ce pas ? Je ne serais pas capable de travailler dans une situation comme celle-ci. Vous pouvez voir que dans la pièce, je veux dire, elle a une belle, elle a vraiment une belle image, voyez, euh, euh, d'un photographe finlandais. Et le reste est blanc. C'est bien, euh, c'est bon pour les gens qui débordent déjà d'énergie. Je ne veux pas être dans une pièce comme celle-ci. Ou celui-ci est encore pire, n'est-ce pas ? Euh, c'est l'espace de travail du salon, les gens veulent que vous, que les organisations veulent que vous décoriez votre espace de travail comme si c'était votre maison. Je ne vis pas dans une maison comme celle-ci. Ce serait terrible, n'est-ce pas ? Vous devenez fou. Ou,
[00:51:22] euh, c'est une photo de, euh, euh, la jambe de ma copine, qui est en entretien d'embauche chez un grand détaillant aux Pays-Bas. Ce n'est pas IKEA, n'est-ce pas ? C'est une salle de réunion, une salle de réunion vitrée remplie jusqu'à ses genoux de petites balles. Parce que c'est amusant. Non, ce n'est pas le cas. Cela n'a rien à voir avec l'auto-organisation. Ce que nous avons trouvé, c'est que l'auto-organisation fonctionne mieux lorsque vous avez moins de règles. Cela signifie, si vous avez moins de règles dans la circulation, vous devez apprendre par vous-même, vous devez penser par vous-même. C'est une photo de l'Alexanderplein à Amsterdam, j'habite à proximité, et ils ont retiré la plupart des panneaux de signalisation et des feux de signalisation de ce carrefour, de sorte que les gens devaient, ils devaient penser continuellement par eux-mêmes. Et je vais vous montrer un bel exemple. Je vais vous montrer un court extrait vidéo. C'est moi dans un taxi à Medan, en Indonésie, il y a deux ans. Et comme vous pouvez le voir, il y a très peu de signalisation sur la route ici. Maintenant, quand vous vous retrouvez pour la première fois dans la circulation en Asie du Sud-Est comme ça, c'est vraiment terrible, n'est-ce pas ? Même nous avons dû traverser la route ici, euh, et comme vous pouvez le voir, le feu de signalisation, le seul qu'ils ont dans une grande ville, est à la fois rouge et vert en même temps, n'est-ce pas ? C'est juste terrible. Et je me demandais pourquoi j'étais dans cette voiture. Heureusement, je ne conduis pas moi-même ici, n'est-ce pas ? Mais je me demandais vraiment, comment les gens traversent-ils la circulation ici ? Et le truc, c'est qu'ils communiquent. Ils se regardent, ils voient qui passe en premier, et ils regardent les autres et essaient de communiquer avec les autres personnes au même carrefour. Et nous avons traversé.
[00:53:01] N'est-ce pas incroyable ? Je vais vous montrer une photo de ma ville natale. C'est là que j'habite, près d'Utrecht. J'habite à deux endroits. Et, euh, c'est un carrefour plein de panneaux de signalisation, plein de lumières, et les gens le traversent sans réfléchir, ils arrêtent de penser. Et c'est fondamentalement ce dont nous devrions nous préoccuper, nous devrions nous préoccuper de, euh, continuellement penser par soi-même, n'est-ce pas ? C'est ce que nous devrions faire dans cette industrie. Cela signifie aussi que si vous voulez abandonner les approches traditionnelles, faites-le, s'il vous plaît. Trouvez votre propre façon de travailler, n'est-ce pas ? Et, euh, c'est vrai, c'est une action automatique, c'est vrai, vraiment vrai. Et, euh, euh, donc, la prochaine chose est, euh, c'est que nous ne sommes pas vraiment bons en estimation. Si vous êtes dans cette industrie, vous l'avez déjà compris. Je continue d'avoir des discussions avec des gens qui pensent que l'on peut estimer le travail que nous faisons. Le problème avec le travail que nous faisons, c'est que la plupart de cela, nous ne l'avons jamais fait auparavant. Parce que si nous l'avions fait avant, nous pourrions simplement installer le logiciel que nous avons construit l'année dernière et le réexécuter, n'est-ce pas ? C'est vrai si vous construisez un produit logiciel. Ce n'est pas vrai si vous développez un logiciel. C'est fondamentalement similaire, euh, à l'industrie automobile, n'est-ce pas ? La plupart des gens comparent le développement logiciel à des voitures sortant d'une chaîne de montage, et la seule différence est que l'une est bleue, l'autre est rouge, ce n'est pas ça le développement logiciel.
[00:54:23] Si vous compariez le développement de logiciels à l'industrie automobile, ce serait la comparaison avec la conception d'un nouveau type de voiture. C'est typiquement la même chose que nous faisons dans le développement de logiciels. Euh, et puis encore, l'estimation que nous avons tendance à faire dans les approches agiles ne fonctionne pas vraiment, elle n'ajoute pas vraiment de valeur. La raison en est qu'il existe ce que l'on appelle la loi des grands nombres. Maintenant, la loi des grands nombres est un théorème et elle décrit le résultat de l'exécution de la même expérience. Je lis ceci sur Wikipedia. grand nombre de fois. Selon la loi des grands nombres, la moyenne des résultats obtenus à partir d'un grand nombre d'essais est proche de la valeur attendue. Eh bien, si j'explique cela brièvement, c'est comme si vous jetez un dé avec les faces 1, 2, 3, 4, 5, 6, vous le jetez 10 fois, alors vous obtiendrez plus ou moins la moyenne, n'est-ce pas, qui est 3 et demi. Mais si vous le lancez mille fois, vous vous rapprocherez beaucoup plus de la moyenne de trois et demi en moyenne, euh, euh, et plus vous faites d'expériences, plus vous vous rapprochez de la moyenne. Cela signifie que si vous estimez des récits d'utilisateurs ou des choses que vous estimez à un faible niveau sur une échelle, si vous en estimez suffisamment, et cela est atteint par environ 20 expériences. Cela signifie, euh, que vous atteindrez la moyenne de votre de votre compétence. Cela signifie que vous pourriez simplement arrêter de faire cela et simplement compter le nombre d'éléments sur lesquels vous travaillez ou voulez travailler, ce qui est également très valable comme estimation, vous avez une échelle de un à un. Cela permet de gagner beaucoup de temps à nouveau. Donc, cela signifie que toutes ces techniques vraiment sympas et ces techniques ludiques de faire du planning poker ou du dimensionnement en T-shirt, quoi que vous fassiez, elles peuvent partir. Parce que vous êtes toujours là, vous êtes toujours au stade où vous expérimentez tout le temps. Et la question est alors, comment pouvez-vous estimer si vous ne l'avez jamais fait auparavant ? Ou pire encore, si personne ne l'a jamais fait auparavant dans votre entreprise, ou personne dans tout le pays, ou peut-être même personne dans le monde, n'est-ce pas ? Comment estimez-vous cela ? Et puis le développement logiciel est trop complexe, n'est-ce pas ? Euh, il est devenu si complexe en raison de la grande variété de technologies que nous avons tendance à utiliser pour fabriquer des produits, pour construire des produits, c'est l'industrie la plus complexe qui soit, n'est-ce pas ? Edgar Dijkstra, célèbre mathématicien ou informaticien, a dit, Je pense qu'en 1984, il a dit que le programmeur doit être capable de penser en termes de hiérarchies conceptuelles beaucoup plus profondes que ce qu'un seul esprit n'a jamais eu besoin d'affronter auparavant. N'est-ce pas ? Vous vous souvenez de cette pile ? Comment pouvez-vous faire cela ? Comment pouvez-vous encore maintenir ce genre de choses, n'est-ce pas ? C'est vraiment incroyablement complexe à maintenir.
[00:57:02] Euh, et cela signifie que si vous voulez construire des produits modernes, vous devez avoir une grande variété de compétences présentes dans votre façon de travailler. Euh, et ce n'est qu'un ensemble limité de toutes ces choses qui sont présentes. C'est là que ces cadres agiles d'entreprise interviennent en quelque sorte, euh, mais le fait est qu'ils n'aident pas vraiment à faire cela. Le nombre de rôles que nous avons est trop important pour s'adapter aux approches agiles traditionnelles ou même modernes.
[00:57:30] Vous devez donc trouver des moyens de contourner cela. Maintenant, euh, je vais sauter la partie sur l'agilité d'entreprise. Parce que je veux vous montrer autre chose. Et j'ai, bien qu'il n'y ait pas de temps fixe, c'est une très belle partie, mais je vais la sauter. Euh, euh, nous avons environ une heure, bien que le temps ne soit pas vraiment fixe. Euh, je veux vous montrer quelque chose, euh, euh, comment vous pouvez contourner cela. Et la chose est, nous revenons au Manifeste Agile. Euh, euh, la petite chose à propos des approches agiles d'entreprise, euh, s'il vous plaît n'y allez pas. Je peux en parler longuement, je peux en parler pendant une heure. Ils n'aident pas à devenir plus rapide dans des cycles plus courts avec des équipes plus petites, euh, et à construire des éléments plus petits, ils ajoutent de la complexité, n'est-ce pas ? Et c'est là le point parce que nous devons découvrir de nouvelles façons de développer des logiciels. Parce que le monde change et donc les façons de développer des logiciels, n'est-ce pas ? Cela signifie que vous devez toujours commencer à penser par vous-même. Cela signifie que vous devez toujours commencer à penser par vous-même. C'est ce que vous faites. Ne copiez pas simplement le modèle de quelqu'un d'autre, mais partez d'un modèle et améliorez-le, et allez au-delà de ce modèle particulier. Allez au-delà de la réalisation de projets, mais allez aussi au-delà peut-être en faisant du Scrum. Allez au-delà des rétrospectives, au-delà des sprints ou des sessions de planification ou de tout ce que vous faites, n'est-ce pas ? Vous pouvez aller plus vite que cela. Et je vais vous montrer très rapidement une façon que nous avons trouvée dans les équipes avec lesquelles j'ai travaillé, comment nous pourrions faire cela. Ce sont en fait deux recettes, deux petites recettes que vous pourriez appliquer à votre organisation. La première concerne votre organisation. Il s'agit de permettre à toute votre organisation de fonctionner comme, eh bien, disons, un seul organisme, euh, divisé en différents domaines dans lesquels vous avez construit des produits, euh, et il s'agit d'identifier où vous voulez aller, pour passer de la zone chaotique à la zone complexe, si vous pouvez trouver un point à l'horizon. Ensuite, il s'agit d'identifier dans quels domaines vous vous trouvez.
[00:59:28] Et mettre en place un petit, ce que nous appelons un conseil de portefeuille, un petit groupe de personnes qui peuvent fondamentalement décider quelles idées et demandes de fonctionnalités et tout ce que vous voulez faire qui arrive, devraient être traitées pour avancer vers le point à l'horizon. C'est donc en fait un petit groupe de personnes qui vous maintient sur la bonne voie. Ceux qui n'ont pas l'autorité de prendre toutes les décisions parce que personne ne l'a, mais, euh, pour en fait aider à guider pour rester sur la bonne voie vers le point à l'horizon. Bien que le point à l'horizon puisse changer, bien sûr. Et ensuite nous partons de là. Donc, vous devez identifier votre point à l'horizon, n'est-ce pas ? Vous devez déterminer où vous voulez aller en tant qu'entreprise. Je vais vous montrer quelques exemples. C'est un exemple, oh, c'est un exemple de base d'une entreprise de conseil agile pour laquelle je travaille, ils ont dit, nous visons à devenir la société de conseil la plus recherchée en Europe. C'est assez ambitieux, mais cela vous donne un objectif. Cela vous donne une direction où vous voulez aller, n'est-ce pas ? Euh, voici un autre exemple d'un de mes clients actuels. Leur mission est d'être à la pointe de la technologie et des expériences personnalisées pour permettre aux fournisseurs de matières premières de jouer un rôle dominant dans le domaine des services à domicile. positions parce que personne n'en a, mais pour aider à guider et à rester sur la bonne voie vers l'horizon des données. Bien que cet horizon des données puisse changer bien sûr. Et puis on part de là. Alors, vous devez identifier votre horizon de données, n'est-ce pas ? Vous devez déterminer où vous voulez aller en tant qu'entreprise. Je vais vous montrer quelques exemples. C'est un exemple, oh, c'est un exemple de base d'un cabinet de conseil agile pour lequel j'ai travaillé. Ils ont dit que nous visions à devenir le cabinet de conseil le plus recherché en Europe. C'est assez ambitieux. Mais ça vous donne un objectif, ça vous donne une direction où vous voulez aller, n'est-ce pas ? Euh, voici un autre exemple d'un de mes clients actuels. Leur mission est de prendre la tête de la technologie et des expériences personnalisées afin de permettre aux fournisseurs de matières premières de jouer un rôle dominant dans le domaine des services à domicile. C'est trop à assimiler, mais c'est leur vision, n'est-ce pas ? C'est leur idée de là où ils veulent aller. Donc tout ce qu'ils font devrait contribuer à aller vers l'horizon des données. Et puis l'étape suivante est d'identifier les domaines autour desquels vous construisez vos produits, n'est-ce pas ? Ici, ils s'intéressaient, euh, aux déchets, à l'énergie et à l'eau, n'est-ce pas ? C'est une entreprise d'énergie intelligente qui veut créer un monde meilleur, n'est-ce pas ? Ils l'ont donc divisé en trois domaines différents. La plupart des entreprises que je vois font cela en fait, elles construisent des produits autour de domaines spécifiques. Et ces domaines peuvent différer, n'est-ce pas ? Et puis l'étape suivante est que toutes les idées, les fonctionnalités, les demandes et les requêtes des clients, les requêtes de bugs, et euh, les améliorations de la qualité du code et l'inspection sécurisée, tout ce à quoi vous pouvez penser, vous pourriez le placer dans un seul panier. Et la prochaine chose que vous pourriez dire est, ok, il y a un petit groupe de personnes qui discutent de ce panier, c'est sur une base hebdomadaire. Et répond à quelques questions simples. Et ces questions simples que nous avons déjà utilisées dans plusieurs entreprises. Elles sont vraiment simples en fait. Elles sont du genre, ok, est-ce que ça aide à atteindre notre horizon de données ? Si ce n'est pas le cas, nous le jetterons, n'est-ce pas ? Nous ne dépensons pas d'énergie sur des choses que nous ne devrions pas faire. La question suivante est : est-ce réalisable ? Pouvons-nous vraiment faire ça ? Ou l'avons-nous déjà fait peut-être ? Si ce n'est pas le cas, nous l'abandonnerons, n'est-ce pas ? Nous ne le faisons pas. Il faut que ce soit réalisable. Et la question suivante est : est-ce vraiment grand ? Est-ce vague ? Est-ce trop conceptuel ? Euh, ça doit atteindre un niveau où nous pouvons réellement le gérer, où nous pouvons réellement y travailler. Si c'est trop grand, nous le renverrons à la personne qui le propose, et il ou elle devra le décomposer et revenir avec les plus petites parties. Et puis si nous avons des parties plus petites, la question suivante est : est-ce que c'est les éléments les plus urgents, sont-ce les éléments les plus urgents sur lesquels nous pouvons passer notre temps ? Si ce n'est pas le cas, nous le mettrons dans la catégorie 'peut-être un jour' et nous le réexaminerons dans environ trois à quatre mois. Et vous pouvez en fait faire cela sur un tableau ou même en ligne. C'est en fait une capture d'écran d'une réunion en ligne de ce tableau particulier chez l'un de mes clients, où ils discutent réellement de ces éléments. Et une fois que ces éléments sont approuvés, une fois qu'ils ont passé toutes ces questions et que cela peut aller très, très vite. Ainsi, la plupart des entreprises se réunissent pendant environ une heure chaque semaine avec ce conseil particulier de personnes, euh, puis elles peuvent passer à l'étape suivante. Et la question suivante est : comment vous organisez-vous pour devenir plus petit, euh, euh, pour travailler en équipes plus petites et pour construire des fonctionnalités plus petites dans des cycles plus courts. Et toujours être capable de gérer toute la complexité que le développement de logiciels vous jette ces jours-ci, vous jette à la figure. Maintenant, voici le truc. Nous sommes arrivés là où les équipes traditionnelles sont généralement séparées par différents rôles, n'est-ce pas ? Vous avez un étage dans votre bâtiment où se trouvent tous les architectes, généralement au dernier étage, puis les analystes, les designers, les développeurs, les testeurs et les personnes des opérations, ils ne communiquent pas. C'était le cas avec les équipes traditionnelles de style cascade. Agile a ajouté à cela. Que nous créons des équipes pluridisciplinaires. Toutes ces personnes sont réunies en équipe pour produire quelque chose. Maintenant, c'était une très bonne idée jusqu'à ce que nous arrivions à un point où la technologie est devenue si complexe que les équipes ne pouvaient plus la gérer. Ils devaient constamment attirer des spécialistes. Maintenant, voici le truc. Et si vous considériez le groupe de personnes capables de construire un produit particulier avec toutes les compétences nécessaires pour cela, et que vous considériez cela comme un collectif ou un flux de valeur, comme on l'appelle dans certaines approches. C'est une photo d'un groupe, un grand orchestre appelé The Nuclear Collective. Ils pouvaient jouer toutes sortes de musique et ils le font dans différents contextes, n'est-ce pas ? Ils pouvaient avoir une section de cuivres qui jouait de la soul avec un chanteur ou un pianiste et un batteur ou ils pouvaient en faire un quatuor de jazz. Ils pouvaient faire toutes sortes de choses avec ce groupe. Maintenant, dans le développement de logiciels, nous avons une situation similaire où nous avons trop de compétences nécessaires pour construire un produit, de la conception UX, de l'étude de marché aux personnes des opérations, QA, euh, des spécialistes du cloud, tout ce que vous pourriez avoir, ils appartiennent tous au même flux de valeur ou au même collectif pour construire des choses. Maintenant, ce qui est intéressant, c'est que chaque élément, s'il est suffisamment petit pour passer du tableau aux équipes, les équipes décident à partir de là comment le prendre en charge. Et ce que j'ai vu avec ces collectifs ou flux de valeur, c'est que chaque élément est pris en charge par un petit groupe de ces personnes, un petit sous-ensemble de ces personnes. Et avec chaque élément, la façon dont cette équipe plus petite est constituée, elle diffère, n'est-ce pas ? Et elle diffère tout le temps avec chaque élément de travail. Donc ça signifie qu'on a abouti à une approche où, finalement, on dit : ok, nous allons en faire encore moins, nous aurons moins de cérémonies et moins de choses superflues. Et nous arrivons à un point où nous disons, ok, chaque fois que nous prenons un élément, nous considérons que c'est le petit problème que nous allons résoudre ce jour-là. Et la deuxième recette que je vais vous montrer vous aide en fait à faire cela. C'est ce que j'appelle la recette de la micro-équipe. C'est une fois qu'un problème survient en haut de votre backlog ou de la liste que vous avez, quelqu'un de la grande majorité du flux de valeur ou du collectif dira : « Je vais prendre celui-là parce que c'est ma compétence qui est requise pour le prendre, ou peut-être que je veux apprendre quelque chose sur ce qui se passe là-bas. » Et je vais le prendre et et et quelqu'un d'une autre des micro-équipes existantes va venir et dire, tu sais quoi, je viens et je t'aide ou je veux apprendre quelque chose à ce sujet aussi. Donc tu formes une petite équipe spécifiquement conçue pour résoudre ce seul problème.
[01:06:26] Vous discutez du travail, vous faites le travail, vous le marquez comme terminé, vous vous séparez, vous rentrez chez vous et vous recommencez le lendemain ou vous restez chez vous d'ailleurs, n'est-ce pas ? Cela signifie que c'est un processus dynamique. Cela signifie que pour chaque élément de travail qui apparaît, un élément de travail apparaît, les gens arrivent, commencent à faire l'élément de travail, le terminent et rejoignent le grand groupe à nouveau. Et ça recommence encore et encore, n'est-ce pas ? Et si vous avez un groupe de personnes qui sont environ 20 à 25 personnes, peut-être même, vous pouvez prendre un certain nombre de ces éléments en parallèle, n'est-ce pas ? Et la collaboration change continuellement, cela signifie que vous apprenez très vite des autres. Je vais vous montrer quelques images de ces micro-équipes en action. C'est typiquement, euh, c'est un développeur et un gars des opérations assis ensemble travaillant sur un élément. Euh, c'est un ensemble différent, ce sont deux développeurs et un testeur. Bien sûr, le testeur doit se lever parce que, eh bien, tester est facile, n'est-ce pas ? Hmm. Ça ne l'est pas. Euh, euh, c'est encore une fois, deux développeurs travaillant sur un élément particulier. Ici, vous voyez, euh, en fait trois architectes dans la vie réelle, euh, et ils rient en fait parce que quelqu'un a probablement cassé leur code, et ils travaillent sur une infrastructure ici, n'est-ce pas ? Ici, vous voyez, euh, qu'est-ce que c'est ? C'est un architecte et un développeur. Voici l'architecte qui prie pour que le travail du développeur fonctionne, n'est-ce pas ? Euh, les architectes sourient, voyez ? Désolé.
[01:07:49] Euh, et, euh, vous voyez toutes sortes de configurations différentes, euh, qu'ils travaillent à des moments précis ensemble. Et ça change tout le temps, donc ça devient vraiment organique. Et ce qui est amusant, c'est que j'ai expérimenté cette configuration pendant, disons, les six dernières années. C'est que vous n'avez pas besoin de l'organiser. C'est juste ce grand groupe de personnes où les éléments entrent dans leur, leur, euh, leur champ d'intérêt et ils les prennent en charge et s'organisent eux-mêmes. Euh, s'ils veulent faire des rétros, très bien. S'ils veulent des stand-ups, s'ils veulent des réunions de planification de sprint, eh bien, vous n'êtes pas obligé d'avoir des sprints. Vous pourriez si vous voulez, mais c'est à l'équipe de décider, n'est-ce pas ? Et ce qui est intéressant, c'est que si vous travaillez en équipes de deux ou trois personnes, et que cela change tout le temps par rapport à ce groupe plus grand, cela présente en fait un certain nombre d'avantages. Parce qu'il n'y a plus besoin de leadership central. C'est le flux de valeur ou le collectif qui le prend en charge. La communication est beaucoup plus facile car pour tout ce sur quoi vous travaillez, chaque élément de travail, il n'y a que deux ou trois personnes qui y travaillent. Cela signifie que vous pouvez travailler au moment et à l'endroit qui conviennent à ces deux ou trois personnes. Cela signifie que si je travaille avec quelqu'un de mon équipe, ce que j'ai fait aujourd'hui, nous avons travaillé, eh bien, ce jour encore, tout le monde travaille à domicile. Mais nous pourrions en fait aller au bureau parce qu'il y a deux personnes autorisées au bureau, s'asseoir dans une pièce pendant une journée, travailler dessus, rentrer chez nous et se séparer à nouveau et faire le lendemain. Cela signifie qu'il n'est pas nécessaire d'avoir des sprints. Ils deviennent redondants en fait. Il en va de même pour les estimations, les raffinements, et vous pouvez travailler partout. Et les progrès sont quotidiens, mais vous devez automatiser les choses à ce sujet, n'est-ce pas ? Donc c'est essentiellement ce que je veux vous montrer. Si vous faites tout cela, cela signifie que vous pouvez arrêter de faire des projets. Mais vous pouvez aussi arrêter de faire les approches agiles plus traditionnelles, car beaucoup de gens ont du mal à les intégrer dans le monde moderne. Donc, en rétrospective, je vais faire une rétrospective très rapidement parce que j'ai passé environ 10 minutes de plus que ce que j'espérais. J'espère que ça ne vous dérange pas, euh, et j'espère que vous me suivez toujours. Donc, nous vivons dans un monde où nous sommes principalement dans des zones complexes et chaotiques. Donc, nous vivons dans un monde où nous sommes principalement dans des zones complexes et chaotiques. Parce que tout change si vite. Non seulement à travers des cas imprévisibles comme le Corona, mais aussi parce que la technologie évolue très, très rapidement. Cela signifie que nous avons dépassé le point de non-retour. Cela signifie également que les approches agiles traditionnelles ne seront pas adaptées pour maximiser ce que vous devez faire maintenant. Et ce que vous devez faire maintenant, c'est en fait construire des fonctionnalités plus petites, arrêter de faire des projets. Faites-le dans des cycles encore plus courts afin que vous puissiez être encore plus agile que vous ne l'êtes probablement en ce moment. Dans des équipes plus petites, euh, et et elles peuvent devenir auto-organisées et autonomes, à l'exception de certaines limites, elles peuvent tout faire elles-mêmes. Cela signifie qu'en période de Corona, où nous sommes tous assis dans des endroits différents, dans des lieux différents, je suis dans mon appartement à Amsterdam maintenant, par exemple, et je travaille avec un collègue qui vit à Haarlem aujourd'hui. Donc, euh, ça s'adapte beaucoup mieux. Plus les équipes sont petites, mieux vous pouvez travailler ensemble. Et plus vite vous pouvez grandir. Et la quatrième partie est de construire des composants plus petits, c'est-à-dire de construire dans des architectures de microservices. Mais je, je pourrais faire une autre conférence à ce sujet. J'écris actuellement un livre à ce sujet, mais Euh, et le point principal est que vous pouvez seulement, vous pouvez en arriver à résoudre un seul petit problème chaque jour. C'est comme ça que mes équipes fonctionnent. Et nous ne résolvons que ce seul, ce seul petit problème. Et la recette pour cela est : choisissez le problème, euh, créez une petite équipe parmi les personnes qui veulent se joindre, discutez du travail, faites le travail, terminez-le, mettez-le dans le pipeline, dissolvez l'équipe et répétez cette recette très simple quotidiennement.
[01:11:32] À partir de là, vous pouvez faire de petits pas. Et si vous pensez que votre organisation est trop grande ou que vous ne pouvez pas la changer ou que vous vous dites, oh, nous ne pourrons jamais la changer. Les managers ne travailleront pas avec nous. En fait, changer les choses est très, très simple.
[01:11:47] Parce que il n'y a qu'une seule personne qui allumera le changement si vous en avez besoin et que vous êtes la seule personne qui peut allumer le changement, n'est-ce pas ? Si vous voulez changer quelque chose, commencez à le changer. Commencez à vous comporter différemment parce que si vous avez fait ce que vous avez toujours fait, vous obtiendrez ce que vous avez toujours obtenu. Et si vous voulez le changer, vous devez le faire. Euh, au fait, dans cette industrie, si vous faites ça, il n'y a qu'une seule chose. Vous ne pouvez jamais arrêter d'apprendre. Parce que nous allons trop vite. Le monde avance trop vite. La technologie avance beaucoup trop vite. Donc vous devez apprendre continuellement. Euh, peut-être encore plus important est que n'oubliez jamais de vous amuser. Oh, et une dernière chose avant de conclure, c'est que, euh, s'il vous plaît, arrêtez de faire des projets. Parce que les projets n'ont jamais fonctionné dans cette industrie. Ils ne fonctionneront jamais dans cette industrie. Merci beaucoup de votre écoute. Je vais vous montrer mes, euh, mes données une fois de plus. Voici donc mon site web, mon compte LinkedIn, mon compte Twitter. N'hésitez pas à vous connecter sur LinkedIn, euh, c'est un moyen facile de se connecter. Twitter aussi. Mon e-mail est là, donc si vous avez d'autres questions, euh, eh bien, dans ce cas, j'espère avoir de vos nouvelles bientôt et je resterai pour une séance de questions-réponses. Je ne suis pas vraiment sûr de comment ça fonctionne sur la plateforme à distance, mais je serai là, n'est-ce pas ? Merci beaucoup de votre écoute et j'espère vous revoir bientôt.

🔹 Suivez-nous sur LinkedIn : FlowCon France

🔹 Site Web FlowCon : flowcon.io

Voir sur YouTube Playlist Complète 2020 Retour aux Archives 2020

Copyright © FlowCon France | This template is made with by Colorlib