Bien démarrer un projet SCRUM

Comment bien démarrer un projet en mode agile comme SCRUM ? L’idée de ce billet n’est pas de détailler toutes ces tâches mais de les présenter dans un cas concret.

Les rôles de chacun dans un projet SCRUM

Pour rappel Scrum définit seulement 3 rôles :

  • Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet. C’est la personne qui la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.
  • L’Equipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système.
  • Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive.

La séparation MOA et MOE

Je rajoute un quatrième rôle que je nommerai l’exécutif, qui représente l’organisation commanditaire, ou autrement dit la MOA, et les intérêts des parties prenantes du projet (utilisateurs, fournisseurs, direction,…). Il en en étroite liaison avec le produit owner qui représente la MOE.  C’est l’exécutif qui a le pouvoir d’arrêter ou non le projet. Le product owner doit alors demander l’autorisation de continuer le projet après chaque phase. Il a donc le contrôle du projet.

A noter que ce rôle n’est pas préconisée par les méthodologies agiles qui ne font de séparation entre MOA et MOE, mais par mon expérience elle est utile pour les projets avec une séparation « contractuelle » entre ces deux entités. Il est cependant recommandé de s’efforcer au maximum de décloisonner ces deux entités qui doivent collaborer étroitement tout au long du projet. En particulier les utilisateurs et opérateurs doivent interagir avec les équipes de développement tout au long du projet (voir DevOps)

La phase d’élaboration

Cette phase permet de s’assurer que l’on dispose de toutes les autorités nécessaires pour initialiser le projet, que l’on dispose d’informations suffisantes pour définir le périmètre du projet, que les modalités de livraisons ont été convenus, et que des candidats ont été retenus pour constituer l’équipe projet.

  • Nommer un exécutif et un product owner : c’est une condition préalable pour s’assurer que le projet est justifié par l’entreprise
  • Recueillir les retours d’expérience passés: il  est possible que d’autres projets menés par entreprise aient permis de tirer des leçons concernant les faiblesses ou les points forts des processus, techniques ou outils utilisés; les personnes ou les équipes justifiant cette expérience préalable doivent être consultées
  • Composer et nommer l’équipe projet: composer l’équipe projet, SCRUM master et développeurs, estimer le temps et l’effort pour chacun de ces roles
  • Préparer les objectifs et enjeux du projet: l’exécutif expose au product owner les informations qu’il dispose (objectifs, raisons, normes, contrat, exigences qualité, critères d’acception, délais, cout, risques …)
  • Définir l’approche projet: le product owner évalue et valide avec l’exécutif la manière dont le projet doit être abordé avant d’être planifié (solution de livraison possibles, confirmer les objectifs, périmètres, contraintes, tolérances, interfaces ..), l’approche agile par SCRUM doit être également validé par l’exécutif.
  • Planifier la phase initialisation: la phase d’initialisation (premier incrément SCRUM) est planifié.
  • valider la phase avec l’exécutif: l’exécutif doit autoriser le démarrage de la phase d’initiation; sans cette autorisation le projets est arrêté.

La phase d’initialisation

La phase initialisation (Sprint Init) a pour but de doter le projet de fondations suffisantes pour mieux comprendre le travail à faire. Voici une liste de tâches pouvant être intégrée dans la phase d’initialisation.

  • Préparer la stratégie du projet: le product owner définit les objectifs, la procédure, les outils ainsi que le rôle et la responsabilité de chacun pour les domaines suivants: risques, qualité, communication, gestion des incidents …
  • Valider les objectifs et les enjeux du projet: le Product Owner présente et valide avec toute l’équipe les objectifs et les enjeux du projet : il doit partager les points qui ont vu dans la phase précédente avec l’exécutif comme par exemple: concurrence, Dead Line et contraintes « imposées » par le client …
  • Découper le projet en livraison et priorisation: le Product Owner présente sa vision du contenu des livraisons du projet, objectifs, jalon et utilisateurs et définit les priorités;
  • Découper les livraisons en Sprint et priorisation: le Product Owner présente un découpage « grossier » du contenu des livraisons avec la priorisation des Sprints.
  • Rappeler des principes de Scrum: un rappel collective à l’équipe et le Product Owner par le Scrum Master ne fait jamais de mal
  • Mettre en place de l’architecture technique: l’environnement technique doit être définit et prêt dés ce premier sprint, avec au minimum un environnements de développement et d’intégration opérationnel (installé et configuré), règles de développement, gestion du code source avec les règles de fonctionnement, le processus de sauvegarde et idéalement un processus d’intégration et de test automatisé
  • Mettre en place le management visuel: l’équipe prépare les  indicateurs visuels du projet: scrum board (user stories, product backlogs, sprint backlogs, burn down chart, identification du sprint courant et contenu) que l’on peut compléter par une partie : problèmes techniques ou organisationnel et actions à faire suite au sprint précédent .
  • Réunion de planification collective: Le product Owner présente les exigences fonctionnels et non fonctionnels des livraisons et l’équipe chiffre avec la technique de Planning Poker et ordonne en  taches. Le découpage permet de valider ce qu’il va y avoir dans chaque Sprint. le Product Backlog est alors constitué et affiché par ordre de priorité.
  • Réunion de planification du Sprint 1: la durée de la réunion doit être de 2h par semaine de Sprint (soit 4h pour un sprint de 2 semaines). On doit définir:
    • le quoi: le produit owner revoit avec l’équipe de développement l’objectif du sprint et le Product Backlog. L’équipe vérifie les estimations, confirme qu’elles sont exactes et sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint
    • le comment: L’équipe fait ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Les tâches de développement sont centralisées dans le Sprint Backlog
  • valider la phase avec l’exécutif: le product owner demande à l’exécutif d’autoriser le démarrage de la phase suivante; sans cette autorisation le projets est arrêté.

Sprint 1

  • Daily Scrum Meeting: Le point quotidien de l’équipe avec le Product Owner; le  tableau du reste à faire Burndown Chart est remis à jour. Les obstacles rencontrés, doivent être priorisées par le product owner, qui doit les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive.
  • Développement et tests: l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog;la tache doit être validée, testée et documentée avant être considéré comme terminée. Le pair programmation peut être mis en place pour veiller à la qualité du code d’une exigence donnée.
  • Réunion de planification du Sprint 2: Dans la dernière semaine du Sprint, l’équipe, le Scrum Master et le Product Owner préparent le Sprint suivant, comme pour le pour Sprint 1
  • Fin du développement du Sprint 1: les taches doivent être développées, testées et disponibles sur l’environnement d’intégration
  • Revu de Sprint: Prévoir une heure par semaine de sprint (soit 2h pour un sprint de deux semaines) ; L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la version et adapter au besoin le plan et le Product Backlog. L’équipe de développement présente au Product Owner idéalement accompagné d’utilisateurs, les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe, il accepte ou refuse les fonctionnalités présentées.
  • Rétrospective de Sprint: Prévoir une durée de 45 min par semaine de Sprint (soit 1h30 pour un Sprint de 2 semaines) : l’équipe et le Scrum master  analyse les obstacles du Sprint 1 et les axes d’amélioration.
  • Mise en place physique du tableau des obstacles: C’est la tâche qui permet de ne pas oublier de mettre à jour la liste des obstacles.
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective): Cette mise à jour dépend des retours de la rétrospective.
  • Calculer la vélocité du Sprint 1: Combien de temps l’équipe a-t-elle passé à développer (et tester) des fonctionnalités pour la release ?

Sprint 2

  • Daily Scrum Meeting
  • Développement et tests
  • Réunion de planification du Sprint 3
  • Fin du développement du Sprint 2
  • Revu de Sprint
  • Rétrospective de Sprint et comparaison avec les rétrospectives précédentes
  • Mise en place physique du tableau des obstacles
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective)
  • Calcul de la vélocité du Sprint 2 et comparaison avec le Sprint 1

Il y a exactement les mêmes tâches entre le Sprint 1 et le Sprint 2 : Seul le contenu change, les résultats du Sprint 1 vont influer sur le Sprint 2 et ainsi de suite jusqu’au dernier Sprint.

A noter que le dernier Sprint correspond à la confirmation que la livraison du produit a été accepté  et que le projet peut être clos pour être passé en maintenance.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s