Exemple d'une application développée avec SCRUM

Au lancement du projet l’ensemble des fonctionnalités à couvrir est listé et priorisé. Cette liste constitue le Backlog du produit.

Au début de chaque Sprint, une séance de planification du Sprint a lieu, réunissant le propriétaire du produit, le chef de projet et l’équipe de développement. L’objectif de cette séance est de lister les fonctionnalités sur lesquelles l’équipe devra avancer. Cette liste, extraite du Backlog du produit, constitue le Backlog du Sprint.

Cette liste est mise en place en fonction de la capacité de production de l’équipe (nombre de personnes, vacances et absences prévues etc…), des choix du propriétaire de produit et des éventuelles contraintes techniques.

A l’issue de cette séance, chacune des fonctionnalités sélectionnées est attribuée à un membre de l’équipe qui devient alors responsable de l’objectif qu’il est ensuite chargé de décomposer en sous-tâches.

Pendant la durée du Sprint, les fonctionnalités retenues sont développées.

Chaque jour, l’équipe de développement commence par une séance appelée Mêlée quotidienne (Daily Scrum) au cours de laquelle chacun des membres de l’équipe va exposer en quelques minutes les activités sur lesquelles il a travaillé la veille, les difficultés qu’il a rencontrées, les activités qu’il aura pendant la journée.

L’objectif de cette séance est de permettre à l’ensemble de l’équipe d’être informé de l’avancement global.

La fin du Sprint est marquée par la livraison des fonctionnalités développées. Ce livrable est alors mis à disposition du propriétaire du produit et des spécialistes fonctionnels qui pourront tester cette version et signaler les problèmes rencontrés à l’équipe de développement.

Une séance de revue de Sprint est également mise en place. Cette séance permet de faire un bilan des activités de l’équipe: quelles fonctionnalités ont été traitées, quelles sont celles qui n’ont pas pu être abordées, quels sont les retours des spécialistes fonctionnels etc…

Au cours de ce bilan, la charge de travail effective de l’équipe est confrontée à la charge prévue et chaque développeur doit alors expliquer les raisons des éventuels écarts.

Cette revue de sprint est également l’opportunité pour l’équipe de recueillir les premières impressions du propriétaire du produit lors d’une démonstration des fonctionnalités implémentées pendant le Sprint.

Cette méthodologie, basée sur la communication, offre les avantages:

• de (re)mettre le propriétaire du produit au cœur du projet
• de responsabiliser chacun des membres de l’équipe de développement
• de permettre des réajustements sur la priorisation des fonctionnalités
• de détecter au plus tôt les éventuelles dérives et d’agir en conséquence

La mise en place de cette méthodologie dans le cadre du développement de myTeacher 3 nous aura permis de tirer chacun de ces avantages et de respecter les plannings initiaux.

Egalement, les dérives de charges ont été très rapidement identifiées et les priorités redéfinies afin de pouvoir respecter nos plannings.

La mise en œuvre de cette méthodologie aura également été l’occasion de mettre en place un certain nombre de nouveaux outils au sein de l’équipe de développement afin de gérer ce projet:

JIRA/GreenHopper pour la gestion de projet ainsi la gestion des tâches et des objectifs, Subversion pour la gestion des versions.

Après ce projet de développement, nous avons l’intention de continuer à utiliser cette méthode et les outils mis en œuvre. Nous devrons toutefois réorienter le concept global afin de le rendre mieux adapté à notre contexte d’éditeur.

Le concept d’intégration continue sera également abordé dans les mois qui viennent afin d’améliorer encore les processus de développement.

Actualité rédigée par Patrick, responsable de l’équipe de développement au CeRFI