Agile et Scrum : de débutant à expert (avec projet pratique)

1. Introduction et aperçu du cours: Bonjour à tous et bienvenue à ce cours qui est intitulé Mastering âge allée et Scrum de débutant à expert. Vous avez pris une décision très intelligente en choisissant d'apprendre h l et est miette. Parce que vous savez, HL est un concept si important dans le monde d'aujourd'hui, quel que soit le domaine d'activité ou la technologie sur lequel vous travaillez. Et ses utilisations en croissance rapide. Près de 71 % des organisations utilisent une IG et ce nombre augmente chaque jour. C' est pourquoi il est très important de le savoir. Et tu es définitivement dans le bon cours pour papa. C' est une classe de maître pour Agile et Scrum, et vous apprendrez tous les petits détails à leur sujet. Vous pouvez utiliser cette Apprentissage pour améliorer votre hypothèse ou travailler dans une équipe Scrum ou obtenir une certification en tant que maître de mêlée, quel que soit votre objectif final. Je suis donc très excité d'embarquer dans ce voyage d'apprentissage. Et je vous remercie d'avoir choisi ce cours. Commençons et voyons ce que tout ce que nous allons couvrir dans ce chapitre d'introduction. Voici donc l'ordre du jour de ce chapitre. Et comme vous pouvez le voir, nous apprenons simplement à connaître les choses qui sont très importantes pour donner l'élan. Nous allons principalement voir ce que couvre ce cours et comment vous pouvez en tirer le meilleur parti. Nous parlerons de moi, votre instructeur, du contenu du cours et des immenses options de support qui suivent une fois que vous aurez la connaissance d'AGI. Alors, que pouvez-vous attendre de ce cours ? Eh bien, ce cours est un paquet complet. Nous allons bien sûr, tout apprendre sur Agile et Scrum et loin Ce cours est conçu. Nous commencerons à partir des concepts les plus élémentaires et passons ensuite au concept avancé. Donc, si vous êtes entièrement nouveau en RH, vous vous sentirez totalement à l'aise dans ce voyage. Ou si vous êtes quelqu'un qui a de l'expérience dans un gel, je vous suggère toujours de regarder tous les chapitres dans l'ordre parce qu'il pourrait y avoir quelque chose de nouveau pour vous ou vous obtiendrez un résumé. Nous allons en apprendre davantage sur les concepts de base de HL et de Scrum, les rôles de Scrum, les cérémonies, comment devons-nous estimer les choses ? Quels sont les artefacts que nous créons ? Et beaucoup, beaucoup plus. Et nous allons garder ces apprentissages interactifs. Il y a donc un petit quiz à la fin de chaque chapitre pour rafraîchir ce que nous avons appris. Un autre point et très utile, il ne suffit pas de connaître la théorie. Nous devons appliquer notre apprentissage dans la pratique aussi parce que c'est là que nous obtenons la vraie connaissance des choses. Et c'est pourquoi nous avons tout un chapitre dédié à la mise en place d'un projet dans Scrum à partir de zéro. Ensuite, nous parlerons également des certifications et des interviews dans ce cours. Donc, si votre objectif est d'obtenir une certification en tant que maître de mêlée, vous bénéficierez sûrement du cours parce que nous avons un chapitre entier consacré aux certifications et aux conseils pour effacer l'examen. De même, si votre objectif est d'exceller dans une entrevue, nous avons un chapitre consacré aux conseils d'entrevue et aux 30 questions les plus courantes. Ensuite, si vous êtes membre de ce cours ou de l'un de mes autres cours, vous obtenez des supports de requête à vie. Donc, utilisez le Q et une option sur le site ou envoyez-moi un e-mail et vous obtiendrez une réponse rapide. Et c'est les gars de soutien à vie. Donc, vous pouvez m'envoyer quelque chose même un an après avoir suivi ce cours et attendre une réponse. Et enfin, ce cours est conçu pour tous les publics à l'esprit. Que vous soyez un nouveau laissez-passer universitaire, un participant informatique ou un folk expérimenté. Le contenu de ce cours couvre tous les niveaux et à la fin de celui-ci, vous auriez toute l'expertise d'Agile et Scrum. Donc, avant de passer aux gars, je voulais juste donner une brève introduction sur moi-même. J' ai plus de dix ans d'expérience dans la gestion de projets et l'assurance qualité. J' ai travaillé et dirigé plusieurs projets de produits AGL en Inde et aussi depuis plusieurs années en nous. Mon adresse e-mail est à l'écran, donc comme je l'ai mentionné plus tôt, aussi, si vous avez des questions, hésitez pas à me déposer un e-mail et je répondrai de manière proactive dans les 24 à 48 heures. Vous pouvez également poster vos questions via le Q et une option sur le site. Maintenant, avant d'aller de l'avant, une des choses que je voulais mentionner était que dans toutes ces années d'expérience de travail, la chose la plus importante que j'ai trouvée que nous avons besoin dans la vie professionnelle est avoir l'art de nous perfectionner pour garder sur l'apprentissage de nouvelles choses. Alors gardez le désir d'apprendre, abordez tout nouveau sujet qui vous intéresse et continuez à construire être un apprenant. Bon, donc nous sommes prêts à entrer. Parcouvrons maintenant le contenu du cours afin que vous sachiez ce qui vous attend. Alors les gars, voici le contenu du cours et au fur et à mesure que nous le traversons, vous remarquerez que j'ai appelé chaque chapitre comme un sprint. Par sprint est le cœur de Scrum et tout le travail se passe dedans et nous le saurons plus tard. Donc chaque chapitre est un sprint pour apprendre quelque chose de nouveau. Dans les 80 sprints, nous apprendrons tout sur Agile et Scrum. Nous commencerons par les concepts de base de HL et Scrum. Ensuite, nous parlerons des rôles de Scrum, des gens qui font partie de l'équipe de mêlée, suivis des cérémonies de Scrum, c'est-à-dire des réunions. Et puis les Artefacts de Scrum. Nous allons ensuite en apprendre davantage sur la planification et l'estimation du sprint, suivis des rapports Scrum que nous créons. Et puis le chapitre 8 est un exercice de pratique complet où nous allons mettre en place un projet à partir de zéro dans une mêlée et voir sa mise en œuvre tout le long de collecte des exigences initiales jusqu'à la publication à l'utilisateur final. Enfin, nous avons le chapitre neuf pour en apprendre davantage sur les certifications, des conseils sur la façon d'effacer l'examen de maître de mêlée certifié. Et enfin, le papier journal dix. Je vais vous donner un tas de questions d'entrevue pour vous aider à préparer une entrevue et j'ai gardé la réponse à ces questions aussi simple que possible afin que vous n'ayez pas à mêler des choses, vos concepts ou vos sons. Donc les gars, comme vous pouvez le voir, c'est une liste assez exhaustive et nous suivrons ce plan au cours des dix prochains chapitres pour faire de vous un expert en agile et mêlée. Maintenant, revenons au dernier sujet de ce chapitre, les opportunités de transporteur dans AGI, Il est très important de voir la route à venir et être motivé. Rappelez-vous, le VIH a commencé quelque part il y a 20 ans. Et dans le monde d'aujourd'hui, c'est la méthodologie la plus couramment utilisée. Si nous parlons de grandes entreprises, de Fortune 500, ou même de plus petites startups, tout le monde utilise AGI. Vous pouvez ramasser n'importe quelle de leur liste d'emploi pour la gestion de projet, le développement ou les tests, et cela nécessitera une connaissance enfant. Certains emplois exigent une certification aussi comme CSM ou CSP Leo et je suggère que vous poursuiviez ces domaines. Avoir une certification donne une reconnaissance à vos connaissances et c'est un ajout plus agréable à la reprise. Si vous êtes déjà dans le rôle de gestion de produit, vous pouvez penser au rôle de propriétaire de produit ou à d'autres rôles de gestion. Si vous êtes trop passionné par h l, vous pouvez être un coach Agile. Les possibilités et les utilisations du VIH sont infinies. Dans les enquêtes LinkedIn des dix premiers emplois les plus prometteurs est Scrum Master et Product Owner sont l'une des entrées. Donc assez impressionnant chemin de transporteur. Et c'est pourquoi j'ai dit au début que vous avez fait un grand choix en choisissant d'apprendre l'AGI. Ok, donc nous avons parlé du cours, c'est le contenu et les opportunités dans AGI. Commençons notre parcours d'apprentissage et commençons par le chapitre suivant pour savoir ce qui est agile et mêlé. Merci. 2. Pourquoi Agile ? (Problèmes avec l'approche traditionnelle): Bonjour à tous et bienvenue au deuxième chapitre du cours. Nous allons maintenant commencer notre voyage dans les concepts de départ d'Agile et Scrum. Nous allons d'abord voir quelle était l'approche traditionnelle, la façon pré Agile de faire les choses. Parce que cela nous aidera à comprendre la raison pour laquelle un enfant est né et pourquoi il est si réussi. Ensuite, nous verrons le Manifeste Agile et les principes qui sont à la base de la HL. Nous discuterons ensuite de la méthodologie EGL suivie par Scrum. Nous utilisons les termes que chaque île est entassée ensemble, mais rappelez-vous qu'il y a une différence entre elles et nous verrons ce que c'est. Ensuite, nous allons jeter un oeil sur le cycle de vie de la mêlée. Donc jusqu'à maintenant, nous étions à la partie qui est ce que c'est. Maintenant, nous allons passer à la façon dont il est fait partie. Et enfin, nous parlerons du MVP et de l'approche progressive, ce qui est un concept important. Alors commençons. Alors nous allons entrer et commençons par le monde agile de faire les choses, comment nous pensons faire avant l'âge Eyal est venu en photo. Donc, la méthodologie la plus courante qui a été suivie avant qu'un enfant ne soit connu était le modèle de cascade. Et c'est à ça que ça ressemblait. Donc les gars, c'est le modèle de cascade et comme vous pouvez le voir, il y a une séquence stricte de phases. Nous avons la phase des exigences, la phase de conception, vérification de la mise en œuvre, et enfin la phase de maintenance. Et les phases précédentes devaient être terminées avant de pouvoir commencer avec la suivante. Donc maintenant, ça a l'air assez simple, mais il y avait un gros problème ici. Et le problème de la dette s'est produit quand nous avons dû revenir en arrière et changer les choses. Alors comprenons cela par un exemple. Considérons un scénario où une entreprise veut développer un nouveau produit, disons un téléphone mobile, ils font l'étude de marché. Ils arrivent avec les exigences de ce dont ils ont besoin et ils décident de le mettre en œuvre en utilisant l'approche des chutes d'eau. Maintenant trois mois après le début, disons que l'endeur de phase de vérification et de test du colorant rouge réalisé aux exigences ont changé. Les clients n'ont plus besoin de ce qu'ils enseignaient au départ. Et donc tout ce qu'ils ont planifié et fait jusqu'à maintenant est parti. Et maintenant, nous devons tout recommencer dès le début, la première phase d'exigence. Si vous y pensez, les gars, c'est la réalité du monde d'aujourd'hui. Si vous voyez l'état d'esprit des clients aujourd'hui, leurs besoins évoluent si vite que études ont montré que dans les grands projets complexes, environ 70% des besoins initiaux seront modifiés pendant le projet. Ce que nous faisons aujourd'hui serait obsolète et remplacé par quelque chose de nouveau dans trois à six mois. Et donc la chute d'eau ne pouvait pas faire face à ce monde des exigences changeantes. C' est donc ce que dit la diapositive. Si vous pensez à ce sujet, même le client, Alors donnez-nous les exigences pour leurs projets. Il se peut qu'ils ne connaissent pas toutes les exigences à l'avance. En fait, il est difficile pour quiconque de deviner comment les marchés et les utilisateurs réagiront à un produit dans les trois à six prochains mois parce que, vous savez, les choses changent si vite. Et pour surmonter ce problème, les choses devaient être bien cours-corrects dans le lot entre les deux et cette augmentation du coût, du temps, des efforts, etc. Maintenant, un autre problème avec Bagdad en cascade, l'utilisateur final ou le client n'a pas été impliqué dans le processus et le logiciel de travail Dessau ou produit assez tard dans le jeu et si un changement était nécessaire, eh bien, revenons à nouveau et vous commencez à implémenter à partir de la phase initiale. Encore une fois, ce qui signifie plus de coûts de temps, d'efforts, etc. Donc les gars, cette approche traditionnelle de chute d'eau que nous avons vu commence à développer des fissures. Et en fait, aux États-Unis où le ministère de la Défense était le plus grand utilisateur de cascade, ils ont découvert que 75% de leur projet n'a jamais été achevé raison de retards et d'une augmentation des coûts due à des changements fréquents. Donc, une fois de plus, pour résumer le problème avec l'approche traditionnelle, numéro un, personne ne peut obtenir l'exigence en un seul coup parce que les choses changent si vite. Numéro deux, l'utilisateur final n'a pas participé au processus. y avait pas de mécanisme de rétroaction. Et le numéro trois, le logiciel de travail ou le prototype est arrivé assez tard sur la photo. Donc, au moment où les changements pouvaient être pris en compte, il était assez tard. Bref, cette approche traditionnelle n'était pas bonne pour répondre à des besoins en constante évolution. C' est ainsi qu'à la fin des années 90, l'industrie voulait aller vers un modèle itératif ouvert aux changements en évolution. Et il a pris en considération les vrais problèmes. Tout d'abord, personne ne peut connaître toutes les exigences. Deuxièmement, apporter des changements est une affaire importante. Il n'est pas facile de continuer à changer les choses chaque fois qu'il y a une nouvelle exigence. Et surtout, nous avions besoin de quelque chose qui peut être numéro un, fait par petits incréments. Numéro deux, la dette pourrait être itérative. Et le numéro trois, cela impliquait une rétroaction continue. Donc, si jamais on a eu une modification, on peut la trouver tôt. Et les gars, c'est le processus de pensée exact qui a donné naissance à un enfant, développement itératif et incrémental avec une rétroaction continue. Et vous entendrez ces trois mots, itératif, incrémental et continu commentaires beaucoup dans ce cours, parce que les autres nécessités sur lesquelles un enfant ou un Scrum est construit. Très bien, maintenant l'industrie avait un peu est commencé à adopter quelques modèles itératifs dans les années 90. Mais la vraie chose est venue en 2001 lorsque 17 développeurs de logiciels se sont rencontrés dans un centre de villégiature aux États-Unis. Et ils ont trouvé quelque chose qui s'appelle le manifeste de la HL. Parlons donc de ce que ce manifeste h l et comment il forme la vision d'un enfant dans la prochaine conférence. Merci. 3. The Agile Manifesto: Bonjour tout le monde. Parlons maintenant du Manifeste Agile. Et il est important de comprendre ce manifeste parce qu'il est le fondement et le principe directeur de la mise en œuvre de la LH partout dans le monde. Ce manifeste a maintenant quatre valeurs fondamentales et 12 principes de soutien. Alors voyons ce qu'ils sont. Et vous savez, il y a un site web dédié à ce manifeste, alors regardons ça. Donc les gars, ils ont un site Web appelé HL manifesto.org. Et c'est à ça que ça ressemble. Et vous pouvez voir les quatre valeurs fondamentales énumérées ici. Et il est dit que les choses à droite sont ce que nous avons fait. Mais au lieu de cela, nous devrions valoriser plus que les choses à gauche et nous devrions les suivre. Donc, numéro un, nous devrions valoriser les individus et les interactions plutôt que les processus et les outils. Les processus sont importants, mais ils ne sont pas souples à l'évolution des besoins des clients. Nous ne devrions donc pas nous en tenir aveuglément aux processus. Nous devrions plutôt nous concentrer davantage sur les individus et leurs interactions. Lorsque les individus collaboreront davantage, ils trouveront une meilleure idée et ne se contentent pas de suivre le processus. Donc, c'était le point numéro un, mais rappelez-vous qu'il ne dit pas arrêter de suivre tout le processus et faire ce que vous voulez. Non, cela dit simplement que les individus devraient interagir davantage, qu'ils devraient collaborer davantage et qu'ils ne devraient pas aller aveuglément à ce que dit le processus. Numéro deux, logiciel de travail sur une documentation complète. Donc, à l'époque de la chute d'eau, Il y avait beaucoup de documentation pour chacune de ces étapes et l'âge. J' ai dit que nous allons garder la documentation au minimum c'est rationaliser tout et se concentrer davantage sur l'obtention d'un logiciel de travail. Donc, une fois de plus, ne comprenez pas que chaque allée dit est arrêté de faire toutes sortes de documents. Non. Au lieu de cela, il veut que nous nous concentrions davantage sur la mise en œuvre de logiciels plutôt que sur l'obtention de documents. Et le numéro trois, la collaboration client sur la négociation de contrat, ce qui signifie impliquer le client dans l'ensemble du parcours. Pensez à ce qu'ils veulent plutôt que d'essayer de travailler comme un contrat écrit unique. Et dernier numéro pour répondre au changement plutôt que de suivre un plan. Et celui-ci est le plus important dans mon, mon point de vue parce que la plupart des gens pensent à des agendas juste à la méthodologie. Mais rappelez-vous toujours qu'un enfant est plus un processus de pensée. Nous devons être HI dans notre pensée seulement alors nous pouvons suivre une méthodologie de prison avec précision. Et le test VIH nous dit de ne pas suivre aveuglément le plan. Au lieu de cela, soyez flexibles, réactifs aux changements afin que nous puissions nous adapter rapidement aux conditions changeantes du marché. Ce sont donc les quatre valeurs fondamentales. Et comme il est dit, il y a de la valeur sur les éléments à droite. Les choses que nous avons faites dans l'approche traditionnelle. Mais maintenant, nous allons valoriser davantage les choses à gauche. Donc, en un mot, c'était la partie d'un gel. Et ici, il énumère le nom de ces 17 personnes qui se sont réunies pour former le manifeste Agile et ont trouvé ces quatre valeurs fondamentales. Maintenant, si vous faites défiler plus bas, vous verrez un lien vers les 12 principes. Donc, c'est la page qu'il faut, et vous pouvez les lire à travers. Il y a quelques points clés ici. abord, nous devons fournir au client une livraison anticipée et continue. Donc si je vous donne un produit après 12 mois et disons que ce n'est pas bon. Il y aurait beaucoup d'efforts, de coûts et de temps pour essayer de revenir en arrière et de le corriger à nouveau. Donc, ne laissez pas cela arriver, livré au client en continu par incréments. Et encore une fois, il y a 12 principes différents. Je ne veux pas les examiner tous. Vous pouvez les lire. Essayons de comprendre les concepts clés ici. Le premier était la livraison anticipée et continue. Et si vous descendez, ça parle de travailler ensemble. Les gens d'affaires et les développeurs doivent donc travailler ensemble. Rappelez-vous les individus et les interactions que nous avons vues dans le premier principe de base. Deuxièmement, faites confiance aux gens, rappelez-vous à nouveau des valeurs fondamentales ne suivent pas le processus et le contrat par aveuglément confiance sur les gens et les faire venir avec le meilleur produit ou logiciel. Ensuite, il y a des interactions face-à-face. Encore une fois, Phi, désolé, conversation en face à face. Donc encore une fois les individus et les interactions. Ensuite, si vous faites défiler vers le bas, nous avons un logiciel de travail. Donc, comme nous avons parlé dans les valeurs fondamentales plus tôt, moins de documentation, plus de logiciels de travail. Nous voyons des logiciels ici, mais vous pouvez penser à des produits aussi. Cela signifie essentiellement que les critères de mesure sont de travailler quelque chose pas seulement des tonnes et des tonnes de documentation. Donc, encore une fois, vous pouvez lire ceci à fond ligne par ligne, mais l'idée d'un GYE, y compris ces principes, vient de ces quatre valeurs fondamentales, qui sont les individus et les interactions sur les processus et les outils , sur la documentation complète, la collaboration avec les clients, la négociation de contrats, et enfin, la réponse, en réponse au changement plutôt que de suivre un plan. Souvenez-vous donc de ces quatre valeurs fondamentales. Tu peux le sauver quelque part. Vous pouvez l'écrire sur votre bureau. En fait, à nos débuts, lorsque nous avons commencé à mettre en œuvre une IG dans notre projet, nous avions l'habitude d'afficher ces grandes affiches sur la dette murale énumérant ces valeurs fondamentales. Et vous pouvez aussi faire la même chose. Vous pouvez les raccrocher dans un endroit où, vous savez, vous faites des réunions régulières qui l'associent ensemble. Et c'est important parce qu'il nous aide à rappeler l'importance de la collaboration, du développement progressif, etc. Et si vous obtenez ces concepts, vous aurez la pleine idée de la puissance Alice. Donc, d'accord les gars, donc c'était tout au sujet du Manifeste Agile. Maintenant, allons dans la prochaine conférence et voir la définition formelle d'un gel. Je te verrai à la prochaine conférence d'ici là. Merci. 4. Définition d'Agile: Bonjour tout le monde. Donc, dans les conférences précédentes, nous avons parlé de l'approche traditionnelle de faire les choses. Nous avons regardé le manifeste de la HL. Voyons vraiment ce qu'est cet ange. Donc, sur votre écran, vous verrez la définition officielle d'AGI et il dit, développement de logiciels HI EL se réfère à des méthodologies de développement de logiciels centrées autour de l'idée de livraison incrémentielle et itérative de petits morceaux de fonctionnalité. Nous sommes des exigences et des solutions évoluées grâce à collaboration entre des équipes auto-organisatrices interfonctionnelles, ce qui permet aux clients de recevoir des commentaires fréquents et de corriger les cours selon les besoins. C' est la définition officielle d'un gel, mais trop de Wurtz, non ? Donc, laissons de côté l'essentiel et concentrons-nous sur les termes les plus importants. Donc, le premier est la livraison incrémentielle et itérative. Rappelez-vous que nous avons parlé plus tôt des anciennes méthodes et le problème avec elles était que nous avons livré le produit assez tard et ensuite nous avons dû faire des changements qui étaient coûteux et retardés. Donc, l'ILC d'âge fournit incrément. Tu n'as pas à tout faire en un court. Faire la première version ou MVP du produit, puis l'améliorer par incréments et via livraisons fréquentes ou itératives d'un petit morceau de fonctionnalité. Ainsi, la conception de petits morceaux, livrez les incréments dans ses plus petits morceaux, puis continuez à répéter tout ce processus. Le prochain concept important est la collaboration. Donc, comme nous l'avons vu plus tôt, aucun processus ou outil individuel ne peut deviner toutes les exigences à la fois. Nous avons besoin d'un groupe de personnes pour collaborer et trouver des solutions. Et c'est pourquoi les équipes d'enfants sont transversales et auto-organisatrices. n'existe pas de concept de gestionnaire de développement ou de gestionnaire de test au sein de l'équipe Scrum. Ils sont tous extérieurs à leur équipe. Les membres de l'équipe qui sont assis ensemble, qui ont travaillé ensemble, ils interagissent les uns avec les autres, ils discutent les uns avec les autres, ils collaborent les uns avec les autres. Et la conception des produits et services utiles pour le client. Et le dernier aspect, rétroaction et la correction du cours. Alors rappelez-vous, des changements viendront sûrement. corrections seraient nécessaires. Gardez donc une rétroaction continue avec le client. Nous ne voulons pas, vous savez, contacter le client après trois mois ou six mois pour recueillir ses commentaires. Nous voulons faire est plus petit, petits incréments. Nous voulons montrer le produit au client. Nous voulons recueillir leurs commentaires et apporter les corrections nécessaires. Donc ces cinq choses que vous voyez en surbrillance sur l'écran, c'est ce que h l est. Souviens-toi, je ne veux pas que tu te souviennes de toute cette définition mot par mot. Et en fait, je ne vous demanderai pas de mémoriser les choses mot par mot n'importe où dans le cours. Rappelez-vous simplement les mots-clés qui sont mis en surbrillance sur votre écran dans la définition. Et si vous allez à une entrevue ou à une organisation et que quelqu'un vous demande ce qu'est un gel ? Vous pouvez indiquer votre propre version en incluant ces mots-clés. Une fois que l'autre personne aura entendu ces mots-clés, elle saura avec certitude que vous comprenez. Salut. Voilà donc l'approche que nous suivrons tout au long de ce cours. Je vais m'assurer que vous comprenez les choses clés et que vous n'avez pas à mémoriser des choses. Donc c'était la définition d'un gel gars. Et fondamentalement, c'est un cycle de planification des choses, les concevoir, de prendre des commentaires, d' examiner le client et de lancer la chose , puis de le refaire encore et encore en itérations. Donc dat est tout hl est le diagramme unique. D' accord, donc je suis sûr que vous savez ce qu'est HFile, son manifeste, ses concepts de base. Parlons donc de la partie de mise en œuvre, et parlons d'un Scrum dans la prochaine conférence. Merci. 5. Définition de Scrum et sa différence par Agile: Bonjour à tout le monde et bienvenue. Parlons donc de notre prochain sujet, qui est un Scrum. Alors, c'est quoi exactement cette mêlée ? Maintenant, nous avons parlé de H L, et nous utilisons souvent Scrum et Age IL ensemble dans le même contexte. Mais rappelez-vous qu'ils sont en fait deux termes différents. Scrum est un cadre de gestion de projet Agile utilisé par les équipes pour développer et livrer des produits complexes. Donc, alors qu'un enfant est un ensemble de valeurs et de principes, est Scrum est le moyen de le mettre en œuvre. Souviens-toi de cette chose. H L est un ensemble de valeurs et de principes et un Scrum est le moyen de le mettre en œuvre. Et souviens-toi. Scrum est une approche incrémentielle et itérative. Alors résumons ces deux mots. Incrémental signifie que nous construisons et livrons le produit en petits morceaux. Et l'itération signifie que nous faisons quelque chose et que nous l'affinons plus loin. Donc, comme nous parlons de logiciels, nous fabriquons un produit initial et ensuite nous les affinons itérativement. Nous faisons des cycles de longueur deux semaines ou quatre semaines. Et dans chacun de ces cycles, nous ajoutons des incréments de nouvelles fonctionnalités et détails au produit initial. Ces cycles sont en fait appelés comme des Sprints et nous en parlerons en détail plus tard. Mais pour l'instant, rappelez-vous que l'objectif de Scrum est de développer des produits dans chaque petit cycle de deux ou quatre semaines appelé Sprints. Et dans chaque sprint, nous ajoutons de nouvelles fonctionnalités, nous ajoutons de nouveaux incréments sur ceux existants. C' est la sortie de chaque sprint. Maintenant, il y a d'autres termes, personnes, processus, et cetera, qui est également défini est Scrum. Et ne vous inquiétez pas, nous en apprendrons plus tard sur chacun d'eux. Mais en résumé, c'est ce qui est Chrome est tout au sujet. Il s'agit d'un cadre HL incrémentiel et itératif pour fournir et développer des produits complexes. C' est tout ce que Scrum est. Maintenant, un dernier point avant d'aller de l'avant est Scrum est utilisé le plus couramment dans le développement de logiciels. Et nous parlons de référence de données principalement dans ce cours. Mais rappelez-vous que Scrum est également utilisable dans d'autres industries comme la fabrication ou d'autres entreprises aussi. Donc, si vous venez de ce contexte, le discours et le mécontentement sont tout aussi significatifs pour vous. J' espère donc que vous êtes clair sur la définition d'une mêlée. Maintenant, continuons, voyons comment HI AL et Scrum sont différents. En parcourant cette liste, vous remarquerez qu'il n'y a pas trop grande de différence de sens. Cette distinction est plus de quoi et de quel sens. Ce dont il parle, c'est que la miette fait ça. Maintenant, nous savons déjà sur la première et principale différence et nous rappelons toujours qu'un enfant est la méthodologie pour le développement et un Scrum est le cadre pour l'implémenter. Donc hl est la valeur fondamentale, h l est le principe de base de faire des choses de développement et un Scrum est sa mise en œuvre. Deuxièmement, HL convient aux petites équipes expertes, tandis que le Scrum est adapté aux besoins en évolution rapide en raison de son aspect de contrôle des processus. Point suivant, le leadership joue un rôle clé dans HDL, mais toutes les décisions Scrum sont prises par équipe. Donc, comme je l'ai mentionné plus tôt, aussi, il n'y a pas de manager, il n'y a pas de chef d'équipe au sein de l'équipe Scrum. Il y a un propriétaire de produit, il y a un Scrum Master, il y a une équipe de développement. Ils sont tous assis ensemble, ils collaborent, ont discuté de l'interaction, et c'est ainsi qu'ils ont résolu les problèmes. Quatrièmement, dans le même ordre d'idées, HI EL favorise la collaboration et l'interaction entre les équipes. Nous l'avons vu dans la valeur fondamentale. Maintenant est miette fait cela via quelque chose appelé une réunion quotidienne debout. C' est donc un rassemblement quotidien d'individus travaillant dans le Scrum et c'est un argent HL7, nous en parlerons dans le chapitre ultérieur, mais c' est ainsi que la collaboration se passe dans cette miette. Ensuite, HL parle de la livraison et des mises à jour sur une base itérative. Encore une fois, est miette fait aussi pourquoi sprints ? Donc ces empreintes, comme je l'ai mentionné plus tôt, sont au cœur de toutes les activités de son Scrum. Si vous travaillez dans n'importe quel Scrum ou si vous allez travailler dans n'importe quel Scrum à l'avenir, vous entendrez des choses comme, ok, nous allons le faire dans ce sprint, nous le ferons dans le prochain sprint. Nous prendrons deux sprints pour le faire. Parce que comme je l'ai dit, ces sprints sont là où toute l'action, tout le travail se passe dans la Scrum. Et dernier point, h l favorise une rétroaction continue. On l'a vu plus tôt. Est miette fait également la dette via quelque chose appelé une démo de sprint. A la fin de chaque sprint. La démo est aussi une cérémonie de mêlée et nous en parlerons en détail plus tard. Pour l'instant, sachez simplement qu'il est fait après chaque sprint pour montrer le produit et recueillir des commentaires, que la méthodologie de rétroaction continue. Donc les gars, c'est la principale différence entre chaque île, c'est Scrum. Et encore une fois, vous n'avez pas besoin de vous souvenir de tout cela, rappelez-vous juste numéro un, HI, et Scrum sont différents. Numéro deux, h L est une méthodologie. Il est guidé par un ensemble de valeurs et de principes fondamentaux que nous avons vus. Et Scrum est une approche basée sur le HL. C' est juste une implémentation de HAL. Bon, alors dans la prochaine conférence, parlons plus de Scrum. Je te verrai à la prochaine conférence d'ici là. Merci. 6. Cycle de vie Scrum: Bonjour tout le monde. Maintenant, nous savons ce qu'est Scrum. Voyons comment les choses fonctionnent là-dedans. Et ce que vous voyez à l'écran, ce sont les étapes qui forment ensemble le cycle de vie de Scrum. Maintenant, nous allons seulement en parler brièvement ici parce que nous avons un chapitre consacré à ces questions plus tard. Alors jetons un coup d'oeil sur eux. Mais avant de les ramasser, réfléchissons à la façon dont nous travaillons dans notre vie quotidienne. Et si vous comprenez cela, vous aurez l'idée de Scrum aussi. Donc nous voulons faire beaucoup de choses dans notre vie, non ? Il y a une grande liste de choses que nous voulons faire ou que nous devons faire. Sur cette grande liste, nous choisissons cinq choses que nous voulons faire cette semaine. Donc, nous voulons aller dans un endroit. Nous voulons nous acheter quelque chose, nous voulons rencontrer quelqu'un, etc. Nous sommes en train de choisir cinq choses, non ? Et puis on fait ces cinq choses au cours de la semaine. À la fin de la semaine, nous résumons comment nous l'avons fait, si nous aurions pu faire mieux, etc. Et puis nous ouvrons à nouveau notre grande liste de choses et choisissons les cinq prochaines choses que nous aurons à faire la semaine prochaine. C' est comme ça que nous travaillons en tant qu'individu, et c'est exactement comme ça qu'une mêlée fonctionne aussi. Nous avons donc une grande liste d'exigences que nous appelons comme le carnet de commandes de produits. C' est juste une grande liste de choses à faire. Nous faisons une réunion de planification et de papa grandes listes nous choisissons comme cinq ou dix exigences en fonction de la disponibilité des équipes ou de la capacité. Et nous les appelons comme l'arriéré de sprint. Maintenant, nous travaillons sur eux dans le prochain cycle de deux ou quatre semaines qui est appelé comme un sprint. Pendant que nous sommes dans ce sprint, nous faisons une réunion quotidienne tous les matins pour discuter des progrès qui est appelé la réunion stand-up. Et une fois le sprint terminé, nous sommes numéro une démo, tout ce que nous avons fait aux parties prenantes pour obtenir leurs commentaires. Et numéro deux, nous avons rétrospectivement en équipe ce qui était bon et ce qui aurait pu être meilleur lors du dernier sprint. Et puis nous répétons tout cela à nouveau sous la forme d' un nouveau sprint commence par une nouvelle réunion de planification de sprint. Papa a dit que tout ce cycle est ce que c'est Scrum. n'y a pas de moyen plus simple de le comprendre. Maintenant, voici la même chose sous la forme d'un graphique. Nous avons donc l'arriéré de produits, que nous avons appris est une grande liste d'exigences que l'équipe rencontre pour une réunion de planification et en choisir une liste plus petite appelée un arriéré de sprint. Ils le feront dans ce sprint. Et encore une fois, ne vous inquiétez pas des détails plus fins sur la façon dont nous le faisons. Nous les verrons plus tard dans les détails. Mais dans cette conférence, nous ne faisons que gratter la surface des choses. Donc, nous choisissons un petit sous-ensemble d'exigences pour faire qui est appelé l'arriéré de sprint. Nous développons et testons ces choses dans les deux ou quatre semaines sprint. Et puis nous allons faire une démonstration avec les parties prenantes. Nous faisons une rétrospective avec toute l'équipe. Et nous pouvons également publier cet incrément aux utilisateurs finaux. Donc décharge assez simple que vous voyez ici est toute la mêlée à un niveau élevé. Ces autres tâches que vous voyez ici, le propriétaire du produit, l'équipe, le maître de mêlée. Ceux-ci sont appelés les règles Scrum et nous verrons à leur sujet plus tard. Et puis il y a différentes réunions ou cérémonies que nous faisons dans la mêlée pour rassembler tout cela et nous allons jeter un oeil aux données aussi plus tard. Mais ceci ici sur votre écran est l'image de haut niveau. Et encore une fois, si vous le regardez, cela se résume à seulement trois mots. Itérez l'ensemble du processus que nous faisons encore et encore. Offrez l'incrément à l'utilisateur final, recevez des commentaires et incorporez cet ensemble. Donc Dat était les gars est miette en un mot. Maintenant, avant de choisir les aspects que nous avons vus ici en détail plus tard, allons voir un dernier sujet de ce chapitre dans la prochaine conférence. Merci. 7. MVP et approches par graduel: Bonjour tout le monde. Parlons donc un peu de MVP et de l'approche incrémentielle dans cette conférence. Maintenant, nous continuons de voir que h l est tout au sujet des incréments. Alors, comment fonctionne ce concept d'incrément ? Jetons un coup d'oeil et vous savez quoi, comprenons d'abord, pourquoi une image ? Et puis nous reviendrons sur ces diapositives. Alors les gars, que voyez-vous dans l'image, c'est ce que signifie MVP ou un produit minimum viable. Rappelez-vous pas cette partie supérieure, la partie inférieure, nous donnons au client un minimum, quelque chose qui répond à leurs exigences. Nous les laissons s'en servir. Nous prenons leurs commentaires et nous l'améliorons dans les prochaines incréments. Et nous continuons à répéter tout ce cycle, en fournissant de nouveaux incréments dans le processus. Maintenant, rappelez-vous que la partie supérieure de l'image est l'approche traditionnelle, comme la cascade, où nous donnons des choses au client par incréments, mais ils ne peuvent pas l'utiliser comme ils ne peuvent pas utiliser seulement deux morceaux de Tyr. Ils ne peuvent pas donner de commentaires à ce sujet. Et au moment où le produit final est prêt, il y aurait beaucoup de choses qu'ils voudraient changer. Et puis nous nous retrouverions avec le même problème que celui dont nous avons parlé plus tôt avec l'approche traditionnelle. Donc, c'est bien. Salut l. Ce que nous faisons, c'est que nous donnons le skateboard de l'état du client afin qu'ils puissent voyager. Ensuite, ils viendront avec les commentaires que OK, Je veux quelque chose de plus rapide et avec des options de siège. Donc, nous allons leur donner un vélo. Ensuite, ils reviendront avec les commentaires que je veux quelque chose qui ne prend aucun effort qui est un plus rapide, donc nous allons leur donner une moto ou une voiture et ainsi de suite. Donc, à chaque incrément, nous donnons aux clients quelque chose qu'ils peuvent utiliser, quelque chose sur lequel ils peuvent donner des commentaires. Sur cette base, nous améliorons le produit. Donc, ce sont les gars, ce que MVP est le produit minimum viable. Nous donnons au client une version initiale du produit qu'il peut utiliser. Les obtenir leurs commentaires. Nous l'améliorons dans les prochaines incréments et itérations. Il est donc basé sur l'approche construire, mesurer et apprendre, ce qui signifie que nous construisons quelque chose. Nous prenons les commentaires et nous les examinons, les mesurons. Nous tirons des leçons de cette rétroaction et nous faisons de nouvelles choses. Et encore une fois, les gars, si vous y pensez, ce concept sous-jacent est à nouveau, itération et incrément. Nous construisons le produit, nous mesurons les commentaires, nous apprenons de celui-ci et le refaisons à nouveau. Donc c'est tout le concept et il est important de comprendre parce que c'est l'image plus large de hL et c'est la miette. Rappelez-vous que nous ne pouvons pas faire les choses en un seul court. Cela signifierait commettre les mêmes erreurs que celles que nous avons faites avec l'approche traditionnelle. Nous nous réunissons en tant qu'équipe collaborative. Nous faisons des choses en itération. Nous avons conçu le MVP initial. Nous y apportons des améliorations incrémentielles et c'est tout. C' est tout ce qu'il y a à comprendre. Impressionnant. Alors maintenant, nous sommes à la fin de ce chapitre et nous allons apprendre les concepts de base ici. Nous avons appris quel âge I l est, ce qui est Scrum est un haut niveau de la façon dont ils fonctionnent et comment l'incrémentation MVP entière fonctionne. Nous poursuivrons ces enseignements dans le prochain chapitre et verrons tous ces concepts et plus en détail. Ce sera donc un voyage d'apprentissage très excitant. Mais avant de terminer ce chapitre, je voulais juste vous laisser avec deux pensées qui sont les plus importantes pour quelqu'un qui travaille dans le VIH. Donc, la première pensée est que h L n'est pas seulement un guide. chose la plus importante est un état d'esprit. Si nous sommes très nombreuses pensées, Si nous sommes l'âge Eileen, notre travail, notre collaboration avec leur équipe, seulement alors nous pouvons mettre en œuvre avec succès un gel ou un Scrum. Alors pensez à HCI comme un état d'esprit qui est le plus important. Deuxièmement, SIS ou une mêlée n'est pas un bâton magique qui résoudra tous nos problèmes. Il peut nous montrer quels sont les problèmes ou quels sont les problèmes qui se posent dans l'industrie. Mais c'est à nous d'avoir l'esprit agile, travailler ensemble pour résoudre ces problèmes et de livrer un produit exceptionnel à l'utilisateur final. Donc, encore une fois, les deux concepts, garder un état d'esprit d'enfant et d'autre part, utiliser l'âge IL-2. Connaissez vos problèmes. Ce n'est pas un bâton magique qui peut résoudre tous vos problèmes. Alors les gars, avec cette pensée, passons au chapitre suivant et apprenons quelque chose qui est connu sous le nom de rôles Scrum, les gens qui composent le Scrum. Je te verrai à la prochaine conférence d'ici là. Merci. 8. Introduction aux Scrum Scrum et des parties de Scrum: Bonjour à tous et bienvenue au troisième chapitre du cours. Maintenant, en commençant ce chapitre, nous allons choisir un par un, les sujets que nous avons abordés dans le dernier chapitre. Et nous allons aller en profondeur pour connaître tous les détails. Donc ce sujet que nous allons aborder dans ce chapitre sont les personnes qui composent une équipe Scrum, plus communément appelée les rôles Scrum. Et je choisis ce sujet particulier d'abord parce que, comme nous l'avons vu dans le dernier chapitre, la première valeur fondamentale de h l dit les individus et les interactions sur les processus et les outils. Les individus sont donc la composante la plus importante d'une équipe Scrum. Et donc nous allons d'abord savoir à leur sujet dans ce chapitre. Et vous savez quoi, nous allons couvrir ce chapitre de façon très interactive. En fait, nous allons appeler les gens les rôles de Scrum en tant qu' amis et nous les rencontrerons un par un et saurons quel est leur travail, quelles sont leurs responsabilités, et cetera. Alors commençons. Et voici l'ordre du jour de ce chapitre. Donc, nous allons parler des rôles suivants. Ils ont pris part, le propriétaire du produit, l'équipe de développement, The Scrum Master. Et enfin, nous allons discuter de la dynamique de l'équipe de mêlée. Alors, quel est le lien et la relation entre eux ? Alors commençons. Donc les gars, ce sont les différents rôles Scrum ou la façon dont nous l'appelons dans ce cours, nos amis dans le Scrum commencent par le bas à gauche. Nous avons les détenteurs de participations qui sont externes à une équipe Scrum, mais ils ont les exigences commerciales sur lesquelles 13 fonctionnent. Ensuite, nous avons le propriétaire du produit qui est comme le capitaine de l'équipe. Il décide de ce que l'équipe doit faire et il fixe la priorité des choses. Ensuite, nous avons l'équipe de développement qui effectue le travail de codage ou de test. Et enfin, nous avons le maître de mêlée qui est le gardien de l'équipe. Et il ou elle s'assure que l'équipe suit est miette efficacement et ils ne sont pas blogués sur quoi que ce soit. Aussi les gars, à l'extrême droite, nous avons l'utilisateur final pour lequel tout le travail est fait. Donc, même si ce n'est pas un rôle Scrum, c'est quand même très important de toujours garder l'utilisateur final à l'esprit parce qu'il ou elle est celui pour qui tout le travail est fait et se soucier leurs exigences et de leurs commentaires est très, très important. Alors commençons et jetons un coup d'oeil à notre première règle, notre premier ami, je les détenteurs de pieux. Alors, qui sont les détenteurs de pieux ? Eh bien, un intervenant est d'abord quelqu'un qui est externe à l'équipe de mêlée. Et deuxièmement, qui a un intérêt ou exigence ou une connaissance du produit en cours de création. Pensez donc au détenteur de la participation comme l'équipe de gestion des produits de votre entreprise qui reçoit les exigences de l'utilisateur final et les transmet à l'équipe de mêlée. Ou quelqu'un dans les ventes, ou même le PDG de l'entreprise pourrait être un actionnaire. Lorsque nous travaillons sur la page des termes et conditions, le gars du service juridique sera un détenteur du pieu parce qu'il ou elle fournira le texte à écrire. Lorsqu' un flux promotionnel est en cours de conception, le membre de l'équipe marketing sera un intervenant parce qu'il utilisera le système. Et si l'équipe Scrum travaille sur quelque chose et qu'ils reçoivent l'aide d' une personne d'une autre équipe parce qu'il ou elle a plus de connaissances sur la dette. C' est aussi une partie prenante. Donc, tous ces acteurs sont comme des parties prenantes différentes et ces actionnaires révèlent leur conception, leur produit ou leur logiciel. Et ils fournissent les commentaires, soit directement de leur part, soit de l'utilisateur final. Et cela nous aide à créer un produit meilleur et précieux. Donc les gars, les papas le sens de « détenteur de pieu ». Juste pour le résumer rapidement, il ou elle est externe à la mêlée. Il a une exigence d'intérêt ou une connaissance du produit. Enfin, il ou elle aide à fournir des informations pour créer un meilleur produit pour l'utilisateur final. Bon, maintenant que nous savons qui est l'intervenant, regardons l'autre rôle de Scrum ou des amis dans la prochaine conférence. Merci. 9. Propriétaire de produit - Rôle et responsabilités: Bonjour et bienvenue. Parlons de notre prochain ami dans le Scrum. Donc les gars sur votre écran sont Kevin, et Kevin est notre propriétaire de produit. Rôle Scrum dont nous allons parler dans cette conférence est le propriétaire du produit, ou PO En bref. Maintenant, le propriétaire du produit est un rôle très important dans l'équipe de mêlée parce qu'il ou elle est comme le leader de l'équipe et la voix des clients a besoin de leur équipe. Kevin est ici responsable de s'assurer que cette équipe fournit des produits précieux aux utilisateurs finaux ou aux parties prenantes. Kevin doit également définir des objectifs et une vision créative du produit. Donc, l'équipe de mêlée qu'il dirige, les développeurs finaux ou les testeurs, ils ne savent pas sur le produit, quoi il est destiné, quelle est l'exigence à remplir ? Ils ne connaissent que les aspects techniques. Donc Kevin doit définir ces exigences commerciales à l'équipe. Il doit traduire ces exigences commerciales dans la façon dont l'équipe comprend la dette et sait ce qu'il faut faire. En outre, Kevin doit gérer l'arriéré des produits. Nous avons donc vu dans le dernier chapitre que le carnet de commandes de produits est comme une grande liste d'exigences à remplir. La tâche de la gestion de cette liste est confiée au propriétaire du produit. Il doit créer des exigences dans l'arriéré connu a connu sous le nom d'histoires d'utilisateurs, il doit écrire les exigences de bas niveau ou les critères d'acceptation dans eux. Il doit modifier les exigences, les supprimer, les classer par ordre de priorité, etc. Et en fait, c'est l'une des responsabilités les plus importantes d'un propriétaire de produit. Les données sont destinées à maintenir l'arriéré des produits. Point suivant. La prochaine responsabilité est de gérer la priorité des choses en termes de temps, l'argent est la portée, etc. Donc assez clair. Prêt, Tâche importante à nouveau. Ensuite, Kevin doit superviser le développement réel du produit. Donc, il a pris l'arriéré, il a fait vider le budget. Maintenant, il doit s'assurer que le travail réel de fabrication du produit se passe en douceur. Donc, cela signifie travailler avec l'équipe de développement, faire un sprint planification pour fixer l'ordre du jour du sprint. Répondez à toute dette de requête que l'équipe a pour soutenir leur travail, et cetera. Cela signifie également travailler avec les intervenants pour planifier les prochains ajouts incrémentiels au produit ou à la sortie, etc. Cinquième tâche, Kevin doit anticiper les besoins des clients. Encore une fois, pour le répéter, tout le travail que nous faisons au sein de l'équipe est pour le client, l'utilisateur final et le propriétaire du produit doit comprendre ce dont le client a besoin. Beaucoup d'exigences des utilisateurs viennent des détenteurs de participations, mais ils seront à un niveau élevé, comment le mettre en œuvre au mieux, comment lire l'esprit du client, comment prédire les risques qu'ils pourraient avoir. Tout cela, tout cela est le travail quotidien d'un propriétaire de produit et une tâche très importante. Ensuite, Kevin, le propriétaire du produit, doit agir comme liaison entre les parties prenantes, l'équipe de mêlée ou même les utilisateurs. C' est donc le communicateur principal de l'équipe. Il communique avec les gars externes. Il communique avec les gars externes. C' est le communicateur de l'équipe. Et enfin, Kevin est responsable de chaque itération et incrément du produit. Il doit donc s'assurer qu'il y a une amélioration suffisante, la fin des progrès réalisés à chaque itération, l'appel final sur la qualité des performances du produit, etc. C' est avec le propriétaire du produit et il doit décider si l'équipe peut aller de l'avant ou si elle doit revenir en arrière et refaire les choses. Donc, les gars, sur votre écran, ce que vous voyez sont les principaux rôles et responsabilités du propriétaire du produit. Maintenant, avant de conclure un point de plus, rappelez-vous plusieurs fois, il pourrait y avoir un analyste d'affaires également sur leur équipe qui va décharger une partie du travail du propriétaire du produit. Ainsi, les rôles et responsabilités de l'analyste d'affaires et du propriétaire du produit se chevauchent quelque peu. Il ou elle peut effectuer une partie du travail que fait le propriétaire du produit. D' accord, comme nous l'avons vu, le propriétaire du produit est un rôle très important dans l'équipe de mêlée. Et le propriétaire du produit est celui qui doit jongler entre beaucoup de responsabilités. Pour résumer ici, il faut travailler avec les parties prenantes d'un côté, l'équipe de la mêlée de l'autre côté. Il doit obtenir les exigences, les traduire. Et c'est lui qui doit finalement s'assurer que l'ensemble du processus de mêlée ajoute des valeurs incrémentielles au profit de l'utilisateur final. rôle très important, beaucoup de responsabilités sur notre ami Kevin ici. Super. Maintenant que nous connaissons le propriétaire du produit, jetons un coup d'oeil à un autre rôle dans la prochaine conférence. Merci. 10. Équipe de développement - Rôles et responsabilités: Bonjour tout le monde et bienvenue. Parlons de nos prochains amis à Scrum. Dis bonjour à Andrew et Karen. Andrew est développeur au sein de l'équipe et Karen est l'assurance qualité ou testeur. Et ils sont tous les deux appelés l'équipe de développement. Donc juste une note rapide ici, bien que l'équipe de mêlée contient différents rôles, comme développeur ou un testeur, ou concepteur ou développeur senior ou testeur senior est miette ne les appelle pas séparés. Ils sont tous simplement connus sous le nom d'équipe de développement parce qu'ils développent le produit selon les besoins du propriétaire du produit. Ce sont donc les gens qui sont responsables de la livraison du produit final. Et c'est leur responsabilité de haut niveau juste pour résumer les choses en une seule phrase. Mais considérons-le plus en détail. La première responsabilité d'Andrew et de Karen est de comprendre les histoires d'utilisateurs qui sont écrites par le propriétaire du produit. Ils doivent mettre en œuvre ces histoires. Donc, évidemment, ils doivent savoir à ce sujet quand l'équipe se réunit pour la planification du sprint ou le toilettage en retard. Et nous allons examiner ces cérémonies en détail dans le chapitre suivant, l'équipe de développement doit s'assurer qu'ils comprennent pleinement ce qu'est l'utilisateur. L' histoire dit, ce que veut le propriétaire du produit, quelles sont les exigences exactes pour que les choses puissent être conçues de la même manière. Le lendemain également fournir des entrées dans la création des histoires d'utilisateurs. Et rappelez-vous que ce ne sont que des entrées de l'équipe de développement généralement ne crée pas un utilisateur est passé, C'est le travail de toner du produit. Mais ils peuvent continuer à écailler avec des entrées ou des suggestions, etc. S'il s'agit d'une histoire purement technique, alors chers commentaires seront probablement pris comme l'appel final. Mais la responsabilité première de créer des histoires d'utilisateurs incombe au propriétaire du produit. L' équipe de développement ne le soutient que. La troisième responsabilité de notre ami Andrew et Karen est d'estimer les histoires des utilisateurs. Donc l'estimation est un grand sujet dans une mêlée et nous avons un chapitre consacré à cela plus tard. Pour l'instant, sachez simplement que l'équipe de développement fournira ses estimations pour l'histoire de l'utilisateur afin que le propriétaire du produit sache combien de travail peut être livré dans un sprint. Quatrièmement, l'équipe de développement s'engage à faire des histoires d'utilisateurs dans un sprint. Et cet engagement vient après la planification du sprint. Et c'est quelque chose que l'équipe de développement doit aussi être honnête, et veiller à ce que cet engagement soit respecté. Le point suivant est l'aspect travail. Donc, écrire du code ou tester les histoires d'utilisateurs qui ont été prises et veiller à ce que la livraison de produits de qualité à l'utilisateur final. En fait, c'est la majeure partie du travail de l'équipe de développement et c'est là que leur temps et leurs efforts seront majoritaires à chaque sprint. Ce sont donc eux qui traduiraient les exigences en travail efficace. D' accord, alors nous avons la responsabilité d'identifier les risques. Et chaque fois que nous disons le risque, il doit aussi inclure des mesures d'atténuation. Donc, si quelque chose ne peut pas être fait, Quelque chose risque de ne pas être terminé. L' équipe de développement doit l'élever au maître de mêlée ou au propriétaire du produit afin qu'il puisse l'aider à le résoudre. Et la responsabilité finale est de pousser les changements dans la production afin que améliorations de la qualité de conception de l' équipe après qu'ils crient est la fin du sprint ou quand le propriétaire du produit le veut, l'équipe doit pousser ces incréments, ces changements dans l'environnement réel afin que l'utilisateur final puisse l'utiliser et que tout son travail acharné puisse être mis en œuvre. D' accord, les gars. Voilà donc quelques-uns des rôles et responsabilités d'Andrew et Karen, notre équipe de développement. Et juste pour résumer une fois de plus en une phrase, l'équipe de développement est celle qui fournit le produit final conformément aux exigences fournies par le propriétaire du produit. Ok, passons au dernier rôle maintenant, qui est le Maître de Scrum. Alors voyons ça dans la prochaine conférence. Merci. 11. Scrum Master - Rôle et responsabilités: Bonjour à tout le monde et bienvenue. Parlons du rôle de Scrum Master. Maintenant, quand on pense aux rôles de Scrum, le premier terme qui nous vient à l'esprit est d'un Maître de Scrum. Mais tu sais, j'ai gardé ça intentionnellement pour la dernière fois pour qu'on sache quels sont les autres rôles. Et puis nous pouvons voir comment le Scrum Master aide à faciliter le travail pour tous. Les gars, voici notre ami Bob, qui est le maître Scrum de l'équipe. Et je vais vous dire ce que Bob a un rôle très intéressant dans l'équipe parce qu'il doit soutenir l'équipe. Il doit s'assurer que cette équipe suit est miettes meilleures pratiques. Et vous devez également vous assurer que les membres de l'équipe ne sont pas blogués sur quoi que ce soit. Donc, le premier point que vous remarquerez à propos de Bob est qu'il est le chef de serviteur de l'équipe de mêlée. Et ce que cela signifie, c'est qu'il doit suivre un style de leadership favorable. Il doit soutenir l'équipe, remplissant les différents rôles de l'équipe. Il sert le propriétaire du produit dans beaucoup de choses. Il est au service de l'équipe de développement et il sert également l'organisation en adoptant avec succès un enfant. C' est pourquoi, comme je l'ai dit, est Scrum Master est un chef de serviteur. C' est l'un des rôles les plus importants et les plus larges de l'équipe. Le Scrum Master aide le propriétaire du produit à planifier le travail avec l'équipe afin que les objectifs de livraison du propriétaire du produit soient atteints. Il aide également le propriétaire du produit à gérer l'arriéré des exigences. Il est efficace et à jour. Ensuite, le Scrum Master s'assure que tous les membres de l'équipe comprennent les objectifs et la portée du travail requis. Voici donc la façon dont le Scrum Master aide le propriétaire du produit. Il l'aide à faire face à l'arriéré et il aide à définir les objectifs et la portée de la dette envers tous les membres de l'équipe. Donc, tout le monde est sur la même page et fait le travail que le propriétaire du produit veut. Ensuite, parlons de la façon dont Bob, le maître Scrum, aide l'équipe de développement. Il est donc responsable de s'assurer que l'équipe n'est pas bloquée. Ils ne sont pas distraits par des interruptions externes ou d'autres distractions et qu'ils sont en mesure de travailler sur les engagements de sprint. Et c'est un travail très important gars parce que vous savez que l'équipe s'est engagée à un ensemble de travail pour le sprint. Et s'ils sont détournés ou distraits que cela, travail sera certainement entravé. C' est donc le travail d'un Scrum Master de s'assurer que cela n'arrive pas. L' équipe est en mesure de se concentrer sur ses engagements. Même temps est Scrum Master assure également que l'équipe n'est pas surchargée. Ainsi, lors d'une planification de sprint, le maître de mêlée vérifie les estimations et la planification de la capacité pour s'assurer que tout le monde a suffisamment de travail, mais personne n'a de surmenage. Voilà donc la façon dont le Scrum Master sert l'équipe de développement. Et enfin, le Scrum Master est l'entraîneur HAL des organisations. Donc Bob ici doit organiser les différentes cérémonies de miettes. Comme ils se lèvent, ils sprint, planification, rétrospective, etc. Et nous verrons ces cérémonies en détail plus tard. Mais pour l'instant, le Maître de la Scrum est l'animateur, l'organisateur de toutes ces cérémonies. Enfin, il doit s'assurer que la mêlée est bien suivie au sein de l'organisation. Et il doit s'assurer que les meilleures pratiques sont diploïdes. Voilà donc la contribution du maître Scrum à l'organisation. Pour résumer, tout comme je l'ai dit, c'est Scrum Master est un rôle avec un très large ensemble de responsabilités. Quand nous parlons de travailler dans une mêlée ou H L et nous parlons de ses avantages. Ces avantages ne se produiront que lorsqu'un enfant ou un Scrum est suivi efficacement, lorsque les gens sont en mesure de travailler efficacement sans aucune distraction. Lorsque la vision du propriétaire du produit est transférée à l'équipe et le travail d'un Scrum Master pour s'assurer que tout cela se passe. Donc, comme vous pouvez comprendre l'importance de Bob, le Scrum Master est beaucoup dans l'équipe. Bon, maintenant que nous connaissons tous les différents rôles dans une équipe Scrum, parlons un peu de leur rencontre et de leur travail ensemble. C' est à propos de la dynamique de l'équipe dans la prochaine conférence. Merci. 12. Dynamiques de Scrum Team: Bonjour à tout le monde et bienvenue. Comprenons le concept de dynamique de l'équipe Scrum. Donc, nous savons qu'une équipe Scrum a un propriétaire de produit, une équipe de développement d'analystes d'affaires, Scrum Master. Alors comment ces gars se réunissent-ils pour travailler ensemble en une seule unité ? Quelle est la synergie qui les lie ? La réponse à tout cela est, encore une fois, ce que nous avons vu dans le chapitre précédent. La première valeur de base de la dette est les individus et les interactions entre les processus et les outils. Et c'est ce qui motive la dynamique de l'équipe. Donc, nous avons vu plus tôt que c'est que les équipes Scrum sont auto-organisatrices et auto-gérées. Cela signifie que les équipes Scrum ne devraient pas être régies par les anciennes méthodes. n'y a pas de gestionnaire de développement ou de responsable de test au sein de l'équipe de mêlée pour contrôler ressources ou estimer les choses que l'équipe gère efficacement elle-même. L' équipe estime pour son travail. Ils disent au propriétaire du produit combien de temps cela prendra, qui fera la tâche, etc., et ils honorent leurs engagements. Ensuite, le Maître de Scrum est là pour agir en tant que facilitateur pour organiser les choses. Et comme nous l'avons vu, c'est l'une des responsabilités d'un Maître de Scrum. Mais vous savez ce que l'équipe ne devrait pas dépendre entièrement d'un maître de mêlée. Sauvons que le Scrum Master est en congé, un jour est encore alors l'équipe devrait se réunir et faire leur debout quotidien. Parce que le concept, rappelez-vous les gars est de l'auto-gestion, d' interagir, de collaborer les uns avec les autres, pas pour le donneur de produit ou un Scrum Master ne pas dépendre d'eux. troisième point est que les équipes Scrum réussissent ou échouent dans l'ensemble de l'équipe. Donc, quand nous parlons des rapports de l'OIT sur l'âge dans le chapitre ultérieur, nous verrons que les équipes sont évaluées sur combien sont les storypoints ils sont livrés, combien d'histoires ils ont fermé, fermé, etc. C' est donc la sortie de l'équipe que l'équipe a réservée, pas les individus, tout comme nous l'avons fait dans le sport. En fait, le mot est que Scrum lui-même vient du sport du rugby. Le point suivant est que les équipes Scrum sont interfonctionnelles. Ils ne vont pas par titres. Donc, comme nous l'avons vu plus tôt aussi, il y a une seule équipe de développement. n'y a pas de développeur, architecte, testeur, concepteur, etc. n'y a pas de catégorisation si nécessaire, le développeur devrait également faire ce test. Le testeur peut prendre le travail de BA, et cetera. Cinquièmement, et nous parlons de culture à partir d'ici. Donc c'est une chose culturelle. I Scrum équipes généralement R est plus petite en taille, c'est-à-dire autour de neuf à 12 personnes est un très bon nombre et toute cette équipe est assis ensemble. n'y a pas de concept d'isolement, il n'y a pas de concept de cabines séparées. Cette équipe est assise ensemble. Ils sont près les uns des autres, donc il y a un lien entre l'équipe, un environnement ouvert pour la discussion. Et le dernier point est une culture de communication efficace au sein de l'équipe. Donc, il y a un debout tous les jours le matin. L' équipe s'asseoir ensemble, ils discutent des choses qu'ils communiquent les uns avec les autres est que les équipes Scrum ont un nom d'équipe, notre manifeste d'équipe, et cetera. Et tout cela contribue à créer un lien, une synergie entre leur équipe. Donc les gars, ce sont quelques-uns des points pour atteindre la dynamique de l'équipe parce que rappelez-vous, HI, ou est Scrum, c'est tout au sujet des individus et des interactions. Il est donc très important pour les équipes de travailler ensemble et de livrer un produit exceptionnel au client. Bon, donc ça nous amène à la fin du chapitre, mais nous allons apprendre des choses cool ici. Nous avons rencontré nos amis dans l'équipe Scrum. Nous avons appris comment fonctionne la dynamique de l'équipe. Dans le prochain chapitre, nous allons parler de leurs rencontres, de leurs interactions dans ce que l'on appelle les cérémonies Scrum. Alors je te verrai dans le prochain chapitre. Merci. 13. Gde Backlog et introduction aux créations de Scrum: Bonjour à tous, et bienvenue au quatrième chapitre du cours. Jusqu' à maintenant, nous avons appris les définitions d'Agile et Scrum. Et nous avons vu les différentes règles, toutes les personnes qui composent l'équipe de mêlée. Maintenant, dans ce chapitre, parlons des diverses réunions auxquelles participent ces rôles, et c'est ce qu'on appelle les cérémonies Scrum. Maintenant, avant d'aller de l'avant, juste pour résumer une fois de plus, est Scrum est basé sur les concepts d'itération et d'incréments. Donc, un Scrum est tout sur la répétition des itérations appelées sprints, dans lesquelles nous concevons des incréments pour l'utilisateur final. Et pour gérer ces sprints efficacement. Pour exécuter ces sprints efficacement, il y a une séquence de réunions ou de cérémonies qui se produisent. Dans ce chapitre, nous allons parler de ces cérémonies et de l'ordre dans lequel elles se produisent. Donc, vous obtenez la séquence logique des choses. Et à la fin, nous les regarderons ensemble et ensuite nous comprendrons tout le cycle de miettes. Alors commençons. Donc les gars, voici le contenu de ce chapitre et ce ne sont rien d'autre que des cérémonies de miettes différentes. Maintenant, dans l'un des chapitres précédents, nous avons parlé un peu du cycle de vie de Scrum. Et j'y ai mentionné à quel point c'est très similaire à la façon dont nous planifions les choses dans notre vie quotidienne. Donc, si vous obtenez cela, vous aurez aussi le but de ces cérémonies. Alors écoutez-moi et regardez le pointeur de la souris en conséquence pour voir comment il se rapporte à Scrum. Alors les gars, réfléchissons à la façon dont nous travaillons dans notre vraie vie. Comment gérer les choses dans notre vie réelle ? Donc, nous écrivons une grande liste de choses que nous voulons faire dans notre vie. Et puis nous prenons un petit sous-ensemble de celui-ci que nous décidons d'accomplir par exemple, la semaine prochaine ou deux semaines, etc.. Nous pensons tous les jours quel point nous avons atteint cet objectif, si des correctifs sont nécessaires, si quelque chose nous bloque, et cetera. Et puis, quand la semaine se termine, nous prenons un résumé de la façon dont les choses quand nous faisons la correction du cours, puis nous répétons tout à nouveau la semaine prochaine avec une nouvelle liste. Ça a l'air familier, non ? Et laissez-moi vous dire que ce qu'on fait dans le Scrum est totalement similaire à ça. Comme vous l'auriez deviné. Nous prenons un arriéré ou une grande liste d'exigences, nous en choisissons un petit sous-ensemble, nous travaillons dessus dans le sprint. Une fois le sprint terminé, nous démontrons le travail à nos parties prenantes afin que nous puissions obtenir rapidement des retours d'information. Ensuite, nous faisons une rétrospective des choses à améliorer. Et nous poussons les modifications à l'utilisateur final si nécessaire. Et puis nous répétons tout cela encore et encore. C'est tout ce que c'est. C' est tout le cycle de ses cérémonies Come. Voyez à quel point c'est simple. Allons donc de l'avant et examinons chacune de ces cérémonies plus en détail. Alors les gars, parlons de notre cérémonie de miettes la plus rapide, du toilettage en retard. Mais avant cela, je voulais juste mentionner que nous allons parler de chacune de la cérémonie dans le même format que vous voyez à l'écran. Ce qui signifie quand c'est fait. Qui sont les participants, combien de durée le steak de cérémonie, et enfin, quel est leur but ? Alors commençons. Alors, qu'est-ce que le toilettage des arriérés ? Maintenant, comme son nom l'indique, c'est un toilettage ou un raffinement de l'arriéré. Donc, pour comprendre cette cérémonie, nous devons d'abord comprendre quel est cet arriéré ? Maintenant, quand nous sommes dans le développement de produits, nous devons travailler à la conception de nouvelles exigences, n'est-ce pas ? Il est donc évident que nous devons saisir ces exigences quelque part. Et DAT est quel que soit l'arriéré. L' arriéré est une liste de nouvelles fonctionnalités ou des modifications apportées aux fonctionnalités existantes, des bugs, tout ce que l'équipe a à faire. Alors pensez à cela comme une grande liste d'exigences qui est créée par le propriétaire du produit en consultation avec les parties prenantes, et c'est le travail que l'équipe doit faire. Maintenant, cette liste contiendra évidemment des tonnes de fonctionnalités, n'est-ce pas ? Nous devons donc l'examiner périodiquement. Nous devons y ajouter des détails, nous devons les prioriser, etc. Et c'est important, ce sont les gars importants parce que alors seulement nous aurons des éléments qui sont prêts à travailler dans les deux prochaines semaines sprint la liste prioritaire des éléments. Et ce gars est exactement ce que fait le toilettage en retard ou la cérémonie de raffinement en retard. Alors regardons les autres diapositives. D' abord, quand est-ce que ce toilettage est fait ? C' est fait avant la planification du sprint. Et ça a du sens, non ? Parce que nous avons besoin que les principaux éléments prioritaires prêts à être discutés par la planification du sprint. En outre, il n'y a pas de règle dure et rapide. Combien de jours avant la planification d'un sprint vous devriez le faire. Mais comme deux à trois jours avant que la planification soit bonne, nous ne voulons pas le faire très tôt et les choses pourraient changer. Tenons donc à deux ou trois jours avant le début du sprint. Le prochain sprint commence. Ça devrait être bon. Point suivant, qui participera au toilettage de l'arriéré ? Donc, nous avons évidemment besoin du propriétaire du produit parce qu'il ou elle est responsable de l'arriéré. Que devrait-on faire ? Quelle est la priorité si l'équipe a des questions, il ou elle peut y répondre. Nous avons donc vraiment besoin du propriétaire du produit. Ensuite, nous avons le maître de mêlée qui le soutient. Rappelez-vous, le Scrum Master aide le propriétaire du produit à travailler indifférent. Donc, l'aider à soigner l'arriéré, à les aider à affiner l'arriéré est l'une des tâches du maître Scrum. Donc le propriétaire du produit serait là, le Scrum Master serait là. Et enfin, nous avons besoin de l'équipe de développement, donc nous n'avons pas besoin de l'ensemble des événements de l'équipe de développement. Certaines personnes de l'équipe de développement feront également le travail. Suivant. Combien de temps cette réunion rit. Donc encore une fois, pas de règle dure et rapide, mais comme une heure est bonne. Tu te souviens qu'on a parlé de faire du toilettage en retard vers trois jours avant la planification du sprint, non ? Et cela signifie que cette équipe serait fin du courant est sprint. Donc, évidemment, l'équipe aura beaucoup de travail à terminer et nous ne voulons pas les garder assis pendant cinq heures dans une réunion. Donc, une heure de toilettage est suffisante si nécessaire. Nous pouvons faire une autre séance d'une heure plus tard, mais cela devrait suffire. Nous ne voulons pas maintenir cette équipe pendant de longues heures avant que la prochaine à la fin du courant soit le sprint parce qu'ils auraient travaillé pour terminer. Nous ferions donc deux à trois jours avant la planification du sprint. Et comme une heure si nécessaire, nous ferons une autre séance d'une heure, mais pas trop longue. Et enfin, quel est le but du toilettage des arriérés ? Donc, d'abord, nous passons en revue les histoires d'utilisateurs qui doivent être faites lors du prochain sprint. point le plus important, nous devons préparer les choses parce que le prochain sprint va arriver dans les deux ou trois prochains jours. Nous devons donc être prêts avec le contenu que nous devons faire leur prochain, nous devons résoudre des faits inconnus et incertains pour une estimation correcte. N' oubliez pas que c'est la première fois que l'équipe de développement voit les histoires des utilisateurs. Ils peuvent donc avoir des questions évidemment, et nous devons les résoudre lors de la réunion de toilettage. Qui va les résoudre ? Le propriétaire du produit les dissoudra. Et en résolvant cela est nécessaire pour que l'équipe puisse estimer le travail correctement. Troisièmement, identifier les dépendances et les risques à l'avance. Nous prévoyons donc de prendre les histoires de tau en tête des priorités lors du prochain sprint. Donc, nous allons identifier les risques ou la dépendance en eux maintenant seulement, donc nous ne sommes pas coincés plus tard. Point suivant, attribuez des estimations aux histoires d'utilisateurs. C' est donc comme discuter des points de l'histoire et nous verrons l'estimation en détail plus tard dans un chapitre ultérieur. Mais pour l'instant, sachez simplement que l'histoire de chaque utilisateur doit avoir un point d'histoire pour l'estimation. Et c'est storypoint est donné idéalement dans le toilettage en retard. Certaines équipes le font dans une planification de sprint, mais le toilettage en retard est le moment idéal pour le faire. Cinquièmement, nous partageons les histoires d'utilisateurs qui sont trop complexes ou qui sont nos inconnues. Donc, s'il y a beaucoup de travail dans un utilisateur est histoire et l'équipe pense qu'ils ne seraient pas en mesure de le faire dans un sprint, alors nous pouvons le diviser en plusieurs histoires. C' est donc aussi l'un des programmes de toilettage en retard. Et le dernier point à emporter. Le toilettage réussi conduit à une planification efficace du sprint. Donc, plus nous mettons d'efforts dans le toilettage des arriérés, plus nous nous préparons à faire les choses pendant le toilettage des arriérés, plus le sprint sera efficace. Et est-ce que ça avait du sens, les gars ? Parce que rappelez-vous, nos exigences sont claires, nos exigences sont descriptives leur estimation correcte, alors les choses seraient très faciles dans le prochain sprint. Très bien, donc tout était sur le toilettage des arriérés. Nous avons terminé la première cérémonie. Maintenant, nous avons une liste prioritaire des exigences. Nous savons sur quelles choses nous devons travailler lors du prochain sprint. Jetons un coup d'oeil à la prochaine cérémonie. Ils sprint planification dans la prochaine conférence. Merci. 14. Planification du sprint: Bonjour tout le monde et bienvenue. Parlons de la prochaine cérémonie. Ils planifient le sprint. Donc, ils planification sprint est le plus important est la cérémonie de miettes, et il implique plusieurs aspects. Nous parlerons de ces choses ici à un niveau élevé. Et puis dans un chapitre ultérieur, nous allons vraiment apprendre une planification de sprint plus en détail, y compris l'importance et les techniques d'estimation. Alors commençons. Maintenant, si nous récapitons dans la dernière conférence, nous avons fait le toilettage en retard et l'équipe finalisé les histoires des utilisateurs en termes d'ordre de priorité. L' équipe a discuté de ces histoires d'utilisateurs et s'ils avaient questions, des dépendances ou des risques, ils ont été communiqués au propriétaire du produit et, espérons-le, il l'a résolu. Alors maintenant, nous sommes prêts à aller dans le prochain sprint et commencer à travailler sur ces exigences, ces histoires d'utilisateurs. Mais avant cela, nous devons planifier sur la façon de le faire. Et l'activité de données est appelée comme une planification de sprint. Quand c'est fait, évidemment au début du sprint, nous ne pouvons pas commencer le sprint si nous n'avons pas terminé la planification du sprint. Qui y participe ? Le propriétaire du produit, le Scrum Master et toute l'équipe. Donc, dans l'arriéré de toilettage toute l'équipe n'était pas nécessaire. Mais ici toute l'équipe de développement devrait y assister parce que tout le monde y arrivera ensuite. Les sprints fonctionnent à partir de cette cérémonie seulement après combien de temps cela devrait durer. Donc encore une fois, pas de règle difficile et rapide, mais pour un sprint de deux semaines à notre dit, ok, rappelez-vous si la planification Sprint est en cours d'exécution assez long, cela signifie que l'équipe ne fait pas de toilettage en retard correctement parce que la majeure partie de la discussion sur les histoires des utilisateurs devrait se faire dans le toilettage de l'arriéré seulement et dans la planification, nous devrions idéalement simplement estimer et charger les choses. Et enfin, voyons quels sont les objectifs d'une planification de sprint. Donc, tout d'abord, nous examinons l'arriéré et nous décidons quels éléments tirer dans le sprint. Signification de ce qu'est l'utilisateur, des histoires, des bugs, etc. Les équipes travailleront sur ce sprint. Rappelez-vous que les histoires de l'utilisateur sont déjà prêtes après toilettage du carnet de commandes et qu'elles sont déjà disposées dans l'ordre de priorité. Nous avons juste à décider en fonction de la capacité de l'équipe, combien ils peuvent prendre au sprint, comme les cinq premières histoires ou 80 histoires ou histoires de tennis, etc. Ensuite, nous discutons de la capacité de l'équipe. Donc, nous parlons de combien est la disponibilité de l'équipe ? Quelqu' un est en congé ? Y a-t-il des vacances ? Quelqu' un a-t-il un autre travail personnel ou professionnel, etc. ? C' est donc une partie de l'estimation et nous parlerons capacité en détail dans le chapitre suivant sur la planification du sprint. Troisièmement, nous assignons des tâches aux développeurs testeur. C' est donc une activité majeure d'une planification de sprint. Nous devons assigner le travail, cette tâche à la personne de l'équipe pour que tout le monde sache qui travaille sur quoi. Et rappelez-vous dans Scrum, cette mission devrait être réciproque. Tout le monde devrait dire par lui-même ce qu'il veut travailler sur la base de ses compétences, de son expérience passée, etc. Tout le monde devrait obtenir un travail égal et suffisant dans l'affectation et personne ne devrait être surchargé. Calendrier d'estimation de l'objectif suivant pour chaque tâche. Donc, pour chaque utilisateur est histoire, nous créons des tâches comme le développement, les tests, l'UAT, etc. Et l'équipe fournit leur contribution comme cette tâche particulière prendra quatre heures, cela prendra cinq heures, etcetera. Et c'est l'estimation des équipes du travail. Nous l'exécutons ensuite à nouveau, Les heures disponibles de cette équipe, cette capacité totale. Et en se basant sur dat, nous décidons du nombre d'histoires que nous pouvons prendre à partir de l'arriéré du sprint à venir. Encore une fois, plus sur ces capacités d'estimation, etc., dans le chapitre suivant. Pour l'instant, sachez que c'est la planification du sprint est la cérémonie dans laquelle nous estimons le calendrier pour chaque tâche. Ensuite, nous avons discuté des dépendances de risque connues qui peuvent perturber un sprint. Donc, nous avons parlé du risque dans le toilettage aussi, si elles ne sont pas abordées, s'il ya quelque chose d'autre qui est venu comme si pas assez de gens sont disponibles dans le sprint. S' il y a des informations qui sont venues nouvelles et qu'elles ne sont pas entièrement abordées, ces choses devraient être abordées lors de la planification du sprint afin que nous sachions à l'avance. Et puis les choses ne nous frapperaient pas soudainement au milieu du sprint après que nous nous sommes déjà engagés à tout le travail. Et le dernier point est Scrum Master facilite la réunion pour assurer une discussion efficace et un accord. C' est un point très intéressant, les gars, et nous avons vu plus tôt aussi que le maître de mêlée est le gars qui gère toute la cérémonie, qui dirige toutes les cérémonies. Donc, lorsque nous sommes dans la planification du sprint, lorsque nous déciderons du travail à faire, le propriétaire du produit, nous allons évidemment essayer de pousser pour plus de travail parce qu'il ou elle a la pression d'un détenteur de pieu pour livrer les choses rapidement. Ecrire l'équipe, d'autre part, va estimer prudemment et ils, et donc il y aurait une différence à venir. Il pourrait être soulevé, il pourrait y avoir des dépendances, des inconnues. y aurait pas assez de travail pour tout le monde. Il pourrait y avoir un surmenage pour tout le monde. Toutes ces choses peuvent arriver. Il y a donc un processus de pensée multiple qui se passe. Et c'est le travail d'un Scrum Master pour gérer tous ces aspects. Le Scrum Master facilite la réunion pour s'assurer que tous les points sont discutés. Le propriétaire du produit répond à toutes les questions que notre équipe a posées. L' équipe n'a pas d'inconnues, cette équipe estime les choses correctement s'il y a un risque qu'elles soient traitées à l'avance. Nous avons vu notre cher a également fait le travail d'un maître de mêlée est d'obtenir le meilleur résultat possible et de qualité de l'équipe. Et ces compétences sont mises à profit au cours de la session de planification du sprint. Les gars, donc c'était une planification de sprint. Maintenant rappelez-vous que nous avons à nouveau un chapitre plus tard à parler est la planification du sprint, y compris l'estimation en détail. Pour l'instant, passons à la prochaine cérémonie et voyons quelles sont les données de la prochaine conférence. Merci. 15. Sprint Daily se tient: Bonjour à tous et bienvenue à la prochaine cérémonie, discrétion, le sprint stand quotidien. Alors résumons ce que nous avons fait jusqu'à maintenant. Nous avons fait le toilettage de l'arriéré, nous priorisons les histoires. On a fait la planification du sprint. Nous avons pris les histoires des utilisateurs, nous avons créé des tâches pour tout le monde afin que tout le monde sache sur quoi il doit travailler. Et nous avons commencé le courant est sprint. Donc maintenant, nous sommes dans le sprint actuel. Et tant que ce sprint est en cours d'exécution chaque matin, l'équipe fera une réunion rapide de 15 minutes qui s'appelle le stand-up pour parler des progrès et des barrages routiers. Alors parlons de cette cérémonie en détail d'abord, quand c'est fait. Donc, c'est fait tous les jours du sprint. Elle se fait habituellement le matin avant que tout le monde commence son travail. L' équipe a donc l'ordre du jour établi pour la journée. Maintenant, certaines équipes le font deux fois par jour au début et à la fin des heures de travail. C' est tout à fait correct. n'y a pas d'outil dur et rapide. Cela dépend de l'accord interne de l'équipe. Mais généralement une réunion au début de la matinée est idéale. Ensuite, Qui sont les participants ? Le propriétaire du produit, le Scrum Master, mais le plus important, l'ensemble de l'équipe de développement. Donc, la plupart des gens considèrent le stand-up comme un exercice de rapports. Nous sommes l'équipe donne son statut au propriétaire du produit, mais ce n'est pas tout à fait vrai. La réunion est pour les membres de l'équipe de se dire qu'il y a des statuts les uns aux autres. Donc, même si le propriétaire du produit ou le Scrum Master n'est pas présent à la réunion, l'équipe devrait quand même se réunir pour se tenir debout et discuter des choses. Parce que rappelez-vous, ils se donnent leur statut les uns aux autres, pas au propriétaire du produit ou à un maître de mêlée. Point suivant, quelle est la durée de son stand up ? Donc, il devrait être très court, pas plus de 15 minutes. Rappelez-vous, nous avons juste à discuter de trois points rapides qui sont écrits ci-dessous. Ce n'est pas un état de travail complet heure par heure. Et donc il ne devrait pas y avoir de conversations secondaires, pas de détails profonds. S' il y a une discussion supplémentaire qui sort de la standup est le statut. Les personnes ou l'équipe peuvent en discuter après que tout le monde ait parlé, mais cela ne devrait pas détourner la réunion stand-up. Nous voulons terminer la réunion stand-up dans idéalement 15 minutes. Et enfin, quel est le but de cette cérémonie ? Donc, d'abord et avant tout, répondre à trois questions. Qu' est-ce que j'ai fait hier ? Qu' est-ce que je vais faire aujourd'hui ? J' ai un bloqueur ? C' est donc le format d'or des standups partout dans Scrum. Et chaque membre de l'équipe devrait s'en tenir à répondre à ces trois questions. Ensuite, nous communiquons les progrès et soulèverons des obstacles. L' idée de base du stand est donc de partager les progrès réalisés par l'équipe tous les jours. Nous savons donc que nous avançons dans la bonne direction au bon rythme. Et pour soulever tout obstacle ou l'équipe de données bloqueur a que nous sachions ce qui retient l'équipe et qui aidera à résoudre ce bloqueur, le maître de mêlée, ou le propriétaire du produit. Dernier point, l'opportunité de collaboration peut se présenter en fonction des statuts. Alors entrons. développeur a dit que je suis blog parce que je ne peux pas obtenir le code source sur ma machine locale ou développeur être rapports dans la norme que je suis coincé parce que c'est une nouvelle chose pour moi et je n'ai pas travaillé dessus récemment. Il y a donc une opportunité de collaboration ici. Un autre développeur dans l'équipe peut dire que, ok, je sais chose Papa, je vais vous aider à vous rappeler une mêlée parle de collaboration dans leur équipe et est standups est un excellent moyen de promouvoir cette collaboration. Juste un conseil. Ne commencez pas à parler des beaux détails dans le stand lui-même. Juste dit sans soucis, je peux vous aider à ce sujet. Et puis les deux individus peuvent se synchroniser dessus après que tout le monde ait fini avec le stand-up. C' est donc une excellente occasion de faire rapport sur les progrès réalisés, signaler les bloqueurs et d'identifier les possibilités de collaboration entre l'équipe. Parce que rappelez-vous que l'achèvement du sprint est la responsabilité de l'équipe. Compléter toute la richesse qu'ils se sont engagés est la responsabilité de l'équipe. L' équipe Soda donne un statut les uns aux autres qui racontent leurs progrès. Ils disent à leur bloqueur qu'ils s'entraident. D' accord. Donc maintenant, nous savons ce qu'est la cérémonie de stand-up est. Souvenez-vous de trois questions. Qu' est-ce que j'ai fait hier ? Qu' est-ce que je vais faire aujourd'hui ? Et j'ai un bloqueur ? D' accord, continuons notre élan d'apprentissage. Et parlons de la prochaine cérémonie dans la prochaine conférence. Merci. 16. Revue ou démonstration: Bonjour à tous et bienvenue à la quatrième discussion de cérémonie, qui est la revue du sprint. Donc, jusqu'à présent, nous avons fait le toilettage de l'arriéré et nous avons priorisé nos besoins. Nous avons fait la planification du sprint et estimé et tâches ces exigences. Nous avons commencé le Sprint et chaque jour avec des données plus rapides stand-up pour discuter des progrès. Maintenant, nous sommes à un point où ils sprint a terminé et nous allons faire notre premier post est l'activité imprimée, qui est appelé un Sprint Review, ou plus communément la démo. Mais avant de commencer sur les détails, réfléchissons à la raison pour laquelle nous avons besoin de la cérémonie. Nous avons déjà pris les exigences, les parties prenantes savent sur quoi l'équipe a travaillé. Alors pourquoi le montrer à tout le monde maintenant ? La réponse est une rétroaction précoce. Rappelez-vous, HIS Scrum est le stress sur les retours précoces et continus. Nous voulons donc obtenir cette rétroaction et nous voulons améliorer le produit en fonction de la dette. Et nous voulons aussi recevoir ces commentaires dès le plus tôt possible. C' est pourquoi nous faisons cette revue immédiatement après la fin du sprint. Ça a du sens, non ? Voyons donc les beaux détails maintenant. Tout d'abord, quand la révision du sprint ou la démo est-elle faite ? Donc, évidemment, à la fin du sprint, nous ne voulons pas attendre dix jours après la fin du sprint. Nous ne voulons pas le faire dès que possible une fois le sprint terminé. Donc idéalement, les équipes le font ce jour-là, il y a des fins de sprint et ensuite ils vont dans la planification du sprint pour le prochain sprint afin que s'il y a des sorties provenant de ces sessions de démonstration et dans nu, des améliorations qui sont nécessaires, ils peuvent rapidement le prendre dans le prochain sprint aussi. Encore une fois, quand l'examen du sprint est-il fait à la fin du sprint ? Qui sont les participants ? Donc, il est la liste complète, mais le plus important, il a besoin de la participation du projet est les parties prenantes et les équipes de gestion des produits. Parce que rappelez-vous du dernier chapitre les parties prenantes sont celles pour lesquelles nous faisons tout le travail. Il est donc important de leur faire la démonstration des choses. Suivant. Quelle est la durée de cette réunion d'examen ? Donc 15 à 30 minutes, c'est bien, peut-être une heure. Encore une fois, il n'y a pas de règle difficile et rapide, mais c'est une démonstration rapide des nouvelles fonctionnalités développées. Nous allons leur montrer des flux importants seulement. Nous ne allons pas leur montrer chaque scénario de détail. Donc, 15 à 30 minutes ou max, une heure est une bonne limite de temps. Et enfin, quel est le but de cet examen ? Donc, le premier est de présenter le travail qui est fait par l'équipe dans le passé est sprint. C' est donc la première fois que les détenteurs de participations vont voir le travail pour lequel ils avaient donné les exigences de texte ou de texte. Donc, le propriétaire du produit était allé obtenir les exigences des parties prenantes ici, a traduit en critères d'acceptation réalisables. Quant à l'équipe, cette équipe a travaillé dessus, elle l'a livré. est donc la première fois que le détenteur de pieu va voir cette chose en action. Deuxième et la plus importante rétroaction des intervenants. Donc, comme je l'ai dit, chaque allée et Scrum dépend de retours précoces et fréquents. Donc ils sprint démo, nous allons nous assurer que cela arrive. Ensuite, célébrez l'accomplissement et le travail d'équipe. Donc, toute l'équipe a mis en un seul sprints vaut le travail pour créer ces fonctionnalités. Ils ont travaillé dur pendant les deux ou trois semaines, quelle que soit la durée du sprint dans l'organisation. Et quand cette fonctionnalité est montrée aux multiples personnes, aux gestionnaires, aux détenteurs de pieu, elle apporte un sentiment d'accomplissement à l'équipe de mêlée. Cela les incite à voir le résultat du travail acharné qui est rétrogradé à tout le monde. Dernier point, idéalement, seuls les travaux entièrement démontrables et testés devraient être montrés. Donc, c'est comme une clause de non-responsabilité. Nous ne devrions pas montrer des choses qui sont partiellement prêtes ou qui ont plusieurs défauts. Rappelez-vous que la sortie de chaque sprint est ce que nous appelons comme un produit potentiellement expédiable. Nous ne devrions donc présenter que des choses qui sont entièrement prêtes et testées. Et qui fait cet appel ? Qui fait l'appel sur la qualité du produit, sur la performance du produit, le propriétaire du produit. Super. Donc, maintenant que nous avons terminé le Sprint et montré notre travail aux parties prenantes, il reste encore un ensemble d'argent qui reste. Nous n'avons pas encore fini. Nous avons encore deux cérémonies à gauche. Parlons donc de la prochaine dans la prochaine conférence. Merci. 17. Rétrospective: Bonjour à tous et bienvenue à la prochaine discussion de cérémonie ils sprint rétrospective ou aussi connu comme le rétro et court. Alors, quelle est cette rétrospective et pourquoi le faisons-nous ? On a déjà pris un papier journal. Nous nous sommes engagés à tout le travail que nous avions accompli. Nous avons rétrogradé au détenteur du pieu du produit. Alors, quel est le besoin de faire cela ? Encore une cérémonie Maintenant, voyons. Donc, la réponse est que la miette contient des activités répétitives. On le sait bien ? Nous faisons le toilettage, nous faisons la planification, nous terminons le sprint, puis nous commençons par un autre sprint, non ? Mais entre tout cela, nous devons comprendre que tout s'est bien passé et s'il y a des possibilités d'amélioration, il est très important de faire cette analyse parce que c'est ainsi que nous allons améliorer les autres choses. Ce sera juste la même réputation des choses avec les mêmes problèmes qui se répètent encore et encore. C' est pourquoi la rétrospective est très, très importante. Malheureusement, de nombreuses équipes ne le font pas. Ils ne s'en soucient pas. Mais il est très important de prendre ce temps pour faire rétro après chaque sprint. Donc, quand c'est fait, c'est évidemment fait après la fin du sprint. Encore une fois, nous ne voulons pas attendre trop longtemps après la fin du sprint parce que nous voulons des commentaires sur le dernier sprint et que les Jours passent, les gens l'oublieront. Donc, l'idée est de le faire dès que le sprint est terminé, peut-être le même jour ou le lendemain après la démo, etcetera. Pour que le sprint soit frais dans la mémoire des gens et qu'ils puissent donner des commentaires corrects. Ensuite, qui tente ? Donc le propriétaire du produit, le maître de mêlée, l'équipe de développement, toute l'équipe devrait y assister. Nous ne voulons aucune personne extérieure. Nous ne voulons pas des gestionnaires, nous ne voulons pas des actionnaires. Non, c'est l'analyse de l'équipe. Donc l'équipe devrait tout faire. L' équipe devrait être présente et ils devraient honnêtement le faire en eux-mêmes. Ensuite, quelle est la durée ? Donc, cette durée est de 30 à 60 minutes. Encore une fois, il n'y a pas de règle fixe. L' idée est de discuter des choses et de s' assurer que tout le monde ait suffisamment de temps pour parler. Enfin, le but de premier et le plus important, recueillir des commentaires pour améliorer le processus et la culture. Rappelez-vous, nous devons faire les mêmes choses, itérer sur les mêmes choses encore et encore dans Scrum. Alors ils sprints, vont continuer. Nous ferons est d'imprimer un à cent, deux cents, mais nous devons apprendre quelque chose de chaque sprint. Nous devons savoir comment améliorer les choses avec chaque Sprint. Et papa est l'objectif de faire rétrospective pour découvrir les problèmes avec le sprint, pour savoir quelles étaient les bonnes choses et comment nous pouvons améliorer davantage. Et c'est pour ça qu'on parle de deux choses. D' abord, qu'est-ce qui s'est bien passé ? Et numéro deux, qu'est-ce qui aurait pu être mieux ? Donc, quoi que ce soit de la juste terminé est imprimer entrer les choses de l'équipe n'était pas bon comme étape et devrait être fait à nouveau. Ou si quelque chose n'était pas bon et quelque chose que nous pouvons améliorer, nous ne devrions pas faire. On fait ressortir toutes ces choses ? Tout le monde en parle. C' est le but de l'examen rétrospectif et honnête de la dette sprint est passé. Point suivant, rappelez-vous l'idée est de ne pas mettre en évidence les défauts ou en faire un exercice de jeu de blâme. Comme je l'ai dit dans le dernier chapitre de Scrum, les victoires et les échecs sont la responsabilité de toute l'équipe. Donc, la rétrospective devrait être faite honnêtement. Il devrait être utilisé pour améliorer les choses. Et plus important encore, il ne devrait pas être enseigné d'un exercice de jeu de blâme. On l'est, on fait juste remarquer les mauvaises choses de tout le monde. C' est pour l'amélioration de l'impression, c'est pour l'amélioration de tout le monde. Alors gardons ça honnête. Ne blâmons pas tout le monde. Enfin, la pratique de la rétrospective régulière renforce l'aspect de l'amélioration continue. Nous devons donc tirer des leçons du passé, nous devons améliorer les choses. Et c'est le but de la rétrospective. Très bien, donc c'était à propos de gars rétrospectifs ou de rétro, s'il ne reste plus qu'une cérémonie. Alors parlons à la prochaine conférence. Merci. 18. Planification de libération: Bonjour tout le monde et bienvenue. Parlons du dernier sujet des cérémonies de Scrum connu sous le nom de planification de sortie. Donc, les gars, la planification de la libération est une cérémonie importante dans une mêlée, bien que vous verrez la plupart des cours ne parlent pas de celui-ci. Je l'ai inclus ici parce qu'il est important de comprendre ces détails. Nous devons savoir quand livrer l'incrément de produit à l'utilisateur final afin qu'il puisse l'utiliser. Et tout notre travail acharné vient à utiliser. Donc, la planification de la sortie des gars est tout au sujet de décider quels incréments d'usine nous voulons pousser à l'utilisateur final. Et quand voulons-nous le faire ? Rappelez-vous que le but de chaque sprint est de concevoir nouveaux instruments et que nous devons savoir quand libérer ces incréments à l'utilisateur final. Certaines organisations le publieront en production après chaque sprint. Certaines organisations le feront après deux. Sprint n'est pas une règle fixe à elle. Il est appelé cadence de libération, et cela dépend totalement de l'exigence commerciale ou de la feuille de route du produit, ou du coût ou de la valeur ajoutée au produit. Ce sont les multiples facteurs sur lesquels se fonderaient nos versions. Et nous parlerons de tous ces aspects lors de cette cérémonie de planification de la publication. Donc, tout d'abord, quand c'est fait, idéalement, nous devrions faire la planification de la publication à intervalles fréquents. On devrait le faire comme après chaque sprint. Parce que rappelez-vous en fonction du moment et de ce que nous devons publier, nous pourrions devoir modifier notre arriéré. Nous devrons peut-être redéfinir les priorités des besoins, réaligner les ressources, etc. Il est donc préférable de le faire à intervalles fréquents. Point suivant, qui assiste à la réunion de planification de la publication ? Il devrait donc s'agir des parties prenantes, du propriétaire du produit et de toute l'équipe de mêlée. Parce que rappelez-vous que tout le monde de l'équipe de développement pourrait avoir un rôle dans la version. Les développeurs déploieront le code, les testeurs vérifieront le code afin que tout le monde ait du travail. Il est donc bon d'inclure toute l'équipe de mêlée ou un petit sous-ensemble de celui-ci. Ensuite, quelle est la durée ? Encore une fois, pas de règle dure et rapide. 30 minutes à 60 minutes est une durée suffisante. Et enfin, quels sont les objectifs de cette cérémonie ? Donc, d'abord, comme nous l'avons discuté, la planification des versions aide à déterminer quelles sont les fonctionnalités que nous pouvons fournir au client. Et rappelez-vous, les choses peuvent être guidés par une liste de fonctionnalités comme nous voulons faire une version une fois toutes ces fonctionnalités prêtes. Ou cela pourrait être dicté par une date comme nous voulons faire une sortie le mois prochain, le deuxième vendredi, donc quels que soient les critères nous discutons à propos de ces choses lors de la cérémonie de planification de sortie. Ensuite, nous examinons la feuille de route du produit et nous prenons la décision. Il est donc guidé par les exigences du produit, les intrants des parties prenantes, tous ces facteurs ensemble pour décider quand voulons-nous libérer le produit. Troisièmement, nous avons également discuté de l'équilibre entre les besoins des clients et la portée. Donc, le client peut vouloir quelque chose de nouveau chaque semaine, mais il y a de vraies préoccupations que les choses ne soient pas prêtes dans ce court laps de temps ou, d'ailleurs, il pourrait y avoir des préoccupations au sujet du budget aussi. Donc on parle de toutes ces choses. Nous essayons de trouver un équilibre entre le coût et la libération fréquemment pour l'utilisateur. Point suivant que la fréquence de sortie variera ou chaque organisation, comme je l'ai dit, certaines équipes sortiront chaque sprint. Parfois, certaines équipes peuvent se libérer après un sprint. n'y a pas de règle dure et rapide. Cela dépend de l'organisation, cela dépend de leurs besoins commerciaux. Dernier point, le plan de mise à jour n'est pas un plan statique et il peut changer en fonction du nouvel ajout au carnet de commandes. C' est pourquoi il est important de revoir les choses. Régulièrement, discutez des choses avec l'intervenant et faites-le, cette cérémonie de planification de la publication fréquemment. D' accord les gars, donc avec ça, nous arrivons à la fin de toutes nos cérémonies Scrum. Récapitons rapidement les choses dans l'ordre dans lequel elles se produisent. Nous faisons donc le toilettage du carnet avant le début du sprint. Ensuite, pour commencer le sprint, nous faisons la planification du sprint pour démarrer le sprint. Chaque jour du sprint, l' impression la plus sauvage est en cours d'exécution. Nous le ferons tous les jours debout. Enfin, lorsque le sprint se termine, nous ferons la démo et nous ferons la rétrospective. Nous devrions également inclure la planification de sortie quelque part ici, comme après la fin du sprint et à intervalles fréquents. Alors les gars, rappelez-vous que toutes ces cérémonies sont fondamentales pour la mêlée. Ils sont chronométrés et chacun d'eux a un but important, comme nous l'avons vu. Nous avons vu leur importance, nous avons vu leur fréquence. Et vous pouvez résumer ce tableau très rapidement pour résumer quand vous avez besoin de quand la cérémonie se produit et quel est leur but. D' accord les gars, donc on a vu les diverses cérémonies de miettes. Passons au chapitre suivant et discutons du prochain composant de Scrum, qui est les Artefacts de Scrum. Merci. 19. Épiques et introduction aux objets: Bonjour à tous et bienvenue au cinquième chapitre du cours. Jusqu' à présent dans notre voyage, nous avons vu ce qui est h i et ce qui est un Scrum. Nous avons vu les différentes personnes dans une équipe Scrum connue sous le nom de rôles Scrum. Et nous avons également vu les différentes réunions ou est cérémonies miettes qu'ils font pour développer un produit ou un accroissement. Dans l'ensemble, nous avons appris à connaître la partie qui et comment de l'histoire. Maintenant, dans ce chapitre, apprenons quelque chose appelé les Artefacts Scrum et comment cela aide l'équipe dans son voyage de Scrum. Alors commençons. Ce sont donc les sujets que nous aborderions dans ce chapitre. Mais avant cela, un avertissement très important pour éviter toute confusion. Rappelez-vous que les artefacts Scrum sont en fait juste le carnet de commandes de produits, l'arriéré de sprint et les incréments. Donc le numéro 456 sur notre liste. Cependant, pour les comprendre, nous devons aussi être apparaissant hors épopées et l'utilisateur est histoire, et c'est pourquoi nous avançons dans un ordre logique. Dans ce chapitre, nous allons d'abord parler d'Epics, puis nous allons parler d'histoires d'utilisateurs. Et parce que les histoires d'utilisateurs sont la source d'exigences pour toute notre équipe, nous verrons les meilleures pratiques pour écrire de bonnes histoires d'utilisateurs. Cela nous aidera à savoir comment les écrire correctement dans notre organisation ou garder un chèque si quelqu'un d'autre l'écrit, alors nous allons passer à parler de nos artefacts. Le carnet de commandes de produits est l'arriéré de sprint et l'incrémentation afin que les choses soient claires pour nous. Et enfin, nous allons apprendre quelque chose appelé la définition de fait, qui est un concept très intéressant et la documentation de l'accord de l'équipe Scrum. C' est pourquoi je l'ai inclus dans ce chapitre. Commençons donc notre voyage et commençons par le premier sujet. Parlons d'abord de ce que signifie Scrum Artefacts. Donc, si nous parlons en termes généraux, le mot artefact signifie les documents que nous créons. Et le but de ces documents est de nous fournir des informations clés et de nous assurer que tous les membres de l'équipe ont la même compréhension des choses. Maintenant, quand nous disons de nous fournir des informations clés, quelles sont les informations que ces artefacts peuvent fournir ? Donc, pour comprendre cela, oublions que c'est une miette pour un moment, et pensons à travailler sur la création ou la modification d'un produit en général. Alors, quelles sont les différentes informations dont nous aurions besoin si nous le faisions ? Tout d'abord, nous aurions besoin de savoir quelle est l'exigence. Parce que ce sont là les exigences sur lesquelles nous travaillerions. Ensuite, nous devons savoir comment la partie, comment nous aborderions cette exigence, quelle est la partie que nous ferions, etc. Et enfin, nous devons aussi connaître les progrès, combien est fait, combien reste, et cetera. Et les gars, c'est le même concept qui s'applique à une mêlée. De plus, les artefacts nous aident à fournir des informations clés comme le numéro un, le produit en cours de développement. Donc, ce ne sont rien d'autre que l'exigence que nous voulons et ils sont stockés sous la forme d'histoires épiques et utilisateurs. Qui les écrit ? Le propriétaire du produit les écrit en consultation avec les parties prenantes et avec l'aide d'un Scrum Master. Et où le propriétaire du produit conserve-t-il ces histoires d'utilisateurs ? Il les conserve dans le carnet de commandes de produits. Deuxièmement, les activités à venir. Nous avons donc déjà vu que lors de la planification du sprint, nous prenons les histoires des utilisateurs de l'arriéré des produits. Et en fonction de la capacité de l'équipe, nous finalisons un arriéré de sprint. C' est la liste des histoires d'utilisateurs sur lesquelles l'équipe travaillerait lors du prochain sprint. Et dernier point le travail terminé jusqu'à présent. Donc, cela se reflète dans notre arriéré de produits ou l'achèvement du carnet de commandes sprint également. Et rappelez-vous qu'il ya plusieurs rapports montrent également cette information. Et c'est pourquoi vous verrez plusieurs auteurs directement des rapports comme Burndown chart, etcetera aussi être un artefact. Mais ici, dans ce cours, nous allons rester avec la liste d'artefacts d'origine et nous allons traiter seulement le arriéré de produit est sprint backlog et les incréments dans ce chapitre. Pour d'autres méthodes de reporting comme Burndown ou diagramme de vitesse, nous avons un chapitre dédié plus tard couvrant entièrement les différents rapports de miettes. Et enfin, dernier point, quel est l'avantage d'avoir des artefacts ? Il fournit donc des informations clés à tout le monde et met tout le monde sur la même page en termes de compréhension. Par exemple, disons que si nous n'avons pas eu d'arriéré de produits, comment les détenteurs de participations seront-ils membres de l'équipe, sachent ce que nous avons à faire et combien de travail reste. Tout le monde aura une compréhension différente du travail attendu et cela causera de la confusion au sein de l'équipe. Ainsi, les artefacts aident à résoudre ce genre de problème. Très bien, comme je l'ai mentionné plus tôt, les artefacts clés dans le Scrum, notre arriéré de produits, un arriéré de sprint et des incréments, et nous allons les traverser dans ce chapitre. Mais pour bien comprendre ce que nous devons d'abord savoir sur les épopées et les histoires d'utilisateurs. Commençons par les premières épopées. Donc les gars achetés sont ces épopées ? Si nous parlons en termes généraux, épopées sont fondamentalement grandes exigences. Donc, dans ce chapitre, une grande partie de ce dont nous parlons concerne uniquement l'exigence. Et la plus grande partie documentée de ces exigences est les épopées. Comme le dit la définition à l'écran, une épopée est une exigence importante qui peut être divisée en petit morceau de travail appelé histoires d'utilisateurs. Donc c'est la définition de l'épopée. Disons, considérons un exemple. Disons que nous voulons créer un site e-commerce et que nous voulons créer son flux de paiement ou de placement de commande. C' est donc une très grande exigence avec beaucoup de travaux, nous devrons prendre soin de Checkout par carte de crédit, par PayPal, Apple Pay et bien plus encore. Donc la refonte de la caisse serait une épopée. Et pour faire les exigences suivantes de paiement par carte de crédit, paiement par PayPal, paiement par Apple Pay, etc. Nous allons créer des histoires d'utilisateurs, c'est l'exemple des épopées et des histoires d'utilisateurs, et c'est la relation entre eux. Nous le verrons plus clairement lorsque nous ferons le projet pratique plus tard, ne vous inquiétez pas. Mais pour l'instant, gardez à l'esprit que la grande exigence est épique et nous créons une petite exigence ou des histoires d'utilisateurs à partir de lui, aussi simple que cela. Lisons donc pour la première fois, épopées peuvent être considérées comme le niveau le plus élevé du travail de développement de produits. Le développement de produits implique donc des exigences. Et ces exigences proviennent d'Epic, qui sont divisées en histoires d'utilisateurs. épopées constituent donc le niveau supérieur ou supérieur des exigences en matière de développement de produits. Deuxièmement, les épopées peuvent étendre plusieurs équipes, plusieurs projets et un tableau Scrum. Donc, cela semble logique Dans notre exemple, épique de la refonte de Checkout. L' un est l'équipe Scrum s'occupera de vérifier sur le site Web. Une autre équipe s'occupera du traitement des commandes backend. 13 gérera l'envoi de courriels lorsque la commande est passée, etc. Donc les épopées sont assez grandes, ils peuvent inclure plusieurs équipes et il y a des planches Scrum. Ensuite, les épopées sont souvent livrées sur plusieurs sprints. Donc évidemment parce que les épopées sont si grandes qu'on ne peut pas les faire en un seul sprint. Il est plusieurs sprint hors travail. Il est divisé en plusieurs histoires d'utilisateurs et pour plusieurs équipes Scrum. Et dernier point, les épopées ont évolué au fil des sprints, obtenant plus d'informations. Alors que nous travaillons sur des sujets, que nous allons travailler sur notre épopée de refonte de la caisse, nous allons apprendre plus de choses. Nous obtiendrons de nouvelles exigences auxquelles nous n'avons pas pensé plus tôt. Nous devrons donc créer de nouvelles histoires d'utilisateurs pour répondre à ces exigences. Alors que nous progressons, que nous avançons dans notre sprint, nous aurons de nouvelles histoires d'utilisateurs liées à ces épopées. D' accord les gars, donc Dat était tout sur les épopées, mais vous n'avez pas besoin de vous souvenir de toutes ces choses. Souvenez-vous juste de deux aspects clés. Numéro un et épique est un gros travail. Et numéro deux, il est décomposé en plus petit utilisateur est des histoires qui impliquent généralement plusieurs équipes et un sprint. Papa a dit que c'est épique. Super. Maintenant que nous savons ce qu'est une épopée, parlons de sa manipulation sous la forme de petits morceaux appelés histoires d'utilisateurs. Parlons de ces histoires d'utilisateurs dans la prochaine conférence. Merci. 20. Histoires d'utilisateurs: Bonjour à tous, et bienvenue sur le sujet des histoires d'utilisateurs. Maintenant, cela va être une conférence très importante parce que chaque fois que vous travaillez dans le Scrum, vous allez traiter la plupart du temps avec des histoires d'utilisateurs. Ces histoires d'utilisateurs seront la source de toutes les exigences et vous y référencerez que vous citiez quelque chose ou que vous testiez quelque chose ou discutiez avec les parties prenantes. C' est pourquoi nous allons parler en détail histoires des utilisateurs dans cette conférence et la prochaine. Alors commençons. Ok, c'est tout d'abord des histoires d'utilisateurs d'eau. Nous avons déjà vu dans la dernière conférence que les gros morceaux d'exigences sont appelés comme des épopées. Et à partir de ces épopées, nous créons une petite exigence appelée histoires d'utilisateurs. Nous prenons ces histoires d'utilisateurs dans un sprint et nous y travaillons. Donc, les histoires d'utilisateurs sont fondamentalement la plus petite unité d' exigence dans Scrum qui peut être livré en un seul sprint. Donc, lorsque l'équipe se rassemble pour la planification du sprint, ils prendront comme cinq, sept ou dix utilisateurs est histoire basée sur leur capacité et ils se lanceront pour terminer toutes ces histoires utilisateur dans un est sprint. C' est donc ce qu'est un utilisateur. L' histoire est la plus petite unité de travail que l'équipe peut livrer en un sprint. Voyons d'abord les puces, les histoires d'utilisateurs sont une explication générale des exigences exprimées dans les termes de l'utilisateur final. Alors, qu'est-ce qu'il y a dans les exigences relatives aux histoires d'utilisateurs et comment écrire ces exigences ? Très important. Nous notons toujours le MNT dans la perspective d'un utilisateur final. Si nous parlons de la caisse avec carte de crédit sur notre site e-commerce histoire d'utilisateur, nous allons l'écrire comme un utilisateur, je veux passer une commande avec une carte de crédit et ensuite nous donnerons les détails supplémentaires. Nous ne l'écrirons jamais comme une personne technique ou un homme d'affaires sait, notre histoire d'utilisateur est toujours écrite du point de vue d'un utilisateur final. Point suivant, comment écrire les aspects détaillés des exigences dans l'histoire de l'utilisateur ? On l'écrirait comme quelque chose appelé les critères d'acceptation. Les critères d'acceptation sont donc un ensemble d' exigences prédéfinies qui expliqueront ce qu'il faut faire. Donc, par exemple, pour notre carte de crédit est histoire, nous allons commencer par, en tant qu'utilisateur, je veux passer une commande avec une carte de crédit. Et puis nous allons mentionner les critères d'acceptation est comme numéro un, l'utilisateur a la possibilité d'entrer une carte de crédit. Numéro à l'utilisateur a la possibilité d'entrer une carte de débit. Numéro trois, l'utilisateur a la possibilité de voir leur liste de sécurité et comme ça. C' est donc la structure d'une histoire d'utilisateur. Et ne vous inquiétez pas, nous verrons un exemple plus tard dans la conférence. Mais juste pour récapituler rapidement, la structure va comme un utilisateur, je veux ainsi et ainsi, et puis nous avons que les critères d'acceptation de détail a troisième, qui écrivent l'utilisateur est histoire, donc nous l'avons déjà vu. C' est le propriétaire du produit. Le propriétaire du produit est responsable de la rédaction des histoires d'utilisateurs. Il ou elle peut prendre l'aide de l'équipe si nécessaire. Il ou elle peut prendre l'aide de la Scrum Master deux facilité, mais la responsabilité ultime de créer des histoires d'utilisateurs, les modifier, de les mettre à jour, de les hiérarchiser, et cetera. Tout est avec le propriétaire du produit. Comme nous l'avons vu lors de la dernière conférence, c'est l'une de leurs responsabilités principales. Et dernier point, les histoires d'utilisateurs sont une composante de l'estimation. Nous allons donc parler de l'estimation en détail dans le chapitre suivant. Mais pour l'instant, rappelez-vous que pour l'histoire de chaque utilisateur, nous avons estimé en utilisant quelque chose appelé points d'histoire. Donc, ces histoires d'utilisateurs servent également de moyen d'estimation. Alors allons de l'avant et jetons un coup d'oeil à la façon dont nous sommes réellement l'histoire de l'utilisateur ressemble. Donc les gars ici est à quoi ressemble une histoire d'utilisateur. Et c'est un problème. Probablement une histoire utilisateur créée pour imprimer quelque chose à partir du tableau de bord des problèmes comme G2 ou quelque chose. Mais ne vous inquiétez pas, ignorez simplement le contexte. Concentrez-vous sur le format. Ainsi, comme vous pouvez le voir, l'histoire de l'utilisateur commence par le mot en tant qu'utilisateur. Donc, comme je l'ai dit, nous écrivons toujours les histoires des utilisateurs du point de vue de l'utilisateur final. Nous n'en parlerons jamais du point de vue des affaires. Nous n'en parlerons jamais d'un point de vue technique. Il sera toujours retourné du point de vue d'un utilisateur final. Et c'est pourquoi l'histoire de l'utilisateur commence toujours par la ligne en tant qu'utilisateur. Et puis vous pouvez voir que nous avons les exigences détaillées, c'est-à-dire les critères d'acceptation. Et les critères d'acceptation ont été très bien écrits dans les puces. Donc, les données, il est clair, tout a été expliqué en détail. Alors maintenant, vous savez que lorsque l'équipe se réunira pour le toilettage en retard ou la planification du sprint, elle passera par cette histoire. Ils liront les critères d'acceptation s'ils ont des questions qu'ils peuvent poser au propriétaire du produit, il ou elle y répondra et ainsi de suite. Mais nous devons donner chaque détail au plus petit niveau possible dans ces critères d'acceptation. Rappelez-vous, nous pouvons ajouter des détails techniques aussi comme s'il ya des informations techniques dette aidera l'équipe de développement. Nous pouvons l'ajouter en bas après chaque détail d'utilisateur professionnel. Et si nous, si nécessaire, nous pouvons attacher une belle maquette aussi. Donc, la maquette aide à la clarté visuelle, surtout si nous faisons un changement de conception ou si nous faisons un changement intensif de l'interface utilisateur, alors il est toujours utile d'attacher une maquette à l'histoire de l'utilisateur. Donc, c'est comme ça qu'un utilisateur est. L' histoire ressemble à Guys. Et maintenant que nous savons ce qu'est un utilisateur, histoire est des watts, ce sont des formats, ce qui est important. Allons de l'avant et apprenons sur les meilleures pratiques pour créer une histoire utilisateur lors de la prochaine conférence. Merci. 21. Comment écrire de superbes histoires d'utilisateurs: Bonjour, tout le monde. Parlons des meilleures pratiques pour rédiger une excellente histoire d'utilisateur. Comme je l'ai indiqué précédemment, rédaction d'une histoire utilisateur est principalement le travail du propriétaire du produit. Donc, si vous voulez travailler en tant que propriétaire de produit, vous devez le savoir, ou si vous travaillez en tant qu' analyste commercial, développeur ou testeur, vous devez toujours le savoir afin de vous assurer que les user stories sont rédigées correctement dans votre organisation. Alors voyons voir. Le premier point, c' garder l'utilisateur final à l'esprit et d'écrire de son point de vue. est très important, c'est que Crum vise à fournir un produit de bonne qualité à l'utilisateur final Pensons en tant qu'utilisateur final lorsque nous créons les exigences. Nous ne voulons pas penser comme un propriétaire de produit, un développeur, un testeur ou non. Que souhaite l'utilisateur final ? Écrivons-le de cette façon. Ensuite, soyez bref et simple. N'écrivez pas trop de détails pour créer de la confusion. Si cela devient trop long ou trop long, cela signifie probablement que l'histoire devient trop compliquée, et nous devrions la diviser en deux histoires distinctes. Soyez bref, soyez simple. Point suivant, ajoutez des critères d'acceptation clairs. Comme nous l'avons vu, ce sont les critères d'acceptation qui constituent la user story. Nous avons besoin de critères d'acceptation clairs, et c'est pourquoi, dans la diapositive suivante, nous verrons comment rédiger de bons critères d'acceptation. Quatrième point, créez en collaboration. Discutez avec les parties prenantes, discutez avec l'équipe de développement, surtout s'il s'agit d'une histoire technique, prenez leurs contributions et créez leur histoire. N'oubliez pas que la création des histoires est le travail du propriétaire du produit, mais qu'il doit toujours le faire en collaboration avec l'équipe. Une personne peut passer à côté de certaines choses. Une seule personne ne peut pas connaître toutes les exigences. La collaboration est une excellente alternative. Point suivant, réfléchissez, affinez ou divisez. Lorsque nous nous occupons de la gestion de l' arriéré ou de la planification des sprints, discutez de l'histoire, parlez-en, posez toutes les questions que vous avez Demandez au responsable du produit de répondre à vos questions, de parler des inconnues, des risques Si nécessaire, modifiez l'histoire, ou si elle devient trop volumineuse, divisez-la en deux ou plusieurs histoires supplémentaires. Enfin, ajoutez des visualisations pour plus de clarté. Personnellement, je suggère que sur ce point, une maquette permet de clarifier les choses plus facilement et elle vaut mieux que 100 mots. Essayez donc toujours d'inclure une maquette dans les user stories, surtout s'il s'agit d'une modification de l' interface utilisateur ou du design. Il existe de nombreux outils sur le marché, tels que Vision , qui permettent de créer de superbes maquettes et de les partager avec l'équipe. Utilisons-les donc. C'est bon. Maintenant que nous savons comment écrire une bonne user story. Parlons de la façon d'y écrire bons critères d'acceptation. Meilleures pratiques pour rédiger de bons critères d'acceptation. Et la première consiste en fait à s'assurer que critères d'acceptation sont présents, sans intention de sarcasme Mais, les gars, vous verrez passer beaucoup de temps à ce que les équipes se contentent de créer une histoire utilisateur avec uniquement une description, et il n'y aura aucun critère d'acceptation. Cela n'est pas correct. Un article doit toujours contenir des critères d'acceptation, car il s'agit de l'exigence détaillée. Si je crée simplement une histoire vide, par exemple disant « passer commande par carte de crédit », il n'y a pas de compréhension commune la façon dont cela devrait fonctionner. Chacun aura sa propre interprétation des choses, ce qui créera évidemment des confusions et des problèmes Écrivez toujours les critères d'acceptation dans les stories, assurez-vous que nous ne créons pas user stories sans y mettre les critères d'acceptation. Deuxièmement, documentez avant le développement. Rédigez d' abord les histoires d'utilisateurs et les critères d'acceptation , puis développez les éléments dans le cadre des détails, ne développez pas d'abord les éléments puis rédigez comme cela fonctionne, comme le savent les critères d'acceptation. Cela pourrait signifier que nous empruntons la mauvaise voie pour aller de l'avant. Point suivant, rendez-le réalisable, mesurable et testable. Lorsque vous écrivez quelque chose dans les critères d'acceptation, assurez-vous que c'est faisable, assurez-vous qu'il est testable N'écrivez pas des choses qui ne seraient pas pratiques à faire. Quatrième point, discutez avec l'équipe, établissez un consensus. Demandez donc l'avis des parties prenantes, assurez-vous que vous êtes tous d'accord sur la même chose, demandez l'avis de l' équipe, discutez-en avec eux, notez-le, posez des questions, répondez-y. N'oubliez pas que c'est l'équipe de développement qui sera rédiger ces histoires et de définir les critères d'acceptation. La collaboration et le consensus avec eux sont donc essentiels. Point suivant, concentrez-vous sur le résultat final, et non sur le comment. Encore une fois, très important, nous devons rédiger les critères d' acceptation en tant qu'utilisateur final, et l'aspect technique ne doit pas éclipser cette partie Si des détails techniques sont nécessaires, nous pouvons les rédiger séparément sous forme note technique ou de note pour l'équipe de développement. Mais la majorité des critères d' acceptation devraient porter sur ce qui est nécessaire, non sur la manière dont nous devons le faire. Enfin, n'oubliez pas d'inclure également les aspects non fonctionnels, sorte que la convivialité et les performances sont des aspects tout aussi importants. Lorsque nous parlons de paiement sur notre site Web de commerce électronique, s'il y a un flux de dix pages pour passer une commande ou s'il faut 5 minutes pour ajouter une carte de crédit, personne ne le fera. Ne parlez pas uniquement des aspects fonctionnels. Pensez également aux aspects non fonctionnels et à la meilleure façon de les mettre en œuvre. C'est bon, les gars. Tout tournait autour des user stories et des critères d'acceptation. N'oubliez pas les témoignages d'utilisateurs plus détaillés et bien documentés que nous aurons avec des critères d'acceptation clairs. La meilleure équipe serait alignée sur une compréhension commune, et il y aura moins d'échecs. Que vous écriviez des user stories dans le cadre de votre travail ou que vous les utilisiez dans votre travail. Assurez-vous toujours qu' ils sont rédigés clairement et joliment conformément aux points discutés. Génial. Maintenant que nous avons parlé d' épopées et que nous avons parlé d'histoires d'utilisateurs Maintenant, revenons en arrière et examinons le sujet même de ce chapitre, les artefacts. Commençons par le premier de la prochaine conférence. 22. Artifact 1 - Backlog de produit: Bonjour à tous et bienvenue au premier artefact, le carnet de commandes de produits. Donc les gars du chapitre précédent, nous avons une idée de ce qu'est le carnet de commandes de produits. Tout simplement, il s'agit d'une liste de produits pétroliers qui doivent être réalisés dans un produit. Donc, si nous voulons faire de nouvelles fonctionnalités ou modifier certaines fonctionnalités existantes, ou nous voulons corriger certains bugs. Ce sont les éléments qui composent le carnet de commandes de produits. Point suivant, le carnet de commandes produit est toujours essayé d'être conservé dans un ordre de priorité. Par conséquent, le propriétaire du produit devrait réexaminer fréquemment l'arriéré parce qu'il est responsable de l'arriéré du produit et qu'il devrait le conserver d'une manière hiérarchisée. Sinon, nous ne saurions pas ce qui est urgent. Nous ne saurions pas ce qui doit être fait en premier et il peut être perdu dans la liste à mesure que l'arriéré de produits augmente. Alors passons par la balle. La première chose à l'écran, comme vous le voyez, est la définition de l'arriéré de produits, qui, comme nous l'avons discuté, est numéro un, une liste de tous les produits livrables qui doivent être effectués. Et numéro deux, il devrait être dans l'ordre de priorité. Ce sont les deux principaux points à retenir de cette conférence. Comme le dit la première puce, carnet de commandes produit comprend de nouvelles fonctionnalités, modifications, des corrections de bogues en France, des modifications, etc. Voilà donc quelques-unes des choses que nous aurons dans le carnet de commandes de produits comme nous l'avons discuté. Et en fait, sur la base de notre expérience passée, nous pouvons affiner cette liste plus loin et simplement dire à l'arriéré de produits contiendrait idéalement numéro un, histoires d'utilisateurs et numéro deux dollars. Deuxièmement, le propriétaire du produit organise ces exigences ou histoires d'utilisateurs selon la priorité. Donc très important, comme nous en discutons, il est nécessaire de garder l'arriéré de produits dans l'ordre de priorité. Et qui est la personne qui s'occupe d'ajouter de nouvelles choses au carnet de commandes de produits ou de maintenir son ordre prioritaire, le propriétaire du produit. Nous avons donc vu dans l'une des conférences précédentes que la création de l'arriéré et le maintien de l'arriéré sont l'une des principales responsabilités du propriétaire du produit. Point suivant, le carnet de commandes produit peut continuer de croître et il agit comme le détenteur de tous les changements futurs. Donc, dans toute méthodologie de développement de produits, il y aurait toujours de nouveaux ajouts aux exigences. Par conséquent, le carnet de commandes de produits continuerait changer avec de nouveaux éléments ajoutés, supprimés ou ré-priorisés. Et dernier point, chaque sprint l'équipe prend histoires de l' utilisateur de l'arriéré produit à faire dans le cycle actuel. Donc, tout changement qui doit être apporté dans le produit, il est d'abord ajouté au carnet de commandes du produit par le propriétaire du produit. Il est discuté avec toute l'équipe. Il est parasité avec toute l'équipe, l'estimation dessus, puis il est pris dans l'une de ces empreintes pour travailler sur. Donc les gars, c'est tout, c'est tout à propos de l'arriéré des produits. Encore une fois, en résumé, vous pouvez considérer l'arriéré de produits comme une liste de souhaits hiérarchisée, une liste tâches nouées, car nous pourrions changer de pistes et ne pas vouloir tout faire là-dedans. Nous l'appelons donc comme une liste de souhaits hiérarchisée qui est gérée par le propriétaire du produit. Et il sert de grand seau d'exigences à partir duquel nous tirons les petites exigences et les développons en sprint. Donc, les gars, c'était notre premier artefact. Vérifions la prochaine dans la prochaine conférence. Merci. 23. Artifact 2 - Backlog en Sprint: Bonjour tout le monde. Parlons du prochain artefact que je sprint arriéré. Donc les gars, à ce stade, nous avons un arriéré de produits qui contient les histoires d'utilisateurs pour chaque nouvelle exigence que l'équipe a à faire. Maintenant, l'équipe va soigner ces histoires dans le toilettage en retard. Ensuite, ils se réuniront pour une session de planification de sprint où ils prendront les cinq ou dix premières histoires d'utilisateurs à travailler dans le sprint à venir en fonction de leur capacité. Et ce groupe de cinq ou dix histoires d'utilisateurs qui ont pris est notre prochain artefact connu sous le nom de carnet de sprint. Ainsi, comme vous pouvez le voir, la définition dit également qu'un carnet de commandes de sprint est un sous-ensemble du carnet de commandes de produits identifié par l'équipe à compléter pendant le sprint. Nous avons donc déjà vu l'arriéré de produits. C' est une grande liste d'exigences que l'équipe prend un petit ensemble d'exigences à partir de là et compose l'arriéré de sprint. Et combien serait l'arriéré de données sprint ? Ce serait beaucoup de travail que l'équipe peut accomplir lors du prochain sprint, aussi simple que cela. Alors allons de l'avant et lisons les balles. Donc, d'abord dans une planification de sprint que l'équipe sélectionne les histoires d'utilisateurs selon la priorité définie par le propriétaire du produit et la capacité de l'équipe. Donc, nous avons déjà vu à ce sujet lorsque l'équipe se réunissait pour une planification de sprint, nous allons passer en revue le carnet de produits, qui est dans un ordre prioritaire. Rappelez-vous, et l'équipe ramassait les cinq ou dix premières histoires en fonction de leur capacité. Ils vont faire ces cinq ou dix histoires dans le sprint actuel et les données sont ce que l'arriéré de sprint est. Point suivant pour l'histoire de chaque utilisateur dans le carnet de commandes de sprint, cette équipe identifie la tâche nécessaire pour l'accomplir. C' est donc l'autre aspect de la planification du sprint que nous avons discuté dans le dernier chapitre. Il suffit de prendre les histoires et de créer un storyboard est le retard de sprint n'est pas suffisant. Nous devons trouver qui va travailler dessus. Ce processus est appelé comme tâche. Cela signifie essentiellement attribuer des tâches à chaque membre de l'équipe. Jusqu' à présent, l'un est l'histoire. Nous allons assigner des tâches de développement à un gars, tester des tâches à un gars, maquette de conception d'UAT, etc. Et les membres de l'équipe se chargeront de cette tâche et y travailleront. Donc, cela aide à clarifier qui va travailler sur quoi, combien de travail chaque gars a. Le propriétaire est-il occupé ? Ont-ils travaillé toutes ces choses ? Point suivant, un arriéré de sprint devrait idéalement rester inchangé pendant la durée d'un sprint. Donc, une fois que nous nous sommes engagés à faire comme des histoires de tennis dans le sprint, nous devrions idéalement ne pas apporter de modifications à cette liste. Et rappelez-vous que j'utilise le mot idéalement parce que si quelqu'un a la capacité disponible parce qu'il a terminé le travail, ou soyons plus réalistes. Et disons que si quelque chose d'urgent est apparu, alors nous devrons sûrement apporter de nouvelles choses à l'arriéré de sprint, non ? Mais à part cela, nous devrions toujours nous en tenir à finir ce que nous nous sommes engagés au cours de la planification. Notez également que dans le cas où nous tirons quelque chose de nouveau, cette équipe doit comprendre comment l'accommoder. Ils ne peuvent pas faire tout le travail déjà engagé plus ce nouveau travail, non ? Donc, ils pourraient avoir besoin de re-prioriser chose, ils pourraient avoir besoin de supprimer quelque chose, ils pourraient avoir besoin de prendre l'aide d'une autre équipe, etc Donc, idéalement, nous ne devrions pas apporter des changements à l'arriéré de sprint une fois qu'ils ont sprint a commencé, mais cela arrive très probablement. Et quand cela arrive, quand nous devons prendre quelque chose de nouveau, nous devons penser à tous ces facteurs. Nous pouvons aussi faire le nouveau travail entrepris. Et dernier point, les gars, si un élément n'est pas terminé, il peut être ajouté à Product Backlog et re-priorisé au début du prochain sprint. Donc, jusqu'à maintenant, nous avons parlé du chemin heureux, surtout où nous avons pris comme dix histoires d'utilisateurs dans un sprint. Nous les avons tous terminés et ensuite nous avons commencé avec le prochain sprint. Mais c'est maintenant comme ça que ça arrive toujours, parfois les choses ne se ferment pas et ils seront roulés au prochain sprint. Donc, à la fin du sprint, nous vérifions l'arriéré de sprint. Nous voyons ce que tout n'est pas fait et se faire rouler. Et nous pouvons soit continuer à travailler dessus dans le prochain sprint, soit nous pouvons le déplacer vers le carnet de commandes de produits et le reclasser en dessous d'autres choses. C' est donc un exercice que nous faisons à la fin de chaque sprint. Et avant qu'ils commencent le prochain sprint, nous devons savoir ce qu'il faut faire si l'une des choses dans le carnet de sprint n'a pas été fermée. Donc les gars, tout était à propos de notre deuxième artefact. Ils sprint l'arriéré. Rappelez-vous, nous allons une fois de plus entrer dans tous les aspects de la planification Sprint, y compris l'estimation et la façon dont nous faisons tous ces, prendre les histoires, penser kappa assis chose, et cetera dans le dernier chapitre quatre maintenant, nous avons vient de voir un niveau élevé de l'arriéré de produits, notre deuxième artefact. Alors passons à autre chose. Vérifions le prochain et le dernier artefact dans la prochaine conférence. Merci. 24. Artifact 3 - Incréments: Bonjour tout le monde. Parlons du dernier artefact, de l'incrément. Donc, les gars, nous avons beaucoup utilisé ce mot dans le cours. Alors voyons ça en détail. Qu' est-ce qu'un incrément et qu'est-ce que cela signifie ? Donc, en termes simples, et incrément est un ajout au produit. Dans notre discussion jusqu'à présent, nous avons vu que dans Scrum cette équipe crée un produit , puis chaque sprint ils y ajoutent de nouvelles fonctionnalités ou incréments. Chacun de ces incréments ajoute à la version précédente du produit, créant un produit meilleur, amélioré et de qualité. C' est donc la définition de l'incrément. Son l'amélioration du produit à partir du courant est sprint plus tous les sprints précédents. Voyons les autres détails. abord, à la fin d'un sprint, l'incrément de produit doit être dans un état utilisable et il doit répondre à la définition de fait de l'équipe. Alors rappelez-vous quel que soit l'accroissement que nous faisons dans le sprint, nous ne pouvons le considérer comme précieux que s'il est dans un état utilisable et s'il satisfait aux critères d'approbation des équipes connus sous le nom de définition de fait. Nous verrons cette définition de fait dans une conférence ultérieure. Mais pour l'instant, il suffit de considérer qu'il s'agit d'une liste de contrôle tous les critères que le produit point devrait satisfaire pour être considéré comme terminé. Deuxièmement, l'incrément doit être dans un état utilisable , que les côtés POD le libèrent trop ou non. Donc, cela semble assez similaire à la première, mais il y a une dette de trésorerie supplémentaire libère le produit. Rappelez-vous que l'un des critères de Scrum est que chaque sprint devrait aboutir à ce que nous appelons un produit potentiellement expédiable. Cela signifie que tout ce que nous faisons dans un sprint, il devrait être assez bon pour être distribué à l'utilisateur final. Maintenant, c'est une autre question de savoir si le propriétaire du produit veut le libérer ou non. Il voudra peut-être le relâcher après deux sprints. Il voudra peut-être le libérer après un mois de son appel. Mais néanmoins, chaque incrément doit être dans un état utilisable et il devrait résulter en un produit potentiellement expédiable. Point suivant avec chaque sprint, l'incrément de produit augmente vers la vision finale ou l'objectif. Donc assez clair, nous avons une feuille de route produit, notre vision de la façon dont nous voulons que le produit final soit. Et à chaque sprint, à chaque incrément, nous ajoutons petit à petit à petit à cette feuille de route, cet objectif final. Et dernier point, les gars, l'aspect central de Scrum est de fournir un accroissement fait. Donc, si quelqu'un nous a demandé, que faisons-nous dans un sprint, la réponse est que dans chaque sprint, nous créons un incrément au produit. Nous créons un beau, amélioré, incrément de haute qualité du produit. Et cet accroissement répond à la feuille de route productive. Cette augmentation correspond à la définition de « fait » de l'équipe. D' accord, papa nous amène à la fin des trois artefacts, le carnet de produits, le carnet de sprint et l'augmentation. Résumons les trois artefacts une fois de plus via cette image. Nous avons donc de multiples exigences qui peuvent venir des parties prenantes sous la forme de nouvelles fonctionnalités ou de corrections de défauts ou d'ajouts techniques, etc. Le propriétaire du produit prend ces exigences et crée un arriéré de produits, ce qui est comme une grande liste de souhaits des choses à faire. Nous prenons un petit sous-ensemble d'exigences de cet arriéré et nous créons le carnet de sprint, qui est le travail que l'équipe effectuera lors du sprint à venir. Et enfin, une fois le travail de sprint terminé, nous avons un incrément au produit, ce qui est comme de nouvelles améliorations d'édition via notre produit et il devrait être potentiellement expédiable. Donc ce type est sur votre écran est un résumé des trois artefacts que vous pouvez rapidement récapituler pour votre mémoire. D' accord, donc nous avons vu les trois artefacts, mais il y a un terme que nous avons beaucoup entendu dans la dernière diapositive et c'est la définition de fait. Voyons donc aussi quelles données sont dans la prochaine conférence. Merci. 25. Définition de Done: Bonjour à tous et bienvenue au dernier sujet de ce chapitre. Parlons de quelque chose appelé comme la définition de fait. Alors imaginez que nous travaillons dans un sprint et que nous prenons une histoire d'utilisateur pour concevoir la caisse avec carte de crédit comme nous l'avons dit plus tôt. Donc, il y a comme sept critères d'acceptation dans l'histoire de l'utilisateur. Et à la fin du sprint, développeur vient et dit que j'ai fait tous ces sept changements. Tout est bon. On peut considérer que l'histoire a fait. Maintenant, devrions-nous juste passer par sa compréhension de w1 et clore leur histoire ? Non. À droite. Nous devrions plutôt avoir une liste de critères d'évaluation pour faire ce jugement. Parce que rappelez-vous, chaque est 2D dans le sprint devrait ajouter à l'incrément et entraîner un produit potentiellement expédiable. Donc, si nous n'avons pas un ensemble de règles, dette certifie que l'histoire de l'utilisateur a fait. Nous pourrions ajouter des choses incomplètes ou de mauvaise qualité au produit. Et c'est là que la définition de « fait » entre en scène. En tant qu'équipe Scrum, nous devrions créer une liste de contrôle. Nous devrions créer une liste de critères auxquels cette équipe peut faire référence. Et sur la base de cela, ils peuvent dire que l'utilisateur est des histoires faites ou non. Et papa checklist est connu comme la définition de fait. Il s'agit d'une liste de critères que cette équipe est censée remplir avec succès avant déclarer l'histoire de l'utilisateur à faire et avant de considérer que le produit est suffisant pour être libéré. Et quelles sont les choses qui sont généralement présentes dans la définition de fait, nous pouvons avoir des critères comme la conception technique devrait être revue, code devrait être testé à l'unité. Les tests fonctionnels doivent être complets sans défauts critiques ou bloqueurs. Les tests d'acceptation par l'utilisateur doivent être effectués, etcetera. Ce ne sont donc que quelques-uns des critères. Je jette juste quelques exemples. En réalité, l'équipe a discuté ensemble et ils ont créé une liste exhaustive, et ils ont suivi cette liste, chaque sprint pour s'assurer qu'ils ajoutent un accroissement précieux au produit. Laissons d'abord la balle. Des, définition de fait aide à vérifier que l'incrément de produit est terminé et prêt pour la livraison. Donc, quand quelqu'un dit ou des histoires d'utilisateurs fait, nous recoupons tout dans la définition de fait est terminé ou non. Si oui, l'incrément de l'usine doit être considéré comme terminé et prêt à être remis à l'utilisateur final. Si ce n'est pas le cas, corrigeons les choses qui échouent, puis revérifions. La deuxième définition de fait aide à minimiser les risques, comprendre les progrès et le travail savoureux, l'effort ou les coûts. Donc, si nous ne confirmons pas que notre produit répond à la définition de fait, il pourrait être incomplet, il pourrait avoir des défauts, il pourrait, il pourrait, il pourrait ne pas répondre aux exigences de l'utilisateur, etc. Et cela augmentera le coût des risques, l' effort, tous ces facteurs. Donc, la définition de del w1 aide à minimiser toutes ces choses. Point suivant, la définition de fait varie d'une entreprise à l'autre et de l'équipe, mais elle devrait être convenue entièrement par l'équipe Scrum. n'y a donc pas de liste fixe d'éléments qui doivent être inclus dans la définition de fait. C' est quelque chose que toute l'équipe de mêlée se réunit et discute, y compris le propriétaire du produit et le Scrum Master. Ils discutent de tous les points qui discutent mode devrait être là, puis ils sont d'accord. Cela deviendra le guide des équipes et ils évalueront tous les changements futurs par rapport à cette définition de fait. Et enfin, comme vous pouvez le voir, certains des éléments de la dette peuvent être dans la définition de fait, comme je l'ai discuté plus tôt. Mais rappelez-vous, c'est une liste de base qui devrait être là à mon avis. Bien sûr, l'équipe est appelée, ils devraient avoir une discussion et ils devraient trouver leur propre liste. Vous pouvez l'imprimer, vous pouvez le coller dans la zone TMJ afin que tout le monde sache quels sont les critères de papa que l'équipe suivra avant de certifier tout comme terminé. D' accord les gars, donc Dat était tout au sujet de la définition de W1. Et avec cela, nous sommes arrivés à la fin de ce chapitre. Je suis très heureux de vous dire que nous avons maintenant couvert les trois principales catégories de Scrum, les rôles, les cérémonies et les artefacts. Bien sûr, nous continuerons notre parcours d'apprentissage. Mais à ce stade, nous avons appris beaucoup de choses liées à sa mêlée. Maintenant, dans le prochain chapitre, nous allons prendre un nouveau sujet est planification du sprint et l'estimation très important et en apprendre davantage à ce sujet. Alors je te verrai dans le prochain chapitre d'ici là. Merci. 26. La planification en sprint en détail et son importance: Bonjour à tous et bienvenue au sixième chapitre du cours. Nous allons consacrer ce chapitre à deux concepts importants : la planification et l'estimation du sprint. Nous avons déjà parlé de la planification du sprint dans le chapitre sur les cérémonies Scrum. Mais ici, nous allons étendre plus loin sur elle parce que, comme je l'ai dit plus tôt, aussi, une planification de sprint est la cérémonie la plus importante de Scrum et nombreuses décisions importantes et le travail de l'équipe entière pour les deux prochaines semaines, sprint dépendra de ça. De même, comme tout autre cadre de gestion de projet, le concept d'estimation est également très important mais délicat dans Scrum. C' est pourquoi j'ai regroupé ces deux sujets de planification et d'estimation du sprint dans un chapitre séparé afin que nous puissions couvrir tous les aspects dans tous les détails ici. Alors commençons. Voici l'ordre du jour de ce chapitre. Nous allons commencer par expliquer pourquoi la planification du sprint est importante, puis passer à l'estimation. Nous allons parler des points de l'histoire, qui est la principale méthode d'estimation dans AGI et le poker de planification, qui est couramment utilisé pour cette estimation. Et enfin, nous allons parler de la capacité et de la vitesse, qui sont deux aspects à considérer lorsque nous faisons est planification et l'estimation du sprint. Alors commençons. Donc la première chose dont on va parler, c'est pourquoi la planification du sprint est si importante ? Comme nous l'avons vu dans le chapitre précédent, est la réunion de planification du sprint où toute l'équipe de mêlée, y compris le propriétaire du produit et le maître Scrum, se réunir avant qu'ils commencent un sprint et ils prennent l'utilisateur est les histoires de l'équipe de données sur les arriérés de produits travailleront sur le prochain sprint. Donc, évidemment, la planification du sprint est la cérémonie dans laquelle nous décidons de l'objectif de l'ensemble du sprint. Nous prévoyons l'évité que toute l'équipe ferait dans les prochains jours et aussi l'incrément de produit qui serait développé sur la base de cela. Donc dat explique certaines parties de celui-ci, une partie de son importance, l'importance de la planification Sprint est dat. Il permet également d'identifier des facteurs tels que l'effort et la capacité de l'ensemble de l'équipe. Et c'est également très important à calculer et à enregistrer. Nous verrons dans la diapositive suivante comment cela est fait et quels sont les concepts de base qui le sous-tendent. Mais pour l'instant, rappelez-vous juste que le plan de travail et l'estimation sont deux sorties très clés de Sprint Planning et de données sage planification sprint est une chose très importante. Donc, point numéro deux, dans une planification de sprint, nous finalisons l'arriéré de sprint. Autrement dit, qu'est-ce que l'équipe de débiteur verbe ferait dans le sprint à venir ? Donc, les deux semaines ou quatre semaines de travail de l'équipe entière, quelle que soit la durée de nos sprints serait décidée entièrement sur la base de cette réunion de planification. Ensuite, les critères exacts d'acceptation des exigences sont discutés et convenus. Ainsi, comme nous l'avons vu plus tôt, les exigences sont saisies sous la forme d'histoires d' utilisateurs et nous avons des critères d'acceptation à l'intérieur de ceux-ci. Et juste pour que nous fassions le bon produit en tant qu'attentes, il est important que toute l'équipe comprenne ces critères d'acceptation. Donc, lors de la réunion de planification, nous avons discuté de ces critères d'acceptation et si un membre de l'équipe a des questions, des préoccupations ou des risques, il est mis en évidence et résolu. Maintenant, rappelez-vous, cela pourrait aussi être quelque chose qui serait fait dans le toilettage de l'arriéré. Mais néanmoins est la planification du sprint est le forum dans lequel les exigences sont à nouveau discutées et convenues avant que nous puissions enfin les prendre dans le sprint. Quatrièmement, chaque membre de l'équipe estime ou pointe les histoires des utilisateurs. Donc, c'est la planification du sprint est là où l'estimation se produit aussi. C' est pourquoi cette réunion est encore très importante. tâche de point suivant est allouée aux membres individuels de l'équipe. Donc, après avoir finalisé les histoires d'utilisateurs sur lesquelles nous travaillerions. La prochaine question qui se pose est de savoir qui fera quoi ? Donc, nous assignons du travail aux membres de l'équipe, nous créons des tâches pour eux afin que tout le monde sache ce qu'ils sont censés faire. Et dernier point, la performance de l'équipe est discutée via Burndown, Velocity chart, etc. Nous parlerons donc de ces rapports dans un chapitre ultérieur. Mais pour l'instant, pensez simplement que comment pouvons-nous nous assurer que cette équipe évalue les choses correctement ? Comment savons-nous que nous progressons correctement dans le sprint ? Donc, pour cela, nous avons des cartes comme brûlé et vitesse, etc. Nous les référons lors de la planification du sprint pour voir les performances de l'équipe. Et cela nous aidera à ne pas trop nous engager dans les choses et à assurer que nous n'assumons que la dette de travail que nous pouvons assumer complètement. Alors les gars, j'espère que vous savez maintenant pourquoi la planification du sprint est une réunion importante. Et lorsque vous travaillez dans une organisation, assurez-vous de rester attentif et concentré pendant les réunions de planification du sprint, demandez toutes les questions que vous avez. Et enfin, ne le surmontez pas plus que ce que vous pouvez livrer. Bon, allons de l'avant et discutons d'une autre estimation du sujet dans la prochaine conférence. Merci. 27. Estimation dans Scrum: Bonjour à tout le monde et bienvenue. Parlons de l'estimation maintenant. Donc, les gars, l'estimation est un concept général. Ce n'est pas seulement limité à Scrum. Chaque fois que nous travaillons à créer quoi que ce soit, qu'il s'agisse d'un produit ou d'un logiciel, nous sommes invités à fournir une estimation. L' estimation des données est une valeur ou un nombre de temps ou d'efforts qu'il faudrait pour faire la chose. C' est donc ce qu'est l'estimation. Maintenant, ce concept d'estimation est très important et laissez-moi m'asseoir aussi délicat, parce que chaque fois que vous travaillez dans un projet, les gens peuvent ne pas se souvenir de beaucoup de choses, mais ils se souviendront toujours de l'estimation que vous avez donnée et ils vous tiendront responsables de cela. Il est donc très important d'estimer les choses correctement. Maintenant, comme tout autre cadre de gestion de projet l'est, miette implique également une estimation. Et quand est-ce qu'on fait ça ? Estimation ? Nous le faisons pendant la planification du sprint. Qu' est-ce que nous estimons ? Nous estimons les histoires des utilisateurs. Maintenant, rappelez-vous que dans certaines entreprises, ils estiment également les bugs ou les défauts parce qu'ils prennent aussi du temps et des efforts. Mais ce n'est pas une tendance générale. Cela dépend de l'organisation. La plupart des organisations est encore seulement l'estimation de l'utilisateur est des histoires. Ensuite, il y a une différence fondamentale dans la façon dont nous estimons les choses dans HI Norris Scrum et dans la façon dont nous le faisions ailleurs. Donc, si nous parlons des approches traditionnelles que nous utilisons pour estimer de la base vers le haut, ce qui signifie que l'étape 1 énumérera les exigences. Est l'étape deux, nous pensons à toutes les tâches à faire est l'étape trois, nous estimons chacune des tâches en heures ou en jours. Et puis, enfin, étape 4, nous les ajoutons tous pour obtenir l'estimation globale. C' était donc l'approche ascendante qui était traditionnellement utilisée. Maintenant, dans un gel, nous suivons l'approche descendante, ce qui signifie que nous estimons sur l'ensemble des fonctionnalités fonction des informations disponibles, correctes, actuellement. Et alors que quelque chose de nouveau surgit, nous pouvons incorporer la dette. Donc, l'idée globale, rappelez-vous ce très important est d'estimer avec toutes les informations disponibles. Et si les choses changent, nous pouvons considérer cela. Et cela nous donne l'avantage de réagir rapidement selon les changements. C' est donc ce qui lui donne son grand point d'être adaptable aux changements constants. Nous estimons avec toutes les informations disponibles. Et puis si les choses changent, nous avons considéré que troisièmement, chaque membre de l'équipe devrait donner ses estimations. Donc, un Sprint Planning est une réunion à laquelle tous les membres de l'équipe assistent comme nous l'avons vu et à l'exception du propriétaire du produit et du maître Scrum, tous devraient donner leur estimation. Les propriétaires de produits ne pointent pas les histoires d'utilisateurs, ils ne donnent que la réponse à la requête est miettes maîtres ne pointent pas non plus vers les histoires d'utilisateurs. Ils aident seulement à exécuter la planification du sprint. Cependant, si le Scrum Master fait un double rôle comme un développeur ou un test ou aussi, il ou elle peut indiquer si l'équipe est d'accord avec lui. Mais dans des circonstances normales, les donneurs de produits et les maîtres Scrum ne pointent pas les histoires des utilisateurs. Toute l'équipe de développement le fait. Point suivant, s'il y a un conflit, le PIO ou le maître de mêlée devrait peser pour expliquer. Donc, la plupart du temps, il arrive qu'un membre de l'équipe évalue une histoire comme disons cinq points et d'autres disent comme OK, c'est huit points et ne paniquez pas en entendant les points Word. C' est ce que nous allons apprendre dans ce chapitre. Pensez-y comme des unités maintenant. Donc, une personne donne le point que 5B et l'autre personne donne le point est huit. Il y a donc un conflit. Et dans des cas comme celui-ci où il y a un conflit, le Scrum Master peut aider l'équipe à parvenir à un accord. Le propriétaire du produit peut également peser s'il estime que 1% pointait plus haut parce qu'il manque des exigences comprises ou trop réfléchies. L' idée générale est donc de discuter, puis de parvenir à un consensus en cas de conflit. Et encore une fois, nous aborderons ces points en détail plus tard. Mais comme vous pouvez le voir, l'ensemble de l'exercice d'estimation est une approche consensuelle dans Scrum. Les unités d'estimation les plus courantes sont les storypoints, le temps, les tailles de T-shirt, les unités personnalisées, etc. Alors, qu'est-ce que les équipes pointent ? Quelles sont les unités ? Les plus courants sont des points d'histoire comme 135, et cetera, la série Fibonacci. Et nous apprendrons dans un certain temps ce que cela signifie et comment décider de ces points. Maintenant, à part ces points, cette équipe peut également estimer sur la valeur temporelle, ou ils peuvent même estimer sur les tailles de T-shirt comme petit , moyen, grand, extra large, etc planification poker, taille de t-shirt, vote point, affinité, regroupement, etcetera. Ce ne sont donc que les noms des méthodes que nous utilisons pour attribuer des points aux histoires d'utilisateurs. Maintenant, la planification du poker est le plus commun, donc nous allons en parler en détail plus tard. Taille de T-shirt comme nous l'avons vu, est sur le regroupement est des histoires en petites, moyennes, grandes, extra grandes, etc. vote de points donne à chaque membre de l'équipe un nombre limité d'autocollants de points et ils peuvent voter pour des histoires d'utilisateurs individuels par mettre un autocollant à côté de lui. Donc, plus le nombre de points dans une histoire d'utilisateur plus grande est sa taille. Maintenant, cette méthode est utilisée pour un petit nombre d' histoires et quand nous voulons garder les choses simples, ce n'est pas aussi commun. méthode la plus courante est la planification du poker. Et la dernière méthode 2, regroupement d'affinité. Ce qu'il fait, c'est qu'il demande aux membres de son équipe regrouper des histoires similaires en catégories de taille. Donc, cette méthode est également utilisée pour estimer facilement s'il y a un grand nombre d'histoires d'utilisateurs si vous voulez regrouper des choses rapidement. Mais comme je l'ai dit, la méthode la plus courante pour estimer est la planification du poker, et c'est ce que nous verrons dans ce chapitre. Ce sont donc les ciels unitaires d'estimation les plus courants et ce sont les méthodes d'estimation les plus courantes dans l'industrie. Et rappelez-vous, nous en parlerons beaucoup plus en détail dans un chapitre ultérieur. Alors continuons notre apprentissage et parlons de ses points d'histoire dans la prochaine conférence. Merci. 28. Points d'histoire: Bonjour tout le monde et bienvenue. Parlons des points de l'histoire maintenant. Alors les gars, c'est quoi un point d'histoire ? En termes simples, il s'agit d'une unité de mesure utilisée par les équipes Scrum pour fournir une estimation des besoins en matière de réalisation. Donc, c'est ce qui est storypoints est juste une unité d'estimation. Et apprenons-le par un exemple. Donc, disons que je viens à vous et que je veux créer un site e-commerce. Combien d'efforts faut-il pour concevoir la page de connexion ? Et tu diras quelque chose comme ça, ok, c'est notre effort moyen, non ? Et puis je vais vous demander, d'accord, combien d'efforts cela prendra-t-il pour concevoir le flux de paiement ? Tu verras ça, ok, c'est un très gros effort ou un gros effort comme papa. Alors c'est comme ça qu'on parle, non ? Et remplacons maintenant la même chose par des nombres. Et nous appellerons ces chiffres comme les points de son histoire. Donc, nous allons estimer les choses sur quelque chose comme 13581321. C' est donc la série Fibonacci et nous allons utiliser ces valeurs pour l'instant. Nous vous demanderons donc de fournir des estimations uniquement sur ces chiffres. Donc si je te demande ça, d'accord. Si c'est un très petit changement, comme juste changer certains textes verbiage, vous direz que, ok, c'est un 1. Si c'est un peu plus complexe qu'un trois points, si je veux concevoir la page de connexion, alors vous direz probablement que c'est cinq points ou huit points. Si je veux concevoir la page de paiement, vous verrez que c'est très complexe. C' est probablement 13 points ou 21 points. Donc, comme la dette. Donc les gars, les papas, ce qui est storypoint est, vous avez peut-être pensé que c'est trop compliqué, mais c'est en fait aussi simple que ça, un nombre pour indiquer l'estimation de penser, écrire. Et nous en apprendrons plus à ce sujet, comment nous progressons, surtout, comment nous donnons cette estimation. Mais pour l'instant, rappelez-vous simplement qu'un point d'histoire n'est rien d'autre qu'une unité de mesure utilisée pour l'estimation. Deuxièmement, les équipes de PEB d'âge utilisent le format des points d'histoire par rapport au format temps. Donc, dans HI Lori Scrum, l'unité principale d'estimation est une histoire de points. Et la raison pour laquelle nous n'utilisons pas le temps, c'est parce que la définition du temps de chacun est différente. Si je demande à une personne combien de temps il faudra pour concevoir le flux de paiement. Il dira que peut-être 20 heures. Si j'ai posé la même question à la personne B, il dira que cela prendra 30 heures. Donc différentes personnes ont une unité de temps différente, et c'est à cause de la différence dans leurs connaissances ou expérience passée, etc. Mais si je demande à la même personne d'estimer les histoires d' un utilisateur par rapport à une autre via vos points d'histoire. Comme si par exemple, je leur ai demandé à tous les deux de me dire à quel point le flux de paiement est complexe en termes de points d'histoire, ils vont probablement trouver des valeurs similaires. Et c'est la logique de la raison pour laquelle nous nous appuyons sur ses points d'histoire sur des valeurs basées sur le temps. Cependant, rappelez-vous que les points sont également, les points sont utilisés au niveau de l'histoire, de l'histoire utilisateur. Nous utilisons toujours la nôtre sur la tâche assignée à chaque membre de l'équipe afin que nous puissions décider de leur temps disponible. Mais ce n'est pas notre principale unité de mesure en AJI. Si quelqu'un vient vous demander quelle est la sortie de l'équipe, vous direz qu'il s'agit de x points, pas en heures. Donc, vous Story Points sont la principale unité d'estimation du VIH ou de la mêlée. Point suivant, nous estimons sans engagement de temps et embrassons l'incertitude. Donc, lorsque nous estimons en unités de temps, nous devons prendre un engagement précis. Mais il est storypoints empêcher cela parce qu'il n'y a pas de mention du temps. De plus, lorsque vous utilisez des points d'histoire, cela nous permet de saisir l'incertitude, qui, nous le savons tous, est une réalité pratique lorsque nous avons affaire à des exigences. Donc quatre points d'histoire. Nous utilisons des valeurs discrètes comme 1358 et cetera, qui est une série Fibonacci, comme je l'ai dit. Et cela résout les incertitudes car vous verrez qu'à mesure que les chiffres sont de plus en plus nombreux, la différence entre eux augmente également. Cela aidera donc à déclencher une alarme si le point est énorme, comme 13 ou 21, et cela signifierait que les exigences sont trop complexes. Nous devons les diviser en histoires plus petites. Quatrièmement, les valeurs relatives comptent plus que la valeur cru. Donc, les points d'histoire de jour très importants pourraient ne pas signifier beaucoup si vous les regardez isolés avec, mais si vous les considérez d'une manière relative, alors cela fournirait une grande clarté. Ainsi, par exemple, est la dette de l'histoire est pointé trois serait trois fois plus qu'une histoire pointée un, et ce serait la moitié comme quelque chose pointu cinq. Donc, juste comme ça, nous pouvons le comprendre en termes relatifs. Le point suivant est les storypoints considérer l'effort plus la complexité, l'incertitude. C' est donc un concept très important et beaucoup de fois on demande cela aux gens dans des interviews. Qu' indique ce point d'histoire ? Donc, la réponse est que les points de l'histoire indiquent la complexité d' une histoire ainsi que l'effort et les incertitudes. Par exemple, disons que nous voulons changer la taille de l'image de profil sur Facebook. Nous voulons les agrandir en ce moment, ils arrivent en quatre par 400 pixels et nous voulons en faire 700 par 700 pixels. Si simple, nous voulons juste faire ce changement. Donc, si nous demandons au développeur, il dirait que c'est un changement très simple 1 pour moi. Mais si vous considérez la même chose de l'aspect du testeur, il ou elle devrait vérifier le même changement sur différents navigateurs appareils. Il devrait s'assurer qu'il ne casse rien comme montrer l'image de profil sur la page du groupe, et cetera. C' est pourquoi la complexité pourrait être faible, mais l'effort pour le testeur est élevé. Nous devons donc tenir compte de tous ces facteurs. Et c'est un exemple très, très simple sur l'effort et la complexité. Nous en verrons plus tard. Et si nous avons des inconnues aussi dans l'exigence, tiret devrait également refléter dans le point. Nous prendrons donc probablement une voie sûre et nous montrerons peu plus haut s'il y a une incertitude. Ce sont donc tous les processus de pensée qui vont dans le pointage et nous verrons comment donner un point bientôt. Mais pour l'instant, rappelez-vous très important, il est demandé dans les interviews aussi, si quelqu'un vous demande, qu'est-ce que ce point d'histoire indique sur quelle base que vous donnez ces points d'histoire, dites-lui que c'est l'effort plus la complexité et l'incertitude. Et le dernier point est que les Story Points sont un peu déroutants au début, mais nous évoluons en équipe. Quand je vois de nouvelles personnes dans leur équipe, elles s'efforcent d'abord de pointer ou elles répètent simplement les points donnés par les autres. Et c'est parce qu'ils ne savent pas ce que les autres donneront. Et puis ils peuvent être interrogés sur où, pourquoi leurs points sont différents. Donc éviter tous ces doutes ne tombent pas dans ce piège est storypoints est un peu déroutant au début, d'accord ? Mais dans un ou deux sprints, vous apprendrez comment évoluer en équipe, comment pointer les choses en équipe, et ensuite vous seriez bien. Très bien, pour aider à rendre ce voyage encore plus facile pour vous aider à expliquer tous les détails de ses points d'histoire. Parlons de la façon dont quelques conseils qui peuvent nous aider à décider de donner les bons points de l'histoire. Alors voyons ça dans la prochaine conférence. Merci. 29. Comment choisir des points d'histoire avec des exemples communs: Bonjour tout le monde et bienvenue. Apprenons-nous sur les conseils pour décider des meilleurs points de l'histoire. Mais avant d'aller de l'avant, nous allons récapituler les trois informations les plus importantes sur son histoire que nous avons vues plus tôt. numéro un est Story Points sont une unité d'estimation dans un GI. Numéro deux est Story Points sont donnés sous forme de nombres, le plus souvent Fibonacci série 13581321. Et numéro trois, les points de l'histoire comprennent la complexité, l' effort et toute incertitude. Bon, maintenant que nous savons ce que sont les Story Points, supposons que nous sommes assis dans la planification du sprint et que le premier utilisateur est l'histoire vient pour discussion. Et vous savez que vous devez le pointer bientôt avec tous les autres membres de l'équipe. Alors, quel est le processus de pensée qui se passe dans votre esprit ? Quels sont les différents conseils et astuces que vous pouvez utiliser pour vous assurer que vous pointez efficacement et correctement. Alors lisons à leur sujet. Le premier, lire les critères d'acceptation et poser des questions pour plus de clarté. Assurez-vous donc que vous comprenez l'exigence détaillée qui renvoie les critères d'acceptation. Vous savez ce que le Propriétaire du Produit accepte, devrait être fait et il n'y a aucun doute si vous avez des questions, demandez au Propriétaire du Produit, demandez au développeur ou à un testeur et débarrassez-vous des inconnues ou des requêtes que vous ont. Ensuite, l'aspect le plus important à faire de notre part. Pensez bien à votre travail. Si vous êtes un développeur, Pensez à ce que tout ce que vous aurez à coder. Qu' il s'agisse d'un code hérité, que ce soit une API front-end, back-end, qu'il s'agisse d'une zone complexe, etc. Si vous êtes un test ou pensez aux scénarios de haut niveau, comment nous allons obtenir les données de test. Devez-vous tester sur plusieurs navigateurs ? Devez-vous tester sur différents appareils, et cetera ? Alors pense à tout ça. Pensez à ces choses lorsque vous lisez les critères d'acceptation et cela résoudra 99,9% de vos problèmes. Cela vous donnera un grand détail sur la complexité et l'effort qui est impliqué dans cette histoire. Et vous seriez capable de pointer selon ça. Troisièmement, écouté d'autres réponses et commentaires. Donc, comme je l'ai dit plus tôt, est la planification du sprint est une réunion très importante. Alors soyez attentif là, soyez concentré. Ils sont à l'écoute de ce que les autres voient parce que vos doutes ou certaines informations supplémentaires pourraient être cachés dans la dette et cela changera vos pensées sur l'histoire. Point suivant, tirer des leçons des estimations antérieures. Donc l'estimation est quelque chose les gars, la dette vient beaucoup de l'expérience passée aussi. Vous devriez donc garder à l'esprit votre apprentissage du passé, que ce soit en travaillant sur quelque chose de similaire ou en connaissant la fonctionnalité et l'inclure dans votre estimation. Cinquièmement, faire des estimations éclairées, mais ne pas gonfler par souci de commodité. Donc, l'une des choses qui arrive beaucoup est les gens ont tendance à pointer les choses plus haut pour des raisons de commodité, ils vont juste garder tout dans le seau supérieur, mais ce n'est pas correct. Essayez de faire votre estimation autant que possible basée sur les connaissances. Point suivant discuté, ne pas seulement la moyenne sur quatre 0s. C' est donc un point très important. Disons que l'équipe pointe une histoire d'utilisateur. Et la personne a donne pi, cinq points, et la personne B donne 13 points. Il y a donc un conflit. Une personne dit que c'est 5 ou la personne dit que c'est un pointeur 13. Ce qu'on ne devrait pas faire, c'est dire ça, accord, tu en donnes cinq. Il en a donné 13. Alors nous allons nous contenter d'un huit. Non, la dette est fausse. Nous devons discuter pourquoi la personne A pense que c'est un cinq, et nous devons discuter pourquoi la personne B pense que c'est un 5V, besoin de les entendre tous les deux. Ensuite, nous devons parvenir à un consensus et pourquoi. Parce qu'il y a peut-être des informations supplémentaires qui sont avec eux. Peut-être que nous n'avons pas pensé à quelque chose, peut-être que nous n'avons pas obtenu les détails complets. Donc, il devrait toujours y avoir une discussion en cas de conflit, chaque partie devrait donner ses arguments et ensuite l'équipe devrait lire le point. C' est donc très important, comme je l'ai dit. Et comme toujours, le Scrum Master jouerait un rôle important en facilitant cela. Septièmement, si elle est trop élevée, est divisée. Ainsi, chaque équipe apprend de son expérience, ce qui est le maximum est le point de l'histoire qu'elle peut faire. Normalement, si elle est 13 ou 21 pour la plupart des équipes. Mais si c'est 13 pointeur ou 21 pointeur, cela signifie qu'il est trop grand. Les exigences sont de waft et de diviser visuellement l'histoire de l'utilisateur en composants plus petits. Et le dernier numéro huit, ne vous inquiétez pas, il ira mieux avec le temps. Donc, comme je l'ai dit, l'estimation est quelque chose qui vient beaucoup de l'expérience. Ne vous inquiétez pas si vos points sont trop différents des autres au début, donnez-lui juste quelques sprints et alors vous serez bon. Rappelez-vous également qu'il est acceptable d'avoir des points différents parce que vous pourriez avoir des informations que d'autres personnes n'avaient pas. Peut-être qu'ils n'ont pas pensé à quelque chose. Alors pointez comme cela vous semble OK, puis donnez votre logique de soutien s'il y a un conflit. Très bien les gars, donc voici quelques-uns des conseils pratiques qui vous aideront à mieux pointer. Considérons maintenant quelques exemples communs de chaque histoire points afin que vous aidiez, afin que vous compreniez le concept encore mieux. Donc les gars, comme nous l'avons discuté dans le passé, normalement nous utilisons la série Fibonacci pour pointer. Et comme vous pouvez le voir à l'écran, nous avons les cartes quatre valeurs, 13581321, dette que l'équipe peut utiliser pour pointer. Normalement, 21 est une valeur très élevée et cela signifierait que le changement est trop complexe ou qu'il faut faire des efforts. Et il devrait être divisé en histoires plus petites. Ou s'il y a beaucoup d'inconnues 2, alors nous devrions résoudre ces inconnues d'abord et ensuite reprendre l'histoire peut-être dans le prochain sprint. La mémoire. Dans certaines entreprises, ils pourraient également penser à 13 S2 point élevé et le diviser. Cela dépend uniquement de l'expérience passée de l'équipe, qu'elle ait pu faire 13 pointeurs dans le passé ou non. S' ils ne sont pas à l'aise avec 13 pointeurs, s'ils n'avaient pas pu le compléter dans le passé, nous pouvons le décomposer en plusieurs histoires de 5.8.3 points comme ça. Voyons donc ce que certains des scénarios communs que nous allons intégrer dans chaque valeur de point. Et comme toujours, nous prendrons l'exemple du site e-commerce parce que c'est quelque chose que nous avons tous utilisé et auquel nous pouvons nous rapporter. Donc les gars sur votre écran à droite commencent à partir du point le plus bas, le point unique. Donc, 1 est un travail très, très mineur, extrêmement faible ou 0 complexité, comme supposons sur le site que nous voulons changer le nom de quelque chose. Nous voulons apporter quelques modifications à n'importe quel message texte. Nous voulons changer le nom de connexion pour vous connecter, ou nous voulons changer le mot de l'historique des commandes pour votre commande. Donc, comme la dette très petit travail, très faible complexité. Ensuite, nous avons trois points. Donc, c'est quelque chose d'un peu plus d'effort et complexe qu'un parce que rappelez-vous, comme nous l'avons discuté, est Story Points sont relatifs. Donc justifiez, si je vous dis juste que quelque chose est 3, cela ne veut rien dire. Cela ne signifiera quelque chose que si vous le comparez avec un pointeur ou un pointeur et alors il serait logique de classer les choses. Alors c'est quoi trois ? Trois est un peu plus d'effort et de complexité qu'un, comme si nous créons l'option Supprimer dans le panier. Cliquez sur le produit, il est retiré de la carte, le prix est mis à jour, choses comme la dette ou un autre exemple est l'e-mail de mot de passe oublié. Donc, tout le changement de mot de passe oublié serait très important. Mais ici, nous parlons seulement d'envoyer des e-mails. Nous avons divisé l'histoire en petits morceaux. Nous ne parlons que de l'e-mail. Donc, envoyer l'e-mail avec un lien pour réinitialiser le mot de passe est très probablement un trois et la dette est juste pour vous donner un exemple, une chose de plus à considérer ici est que certaines équipes ont également utilisé deux points. Donc, ils utilisent dans la série Fibonacci, ils insèrent également la valeur de point deux. Donc, c'est quelque chose de nouveau qui est basé sur la relativité. C' est quelque chose qui est un peu plus complexe qu'un, mais moins complexe que trois. Ensuite, nous avons le pointeur fie. Laissez-moi vous dire que 58 sont les valeurs utilisées les plus courantes et qu'elles signifient la complexité moyenne. Donc, la fibre est quelque chose comme la recherche d'un produit parce qu'il y a beaucoup de combinaisons dans la recherche. Il y a des intégrations externes aussi pour fournir le résultat de la recherche, etc. Donc c'est une complexité moyenne et soviétique dire qu'il est a-fib. Ou disons si vous voulez créer un formulaire de contact vendeur que l'utilisateur remplit et qu'il envoie les informations au vendeur comme la dette. Donc c'est aussi le pointeur fie parce que nous créons un formulaire. Nous l'intégrons au fournisseur tiers. Nous envoyons l'e-mail à l'équipe appropriée. Donc beaucoup de pièces mobiles. Nous dirons que c'est un pointeur de fichier. D' accord, suivant est huit pointeur. Donc encore une fois, plus complexe et d'effort prenant ensuite 5p. Donc, comme la conception du flux pour s'inscrire sur le site, Nous avons besoin d'un formulaire, nous avons besoin d'enregistrer les détails. Nous devons nous assurer que l'e-mail est unique. Nous devons nous assurer que le mot de passe est fort. Nous devons envoyer l'e-mail à l'utilisateur. Donc, comme vous pouvez le voir, c'est un peu plus de travail et de complexité que ce que nous appelons 5p. De même, si nous ajoutons l'article au panier, c'est un flux très important dans le commerce électronique. Nous devons donc répondre à Ajouter au panier un seul article, plusieurs articles. Et en fait, les choses les plus compliquées comme si le produit n'est pas disponible ou si vous ne pouvez pas ajouter ou moins ou plus de dix quantités, si vous avez déjà l'article en carte à travers ce genre de choses. Il y a donc beaucoup de scénarios, beaucoup de flux à considérer. Et nous devons également tenir compte de la quantité de prix, tous ces systèmes différents. C' est pour ça que j'appellerai ça un huit. Maintenant, la plupart du temps, lorsque vous intégrez quelque chose à un système externe, ce qui signifie quelque chose en dehors de l'équipe, c'est généralement un effort un peu plus élevé, complexe. C' est un peu plus complexe, ça prend plus de temps. Donc, chaque fois que vous espérez quelque chose, chaque fois qu'il y a une dépendance externe sur leur équipe, assurez-vous d'inclure cela aussi dans l'image et vous pointez un peu plus haut. D' accord. La suivante est 13. Donc, comme je l'ai dit, les 13 sont généralement divisés en histoires d'utilisateurs plus petites si l'équipe n'est pas aise parce que c'est un grand changement comme la conception de l'ensemble du flux de paiement. Et peut-être que c'est même à 21 ans. Notez à 13 plus, peut-être que nous intégrons une nouvelle méthode de paiement comme nous intégrons PayPal ou la dette de paiement Apple serait à 13 parce que vous pouvez comprendre beaucoup de travail à faire. Il y a beaucoup d'intégrations, coordinations avec l'équipe externe. Il y a beaucoup de tests de bout en bout qui sont impliqués. C' est pourquoi je vais le pointer comme il 13. Maintenant rappelez-vous les gars, ce ne sont que des exemples dans vos entreprises. Certains d'entre eux peuvent être pointés différemment en fonction de votre expérience passée et quantité de connaissances que vous avez et vous l'apprendrez une fois que vous commencerez à travailler. Ces exemples que j'ai donnés ici sont d'un point de vue profane et ne tiennent compte que du cas le plus courant. Mais si vous quelque part, si vous allez à une entrevue et qu'ils vous demandent des exemples, vous pouvez les citer. Tous les bons gars, donc j'espère que vous êtes clair sur ses points d'histoire maintenant est toujours si vous avez doutes ou tout scénario de votre entreprise ou interviewé à, vous aurez envie d'hésiter, n' hésitez pas à utiliser le Q et une option ou m'envoyer un e-mail. Donc c'est mon numéro d'e-mail, les gars. Et si vous avez des doutes, comme je l'ai dit, si vous avez des doutes ou n'importe quel scénario de votre entreprise ou entrevue où les choses n'étaient pas claires pour vous que vous voulez discuter, n' hésitez pas à utiliser l'option q ND ou vous me déposez un e-mail sur cette adresse. Maintenant que nous avons appris des points de son histoire, parlons de la méthode de pointage des choses. Et ça va être un sujet très intéressant. Alors voyons ça dans la prochaine conférence. Merci. 30. Planification du poker: Bonjour à tous et bienvenue sur le thème de la planification poker. Ne vous inquiétez pas les gars, je ne vais pas tout à coup commencer à enseigner votre poker. Vous êtes toujours dans le bon cours de HL. Qu' est-ce que le poker de planification est, c'est une technique d'estimation et de planification séculaire qui est basée sur la participation de l'équipe et le consensus. Alors rappelez-vous, comme nous l'avons dit plus tôt, aussi la planification du poker est l'une des méthodes pour estimer les choses, et il y a beaucoup d'autres méthodes aussi, mais la planification du poker est le plus commun. C' est la méthode la plus consensuelle et je dirais que c'est la méthode la plus impliquée pour l'estimation de l'équipe. Et c'est pourquoi il est utilisé par la majorité des organisations. Et la façon dont cela fonctionne est, et c'est ce qui est écrit dans la diapositive aussi, mais parlons. Donc, disons que nous sommes dans la planification du sprint. Le propriétaire du produit ouvre le premier utilisateur est l'histoire de l'arriéré du produit et il ou elle en parle. Il indique à l'équipe quelle est l'exigence, quels sont les critères d'acceptation, etc. S'il y a des questions ou des risques, et cetera ici, ou le propriétaire du produit y répond. Et une fois que tout est fait, une fois que l'équipe est claire sur toutes les exigences, ils n'ont pas de questions, ils n'ont pas d'inconnues, ils n'ont aucun risque. Le propriétaire du produit ou un Scrum Master donnera à chaque membre de l'équipe un jeu de cartes comme celle-ci que nous avons vu lors de la dernière conférence. Donc tout le monde recevrait des cartes avec le numéro 13581321 écrit dessus. Et je me souviens des gars, le propriétaire du produit et le Scrum Master, ils ne pointent pas. Donc, ils ne prendraient aucune carte sur l'équipe de développement prendrait. Et sur le compte de 1.2.3, toute l'équipe révélera la carte en fonction de son estimation de l'histoire de l'utilisateur. Donc, tout le monde lèverait une de ces cartes reflétant les points de l'histoire qu'ils jugent appropriés. Si tout le monde obtient les mêmes points, assez bien, ça deviendra le point de l'histoire. Si ce n'est pas le cas, s'il y a un conflit comme , disons, personne un, course la carte pour cinq points et personne B lève la carte pour 13 points, alors ils doivent tous les deux expliquer la raison d'être du choix de ce nombre. Et c'est pourquoi j'ai dit au début qu'il s'agissait aussi d'un exercice consensuel. On ne va pas dire ça, d'accord, tout le monde sauf une personne en a donné 13, tout le monde en a donné cinq. Alors disons que cinq est le point de l'histoire. Notez que c'est incorrect. Même si une personne a donné 13 ou même si une personne a donné un numéro différent de l'autre , cette personne doit expliquer la logique qui sous-tend le choix de ce nombre. Parce que rappelez-vous les gars, il peut savoir quelque chose ou il pourrait avoir pensé à quelque chose, ou il pourrait avoir, de son expérience passée, savoir quelque chose que les autres membres de l'équipe ne savent pas. Il est donc nécessaire de l'entendre. Et donc nous avons une discussion autour de ça, pourquoi il a donné des points élevés, pourquoi l'autre personne pense que c'est un point bas. Et sur la base de ce que la personne dit, encore une fois, nous lisons le point tout et cette chose continue et encore jusqu'à ce qu'il y ait un consensus. S' il y a de nouvelles informations qui en découlent, le propriétaire du produit doit y répondre. S' il y a un risque ou inconnu qui en découle, alors le propriétaire du produit doit le dissoudre. Et alors seulement l'équipe allait de l'avant et prendre l'histoire de cet utilisateur et pointé. Donc c'est comme ça que ça marche. Et ce point même, toutes les histoires d'utilisateurs que l'équipe doit prendre dans le sprint. Donc, les gars, c'était tout au sujet de la planification du poker. Et comme je l'ai dit, c'est une méthode très interactive et consensuelle pour estimer les choses. Et c'est le plus largement Un. Un point de plus à ajouter ici, l'activité de planification du poker dat est de donner un des points d'histoire. Il peut également être fait dans le toilettage en retard. Une fois que l'équipe passe par les histoires d'utilisateurs dans le toilettage en retard et que tous leurs doutes sont dissipés, alors nous pouvons le pointer. Ils n'utilisent que des Story Points et planifient le poker. Cependant, 1 à noter, même si nous le faisons dans le toilettage en retard, il est toujours recommandé de revoir les points de l'histoire et de discuter choses une fois rapidement lors d'une planification de sprint parce que rappelez-vous que quelque chose pourrait avoir changé, nouvelles informations auraient été fournies et toute l'équipe n'était pas présente dans le toilettage de l'arriéré, comme nous l'avons vu, mais elles sont présentes dans la planification maintenant. C' est donc une bonne pratique de récapituler rapidement, même si nous avons déjà signalé des choses dans le toilettage de l'arriéré. D' accord les gars, donc c'était tout au sujet de la planification du poker. La diapositive dit aussi les mêmes choses que nous avons parlé. Donc, si vous le souhaitez, vous pouvez faire une pause et lire la diapositive. Mais de toute façon, nous avons déjà couvert tout ça. Alors passons à autre chose et parlons du sujet suivant, la capacité de l'équipe dans la prochaine conférence. Merci. 31. Capacité d'équipe: Bonjour à tous et bienvenue à cette prochaine conférence. Donc, dans celui-ci, nous allons parler de la capacité de l'équipe et de la façon dont nous faisons une planification de sprint basée sur cette capacité. Alors comprenons d'abord ce qu'est la capacité. Maintenant, quand l'équipe se réunit pour la planification du sprint. Et supposons que nous discutons des choses pour un sprint de deux semaines. Donc, deux semaines signifient qu'il y a dix jours ouvrables et chaque jour de travail est de huit heures. Donc, chaque personne est censé contribuer un t heures dans ce sprint. Mais ce n'est peut-être pas vrai. Quelqu' un peut prendre un congé ou quelqu'un peut avoir une formation, ou il peut être occupé avec d'autres engagements. Ça peut arriver, non ? C'est une chose pratique et c'est ce que la capacité prend dans son contexte. Quelle est la disponibilité de l'équipe en heures pour ce sprint ? Et sur cette base, nous ferions la planification du sprint. Alors voyons la diapositive maintenant. abord, Capacité est la disponibilité de l'équipe en heures pour le sprint. Donc on a déjà vu ça. Nous estimons que le mot dette peut être fait dans ce sprint selon les heures disponibles de l'équipe. Point suivant, la capacité est calculée en fonction du nombre total d'heures de travail dans un sprint moins les engagements personnels ou professionnels que les membres de l'équipe pourraient avoir. Disons que les membres de l'équipe peuvent avoir des réunions de congés lors des cérémonies de Scrum, etc. Nous devons donc exclure cela et ensuite nous devons calculer le nombre total d'heures de travail de l'équipe. Et en fait, regardons ça pour un exemple. Donc les gars, disons que nous avons cinq membres dans l'équipe, A, B, C, D, E, et il y a dix jours dans le sprint avec un total d'heures de travail de huit heures par jour. Donc le nombre total d'heures que tout le monde a dans l'équipe est de 80. Maintenant, considérons qu'un jour au sprint est un jour férié, donc tout le monde serait parti, personne ne travaillerait. Donc tout le monde n'aurait pas huit heures disponibles pour ce sprint. Alors disons que la personne a est en congé pour un jour, donc il ne sera pas là avant huit heures supplémentaires. Reste, personne ne prend feuille, alors on met 0. Et puis disons que la personne D a une formation pendant quatre heures en un jour. Donc pendant quatre heures, il ne travaillera pas au sprint. Et enfin, mettons de côté quelques fois pour les cérémonies de miettes différentes parce que rappelez-vous, nous avons un stand quotidien, Nous avons un arriéré toilettage. Nous pourrions avoir quelque chose d'autres réunions, et cetera. Donc, à peu près, laissons de côté six heures pour tout le monde le sprint entier. Alors que la disponibilité réelle de l'équipe est autant, ce qui est 400 heures moins toutes ces choses qui sont ici. Donc, le nombre total d'heures disponibles était de 400, et ensuite nous allons être occupés pendant 82 heures, un membre ou l'autre. Donc, la capacité disponible va être de 400 moins 80 à 318 heures. Donc 318 heures est le temps que nous avons pour ce sprint. Et tout ce que nous voulons faire dans ce sprint, nous ne devrions planifier que la quantité de travail qui peut être fait dans ces 318 heures. C' est ce qu'est tout le concept de capacité. Et en fait, nous allons être plus réalistes parce que nous ne faisons que planifier d'un bout à l'autre ici. Donc idéalement, soyons plus réalistes et considérons seulement une partie de ce temps. Donc, il y a quelque chose appelé comme facteur de focalisation. C' est ce que l'équipe est capable de rester concentrée. Et nous avons supposé que n'importe quelle équipe a un facteur de concentration de seulement 80%. Cela signifie que l'équipe ne sera concentrée que 80 % du temps. Donc, la capacité réelle que nous allons avoir est de 80 % de ces 318 heures, soit 258254 heures. C' est donc notre capacité. C' est la capacité de l'équipe et c'est la durée pour laquelle nous devrions estimer le travail dans ce sprint. Maintenant que nous savons que nous avons 254 heures de capacité, nous allons commencer à partir de l'histoire la plus prioritaire et ensuite nous allons commencer à y ajouter des tâches. Revenons à la diapositive et regardez-la. Nous avons donc 254 heures de capacité. Nous commencerons à partir de l'histoire la plus prioritaire et nous y ajouterons des tâches. Comme nous allons ajouter le développement front-end, les tests de développement back-end, et cetera, toutes les différentes tâches qui sont nécessaires pour compléter cette histoire. Et pour chacune de ces tâches, nous allons ajouter estimé notre satellite pour une histoire numéro un, que le développement prendra cinq heures. Le développement du backend prendra quatre heures, tests prendront deux heures, etcetera, juste pour un exemple. Donc, nous avons un total de 11 heures de dette serait pris dans cette histoire particulière. Maintenant la capacité restante, rappelez-vous que nous avions une capacité totale de 254 heures. Donc, la capacité restante est 254 moins 11, soit 243 heures. Nous avions donc une capacité initiale de 250 ou 4 heures. La première histoire va prendre 11 heures de travail. Maintenant, nous avons à 43 heures de travail restant, donc vous avez encore de la capacité. Passons à l'histoire suivante. Estimons la tâche en dette, et disons que cela prendra dix heures. Donc nous avons dû 43 heures après la première histoire. L' histoire créera dix heures. Donc maintenant nous en avons 233, notre Soviet a encore la capacité. Passons à l'histoire suivante et c'est ainsi que ça se passe. Nous continuons à choisir une histoire jusqu'à ce que nous ayons la capacité disponible. Une fois la capacité épuisée, nous cessons de prendre d'autres histoires et tout ce que nous avons pris jusqu'à maintenant devient notre carnet de sprint sur lequel l'équipe travaillera lors du prochain sprint. Donc c'est ça, les gars, c'est comme ça que se fait la planification basée sur la capacité. Et il est considéré comme un moyen très efficace de faire une planification de sprint. Parce que n'oubliez pas que nous sommes très réalistes dans le calcul de la disponibilité de tout le monde pour travailler. Personne ne peut être là pour travailler 100 heures. Les gens peuvent prendre des congés, les gens peuvent ne pas être disponibles. Et nous prenons tous ces facteurs en considération. Nous comparons leur tâche avec le JavaScript est disponible pour comprendre combien de temps est là. C' est pourquoi la capacité de l'équipe de planifier la capacité de l'équipe et d' utiliser cette capacité pour effectuer une planification de sprint est très efficace et très utile. Bon, maintenant que nous avons vu la planification basée sur la capacité, regardons l'autre variante, planification basée sur la vitesse dans la prochaine conférence. Merci. 32. Velocité d'équipe: Bonjour à tous et bienvenue à cette conférence sur la vitesse et la vitesse basée est la planification du sprint. Parlons d'abord de ce qu'est la vitesse. Velocity est la quantité de travail qui est terminé par l'équipe dans chaque sprint papas ce qu'il est. Alors, apprenons-le par un exemple. Donc, disons que dans un sprint, nous avons pris dix histoires d'utilisateurs et ils sont totalement le point de l'histoire était 75. C' est, à la fin de cette impression que l'équipe a été en mesure de compléter huit histoires d'utilisateurs. Et le total des points de l'histoire qu'ils ont pu livrer était de 60. Sprint à l'équipe a pris un t points d'histoire et ils ont été en mesure de livrer sur 55 points d'histoire. Lors d'un sprint trois, l'équipe a pris 60 points d'histoire et n'a pu livrer que 40. Donc, notre vitesse moyenne est la moyenne de ces trois chiffres que l'équipe a pu compléter. Donc environ 50 ou 51 points, c'est notre vitesse et c'est le travail que l'équipe devrait entreprendre au sprint. Nous allons donc, quand nous nous réunissons pour la planification du sprint, nous allons commencer avec les User Stories dans l'ordre de priorité, et nous allons continuer à les prendre, nous allons continuer à ajouter leurs points. Et une fois que nous aurons atteint 15 points d'histoire, nous constaterons que c'est ce que nous pouvons faire. C' est ce que nous avons pu faire en moyenne au cours des trois derniers sprints. On s'arrête là. Nous ne prendrons pas plus de 50 points d'histoire. Nous allons tirer toutes les histoires jusqu'à ce que 15 points d'histoire dans notre carnet de sprint. Et c'est tout. C' est ainsi que la planification du sprint basée sur la vitesse fonctionne aussi simple que stat. Voyons maintenant ce que dit la diapositive. Bien que nous ayons couvert beaucoup de ces choses. vitesse des points de départ est donc la quantité de travail accomplie par équipe dans chaque sprint. C' est la définition de la vitesse que nous avons vue. Et il est calculé en ajoutant les points d'histoire de toutes les histoires d'utilisateurs terminées dans le sprint et en prenant leur moyenne, comme nous l'avons vu dans la feuille Excel. Troisièmement, nous avons idéalement utilisé les trois dernières données de sprints pour capturer la vitesse. Et ce gars est très important. Il est fait pour éviter toute fluctuation temporaire. Donc, disons que cette équipe était une équipe tendre livrée moins en un sprint parce que les histoires qu'ils ont prises étaient plus complexes. Ou disons que beaucoup de gens étaient en congé dans les données Sprint ou qu'il y avait une panne, etcetera. Nous voulons donc exclure ces fluctuations temporaires. Et c'est pourquoi nous allons calculer la vitesse. Nous prenons la moyenne d'au moins trois derniers sprints et nous l'utilisons pour calculer notre vitesse. Deuxième point, en plus d'estimer correctement les choses et d'éviter un surengagement, les données de vitesse sont très utiles, en particulier pour la planification du projet. Et c'est parce que cela donne au propriétaire du produit et au détenteur du pieu une idée claire du nombre de sprints qu'il faudra pour fournir les fonctionnalités requises. Donc, disons que nous avons n nombre d'histoires d'utilisateurs dans l'arriéré et que l'équipe est capable de faire 15 points d'histoire en moyenne. C' est notre vitesse. Cela nous donnera donc une idée du temps qu'il faudra pour terminer ces histoires dans l'arriéré. Et dernier point, nous devrions toujours tenir compte des données de vitesse dans chaque planification de sprint afin que nous connaissions les antécédents de cette équipe et que nous ne les surmontions pas. Donc, l'un des problèmes les plus courants auxquels l'équipe est confrontée en réalité est le problème du surengagement. Et en regardant les antécédents de cette équipe, les données de vitesse aideront à résoudre ce problème. D' accord les gars, alors on a parlé de vitesse et de capacité, et on a aussi parlé de faire une planification de sprint basée sur eux. Je voulais mentionner une fois de plus à ce stade que équipes Scrum souffrent d'un problème très commun de surengagement, où nous tirons dans beaucoup d'histoires d'utilisateurs dans le sprint. Et puis à la fin du sprint, beaucoup d'entre eux restent ouverts. C' est donc une réalité très courante et pratique. Il est appelé comme sur l'engagement et cela arrive beaucoup. C' est pourquoi il est très important de garder un œil sur la vitesse et aussi calculer la capacité lorsque nous faisons une planification de sprint parce que si l'équipe n'est pas disponible, si l'équipe est en congé, alors nous ne serions pas ne devrait pas prendre autant de travail que nous devrions idéalement accomplir. C' est donc ce que je fais et recommande normalement. Ce que je fais, c'est que j'utilise la capacité de planifier les choses pour le sprint à venir. Et j'utilise les données de vitesse pour avoir une idée générale de la façon dont l'équipe est toujours chaque enregistrement. Ces deux points sont donc tout aussi importants. Ces deux mesures sont tout aussi importantes et nous devrions les prendre en considération lorsque nous faisons une planification de sprint. Ok les gars, donc avec ça, nous arrivons à la fin de ce chapitre très important et nous avons couvert le sujet très important de l'estimation ici. Tellement bon apprentissage. Permettez-moi de répéter que si vous avez questions ou des doutes sur un sujet dans ce cours, s'il vous plaît, n'hésitez pas à utiliser le Q et une option ou envoyez-moi un e-mail. Les concepts d'estimation sont particulièrement déroutants au début, même si au fur et à mesure que vous évoluez, vous seriez bon. Mais si vous avez des questions, si vous n'êtes pas clair sur quoi que ce soit, si vous avez besoin d'aide pour un sujet spécifique de votre organisation, s'il vous plaît n'hésitez pas à me laisser un courriel, mes idées de courriel juste là. Et je répondrai toujours à votre message dans les 24 heures. Bon, alors continuons sur l'élan de notre apprentissage et regardons un nouveau sujet dans le prochain chapitre. Merci. 33. Le tableau Scrum et l'introduction aux mesures de Scrum: Bonjour à tous et bienvenue au septième chapitre du cours. Donc les gars, ce chapitre est sur les rapports ou les métriques utilisés dans Scrum. Et si vous y pensez, chaque cadre de gestion de projet dans le monde a besoin d'un mécanisme de rapport pour mesurer l'efficacité et le progrès des choses. Et c'est Scrum ne fait pas exception. Il y a plusieurs options dans son Crump pour mesurer les progrès et nous allons en apprendre plus sur eux dans ce chapitre. Et vous remarquerez une chose unique, et il est que tous ne sont pas sur la performance individuelle. Il s'agit plutôt de l'équipe Dart. Donc c'est ce que Scrum est comme on l'a vu plus tôt. Nous réussissons ou nous échouons en équipe. Alors commençons et jetons un coup d'oeil au contenu. Maintenant rappelez-vous les gars, j'ai inclus quelques sujets ici que vous ne trouverez normalement pas dans d'autres rapports discussion, mais ils sont tout aussi importants pour mesurer les choses et c'est pourquoi je voulais en parler. Donc, nous allons commencer avec le tableau Scrum et les rapports quotidiens à partir de celui-ci. Ensuite, nous allons apprendre le Bund vers le bas et brûler les graphiques suivis diagramme de vitesse et comment nous pouvons même utiliser le carnet de commandes de produits pour observer les choses. Alors commençons. Donc le premier sujet que nous allons examiner est le tableau Scrum. Et en fait, la planche Scrum est le visage de chaque processus Scrum. Si vous allez à n'importe quel endroit qui suit est miette, vous remarquerez probablement ce tableau physique et il répertorie les différents utilisateurs histoires que cette équipe fait et leurs progrès. Ou il pourrait y avoir une version virtuelle de celui-ci dans la Gita ou tout autre outil que nous utilisons. Mais il n'en reste pas moins que les planches Scrum et le placement des histoires d'utilisateurs sur eux. Le premier moyen pour vérifier la progression des choses. Donc, comme le dit aussi la diapositive, est émietté est un instantané visuel de l'arriéré de sprint. Autrement dit, l'utilisateur est des histoires que nous faisons dans ce sprint. Et il est maintenu sous une forme virtuelle ou physique. Donc, certaines équipes font le est émietté dans un format virtuel, tandis que d'autres le gardent dans une version physique. Les deux sont identiques dans la mise en page. Si je vous montre d'abord la version virtuelle, c'est à ça qu'elle ressemble. Donc, il s'agit d'un projet pour un site de commerce électronique, et comme vous pouvez le voir, il y a plusieurs histoires d'utilisateurs comme celle-ci. Une ici est pour la page de connexion, celle-ci est pour la page de paiement, et cetera. Et pour chacune de ces histoires, nous avons créé cette tâche comme le développement frontal, les tests, l'UAT, etc. Et ce n'est qu'un exemple. Les équipes peuvent créer une tâche à un niveau plus granulaire aussi si elle va séparer les personnes. Et aussi comme vous pouvez le voir, il y a quatre colonnes pour les statuts sont à faire, en cours, tests effectués, etc. Et encore une fois, ce n'est qu'une façon de catégoriser. Les équipes peuvent le personnaliser en fonction de leurs discussions et accords. Et c'est l'un des avantages d'outils comme celui-ci. Donc, le matin, quand leurs équipes font leur standard avant cela, tout le monde devrait déplacer leur tâche sur ce bateau en conséquence. Donc, comme le développement est actuellement en cours, donc il est assis ici, conception de cas de test est en cours taux est assis ici, et cetera, que vous ce n'est pas un commencé, donc il est toujours assis dans le seau à faire comme la dette. Et au fur et à mesure que le travail de quelqu'un est terminé, ils le déplaceront dans ce seau fait. Donc, comme lorsque le développement est terminé, ils le déplaceront vers Dan mentor conception de cas de test est terminée, ils le déplaceront à fait. Et une fois que toutes ces tâches sont déplacées pour défaire la dette signifie tout le travail est terminé et une histoire peut être close. Donc c'était le bateau virtuel. Et en fait, nous allons utiliser ce même genre d' ennuyer quand nous allons faire notre chapitre de projet de vie. Ce n'était donc qu'une brève introduction des bateaux culturels pour l'instant. Et de même, nous avons une autre planche physique aussi. C' est donc l'un des exemples de bateau physique. Et puis nous en avons un autre ici aussi. Donc, les deux sont similaires. Et si vous regardez attentivement, il est très similaire à la dette de conseil virtuel aussi nous avons vu. Et il a encore une fois, les colonnes pour différents statuts comme faire en cours, test fait, etc. Nous créons donc ces colonnes. Nous les séparons par des menaces pour marquer l'état de chaque tâche. Nous avons une note collante pour chaque tâche peut Nous allons les déplacer dans différents seaux comme ils sont terminés. Donc, tout le concept est le même, que ce soit le conseil virtuel ou le bateau physique. C' est juste la différence dans leur configuration et la façon dont l'équipe y réagit, comment leur équipe l'utilise. Désolé. Donc, revenant à la diapositive, certaines équipes aiment faire des choses sur une planche physique parce qu'elle est toujours visible. N' importe qui peut s'arrêter et voir le progrès des choses. Il y a un sentiment d'accomplissement lorsque vous déplacez leurs notes collantes, et cetera. Et une équipe, ils ont préféré faire le tableau virtuel parce que c'est plus en temps réel. Aucun effort n'est nécessaire pour le créer. Il enregistre les notes collantes, les papiers, etc. Encore une fois, en fonction de la préférence des équipes, ils peuvent choisir n'importe quelle version. Mais le plus important à emporter est que le Scrum team board est le rapport le plus courant du travail que l'équipe fait dans un sprint. Et c'est pourquoi j'ai inclus dans ce chapitre, c'est l'une des meilleures méthodes de reporting pour le travail de l'équipe. En allant au conseil d'administration, n'importe qui peut voir sur quoi travaille toute l'équipe, quel membre de l'équipe travaille sur quelle tâche ? Quel est le nombre total de points que notre équipe a pris ? Combien d'entre eux sont fermés ? Combien d'entre eux sont ouverts ? Autrement dit, il y a un bloqueur, etc. Donc, tout dans toutes les informations totales du Sprint est contenu dans ce seul tableau. Habituellement, les équipes font leur matin se lever aussi avec ce bateau ouvert ou si elles font une version physique, elles se tiennent près de la planche et font le stand-up. Et il favorise la discussion entre l'équipe sur chacun des points. Et le plus important, l' un des bons aspects est que quand quelqu'un a terminé son travail, quand quelqu'un déplace ses tâches vers la colonne terminée, cela crée un sentiment d'accomplissement dans toute l'équipe. Les gars, donc c'était à propos d'une planche Scrum. Regardons un autre rapport dans une prochaine conférence. Merci. 34. Décomposer le tableau: Bonjour tout le monde et bienvenue. Parlons du tableau des brûlures maintenant. Donc, avant de le faire, considérons un exemple typique. Dans notre équipe, nous faisons deux semaines de sprint et nous commençons le sprint, disons tous les lundis. Du lundi au vendredi de la semaine en cours, puis du lundi au vendredi de la semaine prochaine, nous allons travailler sur ce sprint. Et puis le troisième lundi qui arrive, cette équipe nous commencerons avec le prochain sprint. C' est le débit d'un sprint de deux semaines. Maintenant, disons que dans ce courant est sprint, nous avons pris huit histoires d'utilisateurs avec un total de 45 points d'histoire. Maintenant, l'équipe doit travailler de manière à ce que nous continuons bons progrès et que nous continuons à clore les histoires à intervalles fréquents. Sinon, que se passerait-il ? Nous serions des morts-fonds vers la fin. Et puis il pourrait y avoir des histoires d'utilisateurs, la dette ne se ferme pas et rouler. Donc, le graphique qui nous montre cette information particulière, c'est-à-dire le travail qui reste à faire par rapport au temps est appelé le tableau brûlant. Et c'est à ça que ça ressemble. Nous avons donc les points de l'histoire d'utilisateur sur l'axe des y vertical, et que les jours ou le temps sont sur l'axe des x horizontal. Et si vous regardez le graphique, il y a deux lignes ici. Ce taillé est la ligne idéale. Cela signifie, ce qui signifie la progression progressive des choses et l'achèvement comme si vous travaillez à un rythme idéal constant. Et la deuxième ligne est la ligne d'achèvement réelle. Ne vous inquiétez pas de la façon dont ce tableau est fait. Si vous utilisez un morceau comme G, droit, serait automatiquement créé pour vous, il n'y aurait pas de travail manuel nécessaire. Essayons de comprendre ce que ce graphique transmet. Donc, nous commençons avec 25 points d'histoire. C' est notre estimation totale. Et l'idée est de garder cette ligne rouge aussi près que possible de la ligne grise. Si le ReadLine réel dépasse celui du DRE, cela signifie que nous allons plus lentement que prévu. Et si c'est en dessous, cela signifie que nous allons plus vite. Donc les deux cas ne vont pas bien. Nous devons rester aussi près que possible de la ligne grise. Ces boîtes, boîtes grises que vous voyez sont pour le week-end, donc il n'y aurait pas de progrès ici. C' est pour ça que cette ligne grise est plate ici. Sinon, du tout, d'autres fois, ça descend progressivement. Cela signifie donc que nous fermons les choses progressivement. Donc, toute l'idée est que le travail réel aussi cette ligne rouge devrait être aussi proche que possible de cette ligne grise. Et la meilleure façon de le faire est de clore des histoires à intervalles réguliers, aussi simple que cela. C' est tout ce qui est nécessaire pour obtenir un graphique de combustion idéal, estimer ce que vous pouvez prendre autant de travail que vous pouvez livrer, puis fermer les choses à un jeu de données d'intervalle progressif. Avant de revenir à la diapositive et de lire, d'autres choses sont une observation rapide ici. Vous verrez que ce tableau a explosé. Alors pourquoi c'est arrivé ? Cela s'est produit parce que nous avons pu prendre dans un nouvel utilisateur est histoire au milieu d'un sprint, ce qui n'est pas une chose idéale comme nous l'avons discuté, mais cela arrive parce qu'il pourrait y avoir eu une nouvelle exigence commerciale urgente qui est venu. C' est pourquoi le graphique court à ce point. Bon, revenons à la diapositive maintenant et continuons. Nous avons donc déjà vu ce qu'est un graphique brûlant et quels sont son axe X et son axe Y. Troisième tableau burndown nous aide à suivre les progrès sprint bureau parce que nous pouvons vérifier jours et voir si nous fermons les histoires ou non et comment ils sprint va. Donc, s'il ne reste que deux jours dans le sprint et que la ligne réelle est à des kilomètres de la ligne grise, alors c'est un problème. Ensuite, il maintient l'équipe à l'horaire. Donc, juste en regardant le tableau, l'équipe peut savoir si elle est sur la bonne voie ou non. Et troisièmement, la brûlure est très simple à comprendre. Comme je l'ai dit, il est créé automatiquement par Gita ou tout autre outil que vous utilisez. n'y a pas d'effort manuel nécessaire et vous pouvez le regarder tous les jours et comprendre si l'équipe est sur la bonne voie ou non. Dernier point, les tableaux de burndown devraient être analysés régulièrement, en particulier par le propriétaire du produit et le Scrum Master pour s'assurer que les équipes sont sur la bonne voie et que les équipes progressent. Et même toute l'équipe peut le regarder dans le stand up. Dans un de mes projets, nous avions une planche Scrum physiquement où nous nous levons tous les matins. Et le Scrum Master avait l'habitude de mettre un imprimé sur le tableau de burndown tous les matins avant de se lever afin que l'équipe puisse voir ce qu'elle fait et s'assurer qu'elle progresse sur la bonne voie. Et rappelez-vous également que ce tableau de combustion est un très bon outil pour la réunion rétrospective. En outre, il indiquera à l'équipe comment ils progressent. Y avait-il un barrage routier, pourquoi ils ne pouvaient pas fermer les choses à intervalles réguliers, et cetera. Graphique si simple et plusieurs utilitaires. Bon, passons à autre chose et parlons d'un autre rapport dans la prochaine conférence. Merci. 35. Grève le graphique: Bonjour tout le monde et bienvenue. Maintenant que nous savons à propos du tableau de combustion, parlons de quelque chose qui semble similaire, mais c'est une chose complètement différente. Le tableau des brûlures. Donc, les gars, le tableau de combustion montre la quantité de travail que l'équipe a déjà accompli et la quantité totale de travail qui est nécessaire dans le projet. Il s'agit donc d'une mesure du travail total nécessaire par rapport à ce qui est accompli. Et c'est à ça que ressemble le tableau des brûlures. Et là encore, nous avons l'effort ou les points de l'histoire sur l'axe des y vertical et le temps sur l'axe des x horizontal. Mais dans le graphique, vous verrez maintenant trois lignes. La ligne jaune est donc la ligne idéale, la ligne rouge est l'effort total nécessaire pour atteindre l'objectif de développement du produit, ce qui signifie notre effort total requis. Et un bleu est le travail accompli, combien l'équipe a déjà accompli. Et vous pouvez voir que cette ligne idéale jaune monte avec le temps. Cela signifie que nous devons progresser vers l'objectif final avec le temps et de manière cohérente. Donc chaque sprint, nous devrions atteindre un peu plus près de lui. Si nous sommes en dessous de la ligne idéale, cela signifie que nous allons lentement et que nous risquons d'être achevés. C' est ce qu'est le tableau des brûlures. Rappelez-vous dans le tableau des brûlures, nous vérifions que nous brûlons des choses qui sont, que nous fermons sont des histoires où, comme dans le tableau des brûlures, nous voyons que si nous montons, nous allons vers notre objectif final. C' est la façon de le comprendre. Revenons aux diapositives et vérifions les autres détails. Donc point numéro un, N2 nous avons déjà couvert. Rappelez-vous que dans le tableau de combustion, nous avons le travail remarquable sur l'axe des y, mais ici, dans le tableau de combustion, nous avons terminé et le travail total. Et c'est pourquoi certaines personnes considèrent les graphiques brûlés plus positifs parce qu'il parle du travail terminé par rapport au brûlage, qui parle du travail remarquable. Point suivant, quels sont les avantages des graphiques de charge de sorte qu'il montre le travail total et le travail terminé côte à côte. C' est donc une très bonne comparaison. Ensuite, il montre combien de travail reste et que nous voyons les deux choses côte à côte. Nous pouvons voir le progrès des choses. Et le dernier point gravure graphique fournit plus de détails sur l'achèvement du projet. Donc, nous avons évidemment des lignes distinctes de travail total et de travail terminé comme nous l'avons vu. Nous saurons donc que notre projet progresse et s'il est sur la bonne voie d'achèvement. Aussi, disons que s'il y a un nouvel ajout au projet, vous pouvez voir cette bosse ici. Donc, cela montrera que quelque chose de nouveau a été ajouté et donc notre portée a augmenté. C' est un très bon avantage de graver le graphique pour suivre l'état global du projet. D' accord les gars, donc c'était le tableau des brûlures et un autre important est le rapport des miettes. Apprenons un nouveau rapport dans la prochaine conférence. Merci. 36. Tableau de vélocité: Bonjour à tout le monde et bienvenue. Parlons de l'un des rapports les plus simples mais puissants dans Scrum dot est le diagramme de vitesse. Donc, dans le dernier chapitre, nous avons parlé de la vitesse, et cela signifie combien de travail nous avons engagé dans un sprint particulier et combien nous avons réellement engagé. C' est donc la vitesse. Et quand nous tracons ces choses côte à côte, nous obtenons ce qu'on appelle le diagramme de vitesse. C' est donc le diagramme de vitesse, et comme je l'ai dit tout à l'heure, c'est un rapport très simple. Tout ce que nous avons, c'est deux graphiques à barres côte à côte. Et sur l'axe y, nous avons notre unité d'effort comme tous les points de l'histoire. Et sur l'axe des x, nous avons les sprints. Et rappelez-vous, comme nous l'avons dit plus tôt, aussi, il est préférable de regarder les données pour les trois ou cinq derniers est imprimé pour mieux comprendre les choses. Donc, ce que nous faisons est pour chaque sprint, nous tracons les Story Points engagés en gris et le terminé est storypoints côte à côte en vert. Donc, comme vous pouvez le voir pour une aide au sprint, cette équipe n'a pas terminé tout ce qu'elle s'est engagé. Le graphique des engagements est quelque part autour de 35, alors que le graphique terminé est d'environ 30. Donc, cela signifie que l'équipe n'a pas terminé toutes les choses sur lesquelles elle s'était entendue. Donc, dans un sprint huit, nous sommes tombés en elle en bref est l'impression neuf et est l'impression dix nous avons obtenu un 100% achèvement. Sprint 11, Nous avons fait plus. Donc, cela signifie que l'équipe a pris quelque chose de plus au milieu d'un sprint et qu'ils ont pu compléter les données aussi. Donc, c'est une bonne équipe de cartes de vitesse gars parce que, comme vous pouvez le voir dans la plupart des cas, ils ont atteint ce qui a été estimé. Et en fait, dans l'un des cas, ils livrent trop. Aussi. Une autre chose à noter est que ici dans un sprint 13, cette équipe a pris un grand succès et il y a un énorme écart entre ce que le engagé et livré. Et rappelez-vous pourquoi cela s'est produit est à l'ordre du jour pour la rétrospective. Mais vous savez, cela pourrait être dû à plusieurs raisons comme plusieurs personnes ont dû prendre des congés soudains ou l'équipe a été arrêtée en raison d'un travail urgent qui est arrivé ou un autre bloqueur est venu, et cetera. Et c'est arrivé en un sprint. Tous se reposent seulement. Tout est que les sprints sont bons. Et c'est pourquoi, si vous vous souvenez, nous avons dit plus tôt que lorsque nous regardons la vitesse, nous devrions regarder la moyenne d'au moins passer trois sprints. Donc, en regardant ce tableau, quelles sont les informations que nous pouvons obtenir ? Nous pouvons dire que pour cette équipe en particulier, environ 45 à 55 points d'histoire est un bon nombre. Les données sont l'équipe de données devrait idéalement prendre parce qu'ils ont été en mesure de faire autant de sprints toute la journée. C' est donc un bon nombre pour eux quand ils se sont rassemblés pour Sprint Planning et quand ils décident de prendre leurs histoires un par un, ils devraient se contenter de quelque part près de 45 à 55 points. Alors c'est tout. C' est un diagramme de vitesse, les gars et comment l'utiliser. Et rappelez-vous, comme je l'ai dit, c'est un tableau très simple mais très efficace. créer est très simple. Nous avons juste à tracer l'estimateur est l'histoire et en fait terminé l'histoire côte à côte. Et en fait, si vous utilisez un outil comme Gita ou tout autre outil de gestion de projet ces jours-ci, ils seront automatiquement créés pour vous. Vous n'avez pas à faire d'effort. La seule chose est que lorsque vous visualisez, il s'assure que vous utilisez les trois ou cinq dernières impressions de données IS pour effectuer l'analyse. D' accord les gars, revenons à la diapositive et continuons. Parlons donc du dernier point parce que nous avons déjà vu le reste une fois. Le diagramme de vélocité permet donc de savoir quelles sont les capacités de l'équipe, combien elles peuvent idéalement fournir. Et sur cette base, nous pouvons planifier nos sprints. Nous l'avons déjà vu dans le dernier chapitre. En fait, pas seulement un sprint, il nous donne une idée de l'ensemble du projet aussi. Ainsi, par exemple, l'équipe fait environ 50 en sprint et nous avons 150 points de plus à faire avant de pouvoir lancer le produit. On peut donc voir qu'il faudra trois sprints pour finir tout le travail. C' est le but de l'utilisation de la carte de vitesse, c'est le but de savoir combien de travail l'équipe peut faire. Donc encore une fois, rapport très simple mais efficace. Bon, donc maintenant nous avons couvert le plus commun est les rapports Chrome, mais il y a une analyse de plus que je voulais parler. Alors voyons ça dans la prochaine conférence. Merci. 37. Garder un œil sur la Backlog: Bonjour à tout le monde et bienvenue. Donc les gars, jusqu'à maintenant, nous avons vu plusieurs options qui nous aident à analyser comment vont les sprints, quels sont les progrès de l'équipe, etc. Nous avons regardé le tableau de combustion, le tableau de vitesse, etc. certains des rapports les plus couramment utilisés dans Scrum. Mais en même temps, l'arriéré de produits que nous avons continué à parler depuis si longtemps maintenant, c'est aussi quelque chose dont je voulais parler et des données parce que juste regarder ce carnet de produits peut nous donner beaucoup d'informations sur la façon dont les choses sont aller. Si vous vous souvenez de nos derniers chapitres, le carnet de commandes produit est comme notre feuille de route produit. C' est donc une liste de souhaits de ce que nous voulons faire. Nous avons une nouvelle exigence, nous l'avons mise dans le carnet de commandes. Si nous obtenons un nouveau défaut qui peut être fait plus tard, nous le mettons dans l'arriéré. Donc, à intervalles réguliers, nous devrions analyser si notre arriéré ne se transforme pas en quelque chose trop grand et ingérable parce qu'alors nous ne pourrions jamais finir les choses, n'est-ce pas. Nous ferions cinq choses dans ce sprint pour une version particulière, mais il y en aurait dix autres ajoutés à l'arriéré et ce sera un processus sans fin. C' est donc l'idée générale de cette diapositive. Je voulais vous faire connaître ce concept à partir de mon expérience personnelle qui rapporte comme le brûlage, la vitesse de combustion. Ce sont de très bonnes métriques. Mais en même temps, le simple examen de l'arriéré peut aussi révéler comment les choses se passent au sein de l'équipe. Voyons donc ce que dit la diapositive. Tout d'abord, l'arriéré est-il trop important et ingérable ? Donc on en a déjà parlé. Nous ne devrions jamais arriver au point où nous devons dire que, accord, nous avons fait trois points de travail pour libérer le produit. Désolé, nous avons fait trois sprints pour libérer le produit. Mais maintenant, nous avons besoin d'empreintes Maurice parce qu'il y a eu une tonne de choses ajoutées à l'arriéré. On ne veut pas faire ça. Notre arriéré ne devrait jamais devenir trop important. Notre arriéré ne devrait jamais devenir ingérable. point suivant est l'arriéré en cours d'examen et d'établissement de priorités fréquemment. Voilà donc la réponse à tous nos problèmes. Le propriétaire du produit devrait examiner l'arriéré fréquemment. Il devrait en donner la priorité et vous devriez le nettoyer fréquemment. Donc, dat est la solution. Troisièmement, tout le monde ne fait que jeter les choses dans l'arriéré. Donc, dans certaines des équipes que j'ai parlé, Ce qui se passe est que pris une histoire d'utilisateur et puis tout défaut ou toute exigence qui vient, ils viennent juste le déplacer à l'arriéré. Je vais donc vous conseiller contre cette pratique. Rappelez-vous que le résultat de chaque sprint est un produit potentiellement expédiable. Donc, traiter le défaut est également important s'il s'agit d'un défaut de boîtier de bord et que nous ne nous attendons pas à ce que cela se produise fréquemment, alors nous pouvons probablement le reporter pour plus tard. Mais tout simplement mettre aveuglément dans l'arriéré n'est pas une bonne idée de faire les choses. Point suivant, soyez transparent au sujet de la dette technique. Donc la dette technique est un agent conceptuel très intéressant. Vous pouvez lire à ce sujet. Cela signifie simplement le coût des futurs travaux qui viendront parce que l'équipe a choisi une solution facile et rapide maintenant au lieu de la meilleure et de prendre du temps. Donc, un gros arriéré est un signe d' endettement technique élevé parce que nous ne faisons que reporter les choses. Et rappelez-vous, à un moment donné, cela va alimenter nos efforts et nos coûts parce que nous devrons les aborder. Voilà donc la dette technique. Et la dette est quelque chose qu'il faut garder à l'esprit, surtout si vous êtes dans un rôle de gestion. Cinquièmement, RV clôturant une histoire d'utilisateur et en ajoutant deux autres à l'arriéré. Donc, si nous ne réfléchissons pas clairement aux exigences , ce qui se passera, c'est que nous ferons une histoire d'utilisateur, mais plus tard, nous découvrirons deux autres exigences que nous avons manquées. Et nous devrons ajouter ces exigences à l'arriéré pour le faire plus tard. Alors pensez, pensez aux exigences clairement. Pensez-y en tant qu'équipe, discutez à ce sujet, essayez de capturer autant d'exigences que possible en un seul coup. C' est quelque chose qui ne serait peut-être pas totalement évitable, mais nous devrions faire de notre mieux que nous le pouvons. Et enfin, est-ce que nous ajoutons beaucoup de bugs pour le travail fait à l'arriéré. Donc, si chaque Sprint, notre nombre de bogues augmente, alors cela signifie que quelque part et nous ne faisons pas les choses avec la qualité. Et malheureusement, c'est un événement très fréquent dans est miette parce que les choses bougent si vite. Essayez donc de comprendre clairement les exigences. Demandez n'importe quelle requête que vous avez. L' idée n'est pas de créer quelque chose avec comme dix défauts qui prendront beaucoup de temps à l'équipe pour corriger. C' est quelque chose qui devrait être observé, en particulier par les responsables techniques et les gestionnaires. Les gars, donc c'était des signes d'alarme pour regarder dans l'arriéré, comme je l'ai dit, nous avons des rapports comme Burndown Velocity, et cetera. Mais si vous gardez un œil sur ces choses simples dans l'arriéré, cela vous donnera beaucoup d'informations sur la façon dont les choses se passent. Très bien, donc avec ça, nous arrivons à la fin du chapitre. Et en fait, nous avons maintenant couvert tous les sujets liés à Agile et Scrum que nous avions prévus dans le contenu du cours. Nous connaissons maintenant le VIH, le Scrum, les différents rôles, cérémonies, artefacts, estimations, métriques, etc., tout ce qu'il faut pour être un expert AGI et Scrum. Donc, félicitations d'entreprise gars, vous êtes maintenant un champion en âge Island est Scrum. Vous êtes parfaitement familier sur toutes les choses à propos de ces sujets. Vous pouvez commencer à le mettre à l'usage. Vous pouvez l'utiliser pour améliorer vos organisations. Vous pouvez le mentionner dans votre CV ou tout ce que vous voulez. Donc les gars, ce cours ne se termine pas ici, bien que nous ayons couvert tous les sujets maintenant que nous avons appris chaque détail en théorie, mettons-le à utiliser dans un projet pratique et voyons comment les choses fonctionnent dans le monde réel. Parce que rappelez-vous Andi, quand nous ferons les choses, nous apprendrons sur la mise en œuvre du monde réel. Je vous verrai donc dans le prochain chapitre et nous commencerons à travailler sur un projet de bout en bout pour discuter de tout en détail. Merci. 38. Projet pratique - Mettre en œuvre Agile - Partie 1: Bonjour à tous et bienvenue. Donc les gars, c'est le projet d'apprentissage pratique de ce cours. Et dans ce chapitre, nous allons appliquer tout l'apprentissage que nous avons fait jusqu'à présent dans le cours pour voir comment les choses fonctionnent dans le monde réel, je suggère que vous accordez beaucoup d'attention à ce chapitre parce que seulement si vous vous concentrez sur les aspects pratiques de chose, vous apprendrez à connaître tous les détails. Alors commençons l'action. Donc, dans ce chapitre va être divisé en quatre parties où nous allons commencer par la façon dont nous obtenons les exigences et comment nous les écrivons comme des histoires d'utilisation. Ensuite, nous allons voir comment le carnet de commandes de produits est créé. Comment faire la planification du sprint et comment finaliser l'arriéré du sprint ? Ensuite, nous allons voir comment le sprint se passe, comment le travail se passe quand ils tournent. Et enfin, nous allons voir comment le travail est libéré et nous allons de l'avant. Et comme vous pouvez le voir, il n'y aurait pas de diapositives dans ce chapitre, tous les enseignements sont pratiques. Nous allons utiliser cet outil Xcel Energy EDA pour comprendre les choses. Maintenant, dans ce projet, nous allons simuler la création d'un site e-commerce. Et j'aime utiliser le commerce électronique pour des explications parce que c'est un domaine très dynamique. Et nous pourrions tous nous y rapporter. Nous avons tous utilisé Amazon, eBay ou tout autre site de commerce électronique. C' est donc un bon exemple à considérer. Et nous allons créer un site e-commerce à partir de zéro, et il va être appelé comme un enfant Mega Mart.com, ce projet d'été mettant en place ce site e-commerce. Et nous verrons comment le faire. Alors commençons. Commençons donc avec la première partie, obtenant les exigences et en les convertissant en histoires d'utilisateurs. Alors, comment obtenons-nous les exigences ? Maintenant, les exigences peuvent provenir de différentes sources. Toutes les entreprises disposent aujourd'hui d'un groupe de gestion de produits dédié qui est responsable de la génération ou de la collecte de ces exigences. Et à nos fins, nous les appelons comme parties prenantes. Nous avons donc déjà vu ce que sont les détenteurs de participations. Ils ont l'exigence commerciale à remplir, et donc chaque équipe recevra les exigences de leur part. Maintenant, rappelez-vous que ces détenteurs de participations génèrent d'abord ou collectent des exigences de haut niveau, ce qui est comme un document de vision produit. Ils peuvent donc rencontrer le client final ou l'utilisateur pour comprendre ces exigences ou pour notre but de créer un site de commerce électronique. Ils se référeront aux besoins du marché ou aux concurrents pour comprendre quelles caractéristiques devraient être présentes. Et sur cette base, ils vont créer une exigence ou une vision de haut niveau. Et cela sera suivi d'une séance de remue-méninges où, vous savez, les équipes de gestion des produits se réunissent et décident quelles sont les fonctionnalités ou les Epics à faire à partir des exigences de haut niveau. Et enfin, il faut que cela soit finalisé. Nous avons les épopées, qui seront divisées en histoires d'utilisateurs. Et nous allons écrire les critères d'acceptation de ces histoires d'utilisateurs qui deviendront nos exigences. Donc c'est tout le flux global. Exigences de haut niveau, puis Epics, puis les histoires d'utilisateurs et les critères d'acceptation en eux. Donc, dans le but de créer un site e-commerce, imaginons Amazon ou eBay dans notre esprit. Et nous allons penser à ce que toutes les fonctionnalités ou épopées qui n'ont pas besoin. Donc, par exemple, ils ont besoin de ce qui suit. Nous avons besoin d'une épopée de compte avec des histoires d'utilisateurs pour l'inscription, la connexion, passe oublié, ma page de compte, inscription par e-mail, le changement de mot de passe, etc. Et puis nous avons besoin d'un pixel de recherche. Dans un tel pixel, nous aurons des choses comme créer une page de liste de boîte de recherche de tous les produits, raffinements de produits, des pages de catégories de tri, des pages de produits, etc. Ensuite, nous pourrions avoir une page de paiement. C' est donc un domaine très important et critique de tout site de commerce électronique. Et nous aurons des histoires d'utilisateurs pour la page du panier d'achat, la page d'adresse de livraison de paiement, le paiement par carte de crédit, PayPal, confirmation de commande Apple Pay, e-mail, toutes ces choses. Et enfin, nous allons avoir l'épopée pour l'architecture de traitement des commandes. Donc, ce sera le matériel technique dont nous avons besoin pour créer une base de données utilisateur, une base de données produit, une base de données ordonnée, etc. Et j'ai inclus cet exemple ici pour vous faire savoir que pour faire les exigences commerciales, nous avons aussi besoin de ce genre de choses techniques. Il pourrait donc y avoir des exigences techniques aussi exigences techniques pures comme la création de toutes ces bases de données. Bon, donc maintenant nous avons toutes ces épopées et nous savons ce que tous les utilisateurs histoires que nous devons créer pour eux. Commençons par écrire ces histoires d'utilisateurs et leurs critères d'acceptation. Et pour les gars de papa, on va utiliser cet outil. C' est donc l'outil JIRA. Vous en avez peut-être entendu parler. C' est un outil très agréable et puissant et il est utilisé par différentes entreprises. dette suit une IG et certains des, la plupart des grands noms du marché pour la gestion des produits et la mise en œuvre de HL. Et vous pouvez l'essayer vous-même. Il suffit d'aller sur leur site Web qui est à lesbian.com et cliquez sur ce bouton essayer maintenant ici pour créer un compte gratuit n'est pas nécessaire d'informations de paiement. Vous n'avez pas besoin de donner une carte de crédit, c'est totalement gratuit. Ainsi, vous pouvez créer un compte vous-même et vous pouvez explorer toutes ces fonctionnalités gratuitement. Donc, lorsque vous créez un compte dans Gita, la première chose que vous devez faire est de créer un projet. Et j'ai créé le mien avec le nom de la dette du site e-commerce. Nous créons un gel Mega Mart. Vous pouvez également créer votre propre projet. Il suffit de cliquer sur ce bouton Créer un projet ici. Et ça va ouvrir quelque chose comme ça. Vous devez donc cliquer sur le bouton de sélection classique ici. Et une fois que vous arrivez à cette page, donnez juste un nom pour le projet et assurez-vous de garder le modèle car il est miette parce que nous allons développer ce projet en utilisant la méthodologie Scrum. Et papa assis, une fois que vous aurez rempli tous ces détails, vous arriverez ici avec votre projet listé ici. Bon, maintenant que nous avons un projet, allons de l'avant et créons nos premières épopées. Alors, cliquez sur ce bouton Créer ici, et créons notre épopée. Donc, si je retourne à la feuille Excel, nous avons eu quatre épopées, compte, recherche, paiement et architecture. Alors créons ces épopées dans le g r2. Donc, je vais sélectionner l'option pour les épopées ici. Et je vais utiliser pour créer la première épopée. nom épique serait le compte. Et donnons le résumé car c'est l'épopée pour les travaux de compte. Je l'ai déjà fait, donc il montre auto rempli de suggestions, mais sont, vous savez, vous pouvez donner n'importe quoi dans quelqu'un et vous pouvez garder l'épopée nommée comme quelque chose de spécifique la dette indique quel domaine il est ou quelle équipe il est, ce genre de choses. Alors, nous allons cliquer. Alors créons cette première épopée. Et ce que nous allons faire est de cliquer sur ceci, Créer un autre bouton ici. Parce que nous devons créer trois autres épopées. Donc, je vais cliquer sur ce Créer. Et comme il est dit, notre première épopée est créée. Ok, créons la prochaine pour la caisse. Ou il a été fouillé. Donc, nous allons créer pour la recherche, et c'est l'épopée pour les travaux de recherche. Alors, cliquez sur Créer. Ensuite, nous pouvons ajouter le 14x Checkout. C' est donc l'épopée pour les travaux de caisse. Et enfin, nous pouvons cliquer sur Créer le dernier pour l'architecture. Et papa set, nous avons créé nos quatre épopées. Donc, si vous vous souvenez de nos apprentissages, et épique est une grande exigence à partir de laquelle nous avons effacé les plus petites, petites histoires d'utilisateurs. Nous avons donc décidé d'adopter pour les epics pour notre compte de projet, la recherche et l'architecture. Nous avons donc créé ces épopées. Maintenant, la prochaine étape que nous devons faire est de créer des histoires d'utilisateurs à l'intérieur d'eux. Alors laissez-moi cliquer sur cette option ici, et laissez-moi cliquer sur cette histoire. Maintenant, nous allons créer notre histoire la plus rapide. Et créons cette histoire pour l'auto-inscription. Donc, je vais le nommer quelque chose comme le flux d'auto-inscription de l'utilisateur. D'accord ? Et encore une fois, ne vous inquiétez pas de toutes ces choses peuplées auto, il se passe parce que je l'ai fait une fois pour la pratique sur ce navigateur. Mais dans votre cas, vous pouvez le taper. Vous pouvez lui donner le nom que vous voulez. Encore une fois, nous voulons que les noms soient spécifiques afin qu'il indique ce que l'histoire sait. N' importe qui peut regarder le résumé et comprendre ce qu'est cette histoire. Nous allons donc passer avec ce résumé. Et la prochaine étape que nous allons faire très importante est d'énumérer les critères d'acceptation juste ici. Donc, si vous vous souvenez des gars, quand nous faisions le chapitre sur les histoires d'utilisateurs et les critères d'acceptation, nous avons mentionné que chaque fois que nous écrivons des critères d'acceptation, nous commençons toujours par les mots en tant qu'utilisateur. Et en fait, le format général est ceci comme une personne. Ainsi, en tant qu'utilisateur ou spécialiste du marketing ou en tant qu'équipe juridique, quel que soit le client final pour lequel nous concevons cette chaîne. Donc, en tant que personnage, je veux un but. Alors quel est le but final de créer cet historique d'utilisateur comme dans ce cas, le résultat final est que l'utilisateur devrait être en mesure de s'inscrire. C' est notre objectif. Et puis enfin, sorte que les parties bénéfiques de ce qui est l'avantage de faire cette chaîne. L' avantage est qu'une fois que l'utilisateur sera en mesure de s'inscrire, il pourra faire le shopping. C' est donc le format général dans lequel nous sommes morts, les critères d'acceptation. Et je vais l'écrire de cette façon. En tant qu'utilisateur, je souhaite m' inscrire sur le site afin de pouvoir commencer à faire des achats. C' est notre déclaration générale, n'est-ce pas ? Et il a été écrit dans ce format. La persona est l'utilisateur. L' objectif est de s'inscrire sur le site et l'avantage est qu'il peut. Il ou elle peut commencer à faire du shopping. C' est donc notre première ligne, le résumé. Laisse-moi enlever cette partie. Et puis ce que nous devons faire, nous devons écrire ces critères d'acceptation détaillés. Ainsi, comme nous l'avons vu plus tôt,les critères d'acceptation comme nous l'avons vu plus tôt, sont la liste détaillée des exigences. Et n'oubliez pas que chaque fois que nous rédigeons les critères d'acceptation, nous devons être aussi détaillés que possible. On n'a rien à laisser à supposer. Nous devons tout marquer aussi clairement que possible. Nous devons couvrir chaque détail autant que possible, n'est-ce pas ? Nous n'avons pas besoin d'aller beaucoup dans la partie comment, comment elle sera mise en œuvre, mais nous devons certainement mettre tout ce qui est nécessaire, la partie y. Bon, alors cliquons sur celui-ci. Nous allons l'écrire d'une belle façon à puces. Donc, je vais dire qu'un utilisateur atterrit sur le site et clique sur le bouton d'enregistrement. Point suivant, inscription. Et ne vous inquiétez pas du contenu exact ici. Je veux dire, c'est juste une façon d'écrire les choses basées sur l'application sur laquelle vous travaillez ou la conception par votre entreprise des critères d'acceptation peut varier, mais l'idée générale reste la même. Nous voulons fournir chaque détail autant que possible. Et nous voulons nous assurer que tout est capturé ici pour que les gens soient, ne laissez rien à leur supposition parce que vous savez, ce qui se passerait si demain l'un des développeurs obtient cette histoire et il commence à travailler à ce sujet, et s'il manque un point, il pourrait vouloir combler les lacunes avec sa propre compréhension des choses. Et puis il pourrait finir par concevoir quelque chose que le propriétaire du produit ne veut pas ou que l'entreprise ne veut pas. Nous voulons donc éviter des situations comme celle-là. Et c'est pourquoi nous allons tout fournir ici autant de détails que possible. Encore une chose, et je dis ça pendant que je tape. Donc, une des choses sur lesquelles je mets particulièrement l'accent lors de la création d'histoires d'utilisateurs est d'avoir une maquette. Donc, comme si vous imaginez ce cas particulier, nous essayons de créer une page d'inscription. Maintenant, nous pouvons écrire toutes les informations autant que possible. Mais si nous mettons une image ici, désastre montre la page d'inscription avec tous ces champs, alors, vous savez, cela aiderait à effacer les choses plus facilement. Rappelez-vous, une image vaut 1000 mots. Et si nous fournissons une image ici, alors les gens seraient en mesure de se rapprocher des choses et ils comprendraient les choses avec des détails complets. Nous avons donc écrit les critères d'acceptation et il dit que l'utilisateur atterrit sur le site Web et clique sur le bouton d'enregistrement. La page d'inscription doit contenir ces champs. Donc CVR indique clairement ce que tous les champs devraient être là, non ? Si l'adresse e-mail est déjà utilisée, nous disons clairement quel est le message d'erreur que nous voulons donner ? Nous ne sommes pas seulement sortir de finir en écrivant qui montrent un message d'erreur. Non, nous disons même quel devrait être le message d'erreur parce que nous voulons qu'il soit clair. Nous voulons que ce soit la façon dont nous voulons exactement la bonne. Et puis nous avons donné quelques règles pour mot de passe comme ils devraient être entre 815 et contenir le numéro de lettre est correcteur spatial comme ceci. Et une fois que l'utilisateur fournit tous les détails et clique sur le bouton Soumettre, ils devraient être pris à la page de mon compte. C' est donc la façon d'écrire les critères d'acceptation. Nous devons être aussi détaillés que possible. Et c'est l'option de navigation à partir de laquelle nous pouvons attacher une maquette. Il montrera que la conception qui est nécessaire et il sera d'une grande aide. Et enfin, ce que nous ferons si nous faisons défiler vers le bas, nous devons attacher cette histoire d'utilisateur à l'épopée. Rappelez-vous que l'épopée est notre grande exigence et nous faisons plusieurs histoires d'utilisateurs pour compléter cette épopée. Donc, pour cette histoire d'utilisateur, nous devons sélectionner une Epic et cette histoire d'utilisateur appartient aux epics du compte. Donc, nous allons créer l'épopée de compte ici. Et je vais cliquer sur ce bouton Créer. Alors c'est tout, les gars. Félicitations, nous avons créé notre premier utilisateur est histoire. Et si nous allons à cet utilisateur est histoire, vous verrez qu'il énumère tout, puces claires, claires et indentation. Donc, tous ceux qui viennent ici, il verra clairement les choses. Donc c'est comme ça que ça marche. C' est le flux complet. Et en fait, nous avons vu ce voyage depuis le début. Nous avons vu comment les exigences sont créées, comment elles sont triées en épopées, puis comment ces épopées sont converties en histoires d'utilisateurs. Donc, si je retourne à notre Excel, nous avons terminé le processus ponctuel de la partie, qui consiste à obtenir les exigences et à convertir en histoires d'utilisateurs. En ce moment, ce que je vais faire est de créer des histoires d'utilisateurs pour toutes ces exigences que nous avons vues. Je les introduirai dans la Gita afin que nous puissions obtenir ce que nous appelons comme un arriéré de produits, une liste complète de nos exigences. Alors laissez-moi créer ces histoires et je vous verrai dans la prochaine conférence pour poursuivre notre étape de bout en bout. Merci les gars. 39. Projet pratique - Mettre en œuvre Agile - Partie 2: Bonjour tout le monde et bienvenue. Nous allons maintenant examiner cette partie, la deuxième partie, où nous allons créer l'arriéré. On ne simulerait pas les actions du toilettage en retard et une planification de sprint. Et nous finirions avec notre carnet de sprint. C' est le travail que nous devons faire dans chaque sprint. Revenons au projet. Donc, si je clique sur ce nom du projet et que je vais à l'intérieur. Sur votre gauche, vous verrez ces quatre premières options, ce dont nous avons beaucoup parlé dans notre apprentissage jusqu'à présent. Donc nous avons la planche Scrum, qui à ce stade serait vide parce que nous n'avons pas complètement configuré les choses et commencé notre sprint. Donc nous reviendrons à ça plus tard. Ensuite, nous avons l'arriéré. Donc, ce gars est notre arriéré de produits. Nous en avons tellement parlé. Nous n'avons cessé de dire que l'arriéré des produits de données est une liste complète de nos exigences. Donc c'est là qu'il est. Et j'ai créé l'histoire de l'utilisateur pour toutes les exigences que nous avions dans notre Excel. Et donc vous pouvez voir toutes ces histoires sont dans le carnet de commandes. Voici la liste complète des exigences que nous devions faire. Et vous pouvez voir toutes ces exigences sont liées à l'épopée aussi. Donc, comme dans votre entreprise, si le compte est une équipe, alors nous savons que ok, sont la comptabilité doit prendre soin de tous ces changements. Si les recherches et d'autres équipes alors juste en regardant ici, nous pouvons dire que d'accord, équipe de recherche doit prendre soin de toutes ces choses ou ceux-ci appartiennent à la fonctionnalité de recherche. Donc, c'est l'avantage d'avoir des épopées que nous savons de quel domaine il vient et de quelle fonctionnalité i spécifique, ces choses liées à droite ? Maintenant, permettez-moi de fermer cette section pour que nous ayons plus d'espace. Et donc les gars, nous avons toutes ces 23 histoires d'utilisation qui sont dans votre arriéré. Nous sommes maintenant bien de commencer par la prochaine étape. Donc c'est là que nous allons faire notre première HI est la cérémonie, le toilettage en retard. Nous allons donc ouvrir cette première histoire d'utilisateur qui va la créer que nous avons écrite avec les critères d'acceptation. Ainsi, le donneur de produit ou le maître Scrum ouvrira cette histoire d'utilisateur et le propriétaire du produit lisera la description et les critères d'acceptation, tout ce qu'il veut faire dans l'histoire. Il montrera s'il y a une maquette, qui encore une fois, je recommande fortement pour des changements de ce genre parce qu'il clarifiera les choses. Le propriétaire du produit expliquera tous ces détails et il leur montrera une maquette. Maintenant, cette équipe va essayer de comprendre ces exigences et s'ils ont des questions, ils vont le demander comme, quelle est la longueur de ce champ prénom ici ? Quelle est la longueur de ce champ LastName, et cetera ? Parce que rappelez-vous, nous voulons clairement mentionné chaque détail. Ainsi, le propriétaire du produit répondra à toutes les dettes et il ajoutera également ces détails à l'histoire. Alors ajoutons ça ici. Donc, disons que le prénom devrait être de 30 caractères. Le nom de famille devrait être un DAT de 30 caractères, n'est-ce pas ? Parce que rappelez-vous l'idée est que nous voulons capturer toutes ces choses aussi détaillées que possible. Nous ne voulons pas qu'un développeur crée le prénom avec seulement dix champs parce que c'était le processus de pensée. Non, nous voulons que ce soit exactement ce dont nous avons besoin. Donc, nous allons tout mentionner ici et il est bon de tout documenter parce que rappelez-vous, personne ne se souviendra de tout cela plus tard. Donc mieux de le documenter maintenant de sorte qu'il sert de référence pour plus tard aussi. Donc c'était la réponse à la question vers le bas va continuer et les gens vont poser la question, l'équipe de développement va poser la question. Le propriétaire du produit répondra à toutes ces choses. Et une fois que cela est fait, une fois que chaque question a été répondu, une fois que tous les points sont dégagés, nous en arrivons à la partie très importante de l'estimation. Très bien, disons que cette équipe est assise comme ça et le propriétaire du produit ouvre l'histoire sur cet écran, il lit les critères d'acceptation, répond à toutes les questions de cette équipe. Tout cela arrive maintenant, données de l'équipe sont assis ici, l'équipe de développement, sauf le propriétaire du produit et le Scrum Master. Toute l'équipe de développement aura des cartes comme celle-ci que nous avons vues. Ce sont donc des cartes simples avec le numéro 13581321, la série Fibonacci. Donc ce ne sont rien d'autre que toutes les options de point d'histoire. Et nous remettons à chacun des membres de cette équipe de développement un ensemble de ces cartes afin qu'ils puissent pointer une histoire. Et ce qui va se passer, c'est au compte de 123, ils vont tous lever une carte avec leur point d'estimation. Donc, disons que pour cette histoire, tout le monde soulève une fib et ignore mes mauvais guides de dessin. Je ne suis pas très bon chez Photoshop. Donc tout le monde dans l'équipe lève la carte avec cinq. Tout le monde dit ça, ok, c'est notre histoire d'utilisateur. Les points de l'histoire sont cinq, tout le monde est d'accord sur la dette. Et donc nous sommes bons à l'histoire et nous allons procéder à la prochaine. C' est donc le chemin heureux où tout le monde s'est mis d'accord sur un point commun. Disons maintenant qu'il y a un conflit. Tout le monde ici l'a signalé sur cinq, mais ce gars ici, il l'a signalé comme un huit. Alors maintenant que se passe-t-il ? Rappelez-vous, nous ne pouvons pas dire que puisque la majorité des gars pointent vers cinq, allons-y avec cinq. Non, nous devons obtenir un consensus. L' exercice de poker de planification est guidé par consensus. Tout le monde doit être entendu, tout le monde a une voix. Donc le maître de mêlée ou le propriétaire du produit demandera à ce type de dette pourquoi il pense que c'est un huit. Et puis il expliquera son processus de pensée et pourrait être comme quelque chose que d'autres n'ont pas pensé. Et donc l'équipe récompensera sur la base de cette nouvelle information et peut-être que tout le monde votera maintenant comme aide parce qu'ils ne pouvaient pas penser à quelque chose plus tôt que le ciel a souligné. Et dans ce cas aussi il y aurait un consensus ou le propriétaire du produit et l'équipe va effacer ces gars doutes qui avaient souligné dans 08. Et sur la base de cette nouvelle information, il sera d'accord pour l'accepter comme un cinq. Donc tout le monde le signale comme un cinq. Nous avons un consensus. Et donc dans ce cas, le point de l'histoire sera finalisé à cinq. Donc nous pouvons revenir à l'histoire et nous pouvons ajouter un point d'histoire à cinq. Donc, c'est l'histoire est estimée comme un cinq et c'est comme ça que les gars l'estimation va se passer. Et idéalement, nous devrions le faire pendant le toilettage en retard. Certaines équipes le font pendant la planification du sprint, mais ce n'est pas idéal. Le toilettage de l'arriéré est le meilleur, désolé, l'argent pour ça. Maintenant, laissez-moi revenir à l'arriéré et vous voyez que si je l'ai actualisé, il commencera à montrer ces cinq points ici. Donc, ces points sont app mais nous savons maintenant quels sont les points de l'histoire pour l'histoire la plus rapide. Maintenant, permettez-moi de mettre cette vidéo en pause et de mettre à jour les points de l'histoire pour d'autres histoires aussi. Ok les gars, donc j'ai daté le point de l'histoire pour les 60 prochaines histoires, et c'est collectivement 42 points. Et supposons que les données sont la vitesse de notre équipe. Nous avons analysé les données pour les trois derniers tours et nous avons constaté que se produit quelque part autour de 40 à 45 points est l'estimation idéale pour cette équipe. Donc nous allons nous arrêter ici. Nous avons fait assez de toilettage pour être préparés pour le prochain sprint. Maintenant, si l'équipe veut et s'ils ont le temps, ils peuvent préparer les prochaines histoires pour l'avenir. Sinon, nous le sommes. Bon pour commencer avec le prochain sprint. Nous avons assez de matériel pour commencer avec le prochain sprint le moment venu. Maintenant que nous avons un arriéré hiérarchisé et estimé, passons rapidement à la cérémonie de planification du sprint. Maintenant, le jour viendra où nous devrons commencer avec le prochain papier journal. Nous allons donc cliquer sur ce bouton Créer Sprint. Et c'est un sprint très. Et donc ce que nous allons faire c'est que nous allons tirer le pointu ce sont des histoires dedans, donc nous devons juste le glisser et le déposer. Donc, vous vous souvenez jusqu'à présent que vous avez vu dans notre voyage combien JIRA nous aide à accomplir toutes ces tâches. Et c'est la raison pour laquelle JNI est l'un des outils les plus populaires dans les industries de nos jours et il est utilisé par toutes les entreprises qui veulent, vous savez, des données en utilisant une élite GI, un des outils les plus utiles pour la gestion des produits, HI EL développement de la gestion, toutes ces choses. Et il est très populaire dans l'industrie aujourd'hui. Donc nous allons traîner ces sept premières histoires dans le sprint parce que c'est le travail que nous allons prendre dans le sprint. Alors supporte juste avec moi pendant que je fais ça. Ok, donc ont déplacé toutes ces 70 histoires et, vous savez, dans les sept aussi, si on veut, on peut changer leur ordre en fonction de la priorité. Ce carnet de commandes de produits est donc une liste hiérarchisée des exigences. Et dans le Sprint aussi, nous devrions garder les histoires dans la liste de la priorité parce que l'équipe va commencer à travailler à partir de l'histoire la plus rapide. Et cela devrait être notre ordre de priorité. S' ils n'ont pas suffisamment de temps, jour des sourds pourrait ne pas être en mesure de compléter celui-ci. Alors continuons à penser à l'ordre de priorité ici. Donc, nous avons tiré 70 histoires dans un sprint. Maintenant que cette équipe va se lancer dans une planification de sprint, ils vont revoir les histoires un par un. Ils le récapituleront rapidement, puis ils attribueront des tâches. Alors faisons ça. C' est notre première histoire que nous avions créée où nous avions rédigé les critères d'acceptation. Et celui-ci est aussi au sommet de notre carnet de sprint. Donc, créons la sous-tâche à l'intérieur. Donc, je vais créer plusieurs sous-tâches comme laissez-moi en créer une pour le développement de l'interface utilisateur, non ? Et puis un autre pour le développement Java, conception de cas de test, l'exécution de cas de test, et enfin UAT et etc Donc, ce n'est qu'un exemple. Je le crée en fonction de mes logiques. Vous pouvez créer une tâche selon les normes de votre organisation. Mais rappelez-vous, encore une fois, l'idée est de les garder détaillées. Comme si une personne va faire développement de l' interface utilisateur et une autre personne va faire le développement Java, alors nous ne voulons pas créer une tâche pour le développement. Nous voulons le séparer pour que tout le monde sache à qui il est chargé, quel travail et qui fait quoi. Nous pouvons suivre leur progression, etc. C'est ainsi que nous allons créer une sous-tâche. Et si je vais à l'intérieur de cette tâche Foster up, nous l'assignerons au développeur. Quel que soit le membre de l'équipe de développement travaille là-dessus. Et nous allons également ajouter l'estimation de la moyenne à ce gars. Alors rappelez-vous, Sprint Planning , en plus de tirer dans les histoires implique également deux tâches supplémentaires. La première est la tâche, donc nous devons assigner la tâche à celui qui le fait. Et la seconde, c'est qu'on doit estimer leurs heures pour ça. Cela nous aidera donc à déterminer la capacité globale. Disons que pour cette tâche, ce type prend cinq heures, non ? Donc on va tirer, mettre des données ici. Et c'est son estimation, l'estimation du temps nécessaire à l'achèvement de cette tâche. Et c'est ça les gars, cette tâche et nos devoirs sont faits. Une fois de plus, permettez-moi de mettre la vidéo en pause et de faire la même chose pour toutes les histoires. Ok, donc maintenant j'ai terminé la tâche pour toutes ces histoires et nous sommes tous sur le point de commencer notre sprint avec ces 70 histoires. Rappelez-vous que lorsque nous prenons ces histoires, nous avons gardé un œil sur leurs points et notre vitesse. Donc notre vitesse pour les trois derniers sprints était, disons une moyenne de 45. Nous avons donc décidé de garder nos points d'histoire encore 42. Nous devons donc, nous devons être conscients de notre vitesse et ne pas la surmonter, ne pas dépasser ce que nous avons pu faire au cours des trois derniers sprints. Et en même temps, nous avons vu que lorsque nous avons créé des tâches, nous avons ajouté des heures à l'intérieur. Donc, sur la base de cela, nous serions en mesure de le comparer à la capacité de cette équipe. Et encore une fois, assurez-vous que nous ne sommes pas trop engagés. Ce sont donc deux aspects que nous devons considérer lors d'une planification de sprint comme nous l'avons vu en théorie, la vitesse et la capacité. Et cela nous aiderait à éviter un engagement excessif qui, comme cela, ferait en sorte que nous ne prenions pas plus que les 70 histoires que nous pourrions idéalement compléter. Ok, donc nous avons tous fini. Nous en avons fini avec le tirage dans l'histoire est la tâche, mettre en heures, et cetera. Donc, nous allons cliquer sur le bouton Démarrer est Sprint et commençons notre Sprint le plus rapide. Et on va garder ces deux semaines de sprint. Il y a une option pour sélectionner autant de semaines que vous le souhaitez ou il y a une option Personnalisée, mais nous allons rester avec deux semaines. Et commençons à partir de lui aujourd'hui et puis laissez-moi cliquer sur Démarrer. Et comme vous pouvez le voir, notre sprint est créé avec succès. Gita a tout créé et l'a mis sur notre, sur notre planche Scrum. Donc c'est notre bateau Scrum. Et comme vous pouvez le voir, il énumère toutes les histoires que nous avions prises dans les indices impriment toutes les 70 histoires ainsi que toute leur tâche qui est assignée à n'importe quel membre de l'équipe le ferait. Donc c'est tous les bateaux de sprint, c'est notre carnet de sprint, le travail que nous allons faire dans ce sprint. Et sur la base de cela, nous savons que ce sur quoi nous travaillerons pour les deux prochaines semaines. D'accord, les gars. Donc, si je retourne à notre Excel, nous avons terminé cette partie. Nous avons créé avec succès un arriéré. Nous avons réussi à assimiler la cérémonie de toilettage en retard et une planification de sprint. Nous avons vu comment nous estimons les choses, comment nous sortons les cartes. Nous avons créé des tâches pour différentes histoires. Nous y avons mis le nôtre, nous avons créé notre propre carnet de sprint, et finalement nous avons commencé le sprint. Alors maintenant, nous sommes dans un sprint. Passons au chapitre suivant et nous allons simuler que les activistes Imprimer Period tank. Vous les gars. 40. Projet pratique - Mettre en œuvre Agile - Partie 3: Bonjour tout le monde et bienvenue. Voici donc nos gars de l'arriéré de sprint que nous avions créé dans notre dernier chapitre. C' est donc notre travail pour les deux prochaines semaines et tout le monde a déménagé une fois que le sprint commence, tout le monde commencera à travailler sur la tâche qui leur est assignée. Et aussi maintenant que nous sommes dans le sprint, rappelez-vous que nous devons faire une halte quotidienne tous les matins. Donc tous les matins, l'équipe se réunira pour un stand up comme ça. Souviens-toi qu'ils font ce stand up avec ce bateau physique. Nous avons un mode virtuel. Donc, si on veut, on peut le faire de la même manière en utilisant un écran avec le tableau virtuel ouvertement, comme ces gars le font avec un tableau physique. Mais l'idée est la même. Tout le monde devrait mettre à jour l'état de sa tâche avant de se lever. Donc, comme le développement de l'interface utilisateur pour la première histoire comme il a commencé. Alors passons en cours. Cette création de cas de test pour la première histoire vient de commencer. Alors passons en cours. Donc, c'est l'équipe dentaire en vrac devrait idéalement faire avant qu'ils se lèvent et se lèvent, ils se tiennent toujours dans un cercle comme celui-ci à côté du tableau physique ou du mode virtuel, peu importe. Et ils vont répondre à leur statut en trois questions. D' abord, qu'est-ce que j'ai fait hier ? Que vais-je faire aujourd'hui ? Et n'importe quel bloqueur attire les gars de format standard d'or, ces trois questions, ça va être une réunion rapide de 15 minutes, minutes tous les jours et puis tout le monde retourne à leur travail et cela continue de se produire tous les jours. Alors ils sprint, ils courent, tout le monde fait le travail qui leur est assigné. Ils mettent à jour leur tâche. Ils assistent au stand up et ainsi de suite. Considérons maintenant point car c'est vraiment le développement de l'interface utilisateur est fermé, donc nous allons passer à fait. La conception du cas de test est également fermée tout en le déplacant à fait. Une fois que le développement a eu lieu. Déplaçons ce type aussi. Donc, une fois que le développement a eu lieu au démarrage des tests, les tests seront également terminés. Ensuite, une fois les tests terminés, l'UAT démarrera et se terminera également. Alors maintenant tout ce qui est à l'intérieur est des histoires terminées. Donc maintenant nous allons, JIRA dira que, ok, vous avez terminé toute la tâche à l'intérieur. Vous voulez mettre à jour l'histoire. Alors laissez-moi cliquer sur la mise à jour. Et comme vous pouvez le voir, cette histoire passera d'en cours à la fin. Nous avons donc terminé notre premier travail dans le Sprint. Nous avons terminé notre premier livrable, notre histoire la plus rapide. De même, l'équipe travaillerait également en parallèle sur toutes ces choses. Et ils mettraient à jour leur tâche. Ils donneraient ce statut à la veille et ils fermeraient des choses. Et rappelez-vous, la même chose serait faite pour les défauts aussi, les défauts seraient également attribués à des membres individuels de l'équipe. Ils travailleraient sur ces défauts, les déplaçaient dans différentes colonnes d'état de maladie que nous voyons et ils fermeraient. Alors c'est comme ça qu'ils sprintent. Nous allons travailler, c'est comme ça que nous progresserons le sprint. Et autre chose que vous devriez noter est que pendant que nous sommes dans ce sprint un, nous devons aussi faire le toilettage en retard pour Sprint deux. Donc deux ou trois jours avant la fin du sprint, nous allons faire le toilettage en retard pour le prochain sprint. Donc, toute la séquence d'événements que nous avons vu jusqu'à maintenant, nous allons répéter, nous allons examiner l'arriéré des produits. Nous allons donner la priorité à ces histoires. Nous allons passer en revue les histoires. Ensuite, nous les avons tirés dans le sprint 1 troisième prochaine planification de sprint vient et toutes ces sources de cela, comme je l'ai dit, un Sprint est une mêlée n'est pas itération de tâche. Nous continuons donc à répéter ces cycles itératifs encore et encore, et nous continuons à fournir de nouveaux incréments à l'utilisateur. Maintenant, rappelez-vous si vous cliquez sur cette chose et vous verrez une option ici pour les rapports. Donc, si vous cliquez sur ces rapports, vous verrez que différentes mesures ou rapports dont nous avons parlé. Donc, vous avez le tableau des brûlures. Vous avez le tableau des brûlures. Je sprint rapporte le rapport de vitesse tout ce que nous avons vu du pain. Et ces graphiques ne seront pas remplis correctement pour moi parce que rappelez-vous, je viens de créer le sprint il y a quelques minutes et je viens le voir aujourd'hui donc il ne sera pas rempli pour moi. Comme vous pouvez le voir, il y a la ligne idéale est là, mais il n'y a pas de ligne d'achèvement parce que nous venons de commencer le sprint quelques minutes en arrière. Mais vous pouvez l'essayer par vous-même. Vous pouvez essayer de créer un sprint clair d'abord, créer un peu d'histoire, Epics, puis crée des histoires avec des critères d'acceptation. Ensuite, créez un sprint à partir de lui. Et puis vous pouvez fermer certaines de ces histoires chaque jour et vous pouvez voir ce graphique bouger de toute façon, l'idée ici n'était pas de montrer ces rapports. Nous l'avons déjà vu. Ce que je voulais vous montrer, c'est que JIRA vous offre la possibilité de consulter ces rapports et JIRA crée ces rapports automatiquement pour vous. Vous n'avez pas à faire un effort manuel pour créer ces rapports. Et encore une fois, c'est un autre avantage pourquoi nous utilisons tellement JIRA pour les projets Agile et Scrum, les bons gars, donc c'est le flux primaire des choses et nous avons couvert la majeure partie des choses et j'ai tout expliqué d'une manière agréable et facile et j'espère que vous êtes clair sur tout. Donc, si vous voyez l'excellent, nous avons couvert les trois parties. On a eu les exigences initiales. Nous avons créé des épopées pour eux, nous avons créé des histoires d'utilisateurs, ajouté des critères d'acceptation. Ensuite, on a fait le toilettage en retard, on a priorisé les histoires, les a examinées, on les a estimés, on les a amenés dans la tâche de sprint , on les a mis en ordre, on a créé un printemps, nous savions quel que soit l'arriéré de sprint, le travail que nous devrons faire au cours des deux prochaines semaines. Ensuite, nous avons fait notre travail au sprint, nous avons fait le stand quotidien. Nous avons déplacé une tâche sur le tableau, nous avons fermé les histoires, nous avons fermé les défauts, nous avons vu le tableau des brûlures, tout cela donc était le flux primaire des choses. C' était beaucoup de choses que nous avons vues. A J'espère que vous êtes clair sur tout. Sinon, vous pouvez me poser les questions si vous en avez. Donc, cette partie est aussi faite. Maintenant, voyons la dernière partie de la dernière conférence. Merci les gars. 41. Projet pratique - Mettre en œuvre Agile - Partie 4: Bonjour tout le monde. Nous avons donc abordé de nombreux aspects liés au projet de bout en bout dans les chapitres précédents. Maintenant, voyons si quelques dernières choses dans cette conférence. Voyons ce beau calendrier que nous avons ici. Comme vous le savez, nous avons commencé notre sprint de deux semaines juste ici. On a fait la planification du sprint. Nous avons obtenu notre travail pour les deux prochaines semaines et nous avons clairement défini qui fera ce que tout était clair sur le tableau, personne ne pouvait le changer. J' ai lu que le travail était visible pour tout le monde. Nous savons qui fait quoi, s'ils sont en cours, s'ils sont blogués, etc. Donc, les choses sont assez triées par eux-mêmes. Le travail progresse. Nous faisons nos stuptions quotidiennes, et cetera, et cetera. Et puis si vous remarquez ici, tout se passe bien. Et puis juste ici quelques jours avant la fin du sprint et nous devons commencer le prochain sprint. Nous faisons le toilettage de l'arriéré ou le raffinement de l'arriéré. Maintenant, nous pouvons le faire ici, nous pouvons le faire ici. Il n'y a pas de règle dure et rapide, mais nous voulons la garder quelques jours avant de commencer le prochain sprint. Parce que rappelez-vous, si quelque chose se produit dans ce toilettage en retard comme un inconnu ou un risque, nous avons suffisamment de temps pour le résoudre avant le prochain sprint. Et rappelez-vous que ce sont les derniers jours de notre course au sprint. Ainsi, les gens pourraient avoir le travail compilé append dévolu pour le terminer avant la fin de ce tour. Nous ne voulons pas prendre beaucoup de temps au cours des deux ou trois derniers jours. Donc normalement, je préférerais faire le toilettage en retard ce mercredi ou jeudi maximum. Donc nous allons le faire ici et ensuite nous serons tous prêts pour le prochain sprint. Et puis, comme vous le verrez ce mardi, quand le courant est la fin du sprint, nous faisons la revue de sprint ou la démo. Nous sommes, nous montrons notre travail à toutes les parties prenantes. Et aussi nous faisons la rétrospective où toute l'équipe se réunirait pour analyser comment tout cela fonctionne, s'ils ont des suggestions ou des commentaires, etc. Et les gars, si vous remarquez, c'est le beauté de l'ensemble du processus. Nous faisons cette démo et rétrospective immédiatement à la fin du sprint. Donc, une fois que nous démontrons le produit aux parties prenantes, nous obtenons rapidement et rapidement des retours d'information. Et une fois que nous faisons la rétrospective, nous obtenons les leçons apprises de ce sprint actuel que nous pouvons mettre en œuvre dans le prochain sprint qui va commencer le lendemain. Donc ces deux cérémonies sont également faites, et maintenant le lendemain nous allons commencer avec une planification de sprint pour le prochain sprint, sprint deux, nous aurons déjà le carnet de commandes de produits que nous avons finalisé ici dans ce toilettage. Et comme nous l'avons vu, nous reprendrons les histoires en fonction de notre vitesse et de notre capacité. Nous allons les charger, nous allons mettre des heures, et cetera, et ce processus itératif va continuer et encore. Et une dernière chose, ce calendrier ne le mentionne pas, mais quelque part nous aurons aussi une sortie du produit des incréments que nous avons conçus pour que l'utilisateur final puisse l'utiliser. Et il n'y a pas de règle fixe pour définir la date de sortie. Il est finalisé lors de la réunion de planification de la publication, et il peut être fait comme ici ou ici. n'y a pas de date fixe à huit. Cela dépend de la feuille de route du produit, la demande du client, du coût, de l'effort, etc. Nous avons vu tous ces sujets et le chapitre de planification des versions. Donc les gars, c'était tout l'aspect pratique d'Agile et Scrum. Nous avons mis en œuvre un projet à partir de zéro. Nous avons créé les histoires d'utilisateurs est sprints, tâche, et cetera. Nous avons fait les différentes cérémonies ou le raffinement des arriérés, le toilettage des arriérés, la planification du sprint, rétrogradé , debout, toutes ces choses. J' espère donc que vous avez tout compris clairement et vous serez maintenant super confiant de tout ce que nous avons appris. Donc, cette dernière partie est aussi complète. Mais comme vous le voyez, nous avons couvert beaucoup de choses dans ce chapitre. Donc, si vous avez des questions, si vous n'êtes pas clair sur quoi que ce soit, n'hésitez pas à utiliser le Q et une option ou vous pouvez me déposer un e-mail ici. Ceci est mon adresse e-mail et comme je l'ai mentionné dans le passé, aussi, je réponds de manière proactive à tous les e-mails dans les 24 à 48 heures. Alors envoyez-moi toutes les questions que vous avez et je ferai de mon mieux pour y répondre. Maintenant, avant de passer aux sujets suivants, un de plus demandé de mon côté, les gars, s'il vous plaît laisser un examen du cours. Cela ne prendra guère deux minutes de votre temps, mais vous êtes en train de nous motiver davantage à créer un bon contenu comme celui-ci pour vous. D' accord, alors passons à autre chose. Nous avons terminé tous nos apprentissages à Scrum. Nous avons couvert les parties théoriques, nous avons couvert les parties pratiques. Examinons maintenant l'aspect de la certification dans le chapitre suivant. Merci. 42. Exams de certification avec des conseils pour les écraser: Bonjour à tous et bienvenue aux neuf chapitres de ce cours. Alors maintenant que nous avons vu tous les aspects de Scrum en théorie et en pratique, parlons de la façon d'utiliser ces connaissances et d'obtenir une certification. Je comprends que beaucoup de personnes qui suivent ce cours seraient intéressées à obtenir une certification aussi. Jetons un coup d'oeil à ce voyage. Parlons d'abord de ce que d'autres certifications, comment s'y inscrire, et comment donner l'examen. Et puis je vais partager quelques conseils qui vous aideront à l'effacer. Il y a donc deux certifications qui sont les plus populaires dans Scrum. Le premier est le maître de mêlée certifié ou CSM. Et l'autre est 35 à Scrum donneur de produit ou CSP o. Si vous êtes un débutant dans Scrum ou que vous êtes juste à la recherche d'une certification pour votre connaissance de sa miette, alors je vais vous suggérer d'aller pour le CSM celui. Et si vous êtes déjà dans le secteur d'activité comme un analyste d'affaires peut l'être, vous pouvez suivre le cours de propriétaire de produit. Cela dépend de votre domaine de travail, vos plans d'avenir, etc. Mais je vous suggère de commencer par le CSM. Donc, dans cette conférence, nous allons parler du cours CSM. Vous pouvez en savoir plus sur CSP aussi, le processus n'est pas très différent. Alors allons sur leur site Web, qui est à l'écran et voir les détails. Rappelez-vous que si vous faites ce cours plus tard, les choses que je parle ici pourraient changer un peu. Et c'est pourquoi je vous pointe vers le site web aussi parce que cela restera toujours à jour. Voici donc la page de certification. Et si vous faites défiler vers le bas, vous pouvez voir les différents parcours d'apprentissage ici dans la piste principale Scrum. Nous avons le Scrum Master Advanced Certified est Scrum Master certifié Scrum professionnellement Scrum Master, comme dans le produit ne pas suivre. Nous avons aussi quelques cours et dans la piste développeur aussi nous avons quelques cours. Je n'ai pas recommandé de cours dans la piste des développeurs. Si vous êtes un développeur et si vous voulez apprendre est miette pour votre propre apprentissage personnel ou professionnel, alors il suffit d'aller pour le cours CSM qui est le meilleur si vous êtes un produit, si vous êtes un secteur d'activité intrus comme un analyste d'affaires et que vous voulez devenir un propriétaire de produit, vous pouvez probablement hors pour ce cours certifié propriétaire de produit Scrum. Mais pour la plupart des gens, les cours de mêlée certifiés seraient les meilleurs. Donc, cliquez sur ce lien de maître de mêlée certifié et il ouvrira quelque chose comme ça. Donc, sur cette page, vous pouvez voir tous les détails et si vous faites défiler vers le bas, vous pouvez voir les exigences pour donner l'examen. Il y a une condition préalable pour donner ces examens CSM et les données que vous devez suivre un cours en ligne ou en personne avant de pouvoir passer l'examen. C' est comme un atelier et c'est obligatoire et ne vous inquiétez pas, il n'y a pas de frais supplémentaires pour cela. Cela fait déjà partie des frais d'examen et cela vous aidera aussi parce que ce sera une sorte de révision pour vous ce que vous avez déjà appris dans ce cours. Maintenant, une fois que vous avez terminé avec cet atelier, vous pouvez passer l'examen et il y aurait environ 50 questions et vous devez en obtenir au moins 37, correct. Et la limite de temps est de 60 minutes. Et croyez-moi, c'est une règle trop détendue. L' examen CSM est très, très simple. Et si vous avez suivi ce cours à fond, si vous voulez réviser les choses dans l'atelier, vous l'effacerez très facilement, juste être préparé. C' est très simple. Maintenant, si vous faites défiler vers le bas et si vous cliquez sur ce bouton Cours de recherche, il vous mènera à la page de détails de l'atelier en fonction de votre pays. Et vous pouvez voir les lieux, les dates, formateurs, etc., en fonction de votre emplacement. Donc, je recommande que vous puissiez faire une recherche sur la ligne 4 en fonction des détails du cours, horaires, des formateurs, etc., tout ce qui vous convient, vous pouvez lire sur l'emplacement aussi. Donc, dans mon cas, tout si vous voyez son affichage en ligne seulement parce que nous sommes dans le temps COBIT, donc les choses sont fermées. Mais une fois que les choses sont normales, iv et des ateliers sont ouverts pour l'interaction en personne. Je vais vous suggérer d'aller pour un cours en personne seulement il est plus interactif et cela vous aidera plus mieux. Vous pouvez donc cliquer sur le lien Inscription pour n'importe quel cours qui vous convient. Et il ouvrira une page comme celle-ci avec les détails les plus fins. Et une fois que vous cliquez sur cette case, il vous donnera les détails pour effectuer le paiement. Donc juste ici et après avoir effectué le paiement, vous recevrez un e-mail de bienvenue. Vous pouvez faire l'atelier, vous pouvez, une fois l'atelier terminé, vous recevrez un autre e-mail qui contiendra les détails pour donner l'examen aussi simple que cela. N' oubliez pas que la seule condition préalable est que vous devez assister à cet atelier avant de pouvoir passer l'examen. Et je pense que c'est une très bonne chose aussi, vous obtenez deux, interagir avec d'autres domaines de logiciels professionnels. Vous arrivez à réviser les choses rapidement et vous pouvez ensuite passer l'examen en fonction de ces connaissances actuelles. Et en fait tout cela et plus d'informations présente leur page FAQ aussi. Donc, si vous allez à la page d'accueil, faites défiler tout le chemin vers le bas et cliquez sur cette FAQ. Ça va ouvrir quelque chose comme ça. Et maintenant, vous devez cliquer sur cette case « Questions de certification » ici. Et vous obtiendrez les détails complets sur un master de mêlée certifié et un examen CSP. Les questions les plus fréquemment posées, j'ai navigué sur l'ensemble de leur site Web pour vous obtenir la meilleure information. Et j'ai trouvé cette page FAQ très sympa. Donc, si vous cliquez sur ce premier, comment puis-je devenir un maître de mêlée certifié ? Cela vous mènera à une page comme celle-ci. Et dans les deux premières questions ici, vous pouvez trouver à peu près toutes les informations que vous voudriez connaître. Je veux savoir. Je vous l'ai déjà dit, mais c'est quand même si vous voulez le lire, ces 2 premières questions auront toutes les informations. Vous pouvez également cliquer sur cela. Que puis-je, puis-je attendre de la question du test CSM et lire les détails de l'examen. Donc, comme je l'ai dit, c'est un examen de 60 minutes avec 50 questions à choix multiples et vous devez répondre correctement à au moins 74%. Et c'est un test en ligne. Vous pouvez le donner de n'importe où que vous voulez. Alors c'est tout. C' est tous les détails que vous aurez besoin de connaître sur l'examen CSM. Et surtout, rappelez-vous, comme je l'ai dit, que c'est un examen très simple. Vous serez en mesure de l'effacer très facilement avec les leçons de ce cours et une révision que vous obtiendrez dans l'atelier. Bon, maintenant que nous sommes au courant de l'examen, revenons voir quelques voyages, conseils pour casser cet examen. Donc, le premier est de lire le Guide Scrum avant de passer l'examen. Donc, si vous allez sur le site, refaisons-le. Je suis donc allé sur leur site web, qui est un mêlé Alliance.org, et je clique sur ces ressources et cliquez sur ce e-books. Et déguiser. Ici, c'est le Scrum Guide. Vous pouvez donc cliquer dessus et télécharger le PDF. Il ne fait que 19 pages et vous pouvez en retirer une copie et en conserver une copie pendant l'examen. Ceci est le lien de téléchargement pour l'obtenir. Point suivant, prendre un test simulé avant l'examen afin que vous puissiez trouver beaucoup de test simulé en ligne, juste Google pour cela et passer par un couple d'entre eux. Cela vous aidera à pratiquer. Il vous dira MOOC quelques questions courantes aussi que vous pouvez préparer. Troisièmement, lorsque vous comparaissez à l'examen, L'un des problèmes communs que toutes les réponses peuvent sembler similaires. Assurez-vous donc que vous lisez attentivement toutes les réponses, puis vous sélectionnez une option qui jeux-questionnaires que vous avez pris dans le cours. Nous sommes sur la même ligne pour vous donner une idée de la façon dont l'examen a été. Donc, cela vous aidera dans une certaine mesure. Mais rappelez-vous, assurez-vous toujours que vous lisez toutes les réponses attentivement et dix, en sélectionnant une option. Point suivant que vous pouvez, vous pouvez utiliser les règles d'élimination, donc éliminer la mauvaise réponse d'abord. Cela vous aidera à exclure certaines options, puis à identifier la bonne réponse. Cinquièmement, être patient est tenu à la connaissance des faits. Donc, comme je l'ai dit, l'examen est très simple. Nous avons déjà appris beaucoup de choses pour cela dans le cours, et vous aurez également une remise à niveau dans l'atelier. Alors soyez patient, soyez confiant et respectez ce que vous avez appris. 6, passez en revue les questions avant où vous avez un doute afin que vous puissiez conserver les réponses lorsque vous avez un doute et y revenir plus tard. Cela vous aidera à gagner du temps. Et enfin, avant de soumettre l'examen, assurez-vous d'avoir répondu à toutes les questions. Donc revérifiez rapidement que toutes les questions sont marquées comme des réponses avant de terminer les choses. Alors c'est tout, les gars. Ce sont quelques-unes des astuces pour aider à l'examen de certification CSM. Et laissez-moi le répéter pour la dernière fois. Si vous faites ce cours à fond, si vous révisez les choses dans l'atelier et apparaissez à l'examen en toute confiance, c'est très, très simple et vous serez en mesure de l'effacer très facilement tout le meilleur. Très bien, donc avec ça, nous arrivons à la fin du chapitre. Passons à la suivante et apprenons sur les questions d'entrevue. Merci. 43. Conseils pratiques pour l'interview: Bonjour à tous et bienvenue au dernier chapitre de ce cours. Parlons de quelques conseils rapides qui vous aideront à clarifier n'importe quelle entrevue, ce soit pour un rôle lié au VIH ou, en général, pour n'importe quel profil. J' ai inclus cette section dans le cours parce que je crois que l'objectif de nous en apprenant quelque chose de nouveau est d'améliorer notre profil de transporteur et, à moment ou à l'autre, de se traduire en un meilleur emploi. C' est donc là que cette section vous sera utile. Dans le même ordre d'idées, j'ai inclus environ 13 questions d'entrevue dans la section des ressources des chapitres. Vous pouvez les lire avant toute entrevue et réviser rapidement les choses. Alors commençons. Alors les gars, disons que nous avons postulé à un emploi et maintenant nous devons aller pour une interview. Alors, comment peut-on se préparer pour le dat ? Voyons quelques règles d'or. Tout d'abord, soyez bien entretenu et préparé. Donc habillage professionnellement, s'il y a un code vestimentaire requis suivi à LC, Vous pouvez habiller dans tout ce qui est professionnel, puis aller à l'entrevue entièrement préparé à ne pas simplement se présenter pour le bien de lui. Deuxièmement, faites quelques recherches sur l'entreprise, le profil de l'emploi, etc. Il est bon de savoir où vous allez. L' intervieweur peut également vous demander si vous connaissez l'entreprise, alors faites vos devoirs. Troisièmement, se comporter, préparer les questions comportementales. Donc, la première question qu'ils posent dans n'importe quelle interview est toujours Parlez-moi de vous ou promenez-moi dans votre profil. Préparez donc une bonne réponse à cela. Quelque chose qui raconte qui vous êtes, vos détails éducatifs, votre expérience de travail, vos compétences techniques , tout prix de projet notable, reconnaissance, etc. Dans mes premiers jours, j'avais une réponse écrite pour que je puisse être préparé. Vous pouvez aussi le faire. Mais si vous faites cela, assurez-vous juste que vous ne sonnez pas comme si vous avez bouché la réponse, dites des choses dans votre ton régulier. Et puis en dehors de cela, il y a d'autres questions comportementales aussi comme, quelle est votre attente ? Êtes-vous un joueur d'équipe ? Tout ce genre de choses. Ainsi, vous pouvez trouver la liste complète sur Internet. L' idée est que se préparer à ces questions comportementales aussi, et pas seulement les questions techniques. Quatrièmement, soyez prêt à parler de chaque processus dans votre entreprise. Donc, quand je prends des interviews, je demande aux gens d'expliquer le processus agile et le parcours complet de leur entreprise. Alors préparez quelque chose sur les mêmes lignes. Comment obtenez-vous les exigences ? Comment faites-vous les cérémonies, comment vous estimez les points de son histoire, comment vous gérez le conseil d'administration de la HL, toutes ces choses. Réponse suivante et très importante clairement, donc répondu d'une manière directe et précise, vous pouvez utiliser des exemples pour compléter votre réponse. Il est toujours utile de suivre les exemples. Vous pouvez donner des exemples de quelque chose de similaire que vous avez fait dans n, dans votre entreprise actuelle ou ailleurs. 6 ne vous battez pas. Soyez ouvert d'esprit, écoutez l'intervieweur et gardez les choses polies. Point suivant et encore, très important. Si vous ne connaissez pas la réponse, dites que honnêtement, il n'y a personne dans le monde qui sait tout, Alors restez honnête et passez sur la question. N' essayez pas de bluffer l'intervieweur. Vous serez pris à coup sûr et ce ne serait pas bon. Deuxième dernier point de toute entrevue, l'intervieweur vous demandera à la fin si vous avez des questions. Alors profite de cette occasion pour demander quoi que ce soit sur le profil d'emploi, l'entreprise , et cetera, que vous voulez savoir qui montrera également votre intérêt pour le travail. Vous pouvez demander à l'intervieweur sa rétroaction générale à votre sujet s'il peut en fournir une, mais ne discutez pas des aspects salariaux qui viendront à un stade ultérieur. Et enfin le dernier point b, la confiance. Alors soyez prêt, soyez optimiste, répondez à tout en toute confiance et espérons que le résultat sera bon. Donc, les gars, ce sont des conseils importants pour l'entrevue. Maintenant, vous trouverez également une liste de 13 questions d'entrevue jointes à ce chapitre, que j'ai soigneusement créé pour couvrir différents aspects d'AGI et de Scrum. Assurez-vous de passer par eux, les réviser avant toute entrevue. Et papa, combiné avec les leçons de ce cours, les conseils ici devraient vous aider à naviguer à travers n'importe quelle entrevue. Je vous souhaite tous les meilleurs gars avec ça, nous arrivons à la fin de ce cours. C' est vraiment excitant de penser à tout ce que nous avons appris dans ce voyage. Nous avons commencé avec les lacunes de l' approche traditionnelle et pourquoi un enfant est venu en image. Nous avons parlé des concepts de base et des définitions d'Agile et Scrum. Nous avons vu les rôles Scrum est des cérémonies de miettes, est des artefacts de Scrum, rapports de planification et d'estimation, certification, d'entrevue, beaucoup de choses. Et nous avons également réalisé un projet avec une mise en œuvre pratique afin que vous puissiez avoir une compréhension pratique de la façon dont les choses fonctionnent dans le monde réel. C' était donc un grand voyage. Et j'espère que ce cours a aidé à atteindre votre objectif d'apprendre sur Agile et Scrum. Une fois de plus, je voudrais réitérer deux points que j'ai évoqués au début du chapitre. Premièrement, la LH n'est pas seulement une méthodologie la plus importante, c'est un état d'esprit. Nous devons être un géant dans nos pensées, notre travail, notre collaboration avec leur équipe. Seulement alors nous pouvons mettre en œuvre avec succès un gel ou un Scrum. Alors gardez que son état d'esprit vous largeur toujours. Deuxièmement, Salut Lori. Scrum n'est pas un bâton magique qui résoudra tous vos problèmes. Il nous montrera quels sont les problèmes ou quels ont été les problèmes de l'industrie. Et c'est à nous de maintenir l'état d'esprit de la HL, travailler ensemble en équipe et de livrer des produits exceptionnels. Donc, l'utilisateur final. Très bien, donc nous sommes à la fin du cours, mais rappelez-vous en vous inscrivant à ce cours, vous avez droit à une installation de support de requête à vie. Donc, si jamais vous avez des questions, des commentaires, si vous voulez parler de quelque chose dans votre organisation, comment cela a fonctionné, et si vous avez une certaine confusion, n' hésitez pas à me laisser un email, mes identifiants de courriel à l'écran, et je réponds rapidement aux aliments dans les 24 à 48 heures. Maintenant, avant de terminer, une finale a demandé sur mon site, s'il vous plaît faire quelques instants pour revoir ce cours et nous donner une note. Vos commentaires sont très importants pour nous et nous aident à créer un contenu exceptionnel pour nos apprenants. Encore une fois, les gars, merci beaucoup d'avoir choisi ce cours et je vous souhaite plein succès dans votre parcours d'apprentissage. Merci.