Index

Notes
MOOC Gérez votre projet avec une équipe Scrum

Cours OpenClassrooms

#01 Les fondements du développement Agile

Le développement agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu.

C’est à partir de ces réalités pratiques, et non pas sur la base d’une théorie globale ou structurante, que l’agilité progresse vers les sphères les plus hautes de l’organisation et participe à la création de ce que l’on peut appeler une culture agile de l’organisation.

Manifeste du développement agile

Quatre valeurs :
  • les individus et leurs interactions plutôt que les processus et les outils ;
  • un logiciel fonctionnel plutôt qu’une documentation exhaustive ;
  • la collaboration avec les clients plutôt que la négociation contractuelle ;
  • l’adaptation au changement plutôt que l’exécution d’un plan.
Douze principes
  1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  2. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
  3. Livrez fréquemment un logiciel fonctionnel, dans des cycles de quelques semaines à quelques mois, avec une préférence pour les plus courts.
  4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  7. Un logiciel fonctionnel est la principale mesure de progression d’un projet.
  8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  9. Une attention continue à l’excellence technique et à un bon design.
  10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  11. Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  12. À intervalles réguliers, l’équipe réfléchit aux moyens possibles de devenir plus efficace. Puis elle s’adapte et modifie son fonctionnement en conséquence.

#02 Définissez les rôles de l’équipe

1. Maîtrisez les piliers Scrum

Fondements du modèle Scrum

Transparence

Garantir que toutes les informations relatives à la bonne compréhension du projet sont bien communiquées aux membres de votre équipe et aux différentes parties prenantes.

  • un langage commun
  • un management visuel
  • une communication bienveillante et conviviale entre les acteurs
Inspection

Vérifier à intervalles réguliers que le projet respecte des limites acceptables et qu’il n’y a pas de déviation indésirable par rapport à la demande de votre client

Adaptation

Corriger les dérives constatées par des changements appropriés afin de mieux répondre aux objectifs de votre gestion de projet

Caractéristiques du modèle

Une approche empirique

L’inspection quotidienne de l’état du projet oriente les décisions.

Un cadre de travail holistique
Une méthode itérative

Découpage du projet en plusieurs cycles identiques ou itérations.
Approche graduelle du produit ou du service final afin de limiter les risques d’erreurs.

Un développement incrémental

La partie du projet réalisé doit être utilisable.
Livraisons régulières de fonctionnalités complètes.

Une pratique agile

Implication des clients et des utilisateurs dans la gestion de projet.
Réactivité face aux demandes.

2. Négociez avec le client

Le product owner

Le product owner ou propriétaire du produit est la personne qui va représenter le client ou le porteur du projet au sein de l’équipe Scrum. C’est un partenaire expérimentédisponible et diplomate.

Limites du client dans un processus agile

Si la participation du client est essentielle dans une méthode agile, ce dernier peut rencontrer plusieurs difficultés dans son implication :

  • manque de disponibilité
  • manque d’expérience
  • manque d’information

Le client est donc représenté par le product owner qui garantit ses intérêts.

Le product owner n’est pas votre supérieur hiérarchique mais fait partie intégrante de l’équipe. Partagez ensemble les enjeux, la vision et la valeur du projet. Représentez ensemble l’équipe vis-à-vis des parties prenantes.

Ses missions
  • expression des besoins avec l’équipe
  • priorisation des besoins pour l’équipe
  • validation des résultats de l’équipe

L’expression des besoins de votre projet se fait obligatoirement sous la forme de récits utilisateur (user stories).

La liste de l’ensemble des récits utilisateur constitue le carnet de produit (product backlog). Contrairement au cahier des charges,  c’est un document qui peut évoluer constamment au cours du projet.

  • Le product owner est l’unique responsable de l’actualisation du product backlog.
  • Le product owner priorise les user stories formulées dans le product backlog.
  • Le product owner prend des décisions structurantes à partir du product backlog.
  • Le product owner surveille le budget et le planning grâce au product backlog.
  • Le product owner participe à la transparence du projet avec le product backlog. 

3. Encadrez l’équipe de développement

Le rôle d’une équipe de développement

Ses membres sont autonomes et ont des compétences multiples et pluridisciplinaires.

  • L’équipe ne peut pas être multi-produits.
  • L’équipe détermine seule ses choix de solution.
  • L’équipe est indissociable et tous les membres sont considérés au même niveau.
  • L’équipe estime sa charge de travail et détermine sa capacité à réaliser une tâche.
  • L’équipe organise et réalise les tâches du projet en respectant le modèle Scrum.
  • L’équipe est responsable de la réussite du projet et de l’atteinte des objectifs.
  • L’équipe participe avec le product owner à toutes les cérémonies Scrum.

Ses outils

  • Le planning poker
    Estimation la complexité de chaque user story avec le product owner. Les estimations ne sont jamais définitives : elles dépendent toujours d’informations qui peuvent évoluer.
  • Le tableau kanban
    Organisation de la charge de travail à l’aide de cartes représentant les user stories réparties dans un tableau divisé en 3 colonnes : « à faire », « en cours », « terminé » (parfois compléter par une colonne « à valider »)
  • L’attribution des tâches
    Répartition des user stories sur la base du volontariat et de la discussion lors de vos réunions quotidiennes

4. Facilitez le travail de l’équipe Scrum

Le rôle d’un scrum master

Le scrum master est au service des acteurs du projet pour lesquelles il remplit une mission de facilitation. C’est un arbitre actif et positif.

  • Valorisez la participation des acteurs du projet (sans les freiner)
  • Assurez l’équilibre au sein de l’équipe (sans jeu d’influence)
  • Soignez vos présentations (sans superficialité)
  • Garantissez le respect des uns et des autres (sans autoritarisme)
  • Simplifiez la complexité des organisations (sans les vulgariser à l’extrême)
  • Accompagnez l’adoption du modèle Scrum par les salariés ou les adhérents
  • Planifiez la mise en œuvre progressive du modèle Scrum
  • Aidez toutes les parties prenantes à comprendre l’approche empirique du modèle Scrum
  • Provoquez des changements qui augmentent l’efficacité du modèle Scrum

5. Communiquez avec les parties prenantes

Les parties prenantes 

Les parties prenantes (« stakeholders » en anglais) sont des personnes en dehors de l’équipe Scrum qui ont des connexions plus ou moins fortes avec le projet.

  • Le sponsor impacté financièrement par la fabrication
  • L’utilisateur final concerné directement par les usages
  • Les experts et spécialistes qui épaulent l’équipe de développement dans le projet

L’environnement du modèle Scrum

Idéalement un espace commun et dédié pour l’équipe :

  • offrant des espaces d’affichage (storyboard, avancement, tableau kanban, etc.)
  • doté des outils de collaboration (tableau blanc, etc.)
  • permettant une communication directe
  • évitant les distractions

#03 Gérez les itérations de l’équipe

1. Préparez un sprint

Le sprint est l’unité de temps des itérations

Un sprint est la période au cours de laquelle une fonctionnalité complète du produit sera développée et incrémentée.
Sa durée, de 1 à 4 semaines, est fixée pour le temps long du projet.

Les sprints s’enchaînent sans temps mort.

Dans un contexte particulier et inattendu, seul le product owner peut prendre la décision de terminer un sprint.

5 règles durant les sprints :
  1. Votre équipe ne peut pas modifier l’objet du sprint.
  2. Votre équipe doit rester constante et régulière.
  3. Vous ne négociez jamais à la baisse la qualité du travail.
  4. Vous aidez l’équipe de développement à renégocier le nombre de tâches avec le product owner.
  5. Vous limitez en amont la complexité des solutions et donc les risques de dérives liés au sprint.

Le sprint pour le scrum master

La vélocité d’une équipe, est calculée en additionnant les story points des user stories terminées au cours d’une itération.

Le sprint d’échauffement

  • calcul de la vélocité de l’équipe
  • constitution de l’équipe
  • choix des solutions structurantes
  • installations des outils collaboratifs
  • mise en place de l’environnement de travail
  • prioritisation des user stories au sein du product backlog par le product owner

2. Évaluez un incrément

L’incrément correspond à une ou des fonctionnalités terminées et validées pendant les sprints.

Vos incréments s’ajoutent à une version partielle, mais potentiellement utilisable, du produit ou du service développé.

  • présenter un produit ou un service exploitable
  • livrer fréquemment votre client
  • intégrer les évaluations à vos sprints

3. Accompagnez la sprint planning

La sprint planning dans le modèle Scrum

La réunion de planification d’une itération (ou sprint planning) est un événement rituel du modèle Scrum qui concerne tous les acteurs de l’équipe.

Elle se divise en deux parties :

Le périmètre : Qu’est-ce qui peut être terminé au cours de ce sprint ?

Le product owner définit l’objectif de l’itération à partir de vos analyses et de vos évaluations du product backlog.

Le plan de l’itération : Comment sera effectué le travail choisi ?

L’équipe se demande comment atteindre l’objectif du sprint.
Vous décomposez le travail en journée (ou moins) afin de lister toutes les tâches des users stories candidates.

La sprint planning pour le scrum master

Anticipez la préparation de ce rituel en respectant :

  • La capacité de l’équipe (selon vélocité)
  • La priorisation du product backlog
  • Les conditions du secteur d’activité
  • L’état actuel du produit ou du service
  • L’impact technologique

4. Complétez le sprint backlog

Le sprint backlog dans le modèle Scrum

Le carnet de sprint ou sprint backlog décrit tous les enjeux de l’itération ; il décrit tout le périmètre de ce qui doit être produit au cours de celui-ci et permet de suivre le travail quotidiennement.

Visualisation via tableau kanban ou scrum board (user stories + actions définies par l’équipe de développement).

Utilisez vos réunions quotidiennes pour analyser les tâches qui n’avaient pas été détectées lors de la sprint planning.

Le sprint backlog pour le scrum master

Visualisation de la somme totale de travail restant dans le sprint backlog via burndown chart :

  • L’axe vertical représente la quantité de travail restant à effectuer (en story points).
  • L’axe horizontal correspond à la durée du sprint (en jours).

Aucune user story supplémentaire n’arrive en cours de sprint, seules les users stories retenues pendant la sprint planning seront développées.

5. Organisez la daily scrum

Les mêlées quotidiennes ou dalily scrums réunissent l’ensemble de l’équipe pendant 15 minutes maximum pour partager l’état d’avancement du sprint et signaler les obstacles rencontrés ››› maintenir une communication fluide.

  • Sur quoi ai-je travaillé hier ?
  • Sur quoi vais-je travailler aujourd’hui ?
  • Quelles sont les difficultés que je rencontre ? Et comment peut-on m’aider ?
Do & don’t
  • La daily scrum se tient tous les jours, de préférence à heure fixe pour générer une forme de rituel.
  • La daily scrum se fait debout pour encourager les participants à respecter la limite de temps.
  • La daily scrum est obligatoirement composée des membres qui développent le projet.
  • La daily scrum est l’occasion d’actualiser le tableau kanban et le burndow chart.
  • La daily Scrum n’est pas l’endroit pour résoudre les problèmes de l’équipe.

#04 Contrôlez le travail de l’équipe

1. Confirmez la maturité d’une user story

La préparation des user stories : définition de « prêt »

Le product backlog doit être correctement défini avant le début de votre gestion de projet.

  • collecte et l’étude des besoins du produit ou service.
  • définition d’un langage commun avec l’équipe.
  • anticipation de la maturité des demandes entrantes pour garantir que les user stories sont assez précises et matures pour candidater à un sprint

La formalisation de la définition de « prêt » (ou DoR, definition of ready) est une tâche du PO qui analyse les US selon ces critères :

  • garantie d’une expression claire des besoins et des tâches
  • vérification de la conformité des user stories aux objectifs du projet
  • explicitation des critères d’acceptation pour chaque user story
  • validation des compétences requises au sein de l’équipe Scrum
  • élimination les dépendances externes de votre gestion de projet

L’optimisation des user stories : grille INVEST

  • Indépendante
    capable de développer la fonctionnalité avant ou après n’importe quelle autre
  • Négociable
    Le PO rédige l’objectif fonctionnel de la user story, l’équipe discute ensuite des meilleures solutions pour y répondre
  • Verticale (Valuable)
    des fonctionnalités réellement utilesqui ajoutent de la valeur au produit
  • Évaluée (Estimable)
    vision précise de la complexité (souvent à l’aide de la formulation des critères d’acceptation)
  • Suffisamment petite (Small)
    Entre 1 et 5 US par sprint
  • Testable
    Les tests de l’intégration dans le produit sont définis en amont

2. Explicitez la conformité d’une user story

La finalisation des user stories : définition de « terminé »

La définition du mot « terminé » (DoD, Definition of Done) détermine les conditions de finalisation de toutes les activités d’un projet : le produit, la version, le sprint, la user story, l’incrément, la documentation, etc.

Voici un exemple pour l’incrément d’un produit informatique :

  • La fonctionnalité est vérifiée avec des tests unitaires.
  • La fonctionnalité est disponible pour acceptation.
  • La fonctionnalité est déployée dans un environnement d’essai.
  • La fonctionnalité est validée par l’équipe Scrum.
  • La fonctionnalité est accompagnée d’une note de version.
  • La fonctionnalité est opérationnelle pour le produit.
  • La fonctionnalité est présentée au client.

3. Présentez les livrables pendant la sprint review

La revue de sprint (ou sprint review) est un rituel Scrum durant lequel l’équipe évalue la complétion de ses objectifs (idéalement avec les parties prenantes).

Durée : 1 heure par semaine de sprint

  • présenter le US sélectionnées et les objectifs du sprint
  • faire la démonstration des fonctionnalités complètement terminées (pas d’état intermédiaire : soit la fonctionnalité est finie, soit elle ne l’est pas)
  • mettre à jour le product backlog en fonction de ce qui a déjà été réalisé (rôle du PO)
  • dresser un bilan du déroulement du sprint ainsi que des problèmes rencontrés
  • analyser les retours directs (feedbacks) pour évaluer la qualité et la pertinence du travail accompli
  • reviser le backlog pour la prochaine itération
Planification de vos livraison (ou story mapping)

Organisez les user stories selon les usages des utilisateurs et les activités principales du projet à développer (placer en haut les user stories indispensables).

Outils : Feature mapCarboard, Prezi, etc.

4. Améliorez votre gestion pendant la sprint retrospective

La rétrospective du sprint ne réunit que l’équipe Scrum (SM, PO, équipe de développement), elle vise à :

  • mettre en évidence ce qui a bien marché au cours du sprint et ce qui doit être amélioré
  • dresser un radar de satisfaction (pour chaque membre, axes usuels : « autonomie », « finalité », « maîtrise »)
  • établir un nouveau plan d’actions concrètes pour une meilleure pratique agile

5. Challengez votre équipe avec la product backlog grooming

Le raffinage ou toilettage du product backlog (product backlog grooming) est une véritable réunion placée entre la sprint retrospective et le prochain sprint planning.

  • Détectez les user stories qui n’ont plus aucun sens pour le projet.
  • Formulez et estimez les nouvelles user stories si des besoins apparaissent.
  • Réévaluez l’ordre de priorité des user stories dans le product backlog.
  • Corrigez les estimations en fonction de nouvelles informations.
  • Découpez les user stories qui pourraient candidater aux prochains sprints.

Vous évitez à l’équipe de se disperser lors de la préparation du projet. Ne prenez pas le risque de découper finement toutes les user stories avant le premier sprint. Orientez surtout votre product owner à maintenir un product backlog « juste à temps ». Si l’équipe n’est pas parvenue à développer une user story indispensable pendant le sprint précédent, vous pouvez aussi la planifier à nouveau (sans modifier son estimation). 

#05 Modèle Scrum complet

 Modèle Scrum
  • La sprint planning (2h pour un sprint d’une semaine) 
  • La daily scrum (15 minutes tous les matins)
  • La sprint review (1h pour un sprint d’une semaine)
  • La sprint retrospective (3h pour un sprint d’un mois)
  • La product backlog grooming (10% de la durée totale de votre projet)