Scrum

Cette page présente un cadre général d’organisation d’une équipe pour réaliser un projet. Elle reprend les concepts des méthodes agiles et en particulier de Scrum. Il ne s’agit pas d’un cours sur Agile/Scrum mais d’éléments pratiques pour une mise en place rapide (et adaptable) en particulier pour des projets d’étudiants. Les termes classiques de Scrum sont en gras.

Scrum donne une place très importante à l’équipe et aux relations humaines. Le support de la méthode peut être très simple (tableau, post-it, …). Des logiciels existent mais ne doivent être qu’un support. Les concepts ci-dessous sont illustrés avec deux solutions le système de gestion de projets Redmine ou le site de gestion de tâche Trello (https://trello.com).

L’équipe (team) est pluridisciplinaire, il n’y a pas de spécialiste a priori d’une tâche. Les fonctions peuvent changer en fonction de circonstances. Chacun va là où il y a du travail et doit avoir en tête qu’il peut évoluer, se former.

Dans l’équipe, choisissez un membre qui a en plus le rôle de product owner. C’est lui qui représente le “client” pendant les discussions internes. En général, il argumente pour augmenter la priorité des éléments qui ont le plus de valeurs et qui sont les moins coûteux à produire.

Choisissez aussi un Scrum master (différent du Product Owner) son rôle est d’aider l’équipe à appliquer Scrum. Ce n’est pas un chef de projet, mais plus un moteur ou un formateur à l’utilisation des méthodes modernes de travail. Il facilite les échanges entre les membres de l’équipe et avec l’extérieur.

L’organisation du projet est guidée par la satisfaction du besoin client, on va donc commencer par créer la liste priorisée (ordonnée) de tout ce qui va être fait par l’équipe pour répondre au besoin client. Cette liste, composée d’éléments, est appelée le product backlog. Elle évolue tout au long de la vie du projet.

Un élément du product backlog peut, par exemple, être :

  • Un scénario (user story) qui présente en quelques mots une fonctionnalité (En tant que <qui>, je veux <quoi> [afin de <pourquoi>]). Les détails nécessaires : Cas d’utilisation, illustration, … peuvent être déposés sur un wiki.
    • Par exemple : “En tant qu’utilisateur je veux pouvoir ajouter un item dans mon panier afin de faire une commande”. Cf. le diagramme de Use Case et le scénario nominal sur le wiki.
  • Un objectif majeur d’ingénierie.
    • Par exemple: Porter le moteur de calcul sous Android, installer le serveur d’application,…
  • Un travail exploratoire ou théorique (se former, écrire un algorithme, un modèle, rédaction de documentation, …).
    • Par exemple: Etudier les arbres lexicographiques pour proposer une amélioration de l’accès aux données.

Il faut noter que la conception, la modélisation, ou la documentation utilisateur ne disparaissent pas, il s’agit simplement d’éléments comme les autres qui doivent être priorisés et dont le niveau de détail peut être ajusté au contexte.

Il est aussi préférable de gérer les défauts avec un logiciel dédié (“bugtracker”) plutôt que dans le product backlog. Ce logiciel peut être lié au logiciel utilisé comme support pour Scrum (les défaut apparaissent alors comme des tâches).

Le Product Backlog doit être DEEP: Detailed appropriately, Estimated, Emergent, and Prioritized.

On ne détaille que ce qui est important, une estimation de l’effort nécessaire pour réaliser les éléments doit être donnée, le product backlog est revu régulièrement (emergent) et les éléments sont priorisés.

Il n’y a pas qu’un seul produit livrable (release) final. On peut aussi prévoir des release intermédiaires, idéalement à l’issue de chaque itération. Il est possible de maintenir un release backlog qui contient les éléments qui ne seront pas traitées avant la prochaine release.

Le travail est organisé en itérations courtes appelées sprint. Ils ont une date de début et une date de fin fixées et se suivent strictement.

Chaque sprint commence par une réunion de planification (Sprint Planning Meeting) (entre 1h et 2h).

On définit tout d’abord le but du sprint, qui correspond idéalement à un produit intermédiaire démontrable (pas nécessairement une IHM).

Ensuite, on définit comment ce but va être atteint :

  • on estime le temps effectif que l’équipe va consacrer au projet (Par exemple 6h/jour/membre).
  • on choisit les éléments du product backlog à traiter (principalement parmi ceux de plus forte priorité). Le nombre dépend du point précédent.
  • on décompose ces éléments en tâches (d’une durée maximale de 3 ou 4h).

Durant un sprint, tous les jours commencent par une réunion de suivi et de coordination de 15 à 20 minutes, le daily scrum. Elle concerne uniquement le sprint courant. Elle se passe devant un tableau pour faire le point. Cette réunion peut être assez systématique, chacun dit brièvement : (i) ce qu’il a fait depuis la réunion précédente, (ii) ce qu’il va faire jusqu’à la prochaine et (iii) ce qui est bloquant. On peut alors ajuster (modifier/supprimer ou ajouter) les tâches du sprint courant. Seuls ces points sont abordés. Les discussions techniques ou détaillées ont lieu après et uniquement avec les membres concernés.

Une fois le sprint démarré, les changements éventuels dans le product backlog ne modifient pas le sprint. Les tâches peuvent être modifiée ou affinées. En cas de problème grave, le sprint peut être interrompu et un nouveau sprint est planifié.

A la fin du sprint, l’équipe tient une revue de sprint (Sprint review) pour faire le bilan de ce qui s’est passé pendant le sprint et en tirer des améliorations pour le suivant. Principalement, on liste les éléments du carnet de produit qui ont été réalisé et on les valide. Il peut y avoir une démonstration du logiciel produit. Le sprint review s’appuie sur les trois pilier de scrum : la transparence, l’inspection et l’adaptation. En fonction de ce bilan, le product backlog et le release backlog peuvent être mis à jour.

Le sprint review ne doit pas prendre plus d’une à deux heures. Sa préparation ne doit pas demander plus de 30mn, sinon c’est qu’il y a un problème dans le fonctionnement au jour le jour.

Le projet se déroule en quatre étapes principales :

  • Planning. Définition des attentes et des contraintes : première version d’un product backlog suffisant pour une première itération.
  • Staging. Première itération pour raffiner le product backlog.
  • Development. Succession de sprint pour réaliser le projet. A la fin, le product backlog doit être vide. Des release intermédiaires sont souhaitables.
  • Release. Le produit final est livré, les éléments pour l’utilisation et la formation (documentation) sont prêts. Le release backlog peut être utilisé comme point de départ pour le product backlog de la prochaine release.

Les deux premières étapes qui précèdent le développement proprement dit sont très importantes. C’est là que vous allez constituer l’équipe, définir sa vision du projet, définir le backlog initial, élaborer une première planification, penser aux priorités et aux risques. Il ne faut pas partir trop vite au risque de faire un faux départ. Bien Penser au but, à l’objectif principal, aux besoins utilisateurs et aux fonctionnalités (acteurs/rôles/story), aux contraintes imposées par le développement. Les fonctionnalités vont vous permettre de constituer des domaines fonctionnels indépendants, à partir desquels vous créerez votre backlog.

Chaque sprint se déroule de la façon suivante :

  • Avant chaque sprint, on organise un Sprint Planning Meeting de 1 à 2h.
  • Chaque jour, on commence par un Daily Scrum de 15 à 20mn.
  • A la fin de chaque sprint, on organise un Sprint Review.

Pour les projets de master 1 :

  • Les sprints seront en moyenne de 5 jours (en fonction des réunions avec le jury).
  • Avant les réunions hebdomadaires vous organiserez un sprint review et un sprint planning meeting.
  • Lors de la réunion hebdomadaire avec le jury (20mn) :
    • vous ferez un bilan rapide du sprint précédent,
    • vous présenterez le sprint suivant (éléments et tâches)
    • vous résumerez les changements sur les products backlog et release backlog.
  • A l’issue de la réunion avec le jury vous finirez le sprint planning meeting
    • en mettant à jour la liste des élements dans les product et release backlogs
    • en défissant précisément les tâches (chacune de 3 à 4 heures maximum) du prochain sprint.

Dans l’idéal à l’issue de chaque sprint on devrait obtenir un, Incrément du Produit Potentiellement Livrable. c’est-à-dire une logiciel fonctionnel, testé et documenté. Pour pouvoir atteindre cet objectif, l’équipe doit utilisé un environnement d’intégration continue. (Ce n’est pas demandé pour le projets de master 1).

Cette page a été rédigée principalement en utilisant :

—- dataentry page —- type : Howto theme_tags : Gestion de projet, Agile technologie_tags : Scrum, Redmine, Backlogs


~~DISCUSSION~~