Allan Kelly

Comme je le disais un peu avant, j'ai une présentation que je fais depuis quelques années appelée Pas de Projets, que certains d'entre vous dans cette salle ont déjà vue, je sais. Et je parle de pourquoi le modèle de projet en tant qu'outil de gestion est mal adapté à l'arène du développement logiciel numérique du 21ème siècle. Surtout quand on pense agile.
L'une des critiques valables de cette présentation est que, bien que je vous explique ce qui ne va pas avec les projets, cette présentation seule ne vous dit pas vraiment quoi faire à la place. Je pense Pour moi, une partie de la réponse est simplement d'arrêter d'utiliser le mot projet.
Cette présentation fait en quelque sorte suite à cette idée de pas de projet. Donc, si vous avez vu Pas de Projets, ceci devrait la compléter. Si ce n'est pas le cas, ceci devrait se suffire à lui-même. Peut-être voudrez-vous aller chercher Pas de Projets après cela. On peut la trouver en ligne à quelques endroits après cette présentation.
Une des raisons pour lesquelles le modèle de projet n'est pas adapté est que quels sont les critères de réussite d'un projet ?
Dans les délais, dans le budget, à temps, ou fonctionnalités, pas de valeur. Nous n'incorporons pas vraiment la valeur et la réflexion sur la fourniture de bénéfices commerciaux à nos clients, nos utilisateurs. Alors parlons de la valeur, ou pour le dire autrement, combien, et quand ? Parce que c'est la question qu'on nous pose, n'est-ce pas ? Combien, quand ?
Combien d'entre vous se sont vu poser cette question ? Combien d'entre vous ont dû débattre de cette question avec des gens ?
Ce projet est-il adapté à l'Agile ou la méthode Waterfall est-elle meilleure ici ? Et vous savez bien que la personne qui pose cette question est un adepte inconditionnel de la méthode Waterfall, n'est-ce pas ? Ou, puisque nous sommes à une conférence Lean Kanban, peut-être la question que vous vous posez est : ce projet est-il adapté au Kanban ? Ou est-ce que Scrum serait mieux ici ? Oui, oui, oui. J'ai une réponse très simple à ces deux questions. Qui s'en soucie ? Qui se soucie de ce qui est adapté à ce projet ? Parce qu'après tout, nous vivons dans un monde post-vérité. Qu'est-ce qui est juste ? Depuis quand nous soucions-nous de ce qui est juste quand il s'agit d'architecture et de choisir Oracle comme base de données ? La vraie question est : lequel rapportera le plus d'argent ? Lequel apportera plus de valeur en termes de bénéfices commerciaux ? Et bien que je parle d'argent, je sais que quand on dit valeur, il est très facile de penser à l'argent. Et, vous savez, l'argent est le meilleur retour d'information, n'est-ce pas ? Quand vous recevez de l'argent en retour, vous pouvez faire des choses avec. Nous parlons vraiment de... bénéfice commercial, quelque chose que votre entreprise ou votre organisation – parce que vous pourriez être une organisation à but non lucratif, vous pourriez être dans le secteur public, quelque chose comme ça – votre organisation considère comme un bénéfice commercial précieux, raccourci par le mot valeur, et donc laquelle, quelle approche nous donnera plus de valeur, plus d'argent, et la réponse est très simple agile, et je ne fais pas vraiment de différence avec le lean. Je pense que le lean et le Kanban font tous partie de cette grande famille agile. Je sais que certaines personnes aiment les différencier, mais je les vois comme faisant tous partie de la même famille agile, et certainement quand il s'agit de la question Waterfall, je pense qu'il est mathématiquement prouvable que l'agile apportera plus de bénéfices commerciaux, plus d'argent, un meilleur retour sur investissement. Je peux vous montrer quelques diapositives à ce sujet une autre fois, mais pour l'instant, continuons.
Nous devons penser à la valeur que nous livrons plutôt qu'au coût. Le modèle de gestion de projet se préoccupe beaucoup du coût. Combien cela coûtera-t-il ? Nous devons nous placer du côté de la valeur dans l'équation. Combien de valeur, combien de bénéfices commerciaux apportons-nous à l'organisation ? Si vous êtes du côté des coûts, si vous argumentez d'un point de vue coût, il y a toujours quelqu'un quelque part qui promettra de le faire pour moins d'argent que vous. Que cette personne puisse tenir sa promesse est une question ouverte, mais je vous garantis qu'il y a quelqu'un quelque part qui dira pouvoir le faire pour moins d'argent. Nous devons nous placer du côté de la valeur dans l'équation et montrer que nous apportons plus de valeur à nos entreprises, à nos organisations. Valeur livrée par rapport au coût de construction, pour paraphraser le Manifeste Agile. Ou, comme le dit mon bon ami Warren, le prix est ce que vous payez, la valeur est ce que vous obtenez. Si vous parlez constamment de combien va être dépensé, vous allez vous retrouver dans une position difficile. Placez-vous du côté de la valeur dans l'équation. Alors voyons à quel point vous êtes bons. Disons que nous avons deux histoires ici.
avec une certaine valeur et un certain temps de livraison.
Qui aimerait faire l'histoire un en premier ?
Des mains levées pour l'histoire un ? Oui, il y a quelques mains qui se lèvent là. Vous savez, quatre semaines, vous pourriez faire un retour rapide sur investissement. Histoire deux, un peu plus longue, plus d'argent. Quelqu'un pour l'histoire deux ?
Quelques mains de plus là, oui, et oui, et vous savez, Scrum est assez clair : faites d'abord la plus haute valeur commerciale, donc nous devrions faire la deux, n'est-ce pas ? mon ami Chris Matts aime décrire le développement logiciel comme un processus d'arrivée d'informations, alors donnons-vous plus d'informations
L'histoire un est pour Halloween. L'histoire deux est pour Noël.
Qui aimerait faire l'histoire un ?
Quelques mains, oui ? Et qui est pour l'histoire deux ?
Vous pensez qu'Halloween est en cours, Noël arrive. Nous sommes le 25 novembre, n'est-ce pas ?
Hmm. Le but de cette présentation, faisons comme si nous étions le 1er septembre.
Qui est pour l'histoire un ?
Oh, quelques mains de plus. Histoire deux ? Oui, d'accord. Faisons l'analyse.
J'appelle cela une courbe de valeur temporelle. Andy Carmichael, qui est ici quelque part, a dessiné des courbes similaires, et nous nous inspirons tous les deux des travaux de Don Reinertsen, dont je m'excuse, je ne dis pas que tu as raison, Don, je trébuche toujours à ce point. L'idée de combien d'argent, combien de valeur vous pouvez livrer à différents moments dans le temps.
Voici notre application du Père Noël. Si nous la livrons le 1er septembre, nous allons obtenir un peu plus d'un million de dollars. La livrer le 15 septembre, un peu plus d'un million. Ensuite, vous commencez à perdre de l'argent. Si vous la livrez après le 27 octobre, le retour diminue assez rapidement. La livrer le 5 janvier. Vous savez, il n'y a que les enfants russes alors. Vous savez, ce sont les seuls qui veulent des cadeaux de Noël à ce moment-là.
Voilà.
Il y a six semaines de développement. Faisons semblant de tout savoir. Cela prend six semaines, d'accord ? Ne parlons pas de l'absence d'estimations. Voyez, une ligne de six semaines est là. Si c'est le 1er septembre et que vous commencez à développer aujourd'hui et que cela vous prend les six semaines que vous pensez, vous ne pouvez pas réaliser les 1 025 000 $ que cette application promet de livrer. C'est impossible parce qu'au moment où vous atteignez la date de livraison, certaines de ces ventes auront disparu.
N'est-ce pas ? C'est le temps que ça prend. Je vis simplement chaque jour. Considérez cela comme aller au supermarché, et quand vous prenez un paquet de saucisses ou un paquet de poisson ou autre chose, vous trouverez probablement soit une date de péremption ou peut-être une date limite de consommation ou peut-être les deux. Cette application est à livrer de préférence avant le 27 octobre. La livrer à une date ultérieure signifie qu'elle n'aura pas aussi bon goût. Une partie du goût, une partie de la valeur de cette application est perdue si vous la livrez après cette date.
Cependant, si vous livrez cette application après le 5 janvier, plus de valeur, plus de goût. Il n'y a aucun intérêt à la livrer à ce moment-là. C'est la date limite de consommation. Si vous la livrez après cette date, vous allez avoir une intoxication alimentaire. D'accord ?
Voici l'application Halloween. Profil similaire, mais remarquez qu'il y a une chute très brutale ici. Une fois de plus, quatre semaines pour développer. Nous ne pouvons pas réaliser toute la valeur qui est livrée. Les quatre semaines pour livrer, nous allons perdre une partie de cette valeur.
Celles que vous utilisez comme date limite de consommation, ce sont les dates de péremption.
Alors, que voulez-vous faire ?
Voilà, ça aide. Je ne pense pas, mais si vous voulez. Encore une fois. Souhaitez-vous, passons en revue les options ici. Qui aimerait faire l'application Halloween puis l'application Santa ?
Deux, trois, quatre. Qui aimerait faire l'application Santa puis l'application Halloween ? Un. La plupart d'entre vous ne peuvent pas décider, n'est-ce pas ?
Nous pourrions faire Halloween et oublier Santa. Au moment où nous aurons construit Halloween, Santa, vous savez, nous aurons perdu beaucoup de valeur sur Santa. Mais nous pourrions faire Santa et oublier Halloween. Oh, il y a beaucoup de mains levées.
Il pourrait y avoir de la valeur là-dedans. Nous pouvons changer les estimations.
Je sais que nous rions. Je sais aussi que je ne suis pas le seul à avoir entendu cela comme une suggestion réaliste. Je suis sûr que certains d'entre vous l'ont entendu. Pensez-vous que changer les estimations aiderait ?
Pas du tout. À moins, bien sûr, que vous dirigiez une de ces équipes Scrum mythiques qui croient en l'engagement. Et quand les estimations sont réduites, ce n'est pas engagé ! Oui, je ne crois pas en l'engagement.
Pourrait changer les estimations. Je pense que c'est une technique populaire auprès des sous-traitants. Et plus le sous-traitant est éloigné, plus il est probable qu'il le fasse parce qu'il ne se fera pas prendre. Nous pourrions faire les deux et prier.
Quelqu'un pour ça ?
D'accord, il y a quelques chefs de produit dans la salle.
C'est l'option des personnes qui n'aiment vraiment pas limiter le travail en cours. Ne pourrions-nous pas les faire toutes les deux en parallèle ?
D'autres suggestions ?
Quelque chose que j'ai oublié ?
Qu'est-ce que c'est ?
Oublier tout. Oui, allez dépenser l'argent pour quelque chose de complètement différent. Qu'est-ce que c'est ?
Quoi ? Ne rien faire. Ne rien faire ?
Oui.
Réduire les exigences, réduire le périmètre. Oui, oui, oui, ce serait la manière agile de le faire. Notre client est un peu épineux. Allez, une autre.
Application de Pâques.
Il y a une autre suggestion qui est généralement proposée à ce stade.
Particulièrement les développeurs ou les managers de développeurs pensent que c'est une option vraiment intelligente.
Deux équipes, faire les deux. En divisant nos ressources, les deux iront plus lentement. Certaines personnes à ce stade suggèrent que nous pourrions réutiliser l'application. Est-ce que cela ne semble pas une bonne idée ? Parce que Halloween et Noël, ils sont un peu similaires, non ? Ils concernent tous les deux les cadeaux et les choses du genre.
Nous pouvons aussi ajouter plus de personnes. Mais combien de temps faut-il pour embaucher quelqu'un à Paris ? Trois mois, quatre mois, six ? Quatre mois. Oui. Si vous n'étiez pas si pointilleux sur qui vous embauchez, il y a plein de gens que vous pourriez simplement avoir. Ce type qui pousse les rues.
Donc, nous arrivons à cette question de réutilisation.
La réutilisation est proposée, mais il y a un vieux tas de questions qui vont avec la réutilisation. Par exemple, quelle quantité de ces applications peut être réutilisée ? Combien pouvons-nous vraiment réutiliser ici ?
Combien d'Halloween peut être réutilisé ? Combien Santa peut-il prendre d'Halloween ? Et cela soulève également la question de la propriété intellectuelle. Vous savez, il y a plein de cabinets de conseil dans le monde qui gagnent vraiment bien leur vie en construisant un produit pour cette entreprise-ci, et ils leur donnent tout le code source, puis les mêmes personnes vont construire un produit très similaire ici pour une autre sorte d'entreprise. Vous ne pouvez pas vraiment prendre le code d'Alstrom et le donner à Siemens. Ils se fâchent.
Nous arrivons aussi à la question de savoir combien de temps la réutilisation ajoute-t-elle ?
Si vous écrivez quelque chose pour qu'il soit réutilisable, combien de temps cela ajoute-t-il à votre livraison ? Quelqu'un sait ? Quelqu'un a-t-il déjà vu une étude sur ce sujet ? C'est en fait un chiffre très difficile à trouver. Je cite généralement Fred Brooks, qui remonte à 1974. Fred Brooks dit que écrire pour la réutilisation prend trois fois plus de temps qu'écrire pour un usage unique. Ce qui signifie que vous devez être garanti que vous allez utiliser cette chose quatre fois avant de réaliser un profit. Un ami à moi, Kevin Henney, dit qu'il a vu un chiffre de 1,8 cité, mais il ne trouve pas de référence. C'est un peu mieux. Mais une quantité effroyable de code écrit pour être réutilisé n'est jamais réutilisé. Vous payez le coût de la réutilisation, qu'il soit de 1,8 ou de 3, mais vous ne bénéficiez jamais de la réutilisation. Et en attendant, écrire pour la réutilisation prend plus de temps, donc vous repoussez cette date de livraison initiale.
Alors, combien d'argent perdons-nous ? Si nous repoussons la date de livraison initiale pour le projet de Noël, ils obtiennent quelque chose de réutilisable pour Halloween ou vice versa, combien perdons-nous parce que la première application est livrée plus tard ? comme écriture pour un usage unique, ce qui signifie que vous devez être garanti d'utiliser cette chose quatre fois avant de réaliser un profit. Un ami à moi, Kevin Henney, dit avoir vu un chiffre de 1,8 cité, mais il ne trouve pas de référence. C'est un peu mieux. Mais une grande quantité de code écrit pour être réutilisé n'est jamais réutilisée. Vous payez le coût de la réutilisation, que ce soit 1,8 ou 3, mais vous ne bénéficiez jamais de la réutilisation. Et en attendant, écrire pour la réutilisation prend plus de temps, donc vous repoussez cette date de livraison initiale.
Alors, combien d'argent perdons-nous ? Si nous repoussons la date de livraison initiale pour que le Père Noël obtienne quelque chose de réutilisable pour Halloween ou vice versa, combien perdons-nous parce que la première application est livrée en retard ?
Et combien gagnons-nous en livrant l'autre plus tôt ?
Mais plus important encore, lorsque vous visez du code réutilisable, vous augmentez le risque pour les deux. Si vous décidez qu'il y a un composant ici qui peut être utilisé dans les deux applications, et que vous vous mettez à construire ce composant, ces deux applications dépendent de cette seule chose. Il y a un risque élevé pour les deux. Si vous voulez réduire le risque, vous les séparez.
Donc je ne pense pas que la réutilisation soit une bonne approche ici. Alors, nous allons rayer cette option. Regardons à nouveau notre modèle.
Si nous faisons le Père Noël en premier,
Nous pouvons gagner 1 025 000 dollars. Nous ne pouvons pas gagner les 1 050 000 dollars complets parce que nous ne pouvons pas l'avoir prêt avant le 13 octobre. Par conséquent, nous devons perdre 35 000 dollars. Tout business case qui dépend de gagner exactement ou plus de 1 050 000 dollars ne tient pas la route. Cependant, si nous sommes occupés à construire le Père Noël, Halloween ne nous rapportera zéro dollar. Par conséquent, le total est... un peu plus d'un million. Cependant,
Si vous construisez Halloween en premier, vous ne pouvez pas l'avoir prêt d'ici le 29 septembre. Ou vous ne pouvez pas l'avoir prêt avant le 29 septembre. Donc vous perdez toujours 15 000 dollars, mais vous gagnez 340 000 dollars.
Et dans le temps restant, vous pouvez livrer le Père Noël. Maintenant, le Père Noël ne vous rapportera pas un million de dollars. Il ne vous rapportera que 800 000 dollars parce que vous ne l'avez pas sur le marché au moment où vous en avez le plus besoin. Cependant, malgré la perte de 225 000 dollars en moins, vous pouvez toujours gagner plus. Si vous faites le Père Noël, puis Halloween, vous gagnez 1 140 000 dollars. Si vous faites le Père Noël, vous ne gagnez que 1 025 000 dollars. N'est-ce pas ?
Mais vous ne pouvez faire cela que si vous avez une idée de combien d'argent vous allez gagner à différentes dates.
C'est ce que Don appelle le coût d'opportunité du retard.
Quand, peut-être que c'est juste moi, mais je trouve que lorsque vous présentez cette idée aux gens, peut-être parce que nous parlons de coût, les gens... Sont très rapides à comprendre les coûts supplémentaires que vous encourrez parce que vous êtes en retard. Donc du personnel temporaire pendant que vous exécutez un processus manuellement ou avant de pouvoir embaucher, licencier des gens. Payer. pour l'expédition prioritaire, les amendes de pénalité, en particulier dans un environnement réglementaire, les coûts supplémentaires que vous encourrez parce que vous étiez en retard. Cependant, il y a la valeur abandonnée, l'argent que vous auriez pu gagner si vous aviez eu cette chose sur le marché plus tôt. Donc les opportunités de revenus perdus, ne pas être sur le marché, ne pas être en vente au moment clé du marché de Noël, du marché d'Halloween, du marché de Pâques. Ne pas être prêt à une date critique. Ne pas être sur le marché avant vos concurrents. L'avantage du premier entrant.
La valeur abandonnée, je pense que nous pouvons nous attendre à ce qu'elle soit bien plus grande que le coût supplémentaire que vous encourrez. Mais nous ne le savons que si nous connaissons le profil de la valeur par rapport au temps. Au fait, comment je m'en sors pour le temps ?
Vous connaissez le vieux dicton, le temps c'est de l'argent ? Complètement vrai. Plus de temps égale plus de coûts. Nous comprenons tous cela. Mais il est également vrai que plus de temps signifie moins de revenus. Plus de temps à construire cette chose signifie qu'elle sera sur le marché pendant moins de temps. Plus de temps à construire ceci signifie que nos concurrents peuvent prendre de l'avance sur nous. Plus de temps à construire cette chose peut signifier que nous ratons une date cruciale.
Habituellement, il y a des exceptions, les revenus sont inversement proportionnels au temps de livraison. Une livraison plus tardive signifie moins de revenus.
J'ai dit, l'homme lui-même est assis ici. C'est l'étude originale.
Je ne sais pas.
Un retard de six mois peut valoir 33 % de vos profits totaux.
C'est beaucoup d'argent. Six mois. Qu'est-ce que c'était ? Il a fallu 18 mois à Apple pour construire l'iPad.
Il y a un examen plus détaillé et approfondi dans le livre de Don ici. Parlez à l'homme vous-même. Ce à quoi cela mène, c'est que nous pensons aux délais comme des choses fixes et ils ne le sont pas.
Les délais sont analogiques. Les délais ne sont pas binaires. Les délais ne sont pas des dates tout ou rien. Les délais ont différentes valeurs ou les dates de livraison ont différentes valeurs, différentes dates ont différentes valeurs. Donc le délai est analogique. Et je peux le prouver assez simplement. Nous allons le faire dans un instant.
Avez-vous déjà été confronté à cela ? Quelqu'un vient, doit avoir ceci, j'en ai besoin pour hier.
Si vous êtes confronté à une telle personne, quelle est la bonne réponse ?
Quelle est la bonne réponse ? Qu'est-ce que c'est ?
Vous êtes là ?
C'est très impoli. Non, face à cette situation, nous avons la technologie. Enfin, nous l'avons en Angleterre de toute façon. Vous connaissez tous cela ? Machine à remonter le temps, oui. Nous retournons simplement dans le temps à une date où nous pouvons le construire pour qu'il soit prêt à la date demandée. Oui, vous y êtes. Donc, vous avez des machines à remonter le temps en France, n'est-ce pas ?
Quelqu'un hoche la tête, quelqu'un secoue la tête là. Pensez à ce profil de valeur temporelle. Ce que nous disons, c'est qu'il en avait besoin hier. Toute la valeur s'est accumulée hier. Aujourd'hui, il n'y a aucune valeur. La valeur était hier. Sans machine à remonter le temps, vous ne pouvez pas revenir en arrière et capturer cette valeur. Donc mettez fin à la conversation. Bof.
La date de péremption était hier. La date limite de consommation est aujourd'hui et vous ne l'avez pas. Alors, oh là là, je n'ai pas de TARDIS, mais peut-être que je peux vous obtenir quelque chose pour demain. Est-ce que c'est ce que vous dites ? Est-ce que c'est ce que vos développeurs reviennent dire ? Je vais travailler toute la nuit. Je vais me donner à fond. Je vais faire l'impossible. C'est ce qui se passe, n'est-ce pas ? Oui. Et que dit l'autre personne ?
Génial. Je savais que je pouvais compter sur vous.
Mais si toute la valeur a été accumulée hier et qu'elle est partie, face à quelqu'un qui dit, j'en ai besoin pour hier, ce n'est pas une conversation très utile parce que vous ne pouvez pas revenir en arrière. La question doit être, eh bien, que pouvons-nous faire ? Si la valeur a été accumulée hier, elle est partie, avançons, autre chose. S'il y a encore de la valeur, cela peut valoir la peine de le faire, mais nous devons comprendre quelle est cette valeur.
Je suis assez rapide dans cette présentation. Je ne sais pas pourquoi je vais si vite aujourd'hui.
Le temps, c'est de l'argent, oui. J'ai l'impression de filer à toute allure.
Un petit peu tôt vaut beaucoup plus, vaut plus qu'un beaucoup plus tard.
Même des entreprises comme Apple le savent. Vous souvenez-vous du premier iPhone ?
Oui, 2,5G. Dans un monde qui devenait un monde 3G, le premier iPhone était un téléphone 2,5G avec une autonomie de combien ? Quelques heures. Il n'avait même pas le couper-coller. Oui, même Apple, qui est présenté comme un grand exemple d'entreprises qui ne créent que des produits parfaits, crée des produits et les améliore, ils produisent quelque chose maintenant. Ils auraient pu attendre une autre année pour l'iPhone, mais ils pouvaient avoir le beurre et l'argent du beurre en livrant quelque chose maintenant, en obtenant des revenus et en faisant en sorte que toutes ces personnes mettent à niveau dans un an. Donc la première leçon est un petit peu de quelque chose maintenant vaut plus qu'un beaucoup plus tard Je suis sûr que certains d'entre vous ont fait face à des responsables produit, des propriétaires de produit, qui veulent tout et ne voient aucun intérêt à ce que vous livriez un petit peu de cela. Et la réponse agile habituelle est, si nous livrons un petit peu, vous pouvez faire fonctionner ces boucles de rétroaction et découvrir ce que vos clients veulent. C'est la réponse habituelle. Réponse agile, n'est-ce pas ? Mais en vérité, ces personnes, ces propriétaires de produit, ces responsables produit, neuf fois sur dix, sont convaincues qu'elles savent ce que le client veut, et elles sont convaincues qu'elles peuvent donner au client ce qu'il veut si seulement vous leur donnez tout. Donc la réponse habituelle, vous savez, eh bien, nous pouvons faire fonctionner les boucles de rétroaction, ne tend pas à avoir beaucoup de poids auprès d'eux. Peut-être que parler d'argent à la place pourrait marcher.
La deuxième leçon est, connaissez le profil de la valeur temporelle ? Quelle est la valeur de cette chose si vous la livriez demain ? Quelle est la valeur de cette chose si vous la livriez la semaine prochaine, le mois prochain, dans six mois ? Si vous connaissez le profil de la valeur temporelle, alors vous pouvez concevoir en fonction de ce profil. La plupart d'entre vous, je suppose, êtes des ingénieurs. C'est ce que font les ingénieurs. On vous donne un problème avec certaines contraintes et vous créez une solution dans ces contraintes. Étant donné une contrainte d'une semaine, vous créerez une solution différente que si vous aviez une contrainte d'un an. C'est ça, l'ingénierie. Nous obtenons les contraintes, nous construisons dans ces contraintes. Et il y a un compromis. Différentes dates entraînent un produit arrivant sur le marché à différentes valeurs. Vous ne capturerez peut-être pas toute la valeur avec votre première version, mais vous en obtiendrez une partie.
La troisième. Troisième leçon, les délais sont élastiques par la valeur. Les délais ne sont pas définitifs. Bien sûr, il y a certains délais définitifs, vous savez, où la valeur disparaît simplement du jour au lendemain. Mais en général, les délais sont élastiques par la valeur. Vous pouvez avoir des livraisons plus tardives, vous pouvez aussi avoir des livraisons anticipées. Voilà une idée nouvelle pour vous.
Un problème. Comment connaissez-vous la valeur de ce que vous construisez ? Confronté à un propriétaire de produit portant des user stories, comment connaissez-vous la valeur de ces stories ?
Est-ce que quelqu'un attribue de la valeur à vos user stories ?
Essayons une question plus simple. Est-ce que quelqu'un attribue des estimations d'effort aux user stories ?
Il y a deux personnes qui lèvent la main, trois, quatre, oui ? C'est une pratique très courante d'attribuer des estimations d'effort aux user stories, n'est-ce pas ? Oui ? Combien de personnes attribuent de la valeur aux user stories ?
Quelqu'un secoue la main. Une personne a levé la main. Vraiment, oui ? Vous voyez très rarement des exigences directement liées à la valeur. Les gens peuvent parler d'un projet, voici nos merveilleuses exigences, et la valeur totale de tout cela est un grand nombre ici. Si nous travaillons dans un système de flux avec beaucoup de petites stories passant par le système, si nous nous attendons à ce que les développeurs mettent des estimations d'effort sur les stories,
ne devrions-nous pas nous attendre à ce que le côté business, les propriétaires de produit, mettent une sorte d'estimation de valeur là-dessus ?
Ce serait bien si nous avions le vrai chiffre. Mais vous savez quoi ? Si vous faites l'analyse financière la plus détaillée, que vous sortez vos tableurs et que vous triturez tous les chiffres et que vous mettez des valeurs sur ces stories, vous pouvez encore faire face à des gens qui disent, vous savez quoi ? Je ne pense pas que ce chiffre soit correct. Avez-vous pris en compte ? Avez-vous pris en compte le taux d'inflation anticipé ? Et même si vous faites l'analyse la plus détaillée, les gens peuvent encore revenir vers vous et dire, je ne suis pas sûr de votre chiffre ici parce que... Ma réponse, enfin, une réponse est simplement de demander à vos parties prenantes. Faites le tour des personnes qui veulent ces choses et demandez, combien cela vaut-il ? Et s'ils ne peuvent pas mettre un chiffre dessus, obtenez une déclaration. Et une autre, comme je l'ai dit, faites l'analyse.
Ou estimez. Si l'estimation est bonne pour les développeurs et l'effort, pourquoi l'estimation ne serait-elle pas bonne pour la valeur ? Donc j'appelle ça le poker de valeur, et vous y jouez à peu près de la même manière que vous avez vu le planning poker. Ceci est une photo, je ne pense pas que vous puissiez bien la voir là.
Ceci est une photo de quelques user stories disposées dans un cabinet d'avocats à Londres. Nous avons pris une user story, quelque part par ici en fait, et nous lui avons arbitrairement attribué 10 000 points business. Parfois je les appelle des points business. Parfois je les appelle des francs français. Parfois je les appelle des shillings américains. Parfois je les appelle des guilders de Paulist ou, vous savez, peu importe.
Et ensuite le propriétaire de produit a lu les user stories. Les parties prenantes, dans ce cas un client externe, ont posé quelques questions sur l'histoire, et ils avaient leurs cartes de planning poker, et ils ont joué leurs cartes de planning poker. Mais au lieu de points d'effort ou de story points, ces cartes étaient libellées nominalement en milliers de points métiers. Donc, s'ils jouaient une carte de cinq, c'était 5 000 points métiers. S'ils jouaient une carte de vingt, c'était 20 000 points métiers. Et tout comme nous le faisons avec le planning poker et l'effort, nous avons annoncé les chiffres, nous en avons discuté, nous nous sommes mis d'accord, généralement en faisant une moyenne, sur une réponse. Et nous avons produit une liste d'histoires avec une valeur associée. Une valeur nominale, c'est suffisant, c'est le classement relatif que nous voulons connaître : quelle est la valeur de ces éléments les uns par rapport aux autres, c'est la première étape. Une fois que vous avez attribué une valeur à ces histoires, il devient beaucoup plus facile de dire : voici une histoire que nous avons évaluée à 5 000 points métiers, si nous la livrons plus tard, la valeur diminue-t-elle ? Si nous la livrons plus tôt, la valeur augmente-t-elle ? un effort où nous avons appelé les chiffres dont nous avons parlé, nous nous sommes mis d'accord sur une moyenne généralement une réponse et nous avons produit une liste d'histoires avec une valeur associée
valeur nominale, c'est suffisant, c'est un classement relatif ce que nous voulons savoir, c'est quelle est la valeur de ces choses les unes par rapport aux autres, c'est la première étape
Une fois que vous avez attribué une valeur à ces histoires, il devient beaucoup plus facile de dire, voici une histoire que nous avons évaluée à 5 000 points business. Si nous la livrons plus tard, la valeur diminue-t-elle ? Si nous la livrons plus tôt, la valeur augmente-t-elle ?
Vous en avez peut-être une, prenez celle-ci, 4 000. Il y en a une ici, 8 000. Si ces deux choses, si elles ont le même profil, elles ne changent pas du tout leur valeur, bien sûr, faites d'abord les 8 000. Mais vous savez quoi ? Cette histoire de 4 000, Peut-être qu'elle est inférieure à celle de 8 000, mais si cette histoire de 4 000 va décliner, disparaître, se dégrader rapidement, et que celle de 8 000 va maintenir sa valeur, il est plus logique de faire d'abord les 4 000 et les 8 000 plus tard. Et certains d'entre vous remarqueront que nous nous approchons dangereusement du principe du premier travail pondéré, ou quelque chose de similaire.
Oui, cela s'intègre bien avec toutes ces méthodes. C'est le même genre d'idée. estimez, attribuez une valeur, vous pouvez ensuite discuter de la valeur, vous pouvez les classer les unes par rapport aux autres, vous pouvez jouer avec la façon dont la valeur change au fil du temps. Je trouve que sans valeur attribuée à ces choses, parler de la variation de la valeur au fil du temps est trop abstrait, les gens ne le saisissent pas vraiment. Mais une fois que vous avez mis un chiffre, et cela pourrait être presque n'importe quel chiffre sur une histoire, vous pouvez alors parler de la façon dont elle augmente et comment elle diminue.
Ainsi, vous découvrez le profil de valeur, vous obtenez une idée de la valeur, vous cherchez à obtenir autant de valeur que possible. Et cela peut signifier que vous réalisez les histoires dans un ordre qui n'est pas dicté par leur simple valeur, vous les faites dans un ordre dicté par leur maturité, la rapidité avec laquelle elles se déprécient.
L'autre chose à considérer ici est, et cela revient à ce que j'ai dit sur le modèle de projet. Supposons que vous ayez deux projets devant vous, le projet A et le projet B. Et parce que nous suivons le modèle de projet, nous voulons terminer le projet A avant de terminer le projet B, n'est-ce pas ? Nous parcourons donc le projet A et nous l'évaluons tout par valeur. Et nous réalisons les éléments de haute valeur et nous descendons dans le projet A. Il arrive un moment dans le projet A où les éléments sur lesquels vous travaillez ont une valeur inférieure à ceux du projet B. Vous avez un projet qui va arriver une fois que vous aurez terminé ce projet et qui comporte une collection d'histoires, une collection de cas d'utilisation, une collection de n'importe quoi. Et si vous leur attribuez une valeur, vous verrez que le projet sur lequel vous travaillez ici, vous avez tous les éléments de haute valeur, vous travaillez sur les éléments de faible valeur. À ce moment-là, vous devez vous demander, nous terminons un projet avec une faible valeur. Nous terminons les éléments de faible valeur parce que nous courons après le calendrier, les fonctionnalités, etc. Et il y a un autre projet qui nous attend et qui libérerait plus de valeur. Est-il juste de terminer le premier projet alors que commencer à travailler sur le second projet apporterait beaucoup plus de valeur ? Plutôt que de faire les cinq derniers éléments de ce projet, faites les cinq premiers de l'autre projet. À ce moment-là, tout le modèle de projet commence à s'effondrer. Vous commencez à voir les projets comme une collection de choses à construire. Ils les ont simplement dans différents compartiments. Et si vous travaillez sur un modèle de flux, le travail s'écoule. Pourquoi iriez-vous au fond de ce compartiment alors qu'il y a plus de valeur à tirer en commençant un autre compartiment ? Le modèle de projet s'effondre. Nous commençons à voir cela encore et encore. Le langage des projets n'est généralement pas très utile. Il nous enveloppe dans toutes sortes de contraintes, alors que nous devrions penser au flux.
Pensez à la valeur comme un input plutôt qu'un output.
Je ne devrais pas vous dire cela.
J'ai un exercice que je fais parfois avec les équipes. Et je divise la salle en deux. Et nous aurons certaines équipes à gauche ici et certaines équipes à droite ici. Et je mets une user story à l'écran qui dit : en tant que fabricant de widgets, je veux une boutique en ligne pour vendre mes widgets directement aux clients. D'accord ?
Et je donne aux équipes de ce côté de la salle une histoire qui dit : en tant qu'artisan à domicile fabriquant des widgets, je voudrais vendre mes widgets directement à mes clients. Si je peux gagner 100 000 $ par an, je peux quitter mon emploi actuel. Mon comptable me dit qu'un site web coûte généralement environ 5 000 $.
Et aux personnes de ce côté de la salle, je leur donne une histoire qui dit : en tant que fabricant multinational de widgets, je veux éliminer l'intermédiaire et vendre mes widgets directement aux clients. Je prévois de gagner 10 millions de dollars par an dans les trois premières années. J'ai budgétisé 1,2 million de dollars pour construire cette boutique en ligne. Et je dis aux équipes, vous êtes en compétition. Vous faites une offre pour ce travail. Et je leur donne un peu de temps et ils écrivent quelques user stories et je dis, revenez vers moi, estimez combien de temps et combien d'argent vous voulez pour entreprendre ce travail ? D'accord ?
Et puis je vais vers les équipes, nous terminons, je vais vers les équipes de ce côté, et je dis, combien ? Et ils diront, oh, eh bien, nous pensions... nous avons besoin d'un million de dollars et d'un an pour construire ceci et ensuite nous avons besoin d'un million et demi de dollars, nous avons besoin de deux ans pour construire ceci, et pendant que les équipes de ce côté lisent leurs réponses les équipes de ce côté, je ne vous mens pas, sont hystériques, elles rient, les gars de ce côté de la salle ne comprennent pas pourquoi on se moque d'eux
Et puis nous nous tournons vers ces personnes. Et je pense, combien ? Et ils disent, oh, eh bien, nous pensons pouvoir le faire en trois semaines. Nous le ferons pour 10 000 $. D'accord ? Et vous obtenez des réponses de ce côté de la salle qui sont d'un ordre de grandeur inférieur à celles de l'autre côté de la salle. Parce qu'une fois que la valeur, une fois que le résultat attendu est connu, les équipes en tiennent compte dans leur planification. Donc les gars de ce côté de la salle, ils vont prendre des systèmes de gestion de contenu sophistiqués, des systèmes de commerce électronique sophistiqués, ils vont avoir une ferme de serveurs, ils vont, oui. Les gars de ce côté de la salle disent, nous allons prendre WordPress, brancher Magento, et nous allons simplement avancer avec ça. L'ingénierie est différente selon les chiffres. Et vous, en tant qu'ingénieurs, face à une histoire et invité à estimer l'effort, si vous savez qu'elle vaut un million de dollars, vous allez la considérer très différemment de celle qui vaut 10 000. Cela illustre également l'idée d'ancrage. Vous savez, quand vous entendez un nombre et que vous mettez à jour votre réflexion interne ? C'est choquant. Vous êtes ingénieurs. Vous concevez en tenant compte des contraintes. Si vous savez que quelque chose ne va rapporter que 10 000 $, 100 000 $. C'est un défi d'ingénierie très différent de quelque chose qui est destiné à rapporter des millions.
Donc, connaissez votre profil temporel, connaissez le profit que vous visez,
Calculez combien vous pouvez dépenser pour obtenir ce profit. Travaillez à rebours. Vous connaissez la date que vous visez. Vous savez combien d'argent vous avez à disposition. Que pouvez-vous construire dans ce délai ? Concevez. Concevez. C'est ce que font les ingénieurs.
J'ai quelques minutes pour les questions.
Un silence stupéfait.
J'ai une question.
Oui.
Pour Jim Benson.
Oh, pour Jim.
Il a un livre intitulé, Nous ne sommes pas des ingénieurs.
Oh.
Ne le sommes-nous pas, Jim ?
Nous aspirons à l'être. Je pense que nous aspirons à être ingénieurs. Je dis cela, je me considère comme un ingénieur de troisième génération. À l'âge de huit ans, je descendais dans les salles des machines et je regardais les navires être révisés en mer.
Je crois que beaucoup de mon développement logiciel, les ingénieurs en développement logiciel sont informés par l'ingénierie, mais je crois que nous avons encore un long chemin à parcourir. Mais vous savez, la plupart des ingénieurs ne font pas ce que les gens du logiciel pensent qu'ils font. Nous parlons des ingénieurs et nous commençons rapidement à parler de la construction de ponts. La plupart des ingénieurs ne construisent pas de nouveaux ponts, ne construisent pas de nouvelles machines, ils maintiennent ceux qui existent en état de marche. Et vous les maintenez en état de marche dans des contraintes.
Clark ?
Des réflexions sur la valeur pour les organisations à but non lucratif ?
La valeur pour les organisations à but non lucratif.
Peut-être qu'avec un 'non' ici, nous pouvons dire des hôpitaux sans raison d'exister.
Alors, qu'est-ce qui est précieux pour un hôpital ? Ce n'est pas l'argent, c'est... Est-ce que ce sont des patients en vie ? Est-ce que ce sont des patients qui ont amélioré leur état ?
J'ai déjà eu des gens du Département pour le développement international à Londres et de Waller Courses, et pour eux,
le bénéfice commercial, la valeur, pouvait être des personnes buvant de l'eau propre, des puits d'eau en Afrique subsaharienne, quelque chose comme ça. Dans une organisation commerciale, c'est assez simple, c'est probablement l'argent. Si vous n'êtes pas dans une organisation commerciale, alors je pense que l'une des choses à faire est de vous demander ce que cette organisation valorise. Ce qui vous amène probablement à vous demander quelles sont les valeurs de l'organisation.
Dans une seconde langue, certains d'entre vous pourraient avoir du mal avec cela en tant que locuteur de langue maternelle, c'est difficile de toute façon. Qu'est-ce que l'organisation veut comme résultat ? Qu'est-ce qui bénéficiera à l'organisation ? Donc, en tant que question plus large, qu'est-ce qui est bénéfique ? Quel est le bénéfice commercial ? Quel que soit votre métier, quelle que soit votre organisation. Donc, vous devez définir cela. Et si vous avez de la chance, vous pouvez mettre un chiffre dessus. Là-dessus.
Bien sûr, nous devons toujours faire attention avec les chiffres. Les gens ici à Paris connaissent la Loi de Goodhart. La Loi de Goodhart, formulée par un ancien économiste de la London School of Economics et de la Banque d'Angleterre, une mesure statistique qui devient un objectif perdra sa valeur informative et modifiera son comportement. Si vous avez quelque chose, les points d'histoire en sont un exemple classique. Si vous dites à une équipe, eh bien, l'équipe, c'est une bonne affaire de réaliser 20 points d'histoire par semaine, mais pensez-vous que nous pourrions en faire 25 ? Devrions-nous viser 25 cette semaine ? L'équipe trouvera un moyen d'atteindre cet objectif. Dans le processus, le comportement changera et le contenu informatif de cette mesure changera.
Donc, demandez ce qui est, revenons à la question de Clark, qu'est-ce qui est précieux pour l'organisation ? Que veut l'organisation ? Ce qui pourrait être une conversation intéressante en soi.
Mike.
J'ai fait du travail avec des organisations à but non lucratif. Oui. Jim aussi, je pense. Ils se soucient beaucoup de la durabilité et ils se soucient beaucoup de maintenir un lien avec les supporters et les sponsors, ce qui n'est vraiment pas différent de n'importe quelle entreprise.
Oui. Je suppose que cela dépend de la partie de l'entreprise dans laquelle vous vous trouvez. De la partie de l'entreprise dans laquelle vous vous trouvez, que vous soyez dans la collecte de fonds ou la livraison. Mais, oui, Jim ?
Vous avez mentionné comment, lorsque vous avez donné une certaine commande au côté gauche de la salle et au côté droit, cela a encadré leur conversation. Vous poser la question a également encadré cette conversation. Je me suis attiré des ennuis. Nous faisons le contraire, où des gens viennent et disent, nous aimerions vous donner un million de dollars pour faire ceci, et je dis, je peux le faire pour 250 000 $, et ensuite ils se fâchent et ils vont trouver quelqu'un pour le faire pour un million de dollars. Parce qu'ils ont l'impression que je sous-estime l'importance de leur problème en proposant une solution moins coûteuse.
Oui.
C'est un point intéressant et peut-être une histoire pour vous laisser réfléchir. Il y a quelques années, j'ai fait du travail avec une compagnie d'assurance au Royaume-Uni. Ce n'est pas une histoire heureuse. Et il y avait ce groupe là-dedans et ils avaient un tas de consultants et de coachs Agile. Et c'était un petit groupe et ils ont adhéré à cette idée que nous pourrions introduire Agile de manière un peu clandestine. Un peu de formation ici, un peu de coaching. Nous pourrions amener toutes ces petites équipes à faire un peu d'Agile, un peu d'Agile. Et j'ai dit, ça ne se passait pas particulièrement bien. Et puis j'ai découvert dans cette organisation qu'il y avait un groupe de processus logiciel. Et le groupe de processus logiciel était chargé de maintenir le niveau de notation CMMI de l'organisation. Pour ceux d'entre vous qui ne savent pas, c'est une manière de sortir de la voiture. et E.G. Mellon University de mesurer à quel point votre processus de développement est mature. Et j'ai découvert que cette organisation avait été avertie quelques années auparavant par le régulateur financier qu'elle allait être fermée parce que son informatique était si mauvaise.
Et ils étaient sortis et ils avaient engagé IBM pour les réparer. Et IBM était venu et IBM leur avait donné un beau processus en cascade. Et IBM les avait inondés de consultants. Et IBM avait résolu leur problème. Et le régulateur était content. Quelques années plus tard, l'organisation essayait maintenant de réoutiller ce processus parce qu'il était horriblement inefficace de travailler de manière agile. Mais vous atteigniez un point où les gens ne prenaient pas de décisions ou ne semblaient pas vouloir prendre le remède. C'était un peu difficile à prendre. Et ce que j'ai réalisé, c'est que lorsqu'ils avaient IBM là-dedans, la facture d'IBM était très élevée. Et je vous garantis que la facture mensuelle d'IBM était à l'ordre du jour de chaque réunion du conseil d'administration. Et ils sentaient vraiment qu'ils devaient prendre le remède d'IBM parce que le régulateur le leur disait et qu'ils dépensaient beaucoup d'argent pour cela. Les gens au sommet dépensaient des millions.
Cinq, six ans plus tard, lorsque les gens de l'agile sont arrivés et ont dit, oh, nous pouvons faire cela à moindre coût, un peu ici, un peu là, ils n'ont pas eu à le prendre au sérieux parce que la facture était beaucoup plus petite.
Vous savez, je pense, encore une fois, parfois le montant d'argent est une information, et en fait facturer un montant plus important Un montant important, comme le dit Jim, montre que vous êtes sérieux au sujet de leur problème. Mais aussi, dit-il, vous savez quoi ? Si vous voulez vraiment changer, vous devez vraiment mettre de la peau en jeu. Ce n'est pas juste quelque chose qui peut arriver à vos développeurs. Vous devez tous mettre votre argent, littéralement, là où est votre bouche.
Merci beaucoup. Je vais laisser le prochain intervenant dire quelque chose.

Transcription (Traduit)