Tester votre libido Agile

Tester

Votre

Libido Agile

Disclaimer

• Nous sommes des trolls

• Ceci est une expérience apprenante

• Aucune des questions ni des réponses ne se veut une

vérité absolue

• Chaque question peut amener le débat, donc n’hésitez

pas à l’ouvrir

• Aucun Scrum Master n’a été blessé durant la

réalisation de ce questionnaire

Mode d’emploi !

A

C

D

B

Template

Questionnaire

1- Quelle forme ont mes specs ?

Définition de besoin

SFD

STD

Les specs ne sont pas sèches…

mais on est agile ou merde ? On y

va.

US validés par tous avec

cas d’acceptance

En tant que …

je dois …

afin de …

Comment se décide si une tâche est DONE ?

Le développeur a

commité dans le contrôle

de source

Ça marche en PROD

On a rempli touts les

conditions du Definition

of DONE

C’est testé en RECETTE

Les tests : Quelle est votre démarche ?

Test en recette avec

cahier de recette

TDDTester, c’est douter

TU / TI

pour valider les devs

Qui teste le produit ?

L’équipe d’intégration

Tests croisés, puis Product Owner

Des utilisateurs finaux,

ou mieux, un singe

Normalement, c’est bon. En tout

cas, sur mon poste, ça marche.

5- Qui décide du changement de périmètre ?

La Direction

C’était pas dans les specs. On va

faire un avenant.Consensus

Le Product Owner

Quand finit le projet ?

C’est en prod. Bon, la date

est dépassée de 6 mois, et

c’est buggé. Mais bon.

La date et la vélocité sont

immuables. Donc la seule variable

d’ajustement est le scope.

Donc quand le client a ce qu’il faut. Quand j’ai

démissionné

Jamais

car il y a

toujours

de

nouvelles idées

A quel moment voit-on le client final ?

Pas besoin, on a la MOA

On a un représentant à notre

disposition en permanenceParticipe à toutes

les phases du projet

Oh bah s’il a

envie de passer,

il peut, hein…

Who’s the boss ?

Chef de projet

(ou son chef)

(ou le chef de son chef)

Celui qui a les sous /

mon commercial

Pas de chef

Et pourtant

ça marche

Scrum Master

Comment mesurer l’état d’avancement ?

Sur Project, c’est marqué

qu’on est à 43,08%

Burndown chart

du Product BacklogNombre de Feature

en Prod

Il nous reste

15 points

sur ce sprint

10- Quels sont mes KPI ?

Surveillance de la

productivité/JH,

et du pourcentage réalisé,

du TJM

Indicateurs de maturité agile :

Quantité d’US dans le Product

Backlog

Nb d’anomalie par US

Vélocité

Pilotage global

Projet

Business Value

Qualité

Business

Contrôle de la

velocité

de l’équipe

Qui s’occupe du déploiement en recette ?

Je sais pas, moi je livre

un doc de déploiement

sur le réseau

Une machine Un Mexicain

N’importe qui

dans l’équipe

Qui attribue les tâches ?

Le chef d’équipe

Je prends ce qui me plait Je prends la

plus prioritaire

en fonction

des conditions

Le PO

Qui fait l’estimation des tâches ?

Celui qui crie le plus fort

pendant le Planning

Poker

C’est celui qui développe

décide. Ou le CP. Ca

dépend.

Consensus

de l’équipe

L’équipe propose

et le chef valide

A quel moment sont rédigés mes tests ?

En recette après la

reception du DEV

Avant pendant et après

Les tests sont en constante

évolution avec le produit

Pendant la rédaction

des US

Démarche ATDD

TDD

pendant le DEV

15- Qui écrit les specs ?

La MOA

Toute l’équipe participe à la

conception (specs wall,…)

Toute l’équipe

concoit l’US

et

ses cas

d’acceptance

Le PO

avec relecture

Amélioration continue ?

Dès qu’il y a

un problème,

Il faut le résoudre

pour

fluidifier la chaîne

Nous n’avons pas

de temps

à perdre

dans des

réunions inutiles

Il suffit que l’équipe soit

moins feignante

Rétro régulière

(et parfois, il en sort quelque chose

d’intéressant)

Avez-vous un suivi des actions mises en place ?

On a trace tous nos

problemes dans le Wiki

On fait un post-mortem en fin de

projet. Et on flagelle les coupables.

Affichage

et

suivi des actions

mises en place

en continu

Quelles actions ?

Qui décide de l’architecture logicielle ?

L’architecte

Consensus Archi, chef et DEV Démarche

innovante

de co-création

FDD / DDD

L’équipe

Comment gère-t-on les deadlines ?

“Tu fais quoi samedi ?”

Arrêtez de faire des tests, on n’a

plus de temps à gaspiller !

Deadline ?

On est

en flux continu,

mec !

On déscope

des sujets

en fonction

de notre vélocité

20- Comment est géré le budget ?

Je sais pas, faudrait

regarder sur le contrat

Le PO gère le porte

monnaie

On a des

indicateurs

partagés

sur le budget

Bon, on a bradé

le forfait,

mais on va se

gaver sur

les avenants

Multi équipe : comment faites-vous ?

On a un chef de projet

pour coordonner les

dates d’accostage

Boards synchronisés,

visibles et connus de

tousScrum of Scrum

COPIL hebdo

Qui travaille sur quoi dans l’équipe ?

Vendu au client :

Equipe d’experts

spécialisés

En vrai :

Des stagiaires

Nous cherchons à ce que tout le

mon monde soit capable de

travailler sur n’importe quelle

partie

Nous avons défini

un market of skill

afin de suivre

efficacement

les compétences

de chacun

Au moins 2

personnes

connaissent

les parties

critiques

de l’appli

23- Partage de connaissance ?

Chacun sa gueule, chacun

son code

Pair programming

Pair, dojo,...

Nous sommes

des artisans !

Revue de code

Template

Les réponses

1- Quelle forme ont mes specs ?

Définition de besoin

SFD

STD

Les specs ne sont pas sèches…

mais on est agile ou merde ? On y

va.

US validés par tous avec

cas d’acceptance

En tant que …

je dois …

afin de …

Comment se décide si une tâche est DONE ?

Le développeur a

commité dans le contrôle

de source

Ça marche en PROD

On a rempli touts les

conditions du Definition

of DONE

C’est testé en RECETTE

Les tests : Quelle est votre démarche ?

Test en recette avec

cahier de recette

TDDTester, c’est douter

TU / TI

pour valider les devs

Qui teste le produit ?

L’équipe d’intégration

Tests croisés, puis Product Owner

Des utilisateurs finaux,

ou mieux, un singe

Normalement, c’est bon. En tout

cas, sur mon poste, ça marche.

5- Qui décide du changement de périmètre ?

La Direction

C’était pas dans les specs. On va

faire un avenant.Consensus

Le Product Owner

Quand finit le projet ?

C’est en prod. Bon, la date

est dépassée de 6 mois, et

c’est buggé. Mais bon.

La date et la vélocité sont

immuables. Donc la seule variable

d’ajustement est le scope.

Donc quand le client a ce qu’il faut. Quand j’ai

démissionné

Jamais

car il y a

toujours

de

nouvelles idées

A quel moment voit-on le client final ?

Pas besoin, on a la MOA

On a un représentant à notre

disposition en permanenceParticipe à toutes

les phases du projet

Oh bah s’il a

envie de passer,

il peut, hein…

Who’s the boss ?

Chef de projet

(ou son chef)

(ou le chef de son chef)

Celui qui a les sous /

mon commercial

Pas de chef

Et pourtant

ça marche

Scrum Master

Comment mesurer l’état d’avancement ?

Sur Project, c’est marqué

qu’on est à 43,08%

Burndown chart

du Product BacklogNombre de Feature

en Prod

Il nous reste

15 points

sur ce sprint

10- Quels sont mes KPI ?

Surveillance de la

productivité/JH,

et du pourcentage réalisé,

du TJM

Indicateurs de maturité agile :

Quantité d’US dans le Product

Backlog

Nb d’anomalie par US

Vélocité

Pilotage global

Projet

Business Value

Qualité

Business

Contrôle de la

velocité

de l’équipe

Qui s’occupe du déploiement en recette ?

Je sais pas, moi je livre

un doc de déploiement

sur le réseau

Une machine Un Mexicain

N’importe qui

dans l’équipe

Qui attribue les tâches ?

Le chef d’équipe

Je prends ce qui me plait Je prends la

plus prioritaire

en fonction

des conditions

Le PO

Qui fait l’estimation des tâches ?

Celui qui crie le plus fort

pendant le Planning

Poker

C’est celui qui développe

décide. Ou le CP. Ca

dépend.

Consensus

de l’équipe

L’équipe propose

et le chef valide

A quel moment sont rédigés mes tests ?

En recette après la

reception du DEV

Avant pendant et après

Les tests sont en constante

évolution avec le produit

Pendant la rédaction

des US

Démarche ATDD

TDD

pendant le DEV

15- Qui écrit les specs ?

La MOA

Le mail et les post-its, c’est des

specs, non…?

Toute l’équipe

concoit l’US

et

ses cas

d’acceptance

Le PO

avec relecture

Amélioration continue ?

Dès qu’il y a

un problème,

Il faut le résoudre

pour

fluidifier la chaîne

Nous n’avons pas

de temps

à perdre

dans des

réunions inutiles

Il suffit que l’équipe soit

moins feignante

Rétro régulière

(et parfois, il en sort quelque chose

d’intéressant)

Avez-vous un suivi des actions mises en place ?

On a trace tous nos

problemes dans le Wiki

On fait un post-mortem en fin de

projet. Et on flagelle les coupables.

Affichage

et

suivi des actions

mises en place

en continu

Quelles actions ?

Qui décide de l’architecture logicielle ?

L’architecte

Consensus archi, décideurs et devs Démarche

innovante

de co-création

FDD / DDD

L’équipe

Comment gère-t-on les deadlines ?

“Tu fais quoi samedi ?”

Arrêtez de faire des tests, on n’a

plus de temps à gaspiller !

Deadline ?

On est

en flux continu,

mec !

On déscope

des sujets

en fonction

de notre vélocité

20- Comment est géré le budget ?

Je sais pas, faudrait

regarder sur le contrat

Le PO gère le porte

monnaie

On a des

indicateurs

partagés

sur le budget

Bon, on a bradé

le forfait,

mais on va se

gaver sur

les avenants

Multi équipe : comment faites-vous ?

On a un chef de projet

pour coordonner les

dates d’accostage

Boards synchronisés,

visibles et connus de

tousScrum of Scrum

COPIL hebdo

Qui travaille sur quoi dans l’équipe ?

Vendu au client :

Equipe d’experts

spécialisés

En vrai :

Des stagiaires

Nous cherchons à ce que tout le

mon monde soit capable de

travailler sur n’importe quelle

partie

Nous avons défini

un market of skill

afin de suivre

efficacement

les compétences

de chacun

Au moins 2

personnes

connaissent

les parties

critiques

de l’appli

23- Partage de connaissance ?

Chacun sa gueule, chacun

son code

Pair programming

Pair, dojo,...

Nous sommes

des artisans !

Revue de code

Template

Qui êtes-vous ?

Le roi du Waterfall

33%

• Prédit tout

• Prévoit tout

• Aime bien les abaques

• Connait son pourcentage

d’avancement au centième de

pourcent près

• … mais sait qu’il est faux

• Changer, c’est renoncer

Scrum Loser

• Applique les principes

• … sans comprendre les

valeurs

• Pense bien faire

• Scrum Master = chef de

projet, command and control

• Pas de specs, pas de docs, on

est agile, mec

• Tester, c’est douter (et en

plus, c’est cher)

• Ne s’améliore pas

44%

Artiste Scrum et XP

• Comprend les valeurs de Scrum et

d’XP

• Aime bien le changement

• Croit en la supériorité du Scrum

partout

• Cherche à s’améliorer en

permanence

• Aucun obstacle ne lui résiste

• Cycles courts

• Le changement, c’est cool

• Echouer, c’est apprendre

65%

Grand Maître agile

• Au dela de l’itération… le flux

• S’adapte à l’existant

• Multilingue

• Sait améliorer sans tout casser

• Anti-gaspillage

• Brise les intermédiaires

• Regarde devant et derrière

• Pense qu’on peut tout découper

en éléments de même taille

• Pas de temps mort

• Devops

86%

Template

Merci

A

bientôt