Stay Updated: Posts | Comments   Follow us on Twitter

Name: Chris

Posts by :

    Jeu des rôles et des responsabilités de Scrum

    January 15th, 2017

    English version here : Scrum Roles and Responsibilities Game.

     

     

    Choose “Français” in language’s listTraduction du jeu Scrum Roles and Responsibilities Game de Andrew Rusling

    Une exécution complète du jeu

     

    Timing : 15 minutes de jeu, 30 minutes de préparation (à réaliser une seule fois).

    Matériel :

    • 32 fiches d’une couleur donnée (J’ai choisi le bleu).
    • 7 fiches d’une autre couleur (J’ai choisi le rose).
    • Un marqueur permanent.
    • Deux feuilles de paperboard (de taille A0).
    • Un bureau très grand ou deux bureaux assez grand pour contenir les deux feuilles de paperboard.

    Instructions :

    Aperçu

    Ce jeu permet de construire une compréhension des rôles et des responsabilités de Scrum. Une fois les cartes préparées (voir les instructions de préparation), vous pouvez facilement répéter ce jeu pour un coût très faible.

     

    Préparation

    Divisez chaque feuille de paperboard en 3 sections de même largeur et intitulez ces sections : Equipe, Scrum Master, Product Owner. Vous devriez pouvoir conserver ces supports pour les réutiliser.

     

    Alimentez les 2 jeux de fiches

    Les fiches bleues (Responsabilités principales)

    • Garantir la qualité
    • Participer au Sprint Planning
    • Participer au Sprint Planning
    • Participer au Sprint Planning
    • Participer à la revue de Sprint
    • Participer à la revue de Sprint
    • Participer à la revue de Sprint
    • Participer au standup quotidien
    • Participer au standup quotidien
    • Participer à la rétrospective de Sprint
    • Participer à la rétrospective de Sprint
    • Participer au Backlog Grooming
    • Participer au Backlog Grooming
    • Participer au Backlog Grooming
    • Conception
    • Réalisation
    • Test
    • Intégration logicielle
    • Déploiement
    • Améliorer les processus
    • Améliorer les pratiques techniques
    • Prioriser le Product Backlog
    • Echanger avec les parties-prenantes
    • Suivre la progression du Sprint
    • Rendre le Product Backlog visible de tous
    • Saisir des éléments dans le Product Backlog
    • Régler les problèmes techniques
    • Régler les problèmes organisationnels
    • Faciliter les événements Scrum
    • Garantir que les règles de Scrum sont suivies
    • Coacher l’équipe
    • Suivre la progression de la release

    Les fiches roses (Responsabilités secondaires)

    • Participer à la rétrospective de Sprint
    • Garantir la qualité
    • Garantir la qualité
    • Participer au standup quotidien
    • Saisir des éléments dans le Product Backlog
    • Améliorer les processus
    • Améliorer les pratiques techniques

    Déroulement du jeu

    Pour 6 à 12 personnes

    Composez 2 équipes de trois à six personnes.

    Fournissez à chaque équipe un jeu de fiches, en leur demandant de les mélanger et les répartir uniformément entre les membres de l’équipe.

    Placez une feuille de paperboard préparée en face de chaque équipe.

    Demandez de placer, en 2 minutes et en silence, les fiches en face du rôle qui porte leur responsabilité. Expliquez qu’il est normal qu’il y ait des doublons. Certaines fiches en doubles peuvent être des responsabilités principales (en bleu) et des responsabilités secondaires (en rose). Cela signifie que certains rôles sont plus ou moins responsable de cette activité.

    Après ce placement, les équipes ont 5 minutes pour aboutir à un consensus d’équipe sur le placement des fiches. Elles devraient échanger autour des éléments sur lesquels elles ne sont pas d’accord au sein de leur équipe.

    Une fois que les équipes sont confiantes dans leurs placements (vous devriez le remarquer par la fin des conversations) demandez-leur d’échanger leurs tables et de contrôler la production de l’autre équipe. Lorsqu’ils ne sont pas d’accord avec un placement, ils doivent discuter calmement avec l’autre équipe.

     

    Apprentissages :

    En général, les équipes tirent des conclusions correctes à travers les discussions qu’ils tiennent autour des cartes sur lesquelles ils trouvent des désaccords. Toutefois, en tant que facilitateur, vous devez surveiller les conclusions ou placements incorrects.

    Un des points remarquables qui émerge de ce jeu est que le Scrum Master n’a pas à résoudre tous les problèmes de l’équipe ou de processus. L’équipe doit s’y impliquer, pour autant le Scrum Master est responsable du fait que cette pratique émerge.

     

     

     

     

    VN:F [1.9.16_1159]
    Rate This
    Rating: 0.0/5 (0 votes cast)

    4 Comments "

    99 Ballons de test

    July 13th, 2013

    English version available here : https://tastycupcakes.org/2009/06/99-test-balloons/.

    This post only contains french version.

    Durée : 30 min

    Matériel pour chaque équipe :
    Ballon de test avec ses critères d'acceptation
    • 20-30 ballons par équipe
    • du papier
    • des règles
    • des ciseaux
    • des marqueurs
    Instructions :

    Commencez par montrer aux équipes un ballon que vous souhaitez créer (ou dessinez-en un).
    Le ballon a un visage constitué de deux yeux ronds, un nez triangulaire, et d’une bouche en demi-cercle. Sans instruction complémentaire, dites aux équipes qu’ils ont 2 minutes pour créer autant de ballons que possible, et que les ballons devront être « acceptés ».

    Éliminez tous les ballons qui ne répondent pas à vos critères de ~ 25 cm de large, des yeux de ~ 5 cm, avec ~ 2,5 cm écart entre les yeux, un nez haut de ~ 3,8 cm, et une bouche de ~ 11,5 cm de large. 

    Très peu d’équipes auront des ballons qui satisferont ces critères.
    Comme vous rejetez leur travail (gâchis), demandez aux équipes si elles ont déjà eu une expérience similaire dans le développement de logiciels.

    Avant le second tour, donnez aux équipes 2 minutes pour discuter sur la façon dont ils peuvent s’améliorer pour la prochaine itération. Ils devraient commencer par demander plus de précisions sur les critères d’acceptation, que vous donnerez avec plaisir.

    Dès le début du second tour, les équipes vont appliquer les critères d’acceptation à leur travail et certains vont même commencer la mise en place d’un « harnais de test » (par exemple : des modèles en papier pour le visage, des moyens rapides pour mesurer la largeur de ballon, etc.).
    Les résultats devraient être meilleurs au second tour.

    Echangez autour de la façon dont ils ont changé leur façon de travailler et autour des améliorations qu’ils feraient la prochaine fois.

    Si nécessaire, faire un tour de plus. Cette fois-ci, chaque équipe doit utiliser un harnais de test et devrait donc produire des ballons avec beaucoup plus d’efficacité et de qualité.

    Aspects couverts :

    • La définition des critères d’acceptation n’est pas la même chose que l’écriture de tests, qui ne s’appliquent qu’après avoir produit quelque chose. Ils peuvent être utilisés comme des exigences, comme des tests, ainsi que comme cible pour les développeurs.
    • L’automatisation des tests d’acceptation (ou exigences exécutables) peut être très utile, comme en témoigne le harnais de test produit pendant la partie.
    • L’investissement dans la création et l’automatisation des tests d’acceptation est utile et  très rentable.

     

    Durée : 30 min

    Matériel pour chaque équipe :
    Ballon de test avec ses critères d'acceptation
    • 20-30 ballons par équipe
    • du papier
    • des règles
    • des ciseaux
    • des marqueurs
    Instructions :

    Commencez par montrer aux équipes un ballon que vous souhaitez créer (ou dessinez-en un).
    Le ballon a un visage constitué de deux yeux ronds, un nez triangulaire, et d’une bouche en demi-cercle. Sans instruction complémentaire, dites aux équipes qu’ils ont 2 minutes pour créer autant de ballons que possible, et que les ballons devront être « acceptés ».

    Éliminez tous les ballons qui ne répondent pas à vos critères de ~ 25 cm de large, des yeux de ~ 5 cm, avec ~ 2,5 cm écart entre les yeux, un nez haut de ~ 3,8 cm, et une bouche de ~ 11,5 cm de large. 

    Très peu d’équipes auront des ballons qui satisferont ces critères.
    Comme vous rejetez leur travail (gâchis), demandez aux équipes si elles ont déjà eu une expérience similaire dans le développement de logiciels.

    Avant le second tour, donnez aux équipes 2 minutes pour discuter sur la façon dont ils peuvent s’améliorer pour la prochaine itération. Ils devraient commencer par demander plus de précisions sur les critères d’acceptation, que vous donnerez avec plaisir.

    Dès le début du second tour, les équipes vont appliquer les critères d’acceptation à leur travail et certains vont même commencer la mise en place d’un « harnais de test » (par exemple : des modèles en papier pour le visage, des moyens rapides pour mesurer la largeur de ballon, etc.).
    Les résultats devraient être meilleurs au second tour.

    Echangez autour de la façon dont ils ont changé leur façon de travailler et autour des améliorations qu’ils feraient la prochaine fois.

    Si nécessaire, faire un tour de plus. Cette fois-ci, chaque équipe doit utiliser un harnais de test et devrait donc produire des ballons avec beaucoup plus d’efficacité et de qualité.

    Aspects couverts :

    • La définition des critères d’acceptation n’est pas la même chose que l’écriture de tests, qui ne s’appliquent qu’après avoir produit quelque chose. Ils peuvent être utilisés comme des exigences, comme des tests, ainsi que comme cible pour les développeurs.
    • L’automatisation des tests d’acceptation (ou exigences exécutables) peut être très utile, comme en témoigne le harnais de test produit pendant la partie.
    • L’investissement dans la création et l’automatisation des tests d’acceptation est utile et  très rentable.

     

    Durée : 30 min

    Matériel pour chaque équipe :
    Ballon de test avec ses critères d'acceptation
    • 20-30 ballons par équipe
    • du papier
    • des règles
    • des ciseaux
    • des marqueurs
    Instructions :

    Commencez par montrer aux équipes un ballon que vous souhaitez créer (ou dessinez-en un).
    Le ballon a un visage constitué de deux yeux ronds, un nez triangulaire, et d’une bouche en demi-cercle. Sans instruction complémentaire, dites aux équipes qu’ils ont 2 minutes pour créer autant de ballons que possible, et que les ballons devront être « acceptés ».

    Éliminez tous les ballons qui ne répondent pas à vos critères de ~ 25 cm de large, des yeux de ~ 5 cm, avec ~ 2,5 cm écart entre les yeux, un nez haut de ~ 3,8 cm, et une bouche de ~ 11,5 cm de large. 

    Très peu d’équipes auront des ballons qui satisferont ces critères.
    Comme vous rejetez leur travail (gâchis), demandez aux équipes si elles ont déjà eu une expérience similaire dans le développement de logiciels.

    Avant le second tour, donnez aux équipes 2 minutes pour discuter sur la façon dont ils peuvent s’améliorer pour la prochaine itération. Ils devraient commencer par demander plus de précisions sur les critères d’acceptation, que vous donnerez avec plaisir.

    Dès le début du second tour, les équipes vont appliquer les critères d’acceptation à leur travail et certains vont même commencer la mise en place d’un « harnais de test » (par exemple : des modèles en papier pour le visage, des moyens rapides pour mesurer la largeur de ballon, etc.).
    Les résultats devraient être meilleurs au second tour.

    Echangez autour de la façon dont ils ont changé leur façon de travailler et autour des améliorations qu’ils feraient la prochaine fois.

    Si nécessaire, faire un tour de plus. Cette fois-ci, chaque équipe doit utiliser un harnais de test et devrait donc produire des ballons avec beaucoup plus d’efficacité et de qualité.

    Aspects couverts :

    • La définition des critères d’acceptation n’est pas la même chose que l’écriture de tests, qui ne s’appliquent qu’après avoir produit quelque chose. Ils peuvent être utilisés comme des exigences, comme des tests, ainsi que comme cible pour les développeurs.
    • L’automatisation des tests d’acceptation (ou exigences exécutables) peut être très utile, comme en témoigne le harnais de test produit pendant la partie.
    • L’investissement dans la création et l’automatisation des tests d’acceptation est utile et  très rentable.

     

    Durée : 30 min

    Matériel pour chaque équipe :
    Ballon de test avec ses critères d'acceptation
    • 20-30 ballons par équipe
    • du papier
    • des règles
    • des ciseaux
    • des marqueurs

    Instructions :

    Commencez par montrer aux équipes un ballon que vous souhaitez créer (ou dessinez-en un).
    Le ballon a un visage constitué de deux yeux ronds, un nez triangulaire, et d’une bouche en demi-cercle. Sans instruction complémentaire, dites aux équipes qu’elles ont 2 minutes pour créer autant de ballons que possible, et que les ballons devront être « acceptés ».

    Éliminez tous les ballons qui ne répondent pas à vos critères de ~ 25 cm de large, des yeux de ~ 5 cm, avec ~ 2,5 cm écart entre les yeux, un nez haut de ~ 3,8 cm, et une bouche de ~ 11,5 cm de large. 

    Très peu d’équipes auront des ballons qui satisferont ces critères.
    Comme vous rejetez leur travail (gâchis), demandez aux équipes si elles ont déjà eu une expérience similaire dans le développement de logiciels.

    Avant le second tour, donnez aux équipes 2 minutes pour discuter sur la façon dont ils peuvent s’améliorer pour la prochaine itération. Ils devraient commencer par demander plus de précisions sur les critères d’acceptation, que vous donnerez avec plaisir.

    Dès le début du second tour, les équipes vont appliquer les critères d’acceptation à leur travail et certains vont même commencer la mise en place d’un « harnais de test » (par exemple : des modèles en papier pour le visage, des moyens rapides pour mesurer la largeur de ballon, etc.).
    Les résultats devraient être meilleurs au second tour.

    Echangez autour de la façon dont ils ont changé leur façon de travailler et autour des améliorations qu’ils feraient la prochaine fois.

    Si nécessaire, faire un tour de plus. Cette fois-ci, chaque équipe doit utiliser un harnais de test et devrait donc produire des ballons avec beaucoup plus d’efficacité et de qualité.

    Aspects couverts :
    • La définition des critères d’acceptation n’est pas la même chose que l’écriture de tests, qui ne s’appliquent qu’après avoir produit quelque chose. Ils peuvent être utilisés comme des exigences, comme des tests, ainsi que comme cible pour les développeurs.
    • L’automatisation des tests d’acceptation (ou exigences exécutables) peut être très utile, comme en témoigne le harnais de test produit pendant la partie.
    • L’investissement dans la création et l’automatisation des tests d’acceptation est utile et  très rentable.

     

    VN:F [1.9.16_1159]
    Rate This
    Rating: 2.0/5 (2 votes cast)

    2 Comments "

Discuss Login
Recent Comments