Scrum : Gestion de projet et collecte de besoins agiles

1. Bienvenue: Bienvenue dans ce cours sur Scrum. Que vous soyez un ScrumMaster, un chef de projet, un développeur et un ingénieur, que vous souhaitiez le tester simplement en regardant Agile, ce cours est fait pour vous. Scrum est un framework de gestion de projet. Il a été initialement développé pour le développement de logiciels, mais il peut en fait être utilisé pour n'importe quoi. Donc, les compétences que je vais enseigner dans ce cours autant que possible. Je vais essayer de m'appliquer à tous les environnements. Mais nous allons procéder à une véritable étude de cas. Nous allons donc examiner la création d' une plateforme de commerce électronique sous la forme d'une application logicielle. Et nous allons voir comment Squirm s'applique à cela. Vous apprenez donc la théorie, la pratique, et nous l'appliquerons également à cette situation. Donc, si tout cela vous convient, alors commençons. 2. Basiques de scrum: Commençons par les bases. Alors, qu'est-ce qui est cultivé ? Eh bien, c'est un cadre de gestion de projet. Il vous aide à réaliser des projets, à les structurer de manière à ce qu'ils fonctionnent. Il a donc été initialement développé pour développer des logiciels, pour développer des projets techniques, mais a depuis été appliqué à toute une gamme de sujets. développement de logiciels est donc son domaine d'activité. Mais en fait, vous pouvez appliquer Squirm à n'importe quoi et cela fonctionne très bien. Je l'ai utilisé dans ma vie personnelle, je l'ai utilisé pour des projets non typés. Et ces valves sont vraiment bonnes. Scrum fait partie de la famille Agile. agilité est donc un mouvement. Ce n'est pas une chose. L'agilité est, c'est une façon d' être et de travailler. Et vous avez la philosophie cool d'Agile. Mais ensuite, vous avez des implémentations spécifiques, des choses comme Scrum, des choses comme Kanban, ce genre de manuel d'acceptation , voici comment vous pouvez mettre ces principes Agile en pratique. fait donc partie intégrante du mouvement Agile global, et il s'agit d'une implémentation spécifique de celui-ci. Scrum. Et la méthode Agile en général est vraiment conçue pour réduire les échecs des projets et les rendre plus fiables. Ainsi, à l'ancienne méthode, les projets avaient tendance à échouer souvent. Et donc, après tout, tout le monde est venu et s'est dit : Comment pouvons-nous faire mieux ? Comment pouvons-nous réduire cela ? Et nous verrons plus en détail comment il s'y prend au fur et à mesure. Alors, comment fonctionne Scrum ? Comment parvient-il à toutes ces choses ? Explorons cela dans les deux prochaines leçons. 3. Agile vs cascade: Comparons une ancienne méthodologie en cascade à une méthodologie plus agile basée sur Scrum. Avec l'ancien système, tout se ferait par étapes. Ce serait une phase de spécification importante. Ensuite, tout le travail de développement pourrait être effectué, suivi des tests et de l'acceptation par les utilisateurs. Maintenant, voici où ça ne va pas. se peut que cela nous prenne beaucoup plus de temps que prévu et que nous manquions d'argent à un moment donné Nous arrivons à la phase de test et nous nous sommes rendu compte que nous devions changer les exigences, mais nous avons déjà fait tout le travail de développement. Ou nous arrivons à l'étape d' acceptation par l'utilisateur et nous la présentons au client ou au client, qui n'aime pas ça et a besoin de changements. Et ensuite, que sommes-nous censés faire ? Nous sommes déjà dans le phage d'acceptation par les utilisateurs. Au lieu de cela, Agile propose d'utiliser un processus itératif dans lequel nous effectuons de nombreuses petites étapes. Nous effectuons donc une petite partie, une petite construction, de petites tâches, acceptation limitée par les utilisateurs, puis nous recommençons le cycle à zéro. Donc, plutôt que d'avoir ces quatre gros blocs où tout se fait en même temps, nous avons ces petits cycles rapides. Et les avantages de cette méthode sont, par exemple , la possibilité de publier une version après le premier cycle. Quand il s'agit d'une ancienne méthodologie en cascade, vous ne pouvez la publier qu'à la fin. Mais ici, nous construisons quelque chose de très basique et nous pouvons le publier après le premier cycle. Nous pouvons également le mettre devant le client afin qu'il puisse le voir. Et ils peuvent apporter des modifications s'ils en ont besoin, si cela ne correspond pas à ce qu'ils souhaitent. Et ces modifications sont acceptables, car une fois que nous les avons terminées, l' acceptation par les utilisateurs était la première étape. Nous revenons à l'entraînement de la phase de spécification. Ensuite, nous devons construire, puis nous le construisons, le testons et le rendons au client. Et nous suivons ces cycles rapides au cours desquels nous collectons de nombreux commentaires et nous obtenons les informations le plus tôt possible, ce qui réduit les risques de défaillance de nombreux commentaires et nous obtenons les informations le plus tôt possible, ce qui réduit les risques de défaillance et permet répondre aux besoins du client. 4. Forts et limitations: Examinons certains des points forts et des limites du défilement. L'un des grands avantages est d'éviter l'échec du projet. Nous avons donc parlé de cette idée selon laquelle les projets de cascades prenaient du temps et arrivaient à leur terme. Et peut-être qu'ils n'y arrivent pas à cause du dépassement des coûts ou qu'ils le font et que l'utilisateur n'aime pas ça. Et tout cela est un échec Scrum et Agile en général éviteront vraiment cela ? Les clients peuvent le voir plus tôt, ce qui leur permet d'être plus satisfaits, car ils peuvent constater les progrès réalisés et constater que cela correspond à ce qu'ils souhaitent plutôt que d' obtenir au final quelque chose qui peut ou non être ce qu'ils souhaitent. C'est un très bon reporting, qui change les exigences des utilisateurs. Donc, si le client l'obtient et qu' il dit  : « Oh, je dois changer cela ou cela ne fonctionne pas vraiment ». Il est beaucoup plus facile de changer si vous n'avez pas tout construit. Et si vous travaillez selon une méthodologie qui impose des modifications, une modification fine fait partie du processus. Le problème avec la cascade, c'est que le client va apporter des modifications au fur et à mesure que vous progressez dans le projet. Et tu as besoin d'un moyen de gérer ça. Et sa méthodologie itérative y contribue vraiment. Cela signifie que vous pouvez sortir la première version plus tôt car vous n'avez pas besoin de tout terminer pour pouvoir l'expédier. Vous pouvez créer les fonctionnalités essentielles, les expédier, puis continuer à les développer après avoir publié les projets. Maintenant, toutes les limites de Scrum et d'Agile. L'un des problèmes majeurs est donc que cela prend un peu plus de temps. Parfois, les gens pensent qu'Agile semble un peu plus rapide, mais ce n'est pas le cas. Il est conçu pour réduire les taux d'échec. Waterfall, Waterfall est donc assez efficace si tout est correct à 100 %. Donc, si vous l'avez planifié et construit à 100 % , puis que vous le testez puis que vous l'avez livré, tout fonctionne parfaitement. Et aucune modification des exigences des utilisateurs ne serait plus rapide que ce cycle itératif dans lequel vous créez un peu, vous le révisez, vous créez un peu, vous le révisez, ce serait plus rapide. Aujourd'hui, je n'ai jamais vu de projet planifié à 100 % et nous sommes alors conscients de l'évolution des besoins des utilisateurs. Je pense donc que l'agilité fonctionne bien mieux. Mais en théorie, si vous pouviez aligner tout cela, Waterfall serait plus rapide. Comme Scrum fonctionne dans ce cycle itératif, cela prend un peu plus de temps. Les parties prenantes ne l'apprécient pas toujours. Donc, s'ils adoptent le style «  cascade » de la vieille école , ils sont probablement un peu inquiets à l'idée d'adopter cette nouvelle méthodologie agile. Et parfois, ils s'inquiètent fait que si nous développons ce cycle itératif dans lequel nous montrons au client un logiciel à moitié construit , cela tend à le paniquer. Mon expérience, les clients l' adorent. Ils se sont vraiment engagés. Ils veulent voir des progrès et ils comprennent qu'ils ne regardent pas le projet terminé. Mais beaucoup de managers de la vieille école craignent vraiment que nous leur montrions un bouton qui n'est pas complètement terminé et que le client supposera que c'est terminé et s'y attend demain. Et il peut parfois être difficile de gérer ces attentes. Scrum est très flexible, mais d'une certaine manière , imprécis et inflexible. Cela fonctionne donc lors de ces sprints durent généralement deux semaines, où vous dites ce que vous allez faire au début des deux semaines, puis vous le faites et vous ne le modifiez pas. D'une certaine manière, c'est une bonne chose, car si vous autorisez des modifications au cours du sprint, les managers essaient souvent de surcharger le travail distraire les ingénieurs et de les faire perdre du terrain. Et ce n'est pas génial. Mais dans certains environnements , vous avez des problèmes urgents qui se présentent, qui ne sont dans certains environnements , vous avez des problèmes urgents qui se présentent pas aussi doués gérer que, par exemple , Kanban, qui est un autre framework Agile, qui est conçu comme une sorte de fois en vie, de faire des affaires comme d'habitude, de proposer des correctifs, il est plus adapté à cela avec Scrum est plus adapté si vous créez un projet pour la première fois. Et, vous savez, vous pouvez dire que nous avons un bloc de deux semaines ici. C'est ce que nous allons faire et permettre à chacun de se concentrer là-dessus. 5. Le sprint: L'un des concepts clés de Scrum, qui est différent de certains autres frameworks Agile, est cette idée du sprint. Il s'agit d'une période de temps fixe pendant laquelle l'équipe accepte de fournir un ensemble spécifique de fonctionnalités. Cela prend donc souvent deux semaines et nous disons, d'accord, dans les deux prochaines semaines, nous allons créer cette fonctionnalité, cette fonctionnalité et cette fonctionnalité. Donc, un sprint, nous aurons un objectif, par exemple, peut-être que l'objectif est de fournir la page de paiement de notre plateforme de commerce électronique. Et il est composé de plusieurs tickets qui intègrent chacune des fonctionnalités requises pour ce faire. Ensuite, nous lançons un sprint et toute l'équipe travaille ensemble pour fournir cette fonctionnalité. La livraison et la réalisation de l'objectif du sprint ne sont donc pas l'affaire d'une seule personne. C'est la responsabilité collective de toute l'équipe. Dans un processus, cela ressemble donc à la planification du sprint. Dans Sprint Planning, l'objectif du sprint est convenu et nous choisissons les tâches à accomplir. Nous sélectionnons donc les numéros ou les tickets que nous allons soumettre et ils constituent le backlog du sprint, qui est essentiellement la liste des tâches à faire pour ces deux semaines. Nous passerons ensuite au sprint lui-même. L'équipe travaille donc à la fourniture des fonctionnalités convenues et rien de nouveau n'est apporté au sprint. Ainsi, lorsque nous planifions un sprint, nous commençons par le moment, puis nous bloquons ce sprint, ce laps de temps pour dire que c'est ce que nous allons faire et que nous allons travailler ensemble pour y parvenir. À la fin du sprint. Ensuite, il y a la rétrospective et la revue. Le travail terminé est donc présenté lors d'une revue et l'équipe réfléchit à son déroulement , à savoir la rétrospective. Il s'agit donc de deux événements distincts, et nous en parlerons plus en détail dans une leçon ultérieure. Et tous les problèmes non résolus sont reportés au sprint suivant ou sont renvoyés au backlog du produit. 6. Longueur de la pulvérisation: La durée d'un sprint peut être ce que vous voulez. Donc, en général, les sprints sont effectués sur des périodes de deux semaines car cela semble bien fonctionner pour la plupart des projets, mais ce n'est pas une règle. Parfois, j'ai fait des sprints d'une semaine, parfois des sprints de trois semaines. Ce que vous voulez vraiment faire c'est déterminer combien de temps il vous faudra pour fournir certaines fonctionnalités, certaines étapes du processus de développement, et en faire votre durée de sprint. Donc, si vous avez une fonctionnalité vraiment importante et délicate à réaliser, une partie du projet doit être réalisée. Ensuite, si cela vous prend, disons, un mois, alors vous devriez faire en sorte que votre sprint dure un mois si nous ne pouvons littéralement pas être décomposés. Et c'est une bonne question à vous poser si vous pensez, d'accord, j'ai besoin d'un sprint de quatre ou six semaines ou quelque chose comme ça. Réexaminez si vous pouvez le décomposer davantage , car vous le pouvez probablement. Mais si c'est littéralement impossible, pouvez allonger votre sprint , car vous pouvez adapter la longueur de l' attelle à nos besoins. En général, deux semaines sont une bonne période. Tout le monde peut baisser la tête. Vous ne passez pas trop de temps à suivre le cycle de sprint et vous disposez d'une bonne période de dix jours ouvrables pour faire avancer les choses, mais vous pouvez la raccourcir ou l'allonger en fonction de vos besoins. 7. Qu'est-ce que les artefacts ?: Les artefacts sont des informations qu' une équipe Scrum utilise pour planifier et exécuter son travail. Ainsi, par exemple, une liste de fonctionnalités à créer serait un artefact. Maintenant, cela pourrait être conservé sur une feuille de calcul. Il peut être conservé dans un outil tel que JIRA, ou il peut même être conservé dans notre tête. Mais je ne le recommanderais pas, car cela crée évidemment un point de défaillance unique. Dans ce module, nous allons explorer les différents types d' artefacts couramment utilisés par les équipes Scrum. 8. Backlog de produits: Le produit est ce que vous livrez et le carnet de commandes est tout ce qui doit être fait. Donc toutes les tâches impliquées dans le projet. Chaque ticket représente une fonctionnalité distincte. Donc, un ticket, une fonctionnalité livrable. Par exemple, si nous prenons l'exemple de notre boutique en ligne, nous avons probablement besoin d'une page d'affichage du produit sur laquelle vous pouvez cliquer sur le produit et voir tous les détails. Et cela comporte divers éléments, car il s'agit probablement du titre et de la description du produit, de la photo quelques critiques et spécifications techniques. Maintenant, chacune de ces choses peut être son propre ticket inscrit dans un carnet de produits. Donc, en ajoutant la création de la page blanche, en ajoutant le titre, en ajoutant l'image du produit, je n'ai pas spécifié d'ajout des avis. Il peut s'agir de billets individuels car vous pouvez les livrer un par un. Vous pouvez publier une page qui ne comporte qu'un titre de produit. Vous pouvez ensuite revenir plus tard et ajouter une photo du produit ou des critiques de produits qui permettent de distinguer certaines fonctionnalités, et ils obtiendront ainsi leur propre ticket. Les billets peuvent désormais être utilisés pour une œuvre plus importante. Donc, dans ce cas, nous avons notre page produit, ou la page produit sera peut-être ce que l'on appelle une épopée. Il s'agit donc d'une collection de tickets qui contribue à une fonctionnalité plus complète. Notre page produit dans son ensemble pourrait donc être une épopée. Et puis il y a des billets individuels dedans. Nous avons donc la description de notre produit, photo du produit, la critique du produit, et tout cela fait partie de l'épopée de la page produit, que nous pouvons ensuite publier à un moment donné. L'objectif du backlog de produits est donc de contenir toutes les tâches à effectuer. Ils conservaient donc tout ce qui concerne la page du produit, tout ce qui concerne la page de navigation, tout ce qui concerne la page de paiement, tout décomposé en tickets individuels et les séparait en ces épopées. Nous savons donc à quel ticket appartient, à quel type de section. 9. Exemple de carnet de produit: Voici un exemple de backlog de produits. Voici donc notre exemple de boutique en ligne. Et nous avons écrit nos témoignages d'utilisateurs ici. Il est donc écrit dans le format user story dont nous parlerons un peu plus tard. Mais par exemple, en tant que visiteur, je ne verrai pas le nom du produit, l'image du produit. Ensuite, en tant que responsable, je veux voir une liste de commandes. Et dans cette colonne, nous l'avons regroupé par époque. Ce sont donc toutes les pages de produits épiques, leur page de paiement, leur épopée de gestion des commandes. Et nous y avons ajouté un sprint provisoire, ainsi la colonne d'état, pour indiquer s'ils ont été terminés, au moment où nous le faisons actuellement, ou s'ils sont prêts. Et il y en aura qui n'étaient pas prêts parce que nous ne les avons pas affinés ici. Il existe désormais de nombreux outils intéressants que vous pouvez utiliser pour gérer votre backlog de produits. Mais je voulais vous le montrer sur cette feuille de calcul parce que je pense que c'est un excellent moyen d'apprendre les bases. Vous pouvez le faire sur une feuille de calcul, vous pouvez le faire sur une feuille de papier, vous pouvez le faire comme vous le souhaitez. Nous allons examiner les outils, car ils sont également très importants. C'est probablement ce que vous utiliserez dans un environnement commercial réel. Mais c'est une bonne façon de considérer les fondamentaux. 10. Carnet de sprint: Au début de chaque sprint, vous sélectionnez les tickets que vous allez utiliser pour ce sprint. Supposons que vous travailliez dans le cadre d'un sprint de deux semaines. Vous passez en revue le carnet de produits et vous dites : «  OK, a, B, C, D, voici les tickets que nous allons apporter et acheter au cours de ce sprint. Ainsi, une fois que vous avez commencé le sprint, ces tickets que vous avez sélectionnés constituent ce que l'on appelle votre backlog de sprint. La liste des produits en attente, tout ce que vous devrez faire pour le projet, la liste des tickets que vous allez créer pour ce sprint spécifique. Ainsi, lorsque quelqu'un est prêt à travailler sur quelque chose, il accède au backlog du sprint et récupère l'un des tickets, tous ceux auxquels vous pouvez donner la priorité. Mais généralement, au cours d'un sprint, il n'y a pas vraiment de priorisation à moins que quelque chose ne bloque quelque chose. Mais si vous avez un bloqueur, il est préférable de laisser cela à un sprint séparé afin les billets puissent être récupérés dans n'importe quel ordre. Ensuite, ils passent de la colonne des tâches à faire, qui correspond au backlog global du sprint au fur et à mesure du développement, de la mise en œuvre et de la livraison. 11. Exemple de carnet de sprint: Voici un exemple : Sprint Backlog. Nous avons donc nos colonnes ici avec la liste des tâches à faire, le backlog ici. Ensuite, au fur et à mesure que nous fabriquons ces billets, donc si je dis que j'ai choisi celui-ci en tant que client, je veux voir le nom du produit. Je peux le mettre en cours, puis l'envoyer pour révision du code. Et continuez simplement à le faire avancer tout au long du processus. Et disons qu'il est prêt à être testé. Les tests le décrivent. Cela ne fonctionne pas. Ils pourraient le remettre en cours, me le réattribuer. Et il pourrait recommencer ce cycle et finir, espérons-le, par se retrouver dans la colonne terminée. Ces colonnes peuvent désormais être aussi flexibles que vous le souhaitez. Nous pourrions donc, au lieu de la vue de l'encodeur en cours, peut-être vouloir la diviser. Ajoutez une nouvelle colonne ici. Nous y voilà. Je l'appellerais avant que nous ne disions qu'il est prêt pour la révision du code. Et lors de la révision du code. Et puis, une fois que j'aurai fini d'écrire le code, je pourrais le coller ici. Et puis quelqu'un d'autre pourrait le récupérer. Quand ils le récupèrent. Cela pourrait figurer ici, par exemple , dans ces colonnes, il n'y a pas de règles, mais selon certains principes généraux, vous voulez probablement une sorte d' arriéré alors qu'il avait besoin d'un arriéré, mais il n'en avait pas besoin. Et en cours de révision et de test du code. En fin de compte, ils veulent se retrouver dans la colonne terminée. Encore une fois, il y a plein d'excellents outils pour le faire, mais c'est agréable de le voir à un niveau très basique. Beaucoup de gens utilisent des tableaux physiques avec des post-its qu' ils peuvent déplacer. C'était très populaire lorsque tout le monde travaillait au bureau pendant les milliers de pandémies et que les équipes à distance ont beaucoup plus d'influence. Mais vous pouvez, si vous le faites dans le cadre d'un projet individuel, cela reste une excellente façon de le faire, car vous avez une expérience vraiment tactile déplacer les cartes sur le plateau. 12. Définition de la réalisation: Comment savoir quand un ticket peut être déplacé dans la colonne Terminé ? Est-ce qu'un document important ici est la définition de « terminé ». Il s'agit d'un document qui décrit exactement ce qui est requis pour qu'un ticket soit considéré comme terminé. Ainsi, par exemple, si nous examinons à nouveau le logiciel, un ingénieur peut créer la fonctionnalité. Mais cela ne répondrait pas à la plupart des définitions du terme terminé, car ce n'est pas le cas, il n'est parti nulle part, il n'est pas testé. Ainsi, la définition de terminé listera toutes les étapes, par exemple il a été créé et testé. Il a été déployé. La couverture des tests est suffisante. Il y a peut-être un peu de surveillance et de journalisation pour que vous puissiez enregistrer que cette fonctionnalité ne fonctionne pas correctement ou s'arrête plus tard. Il a été testé en termes de performances et de sécurité pour s' assurer qu'il n'introduisait aucune faille, etc. Toutes les étapes supplémentaires pour lesquelles vous pouvez dire que ce ticket est terminé, nous n'avons rien à ajouter. Nous n'avons pas besoin de revenir en arrière et de le regarder. Nous sommes heureux qu'il soit dans la nature. Dans la leçon suivante, nous examinerons un exemple de définition de Terminé afin que vous puissiez voir à quoi cela ressemble dans la pratique. 13. Quelles sont les cérémonies ?: Les cérémonies sont des événements qui ont contribué à la planification, à l'exécution et à la livraison du sprint. En général, elles impliquent les membres de l'équipe Scrum, mais lors de certaines cérémonies, nous pouvons également choisir d'inviter des parties prenantes externes. Dans ce module, nous allons explorer tour à tour chacune des principales cérémonies. 14. Scrum quotidien: Le Daily Scrum est une réunion quotidienne. Cela se produit généralement le matin, mais ce n'est pas obligatoire et c'est un peu comme un enregistrement pour tous les membres de l'équipe Scrum. Cela se fait généralement debout, c'est pourquoi on l'appelle généralement stand-up sur le PC. Terme cross-agile, plusieurs frameworks Agile utiliseront le terme stand-up dans Scrum, en particulier. Techniquement, il s'appelle The Daily Scrum, mais c'est la même chose. Et le format est chaque membre indique ce qu'il a fait hier, sur quoi il travaille en ce moment, et tous les obstacles, afin ce qui entrave son travail puisse l'augmenter. Alors. L'objectif est d'aider chacun à rester responsable les uns envers les autres. Et c'est également une bonne occasion de demander l'aide dont nous avons besoin. Ce n'est pas conçu pour être une longue réunion. Il s'agit normalement d'une boîte de temps d' un maximum de 15 minutes et cela se fait debout. Tout le monde est donc encouragé à être bref et précis. Donc, s'il y a quelque chose qui nécessite une discussion plus approfondie, vous avez eu ce que l'on appelle le mettre hors ligne. Alors organisez une réunion séparée. Nous pouvons en discuter avec les parties concernées, car il y a de fortes chances que tout le monde au Daily Scrum n'ait pas besoin d'être impliqué. tenons donc à ces mises à jour concises. Il est utile d'ouvrir votre tableau de sprint pendant que vous le faites afin que les participants puissent se souvenir de ce sur quoi ils travaillent, examiner les tickets et montrer au reste de l'équipe où se trouvent les tickets et comment ils évoluent. 15. Affiner le backlog: Une réunion d'affinement du backlog prépare les tickets pour le sprint. Ainsi, lorsque vous créez votre backlog de produits pour la première fois, vous n'allez probablement pas donner autant de détails que vous pensez, d' accord, page produit, image du produit, films. En gardant les choses assez simples ce ticket n'est pas vraiment prêt à être envoyé à un ingénieur pour qu'il soit recruté pour être mis en œuvre. Et c'est à cela que contribue le raffinement du backlog. Cela peut donc impliquer toute l'équipe Scrum ou impliquer, par exemple, le propriétaire du produit et peut-être l'ingénieur principal travaillant ensemble. Et les tâches liées au raffinement du backlog R21 consistent décomposer le ticket en ses plus petites pièces. Donc, si le ticket est la page d'affichage du produit, cela peut être décomposé en commentaires et images du produit et la page elle-même en jolis petits morceaux. Ensuite, nous devons nous assurer que le billet est prêt à être dépensé. Nous parlons donc ici de l'élaboration des billets. Que souhaite exactement le propriétaire du produit et l'entreprise ? Les spécifications sont-elles vraiment claires. Des notes techniques ou des implémentations doivent-elles être ajoutées au ticket pour que l'ingénieur comprenne ce qui doit être fait ? Y a-t-il des notes sur les tests des testeurs pour comprendre ce qui doit être fait ? Y a-t-il suffisamment d'informations pour ce ticket puisse être lancé dans un sprint, le récupérer et commencer à travailler dessus sans avoir à poser de questions supplémentaires ? Ensuite, nous passerons en revue tous les bloqueurs. Ainsi, par exemple si le ticket ajoute les avis sur le produit à la page Afficher le produit, ce ticket sera bloqué par la création d'une page produit Shell View. Parce que si cette page d'affichage du produit n'existe pas, vous ne pouvez pas y ajouter d'avis. Ce serait donc un bloqueur et nous devrions en tenir compte. Ainsi, pour qu'un ticket réussisse le traitement du backlog, il doit être prêt à être intégré au sprint. Cela signifie qu'il n'a aucun bloqueur, qu'il est prêt à fonctionner et qu'il définit clairement ce qui doit être fait. 16. Points d'estimation: L'une des choses que vous devez savoir avant d' apporter un ticket à un sprint est suivante : combien de temps cela va-t-il prendre ? S'agit-il d'un petit billet et d'un billet moyen ? Un gros billet. Nous avons besoin d'une idée approximative du temps que prendra le ticket afin de pouvoir essayer d'estimer la quantité de travail que nous pouvons accomplir au cours du sprint que nous essayons actuellement de planifier. Maintenant, en termes de portée, au lieu d' utiliser le temps, nous utilisons des points. Et les points sont arbitraires, donc il n'y a pas nécessairement de corrélation entre le point zéro et cela prend autant de temps. Ce que vous faites, c'est voir, vous estimez les points, puis vous voyez combien de points vous pouvez obtenir en un sprint. Et puis à partir de là, vous savez, d'accord, je peux faire en sorte que nous puissions marquer deux points en tant qu'équipe. Nous devons donc marquer deux points la prochaine fois. Maintenant, comment est-ce que cela fonctionne ? Si vous devez déjà avoir effectué quelques sprints et déterminé la valeur de vos points. Comme. Comment commencez-vous avec ça ? Eh bien, là, vous devez d'abord établir un lien entre le temps et les points. Alors peut-être dites-vous qu'il ne faudrait pas une journée pour une personne ou une demi-journée pour une personne. Donc, si vous pensez que les tickets demanderont à l'ingénieur deux jours de test ou un jour, et qu'une autre journée sera consacrée au déploiement, alors vous dites, d'accord, eh bien, cela fait quatre jours, donc nous allons appeler quatre points pour le moment. Et en ce qui concerne tous les billets de la même manière. Et puis au fur et à mesure que vous plissez continuez et que vous obtenez de la nourriture à plusieurs sprints, vous commencez à vous faire une idée de, d'accord , eh bien, ce ticket représente à peu près autant de points. en œuvre va donc prendre autant de temps. Nous savons que nous pouvons atteindre environ 30 points pour sprinter. Nous pouvons donc ajouter 30 points de choses à la rotation. Points de billets. 17. Poker agile: poker Agile est un bon moyen d'estimer les points. Avec certaines de ces cartes, vous pouvez les obtenir, n'importe où. Ainsi, chaque membre de l'équipe recevrait un jeu de ces cartes. Et les cartes ont des valeurs de points selon la séquence de Fibonacci. Vous avez donc environ la moitié de 0,123, 581320. Ces cartes sont vendues à 25, donc elles ne proposent que très peu de cartes d'achat. Vous n'aurez jamais de tickets à 100 points. Vous avez une infinité d'inconnus. L'idée est donc que tout le monde en obtienne un ensemble. Tout le monde les tiendrait comme un joueur de poker et vous les estimeriez, alors vous dites : « OK, nous allons estimer ce ticket maintenant. Et peut-être, peut-être que je vais prendre celui-ci. Peut-être qu'un autre membre de l'équipe ira chercher celui-ci. Et une fois que nous les avons tous choisis, nous les retournons. Je suis parti gratuitement, quelqu'un d'autre vient pour huit. Il y a tellement de différence, nous en parlons et convenons ensuite d'une valeur en points, mais cela permet à chacun de donner une estimation indépendante. Ensuite, vous pouvez déterminer si tout le monde en a choisi trois sauf une. Je veux probablement opter pour la gratuité après un peu de discussion. Mais c'est un bon moyen de recueillir l'opinion indépendante de chacun avant de vous réunir pour discuter des problèmes et essayer de déterminer la valeur des points. 18. Vitesse: Nous avons parlé de cette idée selon laquelle les points ne doivent pas nécessairement correspondre aux temps. Vous pouvez indiquer une complexité ouverte. Donc, quelque chose de très simple pourrait être un point. Quelque chose de vraiment complexe pourrait être, disons, 13 points. Ensuite, après avoir effectué quelques sprints, vous avez une idée du nombre de points que vous obtenez au cours d'un sprint. En fait, nous le mesurons normalement. Nous voyons donc combien de points nous avons placés dans la colonne des dunks lors d'un sprint donné, et cela peut être n'importe quoi. Supposons que la boîte ait obtenu 35, 42 ou 47 points, peu importe ce que c'est. Eh bien, si vous avez l'historique de ces sprints, donc un sprint, vous en avez fait 55 alors que vous en avez fait 42, alors qu'il le fallait pour atteindre sept. Eh bien, vous savez qu'en moyenne, vous obtenez environ 38 points par sprint. Cette moyenne devient donc ce que nous appelons la vitesse. C'est la rapidité avec laquelle nous nous déplaçons et, dans ce cas, la rapidité avec laquelle nous nous déplaçons est généralement environ 38 points par sprint. Donc, une fois que vous avez calculé cette vélocité, alors, vous savez, d'accord, eh bien, au sprint suivant, nous pouvons obtenir environ 38 points, parce que c'est ce que nous obtenons généralement au cours d'un sprint. 19. Planification de sprint: La planification du sprint se fait au début de chaque sprint. Vous conviendrez d'une durée de sprint, puis vous déterminerez le nombre de points que vous pensez pouvoir terminer pendant cette période. Donc, si vous participez, par exemple, à sprint de deux semaines et que vous avez une vélocité de 38 points, alors vous marquez probablement 38 points avec les billets. Si, pour une raison quelconque, raccourcissez-le. Alors peut-être en faisant un sprint d'une semaine, cartes vous indiqueront que vous pouvez probablement atteindre environ 19 points en deux fois moins de temps. Vous déterminez le nombre de points avec lesquels vous devez jouer. Ensuite, vous remplissez un nombre approprié de billets valant des points. Donc, si vous avez 38 points à gagner, vous accédez à votre carnet de produits et vous sélectionnez des tickets d'une valeur de 38 points, et ceux-ci deviennent votre backlog de sprint. Voici donc la liste des tâches à effectuer pour le sprint sur lequel vous travaillez actuellement. À ce stade, l'estimation peut se faire dans raffinement ou dans le cadre planification d'un sprint si cela ne s'est pas produit dans le cadre d'un raffinement, d'un raffinement, d'une bonne idée. S'ils ont déjà été effectués et que vous planifiez le sprint, peut-être que le moment est venu de faire appel à quelques personnes impliquées dans le raffinement et la planification du sprint impliquées dans le raffinement et la planification du sprint pour vérifier que tout le monde est d'accord avec les points. est donc un travail raisonnable que vous pouvez accomplir dans ce sprint. Une fois que vous avez terminé, vous pouvez démarrer votre sprint et vous mettre au travail sur tous ces tickets. 20. Rétrospective: La rétrospective, également appelée rétro road en abrégé, lieu à la fin d'un sprint. Ici, vous passez en revue ce qui a bien fonctionné et ce qui n'a pas si bien fonctionné afin que nous puissions déterminer ce que nous voulons améliorer à l'avenir. Il est important de noter ici qu'il s'agit d'une réunion de processus plutôt que d'une réunion portant sur le travail lui-même. Supposons que nous ayons acheté un ticket pour Sprint et qu' il s' avère qu'il contient un bloqueur. Nous n'avons donc rien pu faire. Cela n'a pas été fait au cours de ce sprint. Dans le rétro, nous ne parlerions pas de la façon de débloquer ce ticket pour pouvoir le faire. Mais nous pourrions parler de choses comme, eh bien, comment se fait-il que nous n'ayons pas réalisé qu'il y avait un bloqueur, donc qu'il était bloqué ? Et que pouvons-nous faire à l'avenir pour nous assurer de ne pas apporter tickets qui ne peuvent pas être complétés en un sprint ? Vous commentez donc probablement certains des billets sur lesquels vous avez travaillé et les problèmes que vous avez achetés. Mais nous ne faisons pas de commentaires directs sur le travail, mais plutôt sur la manière dont nous pouvons travailler ensemble en tant qu'équipe à l'avenir, de manière encore plus rapide et plus efficace. Vous pouvez créer un style rétro comme vous le souhaitez. Mais j'ai quelques idées pour la prochaine leçon. 21. Idées de rétrospectives: Dans cette leçon, nous allons examiner quelques idées pour organiser vos rétrospectives. C'est donc vraiment un point de départ et vous avez vos propres idées, faites les choses de manière créative, vous vous amusez. L'un des classiques est Start, Stop, Continue. Donnez donc à tous les membres de votre équipe un marqueur et des post-its, et posez-les sur le mur ou arrêtez-vous, commencez et continuez. Et les gens peuvent écrire leurs suggestions des choses que nous devrions arrêter de faire, des choses que nous devrions commencer à faire et des choses que nous devrions continuer à faire. Ainsi, dans cet exemple, les suggestions sont les suivantes : vous cesserez d'arriver en retard aux réunions et d'avoir de longues discussions debout. Peut-être qu'ils nous gênent. sprint suivant, l' équipe se concentre donc délibérément sur l'arrêt de ces comportements plutôt que sur les acariens, choses que nous voulons commencer par Peut-être que les rétrospectives sont toujours organisées dernière minute. Il serait donc utile de réserver une salle de réunion, puis les choses continuent. Nous avons donc commencé à utiliser un nouveau serveur de test il y a quelques semaines, alors qu'il fonctionne très bien. Allons-y, continuons à le faire. Une autre façon de le faire est d'utiliser des scores. Vous pourriez donc avoir des titres tels que quelle mesure allez-vous mener à bien ce projet ? Quelle énergie pensez-vous que nous avons en tant qu'équipe et comment plan psychologique, le terrain et chaque membre de l'équipe peuvent attribuer un score ? Il peut y être affiché de manière anonyme. Ensuite, vous pouvez regarder ces chiffres et suivre vos progrès au fil du temps. Alors peut-être faites-le tous les deux mois et voyez comment cela change. Mais aussi, si vous le remarquez, notre confiance a vraiment diminué ou notre sécurité a vraiment diminué. Que faisons-nous en tant qu'équipe que nous pouvons améliorer ? Peut-être parlerons-nous davantage de cette question. Lean Coffee est un type de réunion qui fonctionne bien dans le rétro et qui sort également des métros. Et la façon dont cela se produit est qu'il n'y a pas d'ordre du jour préétabli. La première tâche consiste donc à créer un ordre du jour. Et encore une fois, peut-être, demandez à tout le monde de le publier. Certaines personnes écrivent ce dont elles veulent discuter sur un post-it, le placent sur un mur, puis toute l'équipe peut voter sur l'ordre de la discussion. Donc, vous parlez comme si vous choisissiez les cinq principales choses dont vous voulez parler, nouvelle boîte de temps, chacune d'entre elles. Supposons que l'équipe souhaite parler de la façon dont nous faisons des standups. Tout d'abord, vous réglez une minuterie 5 minutes et vous avez une discussion de cinq minutes. Et lorsque l'alarme se déclenche, l'équipe peut voter pour l'une ou l'autre des options, nous voulons en parler davantage Continuons à parler de stand-up. Ou nous voulons passer au sujet suivant. Et si l'équipe vote pour passer à autre chose, alors tu reprends le deuxième post et tu en parles. Et encore une fois, tu fais la même chose. Il a enseigné pendant 5 minutes. À la fin de ces cinq minutes, vous décidez si cela nécessite plus de temps ou si vous souhaitez passer à autre chose. Et enfin, le team building. Toutes les rétrospectives ne doivent pas nécessairement être abordées pour permettre à une équipe de travailler de manière cohérente. Des activités comme Smalltalk, des jeux vidéo, activités de team building peuvent être très importantes pour réunir cette équipe. Donc, si l'équipe est fatiguée ou si ce n'est pas le cas, c'est assez difficile, comme vous le souhaiteriez Faire du team building et jouer à des jeux amusants peut également être très utile. 22. Modes de travail: Euh, une réunion sur les méthodes de travail, c'est l'équipe qui se met d'accord sur la manière dont elle va travailler ensemble. Chaque équipe est donc différente et les membres peuvent souhaiter travailler de différentes manières pour différentes équipes. Alors, des questions comme « Pouvez-vous récupérer n'importe quel ticket parmi les tickets en attente ou doit-il nécessairement être le meilleur ? attribuez-vous à la personne suivante ou le laissez-vous vide pour lui permettre de comprendre ce qui correspond à notre définition du terme « terminé » ? Quand auront lieu les cérémonies et qui inviterons-nous ? Combien de temps durera Sprint ? Toutes ces questions de processus doivent faire l' objet d'un accord au sein de l'équipe. Et vous discuteriez de tout cela dans le cadre d'une réunion de travail. Vous devez généralement vous réunir lorsque vous formez une nouvelle équipe et que vous êtes opérationnel. Mais si de nombreux membres de l'équipe partent et que de nouveaux membres les rejoignent, ou si cela fait longtemps que vous n'avez pas été blessé et que vous souhaitez renégocier certaines règles de l'équipe, une réunion sur les méthodes de travail renégocier certaines règles de l'équipe, organiser une réunion sur les méthodes de travail est une très bonne solution. clé du succès est de faire en sorte que chacun ait une voix et que chacun ait son opinion sur ce qui fonctionne et ce qui ne fonctionne pas, manière dont il aimerait faire les choses. Ensuite, pour que tout le monde soit d'accord, afin que tous les membres de l'équipe adhèrent vraiment à cette façon de travailler et que tout le monde travaille ensemble pour se soutenir mutuellement. 23. Examen de la sprint: Une révision a lieu à la fin d'un sprint ou une fois celui-ci terminé. Le but de l'examen est passer en revue et de démontrer le travail qui a été effectué. Tout le monde est donc invité, tous les membres de l'équipe Scrum ainsi que les parties prenantes externes souhaitent également que les parties prenantes externes souhaitent savoir ce que l'équipe a fait. L'équipe fait une démonstration à tour de rôle de chacune des fonctionnalités. Et il peut y avoir des questions de la part de parties prenantes externes. Nous les conservons généralement jusqu'à la fin des évaluations qui montrent tout, puis nous autorisons certains commentaires. À ce stade, tous les tickets sont prêts. Donc, s'il y a des changements, s'il y a du travail supplémentaire à effectuer , cela devrait être considéré comme de nouveaux tickets. 24. Équipe de Scrum: Scrum repose sur le travail d'équipe et les équipes Scrum sont interfonctionnelles. Qu'est-ce que cela signifie ? Eh bien, autrefois, les équipes pouvaient être organisées par titres de poste. Vous auriez donc une équipe de concepteurs ici, une équipe d'ingénieurs ici, une équipe de testeurs ici. Et lorsque vous vouliez intégrer quelque chose à la conception, envoyez-le au pool de conception. Et le pool de conception fonctionnerait sur tout et le transmettrait ensuite. Donc, pour tout ce qui avait besoin d'un design pour l'ensemble de l'entreprise, nous faisions appel à une équipe de conception spécifique. Les équipes Scrum ne fonctionnent pas du tout comme ça. Ils sont interfonctionnels, l' équipe Scrum devrait disposer de tout ce dont elle a besoin. Pour une équipe Scrum, par exemple, un concepteur, un ingénieur, un testeur, quels que soient les objectifs d' un analyste commercial dont nous avions besoin à cet égard, tout est contenu dans l'équipe. Ainsi, au lieu d'avoir à vous adresser aux concepteurs, à l'ingénieur ou au texte, tout ce dont vous avez besoin est regroupé au sein d'une seule équipe. équipes sont donc un peu comme une unité mobile de l' armée qui peut opérer de manière indépendante sans être bloquée par d'autres équipes, sans avoir à se déplacer. Nous avons besoin d'un testeur pour cela, mais aucun test n'est disponible. Tout est contenu au sein de l'équipe. Ainsi, lorsque nous essayons de combler notre retard de sprint, nous essayons de faire notre retard de sprint, en sorte que nos billets ne soient pas bloqués par d'autres personnes. 25. Propriétaire de produit: Le propriétaire du produit est responsable en dernier ressort du produit ou du projet. Il s'agit donc de prendre des décisions et de définir des priorités, de déterminer à quoi ressemblera le projet et comment il fonctionnera. Donc, par exemple, si nous pensons à notre page produit de commerce électronique, à quoi ressemblera-t-elle exactement ? Où va-t-on, où, à quoi ressemblera l'expérience utilisateur ? Et aussi des priorités, comme quelle partie du système doit être construite en premier ? que c'est la page du produit qui doit vérifier la navigation ? Quel morceau ? Maintenant, ce n'est pas un rôle technique. Donc, quand je dis comment cela va fonctionner, c'est vraiment une question d'expérience utilisateur. Imaginer que c'est le client qui utilise ce produit, plutôt que des connaissances techniques. Toutes les connaissances techniques appartiendront aux ingénieurs et le propriétaire du produit n'a pas vraiment besoin de savoir comment elles sont mises en œuvre. Ils disent ce qu'ils veulent mettre en œuvre. Désormais, chaque produit doit avoir un propriétaire. Donc, si c'est le cas, vous envisagez de confier le même produit à deux propriétaires de produits. Vous devez probablement séparer ce produit. Mais un propriétaire de produit peut s' occuper de plusieurs produits. Donc, si vous avez beaucoup de petits produits un seul propriétaire peut s' occuper de plusieurs d'entre eux. Ce qui caractérise un bon propriétaire de produit c'est quelqu'un qui sait ce qu'il veut, mais qui est également flexible lorsqu'il est impossible de faire quelque chose. Supposons, par exemple , que vous construisez une maison. Le propriétaire du produit est la personne qui dit : OK, eh bien, j'aimerais avoir des chambres, des salles de bains et un garage. Mais si la Commission de planification revient et dit, eh bien, vous ne pouvez pas avoir de garage, vous voulez que le propriétaire du produit soit prêt à dire, accord, eh bien, changeons cela et je préciserai autre chose. Mais il a une vision claire à donner à l'équipe, à donner aux ingénieurs sur ce qu'ils recherchent. 26. Maître de Scrum: Le Scrum Master contribue au bon fonctionnement de l'équipe Scrum. Donc, malgré le nom Master, ils sont en fait un autre membre de l'équipe et ils sont au même niveau. Ils ne sont pas les chefs de l'équipe. Ils organisent et animent des cérémonies, mais à la demande de l'équipe. Cela ne doit donc pas nécessairement être fait par le Scrum Master. importe qui peut animer importe quelle cérémonie depuis n'importe quel membre de n'importe quelle cérémonie depuis n'importe quel membre de l'équipe peut intervenir et dire : « Eh bien, je vais quitter le rétro, je vais quitter le Scrum quotidien ou s'ils préfèrent, le ScrumMaster peut le faire ». Les tâches typiques d'un ScrumMaster peuvent consister à réserver des salles de réunion, à animer les cérémonies, à parler à d'autres personnes au sujet des bloqueurs. Donc, si l'équipe a besoin de communiquer avec une autre équipe pour résoudre un problème à l'intention des chefs d'établissement, une bonne personne à envoyer sur place représenter l'équipe lors de réunions d'entreprise plus larges. Nous en reparlerons un peu plus dans Scaling Squirm. Mais en réalité, chaque fois l'équipe doit parler à la direction, doit parler à un autre groupe. Les squamous sont vraiment une bonne personne pour les représenter car ils veillent au respect des règles. Donc, si nous nous mettons d'accord sur quelque chose dans le cadre d'une réunion de travail, par exemple si nous serons tous à l'heure pour notre Daily Scrum de neuf heures et demie et que les gens ne se présenteront pas à l'heure, alors c'est généralement au maître d'école de ne pas les reprocher mais de leur dire : «  Hé, juste un rappel ». Nous avons convenu que nous serions tous là à neuf heures et qu'aucun de vous n'entraîne et ne motive l'équipe. Le Scrum Master possède généralement une bonne connaissance d'Agile et de Scrum et peut intégrer ces recommandations comme d'excellents moyens de travailler l'équipe et de susciter intérêt de l'équipe pour le travail qu'elle effectue. 27. Analystes d'entreprise: Les analystes commerciaux, également appelés BA en abrégé, participent à la collecte des exigences. Quelle équipe aurait généralement un ou deux BA. Et leur travail consiste à comprendre les exigences des utilisateurs et à établir un pont entre les souhaits du responsable du produit et ce que les ingénieurs doivent savoir. Le propriétaire du produit pourrait dire quelque chose comme « Je veux que les clients suivre leurs livraisons et voir où se trouvent leurs livraisons ». Le BA disparaîtrait et décomposerait cela en un parcours client. Ainsi, par exemple, le client , en tant que client, je souhaite pouvoir consulter mes commandes en tant que client. Je souhaite consulter les détails d' une commande spécifique en tant que client, je souhaite voir les informations de suivi pour la carrière vers laquelle la commande est envoyée. Ils prenaient donc demande globale des propriétaires de produits, décomposaient en tickets et élaboraient des critères d'acceptation. Alors, comment saurons-nous quand c'est fait ? Par exemple, si nous examinons un ticket en tant que client, je souhaite voir les informations de suivi. Les critères d'acceptation seraient, par exemple, que le client puisse lire le numéro de suivi. Le client peut cliquer sur un lien pour accéder au site Web des carrières et obtenir plus d'informations. Et c'est peut-être le critère d'acceptation de ce billet. La BA est donc chargée de traduire ces exigences générales en exigences plus spécifiques avec lesquelles les ingénieurs peuvent travailler. 28. Ingénieurs: Les ingénieurs ou les personnes qui travaillent dessus, quel que soit le sujet, quel que soit le projet sur lequel vous travaillez. C'est pourquoi on l'appelle souvent l'équipe de développement, mais cela inclut un domaine plus large que celui-ci. Ainsi, des personnes telles que les testeurs, les ingénieurs en automatisation , les ingénieurs en assurance qualité, toutes ces personnes y seraient incluses. Et cela dépend vraiment du type de projet sur lequel vous travaillez quant à ce que cela inclurait. Dans un projet logiciel, vous auriez besoin vos véritables ingénieurs logiciels et probablement de quelques ingénieurs d'automatisation des tests. Et puis le test, c'est en soi. Mais si vous travaillez, par exemple, sur un projet de recherche, vous êtes ingénieur. L'équipe de développement serait en fait l'équipe de recherche ou les chercheurs. Si votre projet consiste à construire une maison, il peut s'agir de constructeurs , d' ouvriers pour hommes, etc. À certains égards, cela n'a pas d' importance, car dans Scrum, l' accent est vraiment mis sur la collaboration en équipe pour livrer les tickets. Ainsi, même si vous avez vos rôles individuels : je suis designer, ingénieur logiciel, test ou quoi que ce soit d'autre, ce qui compte vraiment, c'est le résultat de l'équipe. Ainsi, partout où chacun s' en tient à son rôle, fait des choses différentes s'entraide. Ce qui importe, c'est que tout le monde travaille ensemble pour atteindre cet objectif de sprint, à savoir livrer ces tickets, sans trop se concentrer sur la compartimentation de tout le monde au sein de cette équipe de conception. C'est l'équipe de mise en œuvre, c'est l'équipe de test. Il n'y a qu'une seule équipe Scrum composée de chacun qui contribue à la réussite du projet. 29. parties prenantes potentielles: Les parties prenantes sont des personnes extérieures à l'équipe, mais intéressées par le travail de l'équipe. Alors quel genre de personnes ne l'est peut-être pas ? Voici quelques exemples : les dirigeants de notre entreprise, les membres d'autres équipes travaillant sur des solutions de projet connexes, les architectes et les architectes techniques travaillant au sein de l'entreprise. Les équipes de marketing et de vente. domaine juridique pourrait également être impliqué, et des acteurs tels que les clients, fournisseurs et les régulateurs pourraient également être parties prenantes. Les propriétaires de produits invitent souvent les parties prenantes aux évaluations des sprints, et ils sont également invités à participer à la Scrum quotidienne. Mais ils n' auraient aucun mot à dire sur The Daily Scrum et pourraient donc venir écouter, mais ce seront les membres de l'équipe Scrum qui parleront. Les parties prenantes ne sont généralement pas invitées à la planification du sprint ou rétrospective, car c'est une zone sûre où l'équipe peut discuter de son fonctionnement en interne. 30. Une équipe de scrum typique: Regardons une équipe Scrum typique. Au sein de l'équipe, nous avons donc probablement un chef de produit, Scrum Master et des analystes commerciaux expérimentés ou plus. Donc, un propriétaire de produit, un Scrum Master, généralement un ou deux analystes commerciaux. Et puis il y a les ingénieurs. Les ingénieurs couvrent vraiment tous les acteurs. Donc, les développeurs, les concepteurs, assurance qualité des tests, les chercheurs si vous travaillez sur un projet de recherche, et les ouvriers, si vous construisez une maison, peu importe ce que c'est, ce sont eux qui occupent des tickets. Et puis, en dehors de l' équipe, vous avez des parties prenantes. Cela pourrait donc inclure les chefs d' entreprise, les membres d'autres équipes, les juridiques du marketing et des ventes, les clients et les fournisseurs, ainsi que les régulateurs. 31. Ajouter les membres de l'équipe: Si vous ajoutez des membres à votre équipe, comment en tiens-tu compte ? La quantité de travail qu'ils peuvent effectuer lors la planification des prochains sprints. Eh bien, la première chose à faire est de calculer notre vitesse et nos points par membre de l'équipe. Supposons que notre vitesse soit de 48 et que l'équipe compte actuellement six membres. Ensuite, nous pouvons diviser 48 par six et nous pouvons voir que chaque membre de l'équipe produit environ huit points. Si nous ajoutons ensuite un nouveau membre à l'équipe, nous savons que nous aurons encore huit points à jouer. Cela signifie donc que lors du premier sprint, nous utilisons normalement un multiplicateur de zéros. Nous partons donc du principe qu' ils ne vont pas marquer de points pour le premier sprint. Au deuxième sprint, nous serons en forme s'il y avait huit points, le temps augmentera de 0,5, ce qui nous donnera quatre points. Ensuite, lors du troisième sprint, nous partons du principe qu'ils sont à la hauteur et qu'ils contribuent, ce qui signifie qu'ils peuvent donner les huit points à l'équipe. 32. Types de problème: Dans cette leçon, nous allons examiner problèmes ou les types de tickets. Et il y en a trois principaux. La première est donc une histoire d'utilisateur. Il s'agit donc d'une nouvelle fonctionnalité écrite du point de vue d'un utilisateur, d'un produit. Par exemple, tant qu'utilisateur, je souhaite pouvoir consulter avis sur les produits que je suis en train de consulter. Cela ajoute quelque chose de nouveau au système. Ensuite, nous avons un défaut ou un livre, un livre avec une fonctionnalité existante qui doit être corrigée. Nous l'avons déjà envoyé et il faut le réparer. Nous devons donc obtenir un ticket. Maintenant, ce qui est important, c'est que ce n'est un bogue que s'il ne fonctionne pas comme prévu. Donc, si nous construisons quelque chose d'une certaine manière et que le manager le dit, je veux que cela fonctionne différemment. Ce n'est pas un défaut, c'est une nouvelle histoire utilisateur change le fonctionnement du système. Si le billet d'origine répond aux critères d'acceptation, il ne s'agit pas d'un défaut. S'il ne fait pas ce qui était indiqué sur le billet d'origine, alors faites-le et augmentez-le en bloc. Et puis il y a une dette technologique. Il s'agit donc de problèmes liés au code qui n' ont aucun effet observable sur le système. Donc, quelque chose de sous-jacent que ce développeur sait que nous devons corriger, mais en fait, un utilisateur ne le remarquera pas nécessairement. 33. Histoires d'utilisateurs: Dans Agile, nous écrivons des tickets sous forme de témoignages d'utilisateurs. Cela signifie qu' au lieu d'avoir un ticket qui indique quelque chose comme un formulaire de connexion, nous écrivons quelque chose comme : en tant que client, je veux vérifier l'état de ma commande. Maintenant, cela implique souvent un formulaire de connexion afin qu'ils puissent se connecter et voir leurs commandes, mais ce n'est peut-être pas le cas. Alors pourquoi l'écrivons-nous dans ce format étrange de user story ? Quelles histoires permettent de se concentrer sur l'utilisateur. Nous nous concentrons donc sur le parcours client, qui consiste à suivre tout ce que nous créons et en écrivant de cette manière nous concentrons vraiment sur l'utilisateur final. Ensuite, cela évite les travaux inutiles. Donc, si vous avez quelque chose comme ça, je veux voir mes factures précédentes, celles qui nécessitent un formulaire de connexion. Dans la leçon suivante, nous examinerons une bonne étude de cas qui montre que ce n'est peut-être pas toujours le cas. Nous pouvons donc nous épargner travail si nous utilisons ces user stories. Cela crée des critères d'acceptation très clairs. S'il s'agit de votre billet, il est écrit formulaire de connexion. Eh bien, comment savoir si l'utilisateur est capable de réaliser ce qu'il souhaite ? Veulent-ils se connecter ? Quel but cela leur donne-t-il ? Alors que si c'est quelque chose comme je le souhaite en tant que client, je veux vérifier l'état de ma commande. Il est très clair où le système V0 le fait ou non. Le client peut-il voir l'état de sa commande ? Oui ou non ? Vous avez là des critères d'acceptation très clairs. C'est pourquoi nous utilisons des user stories. 34. Étude de cas de développement axé sur le comportement: Ce dont nous parlons ici lorsque nous écrivons des histoires de cette manière, c'est du développement axé sur le comportement. Il s'agit d'une méthodologie qui dit que nous écrivons ce que les utilisateurs devraient être capables de faire en anglais clair. Ensuite, cela devient notre critère d'acceptation. Nous écrivons des tests automatisés par rapport à cela pour voir si le système le fait. Disons qu'il y a énormément de travail et que j'ai une étude de cas pour vous. Il y avait donc un cabinet d'expertise comptable et ce qu'il voulait faire en sorte que ses clients puissent consulter leurs factures précédentes. Maintenant, si nous nous sommes lancés là-dedans et que nous l'avions construit de la manière habituelle, nous aurions dit : Eh bien, d'accord, nous avons besoin d'un formulaire de connexion et chaque cliente a besoin d'un identifiant . Ils doivent donc saisir son adresse e-mail et ensuite ils ont besoin d'un mot de passe. Le client aurait donc encore un mot de passe à retenir dans cette mer de milliers de mots de passe et il l'oubliera probablement. Nous aurions donc besoin de créer un lien de mot de passe oublié qui leur enverrait un nouveau mot de passe par e-mail. Ainsi, lorsqu'ils oubliaient inévitablement leur mot de passe, ils pouvaient en demander un nouveau. Ils pouvaient réinitialiser leur mot de passe, puis se connecter et voir ces anciennes factures. Ce produit utilise plutôt témoignages d'utilisateurs et un développement axé sur le comportement. Le critère d'acceptation était donc le suivant : en tant que client, je souhaite consulter les factures précédentes. Puis, lorsque le projet a examiné les choses de cette façon, ils se sont rendu compte que la chose la plus simple à faire était de permettre au client de saisir son adresse e-mail. Et cela leur enverrait par e-mail un lien magique qui leur permettrait de voir toutes leurs factures précédentes. Ainsi, plutôt que d'avoir à créer l'ensemble du formulaire de connexion et du formulaire de mot de passe oublié, plutôt que d' avoir à mémoriser un autre mot de passe en le regardant sous l'angle de l'histoire utilisateur, tout le monde s'est rendu compte que le moyen le plus rapide de le faire était simplement leur envoyer par e-mail un lien qui leur permettra d'y accéder. Et c'est aussi sûr que d'avoir un identifiant, car vous avez accès à la messagerie électronique et ils peuvent consulter toutes leurs factures précédentes sans avoir à effectuer de travail de développement et sans que l'utilisateur n'ait à enregistrer un autre mot de passe. À l'aide de ces témoignages d'utilisateurs, l'utilisation de cette approche de développement axée sur le comportement de gagner énormément peut permettre de gagner énormément de temps et offrir une meilleure expérience au client. 35. Être "assez bien": Un concept clé ici est l'idée que quelque chose est assez bon. Nous devons créer la fonctionnalité jusqu'à ce qu'elle réponde aux exigences des utilisateurs, aux critères d'acceptation. Ensuite, nous devons arrêter et fermer ce ticket. Et si nous devons travailler davantage plus tard, nous pouvons créer un nouveau ticket. Mais en gros, ce que nous essayons de réaliser, ce qui doit être réalisé, en supposant que nous ayons besoin de toutes ces choses supplémentaires. Supposons, par exemple, que nous ayons notre boutique en ligne et que vous puissiez consulter la page des produits et que nous souhaitons montrer des produits similaires. Et peut-être que l'histoire de l'utilisateur est suivante : en tant qu'utilisateur, je souhaite voir des produits similaires à celui-ci. Eh bien, nous pourrions partir et créer un système d'IA extrêmement complexe qui recommande des produits. Mais nous pourrions également simplement y placer des produits appartenant à la même catégorie qui répondraient aux besoins des utilisateurs. Et nous ne nous retrouverions pas avec une tâche de développement énorme, car peut-être que le simple fait de montrer des produits similaires et la même catégorie serait génial. Et nous pouvons expédier cela très rapidement et cela fonctionnerait. Nous n'aurions aucun avantage à créer un énorme système d'IA pour recommander des produits. Ou peut-être que nous expédions la solution la plus simple. Et puis nous nous rendons compte que nous obtiendrions beaucoup de valeur si nous avions de meilleures recommandations de produits. À quel point nous pouvons construire la meilleure solution, car nous savons alors que cela vaut la peine d'investir du temps. C'est ce que l'on appelle la méthodologie Lean. Vous pouvez donc obtenir quelque chose sous notre forme de base. Vous voyez ce que les utilisateurs apprécient, vous voyez à quoi ils réagissent, puis vous réévaluez et vous recommencez Tout comme nous avons parlé de ces méthodologies agiles, vous devez itérer, livrer quelque chose, comment cela fonctionne, l'améliorer, plutôt que de créer cet énorme produit qui risque d'échouer dès le départ. 36. Investir: Dans cette leçon, nous allons examiner l'acronyme invest qui peut être utilisé pour créer de bonnes histoires d'utilisateurs. Je suis donc pour chaque indépendant, chaque magasin doit se débrouiller seul et est négociable. Les histoires ne sont pas fixes mais peuvent être mises à jour si nécessaire. donc frustrant d'intégrer ces informations et d'autres éléments tels que , même lorsque vous commencez à implémenter si quelque chose ne peut pas être , si quelque chose ne peut pas être fait pour des raisons techniques , si quelque chose ne peut pas être fait pour des raisons techniques, mais vous devez peut-être réfléchir à la manière de retravailler l'histoire. Si tel est le cas, V signifie « valeur », il doit apporter une véritable valeur ajoutée à l'utilisateur. Comment l'utilisateur bénéficiera-t-il d' une meilleure expérience grâce à ce changement ? E est pour estimable. Vous devez donc avoir une idée approximative du temps que cela prendra. Si vous ne pouvez pas l'estimer, vous devez probablement créer un ticket d'enquête. Un ticket qui ressemble à ce que je souhaite, en tant que développeur, savoir combien de temps il faudrait pour implémenter cette fonctionnalité. Ensuite, planifiez cela , disons une demi-journée et voyez si vous pouvez vous débrouiller sur un calendrier difficile. Ensuite, en fonction de ce calendrier, vous saurez si vous souhaitez poursuivre avec le ticket ou non. S est pour les petites entreprises, sorte qu'il peut être livré en un seul sprint. Tout ce qui nécessite plusieurs sprints doit être détaillé plus en détail. Et T est testable. critères d'acceptation clairs, comment un utilisateur peut-il savoir si ce ticket est complet ? Et idéalement, nous avons également des tests automatisés. réfléchissons donc vraiment à la façon dont nous pouvons le tester dans le cadre d' une couverture de test automatique dès le départ. 37. Prototypage et laboratoires d'utilisateurs: Un bol coopératif entre Agile et Lean consiste à le construire rapidement, créer quelque chose, en gros, à le présenter à l' utilisateur et à voir comment cela fonctionne. Maintenant, le prototypage est un bon moyen de le faire. Vous pouvez donc utiliser quelque chose comme Adobe XD pour créer des interfaces utilisateur fictives. Ensuite, vous pouvez le donner à un utilisateur. Découvrez comment ils utilisent le système, voyez comment ils s'y prennent, apportez quelques modifications avant de créer eux-mêmes le logiciel complexe. Comment faites-vous cela ? Eh bien, vous le modélisez dans quelque chose comme Adobe XD. Ensuite, vous demanderiez à un utilisateur de venir peut-être dans un laboratoire. Tu les filmerais, tu filmerais l'écran. Regardez-les pendant qu'ils le font et prenez simplement des notes sur ce qui fonctionne pour eux. Engagez un dialogue avec eux, dites : « D'accord, eh bien, d'accord, j' aimerais que vous trouviez ce produit. Comment t'y prendrais-tu ? Vont-ils parcourir, faire recherche et consulter l'historique de leurs commandes pour voir s' ils l'ont déjà acheté et ils pourront trouver le lien de cette façon ? Quelle méthode leur conviendra le mieux. Vous leur donnez la démo, vous leur demandez de faire la tâche. Vous leur expliquez où ils envisagent de vous expliquer, d'accord ? Je l'ai dit, essayez de trouver ce produit. À quoi penses-tu maintenant ? Et l'utilisateur pourrait dire : « Oh, eh bien, j'utilise probablement une recherche, et la recherche est ma méthode préférée pour le faire. Ensuite, ils pouvaient chercher et remonter. De cette façon, nous savons exactement comment un utilisateur souhaite que le système fonctionne, et si c'est là où nous pouvons construire ce système et si nous pouvons l'adapter à ses besoins. Maintenant, cela prend beaucoup de temps, mais demandez à quelqu'un de venir dans votre bureau, installez un laboratoire où vous pouvez suivre ce qui se passe ou l'observer et lui confier un ensemble de tâches. Tout cela prend du temps, mais ce temps est vraiment rentable lorsque vous livrez quelque chose qui correspond exactement à ce que le client souhaite. Si vous pouvez voir comment ils utilisent le système, optimisez-le en fonction d' eux et obtenez réellement ce feedback dès le premier jour. Cela prend beaucoup de temps au départ, mais votre temps de développement est ensuite plus court car vous créez exactement ce qu'ils veulent. Contrairement aux systèmes traditionnels, vous vous chargeriez de la majeure partie du développement. Puis il s'est avéré que n'était pas vraiment ce qu'ils voulaient et nous avons dû tout repenser en investissant ce temps tôt. Nous pouvons ensuite créer exactement ce que souhaite l'utilisateur et fournir cette fonctionnalité plus rapidement. C'est vrai, c'est exactement ce qu'ils doivent faire. Et nous pouvons le faire par des moyens tels que prototypage rapide et les laboratoires utilisateurs. 38. Exigences fonctionnelles: Les exigences fonctionnelles vous indiquent ce que le système doit être capable de faire. Par exemple, si nous disons « essayer de vérifier l'état de notre commande », l' exigence fonctionnelle peut être que l'utilisateur puisse voir le statut et les autres clients ne puissent pas voir la commande spécifique du client. Ou si nous construisons un système de connexion, par exemple via un mot de passe, par e-mail, via une authentification à deux facteurs ? Et quels sont les mots de passe ? Réinitialiser ? Existe-t-il donc un mécanisme de réinitialisation ? Peut-être que les utilisateurs devraient pouvoir le faire, devraient être invités à changer leur mot de passe tous les 90 jours. Toutes ces exigences sont des exigences fonctionnelles, car les exigences fonctionnelles documentent les fonctions du système. Ils documentent le fonctionnement du système. Pas légèrement différent des exigences non fonctionnelles. Et quand j' en parlerai, je pense que vous serez en mesure de voir la différence entre lequel est lequel. 39. Exigences non fonctionnelles: Les exigences non fonctionnelles sont des éléments importants ou essentiels, mais qui n'affectent pas directement le fonctionnement du système. Alors, quel genre de choses cela pourrait-il être ? Eh bien, des choses comme les performances, quelle vitesse le système réagit-il ? Disponibilité et adaptation à des charges élevées ? Le service sera-t-il toujours disponible pour la surveillance de la sécurité ? Alors, comment saurez-vous si quelque chose ne fonctionne pas dans les rapports ? Pouvons-nous demander au backend ? Pouvons-nous voir ce qui se passe ? Accessibilité et facilité d'utilisation ? Ces exigences sont probablement plus fonctionnelles maintenant, c'est vraiment important pour celles-ci, puis pour la documentation. Comment les futurs développeurs ou les utilisateurs du système sauront-ils comment il fonctionne ? Notez donc que ces éléments ne sont pas facultatifs, n'est-ce pas ? Tout comme la sécurité et l'accessibilité sont des exigences légales, car nos projets doivent être accessibles. Et si nous ne disposons pas d'une sécurité suffisante, nous allons enfreindre la loi GDPR. Ces éléments ne sont donc pas options supplémentaires dont ils ont tous besoin, mais ils ne font pas réellement partie du fonctionnement du système. Ainsi, par exemple si vous avez une page d'état de commande qui indique au client où se trouve sa livraison, la condition fonctionnelle est que la page lui indique où se trouve sa livraison. Mais il y a aussi un tas d' exigences non fonctionnelles . Alors, par exemple quelle vitesse une page met-elle à charger ? Eh bien, ça pourrait prendre, pas une seconde ou une minute. Maintenant, si cela prend 1 minute, les utilisateurs vont être vraiment agacés et ils vont probablement partir et faire leurs achats ailleurs. Mais techniquement, s' il l'affiche, il répond aux critères d'acceptation, l' utilisateur peut voir l'état de la commande. Ce n'est donc pas techniquement une exigence fonctionnelle, mais c'est vraiment important. De même, en matière de sécurité, si quelqu'un d'autre peut voir l'état de sa commande, cela ne constitue pas nécessairement violation des exigences fonctionnelles. Mais ce serait vraiment important car nous exposerions des données privées à quelqu'un qui ne devrait pas y avoir accès. Il est donc très important de réfléchir aux exigences non fonctionnelles ainsi qu' aux exigences fonctionnelles. Mais ils sont faciles à oublier. Si vous oubliez de créer une fonctionnalité et que vous oubliez de la soumettre aux tests de sécurité ou d'accessibilité, F ou quelque chose comme ça se gâche. C'est pourquoi il est très important d'inclure ces exigences non fonctionnelles dans la définition effectuée. N'autorisez donc pas le déplacement d'un ticket dans la colonne Terminé à moins qu'il ne soit surveillé, à moins qu'il n'ait été testé pour sa convivialité, moins que ses performances n'aient été testées. Mais toutes ces choses qui figurent dans votre définition de « terminé » et ensuite, vous savez, pour les comparer à elles afin de savoir que tout ce qui entre dans cette définition ne les qualifie pas répond aux exigences fonctionnelles et non fonctionnelles. 40. Dette de la technologie: Il existe un type de ticket qu'un ingénieur peut soulever, à savoir la dette technologique ou la dette technique. Cela se produit donc lorsque nous prenons des mesures pour accélérer la livraison, sachant que nous devrons y remédier plus tard. Par exemple, disons que nous développons logiciel qui ressemble peut-être à une application météo. Comment extraire des données météorologiques provenant d' une source externe ? Et nous avons utilisé la bibliothèque a. Mais maintenant, nous devons utiliser la bibliothèque be parce qu'elle est meilleure ou parce qu'elle nous permet de faire quelque chose et que nous voulons simplement passer à la bibliothèque B. Un moyen très rapide de le faire serait d'intégrer la bibliothèque B dans notre application sans supprimer la bibliothèque a, comme cela répondrait toujours aux exigences si nous utilisions maintenant la bibliothèque B, même si la bibliothèque a était toujours intégrée ou introduite dans la base de code d'une manière ou d'une autre. Maintenant, si nous le faisions, cela générerait une certaine dette technologique. Parce que la bibliothèque a doit encore être supprimée à un moment donné, nous ne l'avons tout simplement pas encore fait. Maintenant, pourquoi est-il important de s'attaquer à la dette technologique ? Tout d'abord, cela rend le code beaucoup plus facile à lire si vous êtes nouveau dans le projet et que vous vous demandez  : « Oh, pourquoi utilisons-nous la bibliothèque be, mais nous avons aussi la bibliothèque a dedans ». Qu'est-ce qui se passe là-bas ? Cela peut être très déroutant et, par conséquent, il est plus difficile d'embarquer des personnes. Il est plus difficile de réaliser des travaux de développement futurs. Cela peut ralentir des choses comme le processus de construction. Ainsi, lorsque nous compilons le logiciel, si nous introduisons deux bibliothèques , cela le rendra plus volumineux que nécessaire, en le ralentissant. Ou cela pourrait affecter les performances, par exemple s'il s'agissait d'une bibliothèque JavaScript côté client. Et nous introduisons la bibliothèque A, la bibliothèque B, mais en utilisant uniquement la bibliothèque be. Ensuite, nous chargerions la bibliothèque a dans le navigateur de l'utilisateur sans en avoir besoin. Cela a donc de nombreux effets non fonctionnels, même si cela n' affecte pas nécessairement le fonctionnement du logiciel. C'est la dette technique et c'est pourquoi il est important d'y remédier. 41. Annuler un sprint: En de rares occasions, les exigences du projet peuvent changer en cours de sprint. Nous avons ce principe de Scrum selon lequel rien de nouveau n'entre dans un sprint. Nous définissons donc les tâches que nous voulons effectuer au début du sprint, puis nous commençons le sprint et nous les réalisons. Et nous n'apporterons pas d'autres billets avant le prochain sprint. Alors, que devons-nous faire si ce sur quoi nous travaillons devient inutile et que nous n'avons plus besoin d' atteindre les objectifs du sprint ? Eh bien, dans de tels cas, nous pouvons annuler un sprint et le propriétaire du produit a le pouvoir d'annuler le sprint. Ils pensent que les exigences ont changé et qu'il ne sert à rien de continuer à travailler sur ce sur quoi nous travaillons. Ils peuvent aller de l'avant et annuler le sprint. Tous les tickets en cours de traitement sont ensuite réintégrés au backlog des produits et nous lançons un nouveau sprint. Nous avons donc une nouvelle réunion de planification du sprint. Nous déterminons la date à laquelle notre papier journal sera disponible et nous ajoutons des tickets de données sur les nouveaux billets afin de répondre aux nouvelles exigences. 42. Qu'est-ce que la gestion de la libération agile ?: Lorsque nous parlons d'Agile, nous parlons de petites itérations, petites fonctionnalités que nous développons, que nous préparons et que nous améliorons ensuite. Aujourd'hui, certaines entreprises adoptent l'idée de travailler en mode Agile, mais en réalité, les déploiements se font toujours selon la méthode Big Bang. Toutes ces équipes Agile travaillent donc sur les fonctionnalités d'un logiciel, mais le logiciel n'est expédié que tous les deux mois et toutes les fonctionnalités sont publiées en même temps. Ainsi, lorsque nous parlons d' Agile Release Management, nous parlons de nous débarrasser de cette version Big Bang. Je le remplace par un cycle plus itératif, plus conforme au travail de développement que nous effectuons en sprint, en sprints et au sein des nous effectuons en sprint, en équipes Scrum. L'idée est donc que vous pourriez obtenir un ensemble de fonctionnalités et les publier indépendamment des fonctionnalités sur lesquelles d'autres équipes travaillent. Supposons donc que l'équipe a crée des fonctionnalités et les déploie, et que équipe crée certaines fonctionnalités et qu'elles soient déployées séparément. Il se peut même que nous parlions de billets individuels. TMA termine donc une étape dans le cadre de cette finition, en fusionnant dans la base de code principale, en la déployant, et en déployant ces problèmes un par un. Quelle que soit la manière exacte dont la gestion des versions Agile finit par être mise en œuvre. Il s'agit de réduire ce cycle de développement, ce cycle de vie des logiciels, afin de pouvoir développer de petites fonctionnalités sans avoir lancer de nombreuses fonctionnalités à lancer de nombreuses fonctionnalités en même temps nombreuses versions et en disant vouloir régulièrement de petites versions, conformément au processus Agile. 43. Cycle de gestion de la libération: Tout développement passe par un cycle. Et dans ce cas, nous allons examiner le cycle de gestion des versions. Vous pouvez donc vraiment commencer à n'importe quel point, mais nous commencerons par le haut avec les demandes de modifications. Le propriétaire du produit souhaite que quelque chose change. Nous concevons donc une solution, nous créons des critères d'acceptation qui mettraient en œuvre ce changement. Nous le construisons ensuite et nous écrivons le code , puis nous l'envoyons à quelqu'un d'autre pour qu'il puisse vérifier que le code a du sens et qu'il s'agit d'une bonne idée. Nous le testons ensuite pour nous assurer qu'il fonctionne et s'il réussit, ce morceau de code sera déployé. Nous aurons ensuite des mesures, des rapports sur ses performances. Et s'il y a des problèmes, nous le ferons, nous en signalerons certains. Nous travaillerons ensemble en équipe pour signaler un défaut ou créer une autre histoire utilisateur pour le corriger. Ensuite, cela se répercute sur la demande de modifications. 44. Avantages de la gestion de la libération agile: Pourquoi voudrions-nous publier des versions agiles ? Eh bien, voici les avantages réels du processus de publication Agile. La première est que cela permet de faire sortir les choses plus rapidement. Nous cherchons donc à raccourcir ce cycle de développement. Vous créez donc une fonctionnalité, vous la publiez immédiatement, vous pouvez commencer à recevoir des commentaires à son sujet immédiatement. S'il s'agit d'un changement important, il sortira plus rapidement, regroupé dans une version plus importante plus tard. Deuxièmement, cela fonctionne conformément à Agile. Donc, si toutes ces équipes Scrum travaillent de cette manière très agile, pourquoi votre processus de publication ne le prendrait-il pas en charge ? Pourquoi reviendrions-nous soudainement à l'approche du Big Bang, qui comporte tous ses risques d'échec ? Troisièmement, cela permet à l'équipe Scrum d'assumer la responsabilité de la publication. À l'ancienne méthode, toutes les équipes développaient des éléments puis certains membres de l' équipe devaient prendre responsabilité de les publier, d'examiner les bogues et de surveiller l'impact des fruits publiés. Lorsque vous le redonnez à un processus Agile dans lequel chaque équipe peut publier les fonctionnalités sur lesquelles elle a travaillé. L'équipe Scrum peut alors assumer la responsabilité de tout cela. Ils peuvent développer les fonctionnalités, surveiller ce qui se passe. Ils peuvent effectuer une annulation si nécessaire. S'il y a le pire des scénarios, il y a des problèmes et ils doivent le faire. Mais cela correspond à cette idée selon laquelle les équipes Scrum sont des unités indépendantes et interfonctionnelles. Ils assument la responsabilité du ticket du début à la fin et peuvent guider l'ensemble du processus sans être bloqués par les autres équipes. Et quatrièmement, cela peut être plus sûr. Il y a donc une sorte de mentalité old school à l'origine de cette idée. Au fur et à mesure que vous créez toutes ces fonctionnalités, vous les donnez à vos testeurs et votre texte contient tous ces scénarios pour vous assurer que tout fonctionne ensemble. Mais en réalité, lorsque vous publiez 100 fonctionnalités provenant de dix équipes différentes en même temps, elles interagiront probablement d' une manière que vous n'auriez pas imaginée et vous risquez fort de voir les choses mal tourner. Et lorsque les choses tournent mal, il est très difficile de revenir en arrière, car vous annulez 100 fonctionnalités proposées par dix équipes. Lorsque vous autorisez ces très petites versions itératives. Ensuite, si une version ne fonctionne pas correctement, il est très facile de revenir en arrière car vous ne modifiez qu'une seule chose. Et l'équipe qui l' a modifiée gère la version afin de pouvoir revenir en arrière très rapidement. Je dirais que la gestion agile des versions est non seulement plus rapide et meilleure, mais qu'elle est également plus sûre. 45. Calendrier de publication commun: Examinons quelques calendriers de publication courants. Eux tous. Le style le plus ancien serait ce que nous appelons une sortie de Big Bang. Il s'agit donc d'une version importante qui permet à plusieurs équipes et à une grande équipe de test d'examiner toutes les fonctionnalités. Donc, disons que vous avez trois équipes différentes travaillent sur un produit. Vous travaillez sur Microsoft Windows 9 et vous souhaitez publier Microsoft Windows 10. Toutes les équipes qui y travaillent ont donc intégré toutes leurs modifications et vous les publiez. Big Bang qu'est Windows 10 intègre toutes les modifications en même temps. Et vous avez besoin d'une énorme équipe de test pour examiner toutes les fonctionnalités, car tout le monde apporte ces modifications et on ne sait pas exactement comment elles interagiront ou comment les choses vont échouer, car vous devez tout retester. C'est donc très lent. Ensuite, nous avons quelque chose comme un sprint. Nous abordons donc ici notre processus de publication plus agile. Donc, une publication à la fin de chaque sprint. C'est bien car son calendrier de sortie est très prévisible. Et à quoi bon ? Par exemple, vous pouvez avoir des attelles où vous avez beaucoup de choses à libérer et vous avez des sprints où vous n'avez pas grand-chose à libérer. Donc, vous voulez probablement obtenir ce genre de choses lorsque vous produisez des tas de choses qui peuvent être publiées, vous voulez probablement les sortir plus rapidement. Et quand vous ne produisez pas tant de choses qui doivent être envoyées, alors pourquoi le feriez-vous, pourquoi publieriez-vous ? Cela crée donc un peu de flexibilité à cet égard. En descendant, nous avons cette idée de sortie de fonctionnalité. Donc, publiée manuellement, chaque fonctionnalité est prête. L'équipe Scrum va donc préparer une fonctionnalité. Ensuite, vous allez le fusionner manuellement dans la base de code et le publier. Rapide. De petits changements. C'est agréable et facile de revenir en arrière. Une certaine gestion est requise, comme il s'agit d'un processus de publication manuel. Mais même dans le monde Agile, les entreprises ont vraiment adopté la méthode Agile. La publication de fonctionnalités reste très populaire, car elle permet de procéder à de petits changements rapides sans courir le risque d'une continuité, ce dont nous parlerons ensuite. C'est donc en continu chaque modification, dès que vous fusionnez quelque chose, est simplement transmise à votre serveur de production. Hum, donc c'est super rapide, très facile à annuler parce que vous n'avez qu' une seule validation. Ainsi, lorsque vous annulez des éléments, la seule chose à prendre en compte est que la dernière validation devient un peu délicate si vous vous rendez compte qu' elle est décomposée. Et puis peut-être devez-vous avoir plusieurs validations en retour. Mais si vous n'en publiez qu'un, testez, s'il fonctionne en production, puis à autre chose et pouvez avancer très rapidement. Mais cela nécessite un très haut niveau de couverture des tests, car littéralement tout va être repoussé et peut donc tomber en panne à tout moment. Et vous avez vraiment besoin de ce niveau élevé de couverture des tests pour vous assurer que tout fonctionne. 46. Les clés de la réussite: Voici quelques clés du succès d'Agile Release Management. La première est d'obtenir l' adhésion de la direction. Cela vaut pour pratiquement tout ce que vous faites. Si vous pouvez obtenir l'adhésion de la direction, vous aurez beaucoup plus de facilité. Et comme nous en avons discuté précédemment, il existe une sorte de direction de la vieille école qui préfère les versions Big Bang parce qu'elle pense que c' est plus sûr. J'ai donc tendance à me concentrer sur leur vente, en partant de l' idée que si nous publions ces très petites versions ces très petites versions, nous pouvons les annuler très facilement. Et cela ne ferait que déployer une chose à la fois afin que nous sachions comment elle interagit avec tout le reste. C'est plus sûr. Ainsi, non seulement nous allons obtenir vos fonctionnalités plus rapidement, mais aussi faire en sorte que les choses tournent mal moins souvent. La deuxième consiste à concevoir des fonctionnalités en tenant compte du déploiement. Alors, lorsque vous créez une fonctionnalité, comment allez-vous la sortir ? Des éléments tels que les commutateurs de fonctionnalités en sont un bon exemple. Vous pouvez donc déployer le code si vous le placez derrière le commutateur de fonctionnalités, puis si vous l'activez ultérieurement. Déployez donc le code, activez la fonctionnalité. Si cela ne fonctionne pas, il vous suffit de l'éteindre immédiatement et vous n'avez pas à paniquer. Et si vous pouvez réfléchir à l' avance aux étapes dont j'aurais besoin pour déployer ce ticket, vous constaterez qu'il sera beaucoup plus facile de publier ces versions. La troisième est d'avoir un bon plan de réduction. Si quelque chose ne va pas, pouvez-vous revenir en arrière très rapidement ? Traditionnellement, en matière de méthodologie en cascade, nous n'avions pas de méthode idéale pour le faire, mais c'est beaucoup plus facile lorsque nous publions de très petites versions et cela très petites versions et renforce la confiance si, même en cas de problème, vous vous contentez de taper cette petite commande. Il roule automatiquement sur tout le dos et tout va bien. Quatrièmement, avoir une couverture élevée des tests automatisés. Vous voulez donc vous assurer qu' fois la modification apportée, vous pouvez exécuter l'ensemble du parcours client, c'est-à-dire tous les scénarios que vous devez réaliser automatiquement à l'aide de tous les outils de test automatisés disponibles. Parce que lorsque vous publiez de très petites versions, vous devez effectuer des tests en permanence. Vous apportez un changement, vous testez tout et vous apportez un changement, vous testez tout. La seule façon d'y remédier est d'utiliser des tests automatisés car vous ne pourriez pas avoir assez de testeurs pour réaliser tous ces scénarios. Donc, si vous obtenez cette couverture des tests, cela vous donne, à vous et à la direction, la certitude que les choses vont fonctionner. Et cinquièmement, coordonnez-vous avec les autres équipes. Assurez-vous de savoir ce que font les autres équipes et comment elles peuvent interagir avec vous. Et aussi pour ce qui est de la planification de la sortie d'un Ukrainien ce matin , s'en sortent-ils et le matin ? Comment allez-vous savoir s'il sortent-ils le matin ? Comment allez-vous savoir s'il pourra les sortir à tour de rôle, afin que vous puissiez faire les choses rapidement et efficacement ? Vous n'allez donc pas vous marcher les pieds l'un sur l'autre. 47. Intégration continue: L'intégration continue exécute les tests automatisés après chaque validation. Il se peut donc que chaque fois un développeur lance du code, qu'il l'exécute, ou qu' il fusionne un ticket dans un master, vous souhaitez l'exécuter sur ces branches en fonction du montant que vous souhaitez dépenser pour vos outils d'intégration continue. Je vais maintenant vous montrer un exemple utilisant Travis, qui n'est qu'une des options disponibles. Et j'ai ce projet ici, qui est un environnement d' apprentissage open source. Et j'ai défini un fichier de configuration ici juste pour indiquer au serveur d'intégration continue qu'il est écrit en PHP. Et je voulais le tester à nouveau, soudain, point 4.8, 0.0. Et voici toutes les étapes à suivre pour le configurer. Cela signifie donc que lorsque je lance un commit, il exécute les tâches à la fois sur PHP et PHP 7.01. Nous pouvons les examiner et voir ce qui s'est passé. Travis a tout établi. Il exécute l'installation comme demandé , puis il exécute une unité PHP pour exécuter les tests et c'est réussi. C'est donc génial. Et puis il fait exactement la même chose ici, mais il fonctionne à nouveau, 7.4. Ainsi, si vous avez plusieurs configurations de production différentes, vous pouvez faire tester le serveur d'intégration continue rapport à toutes ces configurations. Et je peux également voir un historique complet. Donc, si je vais dans l'historique des builds, cela indiquera que chaque fois que je lance une validation, c'est qu'une compilation est terminée. Et par exemple, ici, nous en avons eu un qui a échoué à la construction. Nous pouvons donc entrer et nous ne pouvons malheureusement plus voir les journaux, mais nous savons que quelque chose s'est mal passé là-bas. Et puis je répare autre chose ici. Donc, dans ce cas, il s'agissait de modifier la version de PHP pour qu'elle corresponde au serveur. Et nous pouvons voir que la version fonctionne à nouveau. C'est donc très facile à retrouver. Vous pouvez exécuter les tests automatisés dans divers environnements et voir très facilement ce qui ne va pas, car vous pouvez voir exactement où la version a cessé de fonctionner. 48. Livraison continue: continue constitue une étape supplémentaire par livraison continue constitue une étape supplémentaire par rapport à l'intégration continue. Le code passe donc automatiquement tous les tests automatisés et est automatiquement déployé dans votre environnement de production. Cela ne signifie pas que vous déployez chaque commit. Il existe donc plusieurs stratégies de branchement. Vous pourriez l'utiliser, vous pourriez l'avoir pour avoir une succursale de production. Et chaque fois que vous fusionnez élément de la base à la production, toutes les tâches automatisées sont exécutées. Et si cela fonctionne, ils remontent sans aucune autre intervention humaine. Vous pouvez également l'avoir là où se trouve Master dans votre environnement de production. Et chaque fois qu'une équipe fusionne un ticket individuel dans le master, elle exécute tous les tests et se déploie automatiquement. En fait, cela va à l'encontre de l'idée d'un déploiement manuel. Ainsi, un ticket peut fusionner une fonctionnalité lorsque tous les tests sont exécutés automatiquement et, si tout va bien, ils sont transmis à l' environnement de production. 49. Outils de livraison continue: Il existe un grand choix de serveurs de construction et d' outils d'intégration continue. Dans cette leçon, nous aborderons quelques-unes d'entre elles. Le premier à mentionner est probablement Jenkins. Il s'agit donc d'un serveur d'automatisation open source. Vous devez donc l'héberger vous-même. Vous devez disposer d'un serveur au sein votre organisation et exécuter Jenkins vous-même. Mais c'est open source, c'est gratuit et vous pouvez l'exécuter en interne. Ensuite, nous avons les environnements hébergés auxquels il est généralement possible de se connecter. Si vous avez quelque chose comme un dépôt GitHub, il s'y connectera et extraira votre code de là. Nous avons donc Travis CI, dont je vous ai montré l'exemple. Et puis nous avons également un CircleCI. Et si vous préférez conserver les choses sur GitHub, GitHub propose en fait un outil appelé GitHub Actions, qui vous permet d'effectuer des processus CI et CD et, évidemment , de vous connecter très bien si votre référentiel s'y trouve ou vous pouvez utiliser une plateforme comme Get lamp. C'est un peu comme un serveur d'intégration continue intégré à un hub. C'est donc à la fois pour le serveur Git et il créera également votre logiciel pour vous. Et puis Team City est un autre serveur d'intégration continue qui est également très populaire. 50. Logiciel agile: Jusqu'à présent, nous avons principalement utilisé des feuilles de calcul et les avons publiées. Et c'est un excellent moyen d'apprendre les bases et de comprendre le fonctionnement des systèmes. Mais dans un contexte commercial, une grande partie de ces tâches sont normalement effectuées l'aide d'un logiciel de gestion de projet. Et c'est vraiment bien, surtout si vous avez une équipe à distance où les gens sont partout et qui ont tous besoin de voir le tableau et de voir où se trouvent les billets. Et tout le monde collabore ensemble. C'est là que le logiciel de gestion de projet prend tout son sens. Dans ce module, nous allons donc explorer certaines de ces solutions qui sont déjà disponibles pour que vous puissiez les utiliser. 51. Jira: Jira est probablement l'outil le plus populaire pour faire du Scrum en ligne. Alors allons-y et créons un projet ici. Nous l'appellerons boutique de commerce électronique. Et nous allons modifier notre modèle ici pour le gommer. Parfait. Oui, ça a l'air bien. Nous allons le créer. Je vais ne pas avoir d'outils pour le moment. OK, super. Nous avons donc notre arriéré. Voici donc notre feuille de route. Ici, nous avons un arriéré qui nous permet de commencer à y ajouter des problèmes si nous le souhaitons. Ou nous pourrions également commencer à ajouter des éléments. Donc, ici, cette page produit est un peu comme une épopée. Et je dois dire qu'en tant que visiteur, souhaite voir le titre du produit. En tant que visiteur, je souhaite voir une photo du produit. En guise de visite. Je souhaite lire les avis sur les produits. Ensuite, nous pourrions ajouter une autre époque ici. On pourrait donc dire portail de gestion. Ensuite, en tant que responsable, je veux voir la liste des commandes. Et en tant que manager, je souhaite expédier et commander. Cet onglet de feuille de route permet d'effectuer des ups. J'ai plutôt créé ces épopées. Et ça m'aiderait si je pouvais épeler. Nous expédions et commandons. Génial. Alors cela ne nous permettra probablement pas de les supprimer, mais essayons. Nous y voilà. Nous pouvons donc entrer dans chacune d'elles et ajouter une description. Ensuite, nous pouvons ajouter quelques points de l'histoire ici. Alors peut-être beaucoup d'entre eux. Disons que c'est trois. Et celui-ci en a cinq. Celui-ci va être deux. Et celui-ci va aussi être un cinq. Super, nous avons donc quelques valeurs de points. Et si nous avons un arriéré, nous pouvons commencer à les organiser en sprints. Nous voici donc arrivés à notre premier sprint. Et nous pouvons faire glisser certains de ces tickets n. Nous avons donc les tickets de notre page produit n, nous les avons laissés en attente. Et si nous cliquons sur Start Sprint, nous sommes maintenant sur l'onglet du tableau. Et voici notre tableau. Nous pouvons donc ajouter quelques colonnes ici si nous le voulons. On pourrait appeler cela une révision de code. Je vais le mettre là. Et nous en ajouterons un à des fins de test également. Mets-le là-dedans. Ensuite, si je veux commencer par un ticket, je peux me l'attribuer. Je peux l'envoyer en cours. Et voici notre tableau Au fur et à mesure que nous mettrons à jour tous ces billets, vous le ferez pour tout le monde. Et évidemment, lorsque nous inviterons les membres de notre équipe, ils pourront également voir les tickets se déplacer d'une manière ou d'une autre au fur et à mesure que nous les déplaçons. 52. Graphique de gravure: Un indicateur clé que vous souhaitez prendre en compte dans votre sprint est donc le Burndown Chart. Donc, si nous cliquons sur ce bouton Insights, nous pouvons voir la progression du sprint qui nous indique quel pourcentage est fait, est en cours ou n'a pas encore commencé. Et nous avons également ce graphique Sprint Burndown ici. Je l'ai donc défini comme un sprint de deux semaines. Et nous pouvons voir qu'en théorie, nous devrions compléter ce nombre de points. Donc, à mi-chemin, nous devrions être à peu près à mi-chemin des points. Au fur et à mesure que nous transférons ces tickets, nous pouvons désormais dire que nous sommes en cours de traitement à 100 %, mais rien n'a encore été fait. Mais alors si je prends l'un de ces tickets et que je le place sur Terminé. Et encore une fois, nous allons rafraîchir. Maintenant, nous en sommes à 56 % de travaux terminés, 44 % de travaux inachevés. Et nous pouvons constater que notre graphique d'avancement est vraiment beau car nous voulons cette ligne bleue, qui représente le travail effectué pour revenir à zéro avant cela. Il faudrait donc atteindre cette limite pour y parvenir. Si c'est ici, alors nous ne terminerons pas le travail aussi vite que nous le pensions. Si c'est ici, alors nous terminerons le travail plus rapidement que prévu. 53. Trello: Trello est un outil très simple pour créer des tableaux et des listes de tâches. J'ai donc un tout nouveau tableau ici et nous pouvons y ajouter les colonnes de notre choix et peut-être en ajouter un en cours. Si je peux épeler. Et puis une révision du code, des tests et c'est fait. Ensuite, je peux commencer à ajouter des éléments ici. Je veux donc voir le nom du produit. En tant que visiteur, je souhaite voir une photo du produit. Dites visiteur. Je souhaite lire les avis sur les produits. Ensuite, on peut cliquer dessus. Je peux me les attribuer, par exemple. Je peux ajouter une description, alors enregistrez-la. Et puis mes petites photos, parce que je les ai signées, je peux les mettre en œuvre. Maintenant, ce que Trello ne fera pas car Trello est très simple à utiliser. C'est ça. Nous sommes sur la bonne voie maintenant. Il ne nous fournira pas tous les rapports que certains des outils les plus avancés peuvent fournir. Mais c'est idéal pour les petits projets, projets simples ou les projets où vous souhaitez simplement continuer, démarrer et ne pas perdre trop de temps à vous trop de temps car vous pouvez facilement créer ces petits tableaux, les partager avec votre équipe et permettre à tout le monde de travailler très rapidement. 54. Murale: Voici un autre outil appelé Miro, qui contient de nombreux modèles. Ainsi, lorsque vous le chargerez pour la première fois et que nous n'en aurons plus, vous pouvez utiliser ces liens entre amis. Mais si vous optez pour Agile, y trouverez plein de choses intéressantes. Ainsi, par exemple il y a un modèle de rétrospective, Start, Stop, Continue, Retrospective. Un tas de choses dont nous avons parlé. Ou nous pouvons nous contenter d'une feuille de travail à cinq raisons, vraiment utile pour les navires de guerre, les rétrospectives d' équipe, les torsions quotidiennes. Et il établira une vue du tableau. Et encore une fois, probablement des orbitales. Vous pouvez le partager avec tous les membres de votre équipe, puis commencer à l'utiliser. 55. Bâtir la sécurité psychologique: La sécurité psychologique consiste à déterminer si les membres de l' équipe ont le sentiment d'avoir confiance en la sécurité d'exprimer leurs pensées et leurs idées. Et c'est vraiment la responsabilité de l'équipe de le construire. Parce que malheureusement, beaucoup d'entre nous ont fait l'expérience de ne pas vouloir parler. Nous ne voulons pas partager des idées parce que nous sommes inquiets. Nous serons jugés, nous crierons, nous serons virés, peu importe ce que c'est. Ce ne sont pas des environnements psychologiquement sûrs. Et dans Scrum, nous reconnaissons que chaque membre de l'équipe a quelque chose de vraiment précieux à lui présenter, à commenter. Donc, si nous pouvons renforcer la sécurité psychologique afin que les membres les plus timides ou de l'équipe, voire tous les membres de l'équipe, puissent vraiment honnêtement leurs sentiments ou leurs opinions, alors c'est vraiment bénéfique. Alors, comment renforcer la sécurité psychologique ? Eh bien, l'établir verbalement et par le biais de méthodes de travail est vraiment un bon moyen de souligner que l' opinion de chacun est valable. Donc, avoir cela écrit et faire en sorte que tout le monde soit d'accord, en tant qu'équipe, sur le fait que nous voulons vraiment avoir cette contribution et que nous n'allons pas porter de jugement. Nous allons écouter et respecter l'opinion de chacun, contribue grandement à renforcer cette sécurité. Les bonnes règles à avoir peuvent inclure fait qu'il est normal de faire des erreurs. Si nous avons une culture du jugement et du blâme, les gens n'admettront pas leurs erreurs et nous n' apprendrons donc rien. Alors que si nous établissons une culture dans laquelle nous ne blâmons pas les gens pour leurs erreurs, nous nous contentons de regarder ce qui n'a pas fonctionné et comment nous pouvons nous assurer que cela ne se reproduise pas, alors les gens sont plus susceptibles d'être honnêtes. Nous pouvons donc résoudre ces problèmes. Avoir l' avis de chacun est précieux, c'est juste avoir cela en règle générale, beaucoup de gens peuvent penser que leur opinion n'est pas importante. Donc, si l'équipe convient que l' opinion de chacun est importante, cela peut vraiment inciter certaines personnes à être plus ouvertes. Avoir une culture de respect, respecter l'idée des tampons et ne pas avoir d'interruptions. Nous avons probablement tous assisté à des réunions où une personne ne cesse de nous interrompre et c'est vraiment ennuyeux, impoli et irrespectueux. Et la personne interrompue finira par abandonner et ne pas partager ses idées. Donc, si nous établissons l'idée que lorsque quelqu'un parle, nous ne l'interrompons pas, ce qui devrait être une habitude de base, mais nous avons souvent besoin d'un petit rappel. Cela peut alors s'avérer un outil très utile L'un des moyens d'y parvenir est de veiller à ce que des rétrospectives soient organisées régulièrement pour s'assurer que les gens ont leur mot à dire et qu'ils peuvent exprimer leur opinion sur les choses et confiance en l'équipe. Et ça peut être vraiment bien de les retirer du site. Donc, si vous avez un bureau ici, vous avez peut-être un café ici. Ça peut être vraiment bien d'aller dans ce café ou d' aller ailleurs. Il suffit de le retirer du bureau pour que les gens aient l' impression d'être au bureau, ce qui ressemble clairement au domaine des managers. Et nous serons peut-être un peu plus nerveux à l'idée que vous l' emmeniez dans un environnement plus détendu, comme un café, qui un environnement plus détendu, comme peut également vraiment aider les gens à s'ouvrir. 56. Réunions de lavage: Les réunions de culte ont lieu une fois qu'un projet est terminé, mais aussi, plus important encore après que quelque chose ne va pas. C'est une époque où les gens s' inquiètent du blâme. Le but de la réunion est donc vraiment de déterminer ce qui s'est passé et ce que nous pouvons améliorer la prochaine fois. donc très important de souligner qu'il ne s'agit pas d'une enquête, comme d'essayer de trouver des personnes à blâmer et de les punir pour cela, mais simplement de comprendre ce qui s'est passé et où nous pouvons y remédier. Nous pourrons donc faire mieux la prochaine fois. Maintenant, un très bon outil pour les réunions de culte est d'utiliser ce que l'on appelle les Cinq Pourquoi. Nous nous demandons donc cinq fois pourquoi. Et plus nous le faisons, plus nous nous attaquons à la cause première du problème. Disons que nous avons eu une panne de serveur et les équipes se sont réunies pour une réunion de préparation. Et on pourrait se demander pourquoi le serveur est tombé en panne ? Quand, pourquoi ? Eh bien, il n'y avait plus d'espace disque. D'accord. Pourquoi n'avait-il plus d'espace disque ? Eh bien, les poumons l'ont rempli et il y avait tellement de journaux qu'il rempli tout le disque dur. Alors pourquoi le serveur a-t-il été rempli de journaux ? Eh bien, aucun moniteur n'était configuré sur le serveur pour nous avertir lorsque le disque dur était plein à 80 %. Pourquoi n'y a-t-il pas eu de configuration du moniteur ? Eh bien, ce n'était pas dans notre définition de terminé lorsque nous avons créé le serveur, nous avons donc oublié de le faire. Pourquoi ne figurait-il pas dans notre définition du terme « terminé » ? Eh bien, nous n'avons jamais eu de réunion sur les méthodes de travail permettant à l' équipe de trouver une solution. Nous pouvons donc comprendre que lorsque nous posons toutes ces questions sur le pourquoi et que nous continuons à creuser, nous continuons à creuser un problème qui, au début, pourrait sembler être la faute d'une personne. C'est quelqu'un qui a laissé le serveur tomber en panne. En fait, à la racine du problème. C'est un problème d'équipe que nous pouvons améliorer la prochaine fois. Nous pouvons avoir les moyens de travailler. Nous pouvons améliorer notre définition du terme « terminé ». Nous pouvons revenir en arrière et y jeter un coup d'œil, améliorer la surveillance. Toutes ces questions ont été soulevées parce que nous n'arrêtions pas de nous demander pourquoi il fallait s'attaquer à la racine du problème au lieu de penser au blâme. Le point clé d'une réunion de culte est de vraiment parler. Nous avons parlé de sécurité psychologique, création de cet environnement. Eh bien, nous ne blâmons pas, nous examinons simplement ce qui n'a pas fonctionné pour savoir ce que nous pouvons changer à l'avenir. 57. Vendre l'agile à la gestion: agilité peut sembler une bonne idée pour beaucoup d'entre nous, mais la direction n'est pas toujours d'accord avec elle. Alors, comment les convaincre que c'est une meilleure façon de faire les choses ? Eh bien, tout d'abord, nous devons examiner les inquiétudes que la direction pourrait avoir. Premièrement, c'est un changement. Le changement peut faire peur. C'est une façon différente de la façon dont ils faisaient les choses auparavant. Ainsi, si une entreprise a réussi ou si elle a du moins réussi à s'en sortir jusqu'à présent, elle change. Il y a toujours un élément de risque là-dedans. Il peut sembler qu'il faut du temps pour faire quoi que ce soit plutôt que de recourir à la vieille méthode en cascade, qui est efficace si elle fonctionne parfaitement. Nephron fonctionne parfaitement, bien sûr, mais c'est hypothétiquement possible, alors que nous vendons du management et des idées. OK, eh bien, nous allons créer une page de produit vierge. Ensuite, nous allons y mettre un titre. Ensuite, nous allons y mettre une image et publier, présenter et revoir toutes ces choses. Au cours présenter et revoir toutes de cette étape, vous aurez peut-être l'impression que cela va prendre du temps. Et cela donne également du pouvoir aux équipes plutôt qu'aux managers. Et c'est effrayant si vous êtes manager et que vous êtes habitué à microgérer et à tout contrôler. Puis quelqu'un arrive et dit : «  nous avons cette méthodologie Scrum et c'est vraiment bien de donner à l'équipe les moyens de faire le travail, alors cela peut l'inquiéter parce qu'elle aime être contrôlée ». Alors, comment répondre à ces craintes, à ces inquiétudes ? Le premier concerne les échecs coûteux et la lenteur des processus d'approbation. Donc, disons que le Big Bang se déclenche, qu'il se produise et qu' il faille des heures pour le faire reculer. Et il y a toutes sortes de plaintes, alors c'est une bonne chose à documenter. Ou si ce processus d'approbation lent où vous souhaitez, vous déployez une fonctionnalité et cela prend deux semaines. Et les termes du produit demandent : où se trouve-t-il, où se trouve-t-il ? Et vous dites, eh bien, qu'il sortira dans la prochaine version, mais nous publions des versions à l'échelle de l'entreprise, donc nous ne pouvons rien faire. Vous allez devoir manger tard. Et puis nous manquons un document de date limite, tout ça. Parce que si vous pouviez vous adresser à la direction et lui dire : « Écoutez, il y a eu un énorme échec à cause des sorties Big Bang ». Ici, nous n'avons pas respecté une date limite importante pour modifications, car nous avons dû attendre la prochaine version. C'est une bonne preuve que le processus actuellement en place ne fonctionne pas. Pour mettre l'accent sur les avantages d'une livraison plus rapide, les responsables préfèrent généralement faire connaître les choses le plus rapidement possible. Donc, si nous pouvons leur dire, écoutez, cette fonctionnalité que vous avez demandée, cela m'a pris huit semaines. Ensuite, il a fallu attendre encore deux semaines pour obtenir un soulagement. Et en fait, nous pensons pouvoir obtenir une version de base en deux temps, y compris la sortie. Nous n'aurons même pas à attendre la prochaine version. Ce sera un argument de vente important. Et nous en avons parlé plus tôt introduisez également cette idée de sécurité. Cette idée : si nous procédons à de petites versions, plus faciles à annuler, nous aurons moins de ces défaillances catastrophiques. La troisième, c'est de parler d'équipes plus heureuses. En général, les équipes préfèrent travailler de manière agile plutôt que de travailler en cascade. D'une manière spectaculaire, l'équipe n'a pas vraiment le contrôle. Cela fonctionne sur une partie du système. Il n'en assume pas la responsabilité. Cela ne mène pas à bien, ne donne pas de pouvoir à l'équipe. tout le contraire qui est gaspillé. Cela permet à l'équipe d'assumer responsabilité de ce qu' construit et de la manière dont elle va le réaliser. Et les gens adorent le fait que les équipes adorent ça, ils adorent ça. L'entreprise leur confie cette responsabilité. Ensuite, ils sont capables de faire ce travail et ils sont capables de le faire bien. Et cela signifie des équipes plus heureuses. Et du point de vue de la direction, cela signifie une réduction du chiffre d'affaires. Les gens ne vont pas partir parce qu'ils aimeront davantage leur travail et ils vont donc rester dans l'entreprise. La quatrième est de reconnaître que le changement fait peur. inquiètent peut-être Toutes ces choses les inquiètent peut-être et nous pouvons dire : «  Eh bien, oui, ce sont des inquiétudes. Nous sommes presque certains à 99 % que se tortiller vaut mieux qu'une cascade, parce que tout le monde y va ces derniers temps. Mais pourquoi ne pas le faire à titre d'essai ? Et un essai est un excellent moyen de contourner les objections, car si vous dites : « OK, essayons ça pendant trois ou six mois et voyons comment cela fonctionne ». Et si tout explose, nous retournerons à la cascade. Mais si cela fonctionne et que nous pouvons étendre et le déployer dans toutes les équipes, vous aurez beaucoup plus de chances d' obtenir l'adhésion, car cela vous permettra de l'essayer. Et c'est moins risqué car ce n'est que temporaire. Mais bien sûr, nous allons l'essayer. Qui travaillent vraiment bien. Ils l'adoreront et nous serons en mesure de le déployer dans l' ensemble de l'organisation. 58. Coaching de bonne pratique: Nous avons évoqué l'idée selon laquelle nous devons parfois encadrer les meilleures pratiques et encourager votre équipe à réellement utiliser l'ensemble du framework disponible dans Scrubs. Alors, comment s'y prendre ? Comment entraîner efficacement ? Eh bien, la première est de commencer là où l'équipe se trouve actuellement et de voir ce qui fonctionne pour elle. On a donc parfois tendance à intervenir et à essayer de commencer à apporter des modifications. Mais si nous le faisons, l'équipe sera probablement très opposée. Et ils sont satisfaits de la façon dont les choses se passent. Si nous y allons, voyons ce qui fonctionne, voyons ce qui ne fonctionne pas. Et nous pouvons observer, nous pouvons poser des questions, puis nous pouvons voir ce qui ne fonctionne pas vraiment pour eux. À ce moment-là, nous pouvons commencer à suggérer des changements et dire que j'ai remarqué que cela ne fonctionne pas pour vous. Et si nous essayions de cette façon, cela aiderait peut-être à résoudre le problème. Faites des suggestions, pas des commandes. Les gens n'aiment généralement pas qu'on leur dise quoi faire. Donc, comme nous venons de le dire, si nous pouvons faire des suggestions et les proposer à l'équipe, elle peut choisir de les accepter. Ils peuvent choisir de ne pas l'accepter. S'ils ont le sentiment d'avoir le contrôle des changements, ils seront bien plus enclins à les apporter que si nous essayons de leur imposer quelque chose. Posez des questions sur comment ou quelles questions plutôt que sur les raisons pour lesquelles nous les posons à quelqu'un Pourquoi le faites-vous de cette façon ? Cela semble assez accusateur. Et cela met les gens sur la défensive. Si nous utilisons des questions telles que « comment » ou « comment », « d'accord , comment procédez-vous et à quoi cela ressemble-t-il ? Comment ça marche pour toi ? Ensuite, les gens examinent un peu plus la situation au lieu de se mettre sur la défensive comme ils peuvent se demander pourquoi. N'oubliez pas que la manipulation d'ArcGIS n'est pas une religion. Alors concentrez-vous sur ce qui fonctionne, emportez-lui ce qui fonctionne, et vous n'aurez pas à utiliser ce qui ne fonctionne pas. Si quelque chose ne fonctionne pas tout à fait pour vous dans le cadre de Scrum, n'utilisez pas cette partie, utilisez les éléments qui vous conviennent au sein de votre organisation, de votre équipe, peu utilisez les éléments qui vous conviennent au votre organisation, de votre équipe, importe ce que c'est, intégrez les bonnes choses et ne soyez pas trop dogmatique quant aux règles. Soyez un modèle. La chose la plus importante que nous puissions faire est de suivre nous-mêmes les meilleures pratiques. Si nous ne le suivons pas, ne pouvons pas nous attendre à ce que d'autres personnes le suivent. Donc, s'il y a des domaines dans lesquels nous pensons que nous ne sommes peut-être pas tout à fait en accord avec notre vision des meilleures pratiques, alors adoptons cette voie afin de montrer à quoi ressemblent les bonnes pratiques. Et aussi, quand les gens verront que cela fonctionne pour nous, alors je ne pense pas que cela fonctionne pour Chris, peut-être que je vais l'adopter également. Découvrez la situation globale des équipes au sein des organisations. Parfois, l'équipe fait les choses d'une certaine manière et il existe une meilleure façon de le faire. Mais c'est parfois la meilleure façon de le faire dans le cadre la structure organisationnelle dans laquelle ils sont contenus. Il est donc important de réfléchir à la manière dont les valeurs générales de l'organisation peuvent affecter l'équipe et l'amener à faire les choses d'une certaine manière. Ensuite, essayez les modifications à titre expérimental. changement peut donc faire peur, mais si nous le vendons à titre expérimental, pourquoi ne pas simplement l'essayer lors des deux prochains sprints et voir comment cela fonctionne. Les gens sont beaucoup plus enclins à s'y engager parce qu' ils ne pensent pas s'engager à modifier définitivement les chiffres. D'accord, nous allons l' essayer pour Sprint. Deux sprints, c'est deux mois, peu importe ce que c'est Si vous essayez de nager en général, vous devriez probablement vous engager sur une période plus longue, peut-être trois à six mois, au moins, quelque chose comme ça. Mais si vous le formulez comme une expérience, essayons ceci et nous pourrons revenir à l'ancienne méthode. Si cela ne fonctionne pas, les gens seront beaucoup plus détendus idée d'essayer des choses que si vous leur dites, accord, que nous devons passer à la vitesse supérieure maintenant. Cela semble très permanent et très effrayant lorsque nous disons : essayons-le comme expérience et voyons si cela fonctionne ou ne fonctionne pas. Les gens sont beaucoup plus enclins à s'engager. 59. Comment mettre à l'échelle du Scrum: Scrum est conçu pour une équipe d' une dizaine de personnes et cela commence à devenir ingérable. Vous ne pouvez pas tout faire dans une mêlée quotidienne. Et cela signifie que les mises à jour sont moins significatives parce que les gens d'ici et les gens d'ici travailleront probablement sur des choses différentes. Les mises à jour ne fonctionnent donc pas vraiment et il ne s'agit pas vraiment d' un environnement d'équipe. Mais que se passe-t-il si vous avez un projet qui nécessite plus d'une dizaine de personnes, comme c'est souvent le cas dans le monde des affaires ? Dans ce cas, vous avez besoin de plusieurs équipes Scrum. Mais ce qui est préoccupant, c'est ce qui se passera si les équipes de mêlée commencent à se marcher sur les pieds et à se gêner mutuellement. Comment passer d' une seule équipe Scrum à plusieurs équipes Scrum ? Eh bien, c'est ce que nous allons examiner dans ce module. 60. Scrum de Scrum: Si nous avons plusieurs équipes Scrum et qu'elles doivent être capables de communiquer pour les empêcher de se bousculer les unes les autres. Alors, comment y parvenir ? Eh bien, l'une des solutions est Scrum of Scrums. Il s'agit donc essentiellement d'une mêlée quotidienne. donc la même chose que le Scrum quotidien. Mais chaque équipe Scrum en envoie une délicate ce qui donne lieu à une meilleure Scrum of Scrums. Cela peut donc être fait quotidiennement chaque semaine si cela fonctionne dans votre organisation ou selon la fréquence qui vous convient. Mais c'est le même format qu'une mêlée quotidienne. Chaque natation est représentée par une personne, et cela peut être n'importe qui. Cela pourrait donc être le Scrum Master, si cela a du sens, peut-être, un ingénieur en chef, mais cela pourrait vraiment être n'importe qui. Vous pouvez alterner les membres de l'équipe afin que chacun puisse participer à la Scrum of Scrums et voir comment cela fonctionne. Lorsque vous êtes dans la Scrum de Scrum elle-même, cela fonctionne comme les mêlées quotidiennes. La question à se poser est donc la suivante : qu'avons-nous fait ? En particulier, des choses qui pourraient avoir un impact sur les autres équipes ? Que faisons-nous actuellement qui pourrait avoir une incidence sur Teams et quels bloqueurs les autres équipes pourraient-elles nous aider ? Donc, de la même manière que lorsque nous faisons notre mêlée quotidienne, nous parlons de ce que nous avons fait individuellement par le passé, ce que nous faisons actuellement et des obstacles que nous avons, nous participons à la Scrum des Scrums et nous disons à notre équipe que c'est ce que nous avons fait, c'est ce sur quoi nous travaillons. Ce sont des bloqueurs pour lesquels nous avons besoin d'aide. Chaque équipe contribue afin que les équipes sachent sur quoi chacun d'entre nous travaille. Ensuite, le délégué retourne à son équipe Scrum individuelle et transmet des informations non pertinentes au reste de cette équipe. 61. Produits de séparation: un des concepts clés de Scrum est qu' un produit a un propriétaire. Vous ne pouvez pas avoir un seul produit. Nous avons plusieurs propriétaires de produits. Que se passe-t-il si vous devez faire en sorte que les équipes Scrum travaillent sur le même projet ? semblerait que vous ayez deux propriétaires de produits différents dans chaque équipe travaillant sur le même produit. Comment gérez-vous cela ? Eh bien, dans ce cas, nous devons diviser les produits d' une manière ou d'une autre en sections distinctes. Prenons donc à nouveau notre site de commerce électronique , à titre d'exemple. C'est un gros combat et nous voulons que différentes équipes Scrum y travaillent. Mais nous ne pouvons pas avoir deux propriétaires de produits propriétaires du site de commerce électronique. Ce que nous pourrions faire, par exemple, c' est le diviser en front-end et en back-end. Donc, par domaine frontal, les éléments que le client verra s'il se rend sur le site pour le parcourir. Ensuite, le système dorsal est ce que le personnel de l'entrepôt et l'équipe de vente travaillant pour le site de commerce électronique utilisent pour gérer et expédier toutes les commandes. En les séparant, vous pouvez avoir une équipe Scrum responsable de chacune d'elles. Vous pouvez donc demander l'équipe Scrum de travailler du côté client. L'équipe Scrum travaillera sur le back-end du produit et vous aurez un propriétaire de produit pour chacun d'entre eux qui les gérera. Maintenant, une autre solution que vous pouvez faire est de faire travailler un propriétaire de produit au sein de plusieurs équipes Scrum. L'équipe A travaille donc sur le front-end, l'équipe B travaille sur le back-end. Et comme il y a un propriétaire de produit qui gère et travaille au sein des deux équipes, ce qui en fait un propriétaire de produit très occupé. Mais en fonction du nombre de décisions et de l'autonomie dont dispose l'équipe, cela peut également très bien fonctionner. 62. Alignement de la sprint: Si vous avez plusieurs équipes Scrum, vous devriez peut-être commencer à réfléchir à l'alignement des sprints. Donc, si vous avez une équipe A et une équipe B ou si leurs sprints commencent en même temps ? Vont-ils être différents ? Le temps passé à les faire fonctionner en même temps fonctionne très bien car si vous avez des bloqueurs, comme TMA, ils sont bloqués par un élément sur lequel travaille l' équipe B. L'équipe a commencé à travailler là-dessus en disant « sprint libre » et équipe avec le nez pour être capable de le reprendre au sprint quatre, en faisant miroiter, c'est terminé. Ainsi, tout est aligné. Vous pouvez aligner les feuilles de route de vos produits. Vous pouvez donc dire, en gros, que TMA va travailler au sein de cette équipe, travailler là-dessus. Et puis dans deux semaines, quand le sprint et nous le modifierons. Il peut donc être très utile de les aligner. Pour certaines organisations, il est préférable de ne pas les aligner uniquement pour des raisons logistiques. sûr que vous n' avez qu'une seule salle de réunion. Ensuite, si toutes vos équipes Scrum commencent à prendre de l'aspirine et y mettent fin, elles seront utilisées le même jour. Ils voudront tous deux disposer de la salle de réunion pour planification du sprint et pour les rétrospectives le même jour. Dans ces cas-là, vous devriez peut-être échelonner l'équipe de sprint avec une étoile ici et faire un sprint de deux semaines et l'équipe B commencer ici environ une semaine plus tard. Donc, le décalage, afin qu'ils ne se heurtent pas à ces réunions avec des conflits. En termes d'alignement ou d' alignement des différentes équipes dépensées. C'est là que la variation de la durée du sprint peut s'avérer très utile. Supposons que vous ayez eu TMA et que vous venez acheter Team Be On une semaine plus tard. Mais en fait, vous voulez aligner leurs sprints et vous pourriez demander à l'équipe A de faire un sprint de trois semaines, afin qu'ils se terminent tous les deux en même temps. Ou vous pourriez réduire la tuberculose à un sprint d'une semaine. Ensuite, ils reviennent à la question de savoir si vous utilisez des sprints de deux semaines par défaut, ils reviennent aux deux dépenses, puis les alignent. Vous pouvez donc le faire comme vous le souhaitez, mais il peut être très utile de savoir si vous voulez les aligner ou non et comment vous allez les aligner si vous voulez les aligner ou non et comment vous allez les aligner en utilisant la longueur des sprints. 63. Autres méthodologies: Ce cours s'est concentré sur Scrum, mais il existe d'autres méthodologies agiles vous souhaiterez peut-être utiliser de temps à et des frameworks que vous voudrez peut-être intégrer à SCRUM et qui complètent vraiment Grown. Dans ce module, nous allons donc en discuter au sujet de méthodologies et de cadres agiles qu'il vous serait très utile de connaître lorsque vous travaillez dans Scrum. 64. Kanban: Scrum et Kanban sont probablement les frameworks Agile les plus populaires pour la gestion de projets. Alors, quand utiliseriez-vous Squirm et quand utiliseriez-vous Agile ? C'est vraiment la solution idéale pour réaliser nouveaux projets dans lesquels vous créez quelque chose, une solution Greenfield, vous avez une tâche à accomplir. Tu sais, tu as, disons, six mois pour le faire. Et tu as juste besoin de passer à travers toutes les choses. Kanban a tendance à être plus adapté à un environnement de travail normal ou à un type de statu quo. Vous avez peut-être déjà créé votre plateforme de commerce électronique. C'est en direct et vous avez juste besoin de voir ce qui se passe. Petites améliorations, petites corrections. Vous n'avez pas le type de feuille de route complète que vous avez développée en matière de produits. Mais vous devez réagir beaucoup plus rapidement, car vous êtes confronté à des problèmes actuels sur le site Web. kanban fonctionne donc un peu différemment dans la mesure où il n'y a pas de Sprint Scrum. Nous avons cette idée des sprints et nous avons, disons, un bloc de deux semaines. Nous décidons de ce que nous allons faire et commençons par deux semaines, nous le faisons pendant deux semaines et nous allons revoir ce que nous allons faire. Dans Kanban. Il y a un tableau continu et un arriéré de produits. Et le genre de ce que nous pensons du Sprint Backlog, la liste de tâches, c' est pareil. Le backlog de produits se trouve donc déjà dans la colonne des tâches du tableau et par ordre de priorité, afin que vous choisissiez le premier. Supposons donc que nous reprenions notre plateforme de commerce électronique. Nous l'avons en direct. Et nous avons remarqué que le symbole de la devise affiche pas tout à fait, n' est-ce pas ? Pour certains utilisateurs. Et c'est un très gros problème car il concerne les paiements. Ainsi, le propriétaire du produit créerait un ticket indiquant que le symbole monétaire ne s'affiche pas correctement, l'enverrait probablement directement en haut du backlog. Donc, le prochain ingénieur à récupérer quelque chose, nous serons en mesure de le récupérer. Ainsi, au lieu d'avoir ces sprints, tout se trouve dans une seule liste. Vous choisissez la solution la plus importante et si quelque chose doit être fait de toute urgence, vous la soumettez et vous la placez directement en haut de l'arriéré afin de pouvoir y travailler. Maintenant, cela signifie que dans Scrum, nous mesurons la vélocité. nous réussissons plus nous obtenons de points de nourriture par sprint, mieux nous sommes. Dans Kanban, on parle de temps de cycle. Donc, à partir du moment où le ticket est levé, quelle rapidité pouvons-nous le faire passer à tous les niveaux, le publier et le terminer ? En résumé, Scrum est idéal lorsque vous avez des tâches fixes et que Scrum est idéal lorsque vous avez des vous êtes heureux de participer à ces sprints de deux semaines, une fois que vous avez trouvé quelque chose et que vous juste besoin d'apporter de petites modifications. Et vous vous inquiétez moins à l'idée de faire un gros travail. Vous avez juste besoin d'obtenir ces correctifs rapidement. Kanban peut être plus utile. Là-bas. 65. Programmation extrême: La programmation extrême est une approche agile de l'écriture de code. Comme Agile en elle-même, il n'existe pas de règles claires, mais il existe autrefois un ensemble de principes et de techniques qui s' assemblent pour former ce que nous appellerions la programmation extrême. Cela implique souvent que plusieurs personnes travaillent sur le même morceau de code. Il peut donc s'agir de code écrit par paires, dans le cadre de la programmation par paires, laquelle une personne est le pilote en train de taper les choses, mais où elle collabore avec une personne dans laquelle une personne est le pilote en train de taper les choses, mais où elle collabore avec une personne assise à côté d'elle pour prendre les décisions, ce qui permet à la fois de détecter ce qui fonctionne et de savoir comment le concevoir. Vous pouvez même passer à la programmation mafieuse. Ainsi, quatre ou cinq personnes examinent un seul morceau de code, soit sur leur propre ordinateur, en collaborant en temps réel, soit sur un ordinateur entièrement assis, si cela vous convient. Cela garantit ainsi un code de très haute qualité. Mais bien sûr, cela prend plus de temps. Si vous travaillez en binôme, seule la moitié de vos ingénieurs écrivent du code et programment encore plus. Donc. Le code doit être revu et approuvé de manière approfondie par quelqu'un d'autre. Cela devrait donc figurer dans tout ce que vous écrivez. Si vous écrivez un morceau de code, envoyez une pull request ou une révision de code à quelqu'un d'autre. Et quelqu'un d'autre devrait regarder ce code pour s'assurer qu'il a du sens. Donnez des commentaires et transmettez-les à la personne. S'il s'agit d'un passage immédiatement ou si des modifications sont nécessaires ou suggérées, transmettez-le à l'auteur pour voir s'il souhaite apporter ces modifications. Les tâches automatisées doivent être écrites pour tout. passer à cette idée d'intégration et de livraison continues, il faudrait donc livraison continues, il faudrait des tests automatisés pour chaque fonctionnalité que nous écrivons, car il est impossible pour testeurs humains de toutes les comprendre, en veillant à ce choses soient aussi simples que possible. fait, nous voulons toujours écrire le moins de code possible et le rendre réutilisable. Et si nous pouvons écrire un morceau de code que nous pouvons utiliser à trois endroits différents et supprimer l'ancien code volumineux, alors c'est formidable, car moins de lignes de code signifie moins d'endroits où les choses peuvent mal tourner. Ensuite, le développement piloté par les tests, dont nous parlerons dans la leçon suivante. 66. Développement axé sur les tests: développement piloté par les tests, également connu sous le nom de TDD en abrégé, est une méthode d'écriture de code dans laquelle nous écrivons le test unitaire avant d'écrire le code lui-même . Pourquoi faisons-nous cela ? Eh bien, cela nous empêche d' ajouter du code dont nous n'avons pas besoin. Nous avons donc parlé plus tôt de l'idée d'écrire une histoire d'utilisateur et de dire qu'en tant qu'utilisateur, je voulais le faire. Ensuite, nous pouvons écrire le code en sachant que dès que nous répondons aux critères d'acceptation, nous avons rempli le travail. Eh bien, c'est fondamentalement la même chose en ce sens que nous écrivons d' abord le test pour dire ce que ce code doit être capable de faire. Ensuite, nous écrivons le code pour remplir ce texte. Ainsi, dès que le test unitaire est réussi, nous pouvons commencer à écrire du code. Nous n'avons pas besoin d'ajouter quelque chose d'autre, car nous avons réussi ce test unitaire et par conséquent, il fait tout ce dont nous avons besoin. Ainsi, écrire d'abord le test, puis le code fonctionnel suite, nous permet de nous assurer que tout est couvert par des tests. Et deuxièmement, nous n'ajoutons aucune surcharge au code car nous pouvons l'arrêter dès que le test est réussi. 67. Développement axé sur les comportements: Le développement piloté par le comportement est une extension du développement piloté par les tests, duquel nous écrivons nos tests dans des histoires d'utilisateurs, puis nous écrivons le code correspondant à ces histoires utilisateur. Alors, qu'est-ce que cela signifie vraiment ? Disons que nous sommes en train de coder le système de paiement de notre plateforme de commerce électronique. Nous pouvons écrire une histoire du type En tant que client, je souhaite pouvoir voir le total de mon panier ». Ou en tant que client, je souhaite être en mesure d'effectuer le paiement de ma commande. Et ce serait la langue dans laquelle nous écrirons le test. Ce serait notre test, disons, et c'est très compréhensible. Tout le monde peut y jeter un coup d'œil, le propriétaire du produit pourrait écrire lui-même. Toute personne qui regarde le test, même une personne non technique, comprend ce qui s'y passe. Nous avons ensuite une couche de code au milieu, qui traduit cela en un véritable test indiquant que je souhaite effectuer le paiement de ma commande. Quelles sont les étapes automatisées pour réellement tester cela ? Donc, faire traduire le langage naturel en test. Et puis, bien sûr, nous avons notre code fonctionnel, la véritable plateforme de commerce électronique elle-même. Il y a donc un peu 33 pièces dedans. Quel est, quel est l' avantage de faire cela ? Lorsque nous écrivons le code en langage naturel. Tout le monde peut le comprendre, le propriétaire du produit, aspects non techniques, et venir voir exactement ce que nous testons. Deuxièmement, il met vraiment l'accent sur la satisfaction de ces besoins des utilisateurs. Nous pouvons donc d'abord écrire notre test. J'ai besoin que l'utilisateur puisse effectuer ce paiement. Ensuite, nous écrivons notre test et notre code fonctionnel pour y parvenir. Et dès que nous l'aurons atteint , nous pourrons arrêter. Nous n'ajoutons rien de plus, car nous savons que cette histoire d'utilisateur est définie et nous avons déjà une couverture complète des tests à ce sujet. Nous savons donc que nous pouvons le faire passer par un pipeline d'intégration continue et tout fonctionnera parfaitement car les tests couvrent ce domaine, n'avons besoin de rien de plus et tout le monde peut comprendre ce qui se passe. Aujourd'hui, il existe un certain nombre de frameworks BDD de développement axés sur le comportement populaires . Nous avons un concombre en Ruby, chapeau en PHP, comportement J en Java, mais quel que soit le langage dans lequel vous travaillez, il existe probablement un framework BDD. Je recommande donc de monter, jeter un coup d'œil , de voir ce qui s'y trouve, de l'essayer et de voir comment vous vous y prenez.