Les clés de l’Agilité Valeur ChangementCollaboration QualitéCadence

BAckLogs

UtiLisAteUrs

scrUm mAster

scrUm teAmProdUct ownerresponsabilités :

responsabilités :Expriment leurs besoins et leurs priorités auprès de leur représentant : le Product Owner.Clarifient les besoins à l’occasion d’ateliers avec l’équipe notamment en exprimant des cas de test.Effectuent régulièrement une recette intermédiaire du produit.Procèdent à la recette finale des releases prêtes à être mises en production.

Garantit l’application du processus Scrum.Assure l’efficacité de l’équipe et élimine les obstacles.Facilite la coopération entre tous les acteurs du projet.Protège l’équipe des interférences extérieures.Aide l’équipe à s’améliorer et à travailler de façon autonome.

Réalise le produit final attendu par le Product Owner.Garantit la qualité en continu du produit.Démontre des fonctionnalités complètes, exécutables et testées au Product Owner.S’auto-organise pour atteindre les objectifs partagés.Communique le reste à faire et l’avancement du produit. Améliore le processus en continu.

Porte et communique la vision du produit.Identifie les fonctionnalités attendues.Etablit les priorités.Etablit le plan de release (mise en production).Veille au retour sur investissement.S’assure que l’équipe dispose des informations nécessaires.Définit les critères d’acceptation du produit.Valide avec les utilisateurs le produit livré.

Vision synthétique du produit pour les utilisateurs : liste ordonnée des fonctionnalités et exigences attendues.Priorités fixées en fonction de la valeur ajoutée métier (P1, P2, P3...).Estimation des fonctionnalités en points de complexité relative (story points).Découpage suffisament fin pour que chaque fonctionnalité soit réalisée (« done ») et acceptée (« done done »)en une itération.Visibilité de l’avancement du projet : suivi des exigences réalisées et restant à faire.

Le Product Owner énonce les objectifs, fixe les priorités et précise les besoins.L’équipe élabore l'itération backlog.L’équipe et le Product Owner ajustent les objectifs pour pouvoir s’engager.

La vélocité est le nombre de points de complexité livrés au cours d’une itération.Cet indicateur peut être remplacé par la productivité qui est le ratio { nombre de points livrés } / { nombre de jours travaillés }, pour obtenir une mesure indépendante de la capacité de l’équipe qui peut fluctuer (congés / absences, entrées / sorties).

Chaque itération enrichit le contenu fonctionnel et la valeur du produit livré.Mieux vaut livrer quelques nouveautés, plutôt que d’introduire des anomalies.Pour être livrée, chaque fonctionnalité doit être terminée, conformément à des critères pré-établis (Definition of Done).

Le produit livré à chaque itération est soumis au feed-back des utilisateurs.La recette intermédiaire en fin d’itération garantit l’alignement continu entre les équipes métier et informatique.Les anomalies sont corrigées au plus tôt, idéalement durant l'itération suivante.La recette est outillée pour automatiser des tests de non-régression.Si possible, la recette intermédiaire inclut des tests de performance.

Le système est découpé en fonctionnalités de petite taille (user stories), réalisables au cours d’une itération.Chaque fonctionnalité est spécifiée par des exemples qui peuvent ensuite être traduits en autant de cas de tests automatisables (Behavior Driven Development).La non régression du système est assurée en continu par les cas de test fonctionnels automatisés.

De façon récurrente, le développeur code un test unitaire explicitant le besoin, puis code le plus simplement possible la fonctionnalité correspondante.Lorsque le test passe, le développeur remanie le code pour faciliter les futures évolutions et accroître sa qualité.

Elle consiste à régulièrement et automatiquement : construire, empaqueter et déployer le produit, le soumettre à différents tests techniques et fonctionnels, en mesurer la qualité intrinsèque et en générer la documentation afférente.Les anomalies sont corrigées au plus tôt pour assurer la qualité en continu.

La prédictibilité est le ratio { nombre de points livrés d’une itération } / { nombre de points prévus lors de l'iteration planning }.Cet indicateur permet de maîtriser la capacité de l’équipe à tenir ce qu’elle prévoit de faire.

La qualité est mesurée par des indicateurs majeurs : taux d’anomalies par rapport aux tests exécutés, taux de couverture du code par les tests unitaires automatisés, taux de couverture du produit par les tests fonctionnels automatisés.

Ces indicateurs doivent respecter des seuils établis dans le cadre de la stratégie de test, en fonction des enjeux et de la nature du produit développé.

A heure et lieu fixes, l’équipe se synchronise et s’engage sur ses tâches.Chaque membre de l’équipe dit ce qu’il a fait la veille, ce qu’il compte faire le jour même et énonce les points de blocage (à traiter hors du daily scrum).

L’équipe fait une démonstration des nouvelles fonctionnalités au Product Owner qui réagit, accepte ou refuse la livraison, peut demander des modifications et compléter les besoins.

Les membres de l’équipe identifient les bonnes pratiques à proroger, celles à améliorer, ainsi que quelques actions à mettre en oeuvre durant la prochaine itération pour améliorer le processus (et pas le produit).

Liste des tâches à réaliser pour livrer les fonctionnalités issues du Product Backlog et constituant le périmetre de l’itération.Estimation des tâches en heures.Reste à faire estimé quotidiennement.Etat de la tâche possible : non démarrée, en cours, terminée, reportée.Visibilité de l’avancement d’une itération : suivi des tâches terminées et restant à faire.

Les utilisateurs doivent être impliqués dès le début du projet.Régulièrement, ils donnent du feedback à la Scrum Team.

Sa présence permanente est fortement recommandée.

Sa taille doit être limitée à 8 ou 9 personnes dédiées au projet.Il est préférable que l’équipe soit co-localisée sur un plateau projet.

Il doit être mandaté pour décider et arbitrer les besoins.Il peut s’agir d’une équipe pluridisciplinaire (métier, technique, expérience utilisateur).

responsabilités :

responsabilités :

cérémonies indicAteUrs AgiLes PiLotAge PAr Les tests& intégrAtion continUe

PrinciPes et vALeUrs

LivrAison et recetteProdUct BAckLog PLAnning d’itérAtion

dAiLy scrUm

revUe d’itérAtion

rétrosPective

2h en début d’itération

15 min quotidiennement

1h en fin d’itération

1h en fin d’itération

véLocité

AccePtAnce test driven deveLoPment

Communication et FeedbackCourage et TransparenceConfiance et RespectSimplicité et HumilitéAmélioration continue

LivrAison incrémentALe

recette intermédiAire

test driven deveLoPment

intégrAtion continUe

PrédictiBiLité

QUALité

itérAtion BAckLog

1 2

3

9

10

5

6

11

11

8

7

5

5

4

AfficheCleAgilite-20140225.indd 1 28/02/14 11:34