CONTEXTE

Je vous propose aujourd’hui de découvrir Scrum. La méthodologie agile la plus populaire dans l’univers du développement informatique. On parle beaucoup de Scrum, des miracles réels ou supposés que cette méthodologie permet d’accomplir. Voyons donc de quoi il en retourne.

Avant d’entrer dans le vif du sujet, commençons par une courte introduction sur la genèse des méthodologies agiles.

I. LA GENÈSE DES MÉTHODOLOGIES AGILES.

Au commencement, il y avait le cycle en V. Une approche développée en raison du manque de réactivité du modèle en cascade. Puis, en réponse  aux insuffisances du cycle en V,  les méthodologies agiles se développèrent. Commençons donc par le commencement (ou presque).

LE CYCLE EN V

Il s’agit d’une amélioration du modèle en cascade. En effet, cette méthodologie de gestion de projet permet d’éviter les retours aux étapes de conception précédentes en cas d’anomalies constatées lors des différentes phases de tests. Ce que, bien sûr, ne permet pas le modèle en cascade.

Par exemple, lorsqu’une erreur est constatée en phase de recette, on va se référer aux documents de spécifications (des besoins utilisateurs) et au cahier des charges fournis dans la première phase d’analyse des besoins (cf. graphique ci-dessous).

Cette démarche permet de cadrer très précisément le besoin, l’architecture et la conception (interface graphique, fonctionnalités, workflow et règles de gestion.) afin d’éviter les déconvenues en fin de projet. Vous l’aurez compris, on spécifie beaucoup et très précisément dans ce modèle. En effet, chacune des parties impliquées dans le projet intervient à un moment bien déterminé et fournit une documentation détaillée et spécifique à la phase en question. Cette manière de fonctionner permet ainsi de connaître très précisément les livrables d’un projet informatique, son budget et ses délais. C’est un avantage indéniable. Cette méthodologie a, malgré tout,  elle aussi montré ses limites face à un environnement technologique devenu complexe et extrêmement mouvant.

Du point de vue des logiciels livrés, les principales limites étant :

  • Des spécifications initiales figées, irréalisables ou non adaptées aux évolutions des besoins
  • Des fonctionnalités ajoutées « à la volée » qui s’avèrent coûteuses et parfois inutiles. Ce à quoi il faut ajouter une renégociation contractuelle qui peut être très douloureuse (temps consacré à l’alignement, à la redéfinition du périmètre, à la renégociation et aux avenants au contrat)
  • Des produits qui sont livrées trop tard (le besoin a changé entre temps ou il est plus complexe que ce qui avait été anticipé).

D’un point de vue organisationnel :

  • Un manque de reconnaissance du travail des équipes de réalisation
  • Une communication parfois inefficace (les individus se « cachent » derrière la documentation)
  • La démobilisation et le découragement des équipes lorsque finalement le produit fini ne correspond pas aux attentes .

L’illustration ci-dessous montre bien les risques des projets en cycle en V où l’on ne se rend compte que trop tard que le produit réalisé ne correspondra pas aux attentes.

Bien que possédant de nombreuses limites, le cycle en V peut encore s’avérer utile pour certaines typologies de projet. Toutefois, nous ne nous y attarderons pas aujourd’hui.

Vinrent ensuite les méthodologies agiles…

II. LES MÉTHODOLOGIES AGILES

Maintenant que nous avons planté le décor de ce qui les a précédé, parlons donc des méthodologies agiles. Les méthodologies « agiles » existent depuis les années 80 mais c’est le manifeste agile (publié en 2001) qui les a démocratisées. Ce manifeste est apparu dans le domaine du développement logiciel. « Il s’agit d’une réaction radicale à la tendance dominante [de l’époque], pour promouvoir des processus plus légers. » (Scrum – Le guide pratique de la méthode agile la plus populaire, Auteur : Claude Aubry).

Cette opposition radicale est illustrée par les 4 valeurs de l’agilité définies dans le manifeste. Il est dit la chose suivante :

  • Les gens et leurs interactions sont plus importants que les processus et les outils
  • Un logiciel qui fonctionne prime sur de la documentation exhaustive
  • La collaboration avec les clients est préférable à la négociation contractuelle
  • La réponse au changement passe avant le suivi d’un plan.

Je vous vois déjà froncer les sourcils… Oui, ces valeurs sont pleines de bon sens et oui, aucune organisation ne peut décemment promouvoir l’inverse. Et pourtant, on peut constater le contraire dans de nombreuses organisations où les process, la hiérarchie ou la mesure de la performance aboutissent à créer des comportements aux antipodes de ces valeurs.

Revenons-en au manifeste. En plus de ces 4 valeurs, 12 principes ont aussi été énoncés. S’il ne faut en retenir qu’un, le premier est indéniablement celui que vous devez garder en tête.

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

On notera que dans ce premier principe, on aborde clairement la nécessité de livrer rapidement mais aussi et surtout de livrer des fonctionnalités à valeur. Ce dernier point est souvent négligé au profit de la rapidité et de la modification à outrance des objectifs.  Malheureusement, l’agilité souffre parfois de sa popularité en étant comprise dans son acception la plus littérale.

Le manifeste a donc défini des valeurs et des principes qui se veulent universels. Il est à noter que les mises en pratique peuvent varier selon les projets, les contextes et les équipes. C’est pour cela que l’on peut parler de pratiques agiles. Chacune des pratiques agiles, prise de manière unitaire, apporte de la valeur aux équipes qui les emploient. Mais c’est bien lorsque ces pratiques sont intégrées dans une approche agile spécifique (ou méthodologie)  qu’elles se renforcent les unes les autres.

Si je devais résumer l’apport des méthodologies agiles par opposition au développement en cycle en V, je le ferais comme sur le schéma ci-dessous.

Explications : Faisons un parallèle simple et en dehors du développement logiciel; un moyen de locomotion. Avec le développement agile, on cherche bien à livrer rapidement une fonctionnalité (se déplacer plus rapidement) qui apporte de la valeur (le skateboard par opposition à la roue qui n’apporte pas de valeur). Les feedbacks obtenus grâce à cette livraison vont permettre d’itérer et de proposer une nouvelle version du produit. Ici, la trotinette est plus stable et plus facile à manier. C’est bien les feedbacks qui nous permettent d’arriver à la voiture à la fin. Le résultat est le même, c’est vrai! Peut-être même que le développement agile n’aura pas permis de créer le produit « voiture » plus rapidement. Néanmoins, on apporte de la valeur à l’utilisateur plus rapidement. On a aussi préempté une place de choix dans l’esprit du client/utilisateur. A n’en pas douter, l’utilisateur sera probablement plus tenté d’acheter la voiture chez nous que chez le concurrent du cycle en V car il nous connaît. Bref, cette comparaison a de nombreuses limites mais vous comprenez l’idée. Regardez donc les premières versions de produit des GAFAM et des plus gros acteurs du digital. Vous serez convaincus! 

Avant de conclure cette partie, il est important de noter la différence entre méthodologies agiles et agilité. En effet, bien que reposant sur des fondements théoriques similaires, on ne parle pas de la même chose quand on parle d’agilité et de méthodologies agiles. L’agilité fait référence à  de nouvelles méthodes de management, de culture d’entreprise et de valeurs. Vous constaterez probablement dans vos entités qu’une transformation agile dans les méthodologies appelle souvent un changement de culture.

Natacha Soldat, une de nos coachs agile, précise :

  • Agilité  = Ensemble de valeurs et de principes (décrit plus haut)

  • Méthodes agiles : Ensemble des pratiques et outils

  • Être agile = Appliquer les valeurs et principes fondamentaux de l’agilité, ce qui implique un fort changement de culture d’entreprise et d’état d’esprit

  • Faire de l’agilité = Appliquer les frameworks et outils sans se préoccuper des changements culturels

Maintenant que vous maîtrisez un peu mieux les fondements des méthodologies agiles, passons donc à Scrum.

III. SCRUM EN BREF 

Vous avez peut-être l’impression que nous nous sommes égarés. Rassurez-vous, il n’en est rien! Il est important (je pense) de comprendre la genèse et la philosophie des méthodologies agiles si l’on veut bien comprendre Scrum. C’est même bien plus important que d’en connaître tout le jargon.

Si je dois résumer Scrum, je le ferais de la manière suivante. Scrum est un framework simple et facile à mettre en place qui définit des rôles, des cérémonies (ou cérémonial) et des éléments structurants additionnels (ou artefacts) afin de mettre en œuvre une démarche agile de développement logiciel.

CE QU’IL FAUT RETENIR :

Les rôles

L’équipe scrum est  pluri-disciplinaire et auto organisée. Elle est constituée du Product Owner, du Scrum Master et des développeurs (comprendre « équipe de développement » i.e. dev, architecte, QA …). Toutes les compétences nécessaires aux développements du produit doivent être présentes dans l’équipe.

  • Le Product Owner (PO) est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement.
  • Le Scrum Master s’assure de la bonne application/organisation de Scrum
  • Les Développeurs sont en charge de la réalisation du produit
  • Les parties prenantes sont toutes les personnes intéressées d’une façon ou d’une autre aux résultats du produit développé par l’équipe. Il est important de connaître toutes les parties prenantes pour que le projet se déroule au mieux.

NB : Il peut y avoir des parties prenantes  dites « expertes », elles  participent au développement du produit mais ne font pas que ça. Elles peuvent être des sources de blocages. Il faut donc anticiper et lister les obstacles. Cette liste doit être visible de tous. 

Le sprint

Un sprint est un cycle de développement court (2/3 semaines) durant lequel l’équipe travaille sur des fonctionnalités pour aboutir à un incrément du produit. On est donc dans une approche itérative et incrémentale. L’enjeu pour une équipe Scrum est bien d’aboutir à un produit partiel qui fonctionne (i.e. qui est utilisable et donc livrable en production !). Le produit s’enrichit ainsi à chaque itération.

Le contenu et l’objectif d’un sprint sont définis par l’équipe en tenant compte des priorités définies par le PO et des capacités de l’équipe. Les développeurs s’engagent à terminer l’ensemble des tâches/stories qui leurs sont assignées pour un sprint. C’est pour cela qu’il leur incombe de déterminer la charge de travail qu’ils peuvent supporter. Une release (livraison en production) est constituée d’une série d’itérations (de sprints). Les releases interviennent généralement au bout de 5/6 sprints. Selon le type de logiciel, les outils de développement et la maturité de l’organisation, ce rythme de livraison peut être beaucoup plus soutenu. Certaines équipes « poussent en production » tous les jours.

 Lancement d’un projet – le sprint 0

Le sprint 0 n’est pas un sprint comme les autres. Il peut être considéré comme un kick-off pour l’équipe. Au démarrage d’un nouveau cycle, le sprint zéro permet à l’équipe de s’organiser et de lever les incertitudes techniques et fonctionnelles.

Particularités :

  • Il n’a pas de durée fixe
  • Il se termine lorsque l’équipe est constituée, les règles de vies de l’équipe définies, le socle technique établi (i.e. les risques techniques sont limités), les besoins logistiques pourvus et enfin que le backlog du sprint 1 est prêt.

Les artefacts

  • Le backlog produit :  est une liste priorisée des fonctionnalités attendues d’un produit ainsi que tout le travail à effectuer pour réaliser ce produit.
  • Le backlog de sprint : est une liste priorisée des user stories à réaliser durant un sprint afin d’aboutir à un incrément du produit.
  • Le plan de release : est une mise en avant des sprints à venir ainsi que leur contenu nécessaire pour déployer une version de produit.
  • La liste des obstacles : est une liste qui met en avant les éléments bloquant la réalisation du travail de l’équipe.
  • Burnup/ Burndown : le « BurnUp » est un graphique qui montre la tendance de ce qui est fini sur le sprint en cours. Le « BurnDown » est un graphique qui montre la tendance de ce qu’il reste à faire sur le sprint en cours.
  • Incrément de sprint : Il s’agit du résultat du sprint qui vient donc incrémenter le produit.

IV. LE PRODUIT FINI DANS SCRUM : FONCTIONNALITÉS ET PRIORISATION

FONCTIONNALITÉS ET USER STORY

Scrum sert à  développer des produits en déployant rapidement des fonctionnalités.  Ces fonctionnalités sont collectées et  priorisées dans un backlog (le backlog produit). Le Product Owner est responsable du backlog produit et de sa priorisation.

Pour décrire une fonctionnalité, on utilise les user stories (histoires utilisateur) pour décrire le produit et l’impact que ce dernier doit avoir. Il existe 5 types d’items de backlog :

  • Les user stories fonctionnelles
  • Les bugs
  • Les user stories techniques
  • Les user stories de remboursement de dette technique
  • Le « spike » technique (des travaux d’étude pour dé-risquer un élément du backlog )

NB : La question de la valeur doit toujours piloter l’intégration et la priorisation d’une user story. Quelle qu’elle soit (fonctionnelle, technique ou de remboursement de dette technique)! Par ailleurs, la qualité est au coeur de la démarche. Sans qualité il n’y a pas de valeur. On peut donc dire que dans un monde idéal les stories de remboursement ne devraient pas exister !

Comment décide t-on des user stories qui peuvent entrer dans le backlog produit ?  Une user story pour rentrer dans le backlog produit doit  :

  • Être indépendante … par rapport aux autres users stories
  • Être négociable … et négociée, i.e. discutée avec l’équipe
  • Apporter de la valeur à l’équipe, à l’organisation, à l’utilisateur final
  • Être estimable
  • Être suffisamment petite
  • Être testable

 

 

 

 

C’est le modèle INVEST, il en existe de nombreux autre. Enfin une user story peut se rédiger de la manière suivante.

  • En tant que … à QUI ?
  • Je souhaite que … à QUOI ?
  • Afin de …  IMPACT

Il existe de nombreuses méthodes pour bien rédiger une user story. Ce qu’il faut garder à l’esprit c’est bien qu’une user story est avant tout une histoire qui vise à décrire un morceau de fonctionnalité pour un utilisateur donné. Elle doit pouvoir être développée en un sprint. Sa valeur et son impact doivent être identifiés et explicités.

Abordons maintenant la question de la priorisation de ses user stories dans un backlog.

LA PRIORISATION

La priorisation est un exercice périlleux qui peut, vu de l’extérieur, sembler opaque. Il ne l’est pas, bien au contraire! En effet, le Product Owner en communiquant avec l’équipe de réalisation et les différentes parties prenantes va pouvoir identifier les stories les plus prioritaires en fonction d’un certain nombre de critères.

On peut donner en exemple :

  • La valeur ajoutée
  • Le coût de développement
  • La connaissance apportée à l’équipe
  • La quantité de risques éliminés
  • La dépendance

Une fois la priorisation faite, il convient « d’affiner » la user story. Ce travail réalisé par l’équipe permet de lever les risques autour de l’U.S. afin de la faire « rentrer » dans le backlog de sprint. Ce travail d’affinage peut « challenger » la première priorisation. Pour savoir à quel moment arrêter l’affinage, la notion de prêt (ready) est souvent utilisée.

Une user story ne peut rentrer dans le backlog de sprint que lorsqu’elle est prête. Concrètement, une définition de « prêt » peut se faire de la manière suivante :

  • La story est définie – Elle a été écrite et explicitée
  • La story est démontrable – Une fois réalisée, les développeurs pourront la « montrer »
  • La story est désirable – Cette story apporte de la valeur, elle est donc désirable
  • La story est « dérisquée » – Il n’existe plus d’incertitude technique ou fonctionnelle pour la réaliser
  • La story est décomposée – L’ensemble des tâches nécessaires pour la réalisation sont identifiées
  • La story est discutée – Le Product Owner a exposé la story à l’équipe. Elle est connue. Elle a été discutée en affinage.

 

Récapitulatif

Pour terminer sur Scrum, il convient de parler des cérémonies (aussi appelées « cérémonial »). Il y en a 6. Ces cérémonies rythment la vie de l’équipe au cours des sprints.

Pour la dernière partie de cet article, je vous en propose un rapide descriptif.

V. LES CÉRÉMONIES DE SCRUM

  • La revue dure 40-45 minutes environ. Les participants sont l’équipe et les parties prenantes. Elle a lieu en fin de sprint et elle permet, d’une part de montrer la stabilité de l’équipe aux parties prenantes et d’autre part de faire des prévisions sur le futur. On montre l’incrément du produit pour obtenir du feedback et l’on détermine si l’objectif de sprint est atteint.
  • La planification de sprint  n’a pas de durée spécifique. Les participants sont l’équipe et éventuellement les parties prenantes expertes. Elle a lieu en début de sprint. Elle a pour but de définir les stories sur lesquelles vont travailler les développeurs lors du sprint. Le Product Owner fixe aussi un objectif de sprint à atteindre.
  • Le daily scrum ne doit pas excéder 15 minutes. Les participants sont l’équipe. Il a lieu tous les jours. Au cours du sprint, les daily servent de points de contrôle du bon déroulement du sprintCes réunions doivent permettre à l’équipe d’effectuer d’éventuels ajustements pour assurer le succès du sprint. Par exemple, il est possible de sortir une story qui mettrait en danger l’exécution du sprint. L’équipe de développement inspecte son avancement vers l’objectif de sprint, planifie en conséquence les travaux de réalisation sur les prochaines 24h et identifie les obstacles qui la ralentissent.
  • La rétrospective dure environ une heure. Les participants sont l’équipe. Il est conseillé de ne pas impliquer les managers afin que l’équipe se sente en confiance.  L’équipe revient sur les éléments marquants du sprint … ce qui a marché et ce qui n’a pas marché afin d’identifier les points d’améliorations pour le prochain sprint.
  • Le meeting d’affinage n’a pas de durée spécifique. Il permet à l’équipe de préparer le backlog.
  • Le poker planning ne doit pas durer plus de 30 minutes. Les participants sont l’équipe et éventuellement les parties prenantes expertes.  Elle permet d’estimer des stories. Ce n’est pas une cérémonie Scrum à proprement parler mais de nombreuses équipes l’utilisent.

Récapitulatif

Scrum en image : 

 

Voilà ! Vous savez tout ce qu’il y a à savoir sur Scrum. Des fondements méthodologiques de ce framework à sa réalité opérationnelle. Scrum est un framework très utilisé car il es simple d’application et le nombre de règles est limité. Ces éléments permettent à une équipe de rapidement se structurer en mode agile. Néanmoins, se structurer en mode agile ce n’est pas être agile. Vous l’aurez compris, il ne s’agit donc pas uniquement d’appliquer les règles mais bien de comprendre le pourquoi du comment pour être capable de faire les bons arbitrages et déterminer le modèle qui fonctionne le mieux pour votre équipe et votre organisation !