Scrum crash course #1

Introduction

Cela fait quelques temps que j’entends parler des méthodes agiles. Au niveau professionnel, j’utilise depuis maintenant plus de 10 ans la méthodologie de gestion de projet HERMES. Méthode qui présente de nombreux avantages mais aussi des faiblesses. Celles-ci sont largement renforcées par la machine administrative, lourde et truffée de grosses procédures à laquelle je suis confronté quotidiennement.

Je suis convaincu depuis quelques années que les méthodes agiles m’apporteraient une réelle souplesse, que ce soit dans la réalisation d’un projet ou dans mon rôle de gestionnaire d’équipe.

Le récent entretien avec J.-C. Grosjean décrivant l’intérêt d’allier démarche ergonomique et agilité a renforcé ma curiosité. À tel point que j’ai fait le choix de découvrir une des méthodes agiles les plus populaires : Scrum.

Jim Highsmith décrit l’agilité comme la capacité :

  • à favoriser le changement
  • à s’adapter au mieux à un environnement turbulent

Mais attention, favoriser le changement ne veut pas dire faire n’importe quoi et changer d’orientation sans arrêt.

Méthodes agiles ?

L’objectif des méthodes agiles est tout à fait noble : offrir une meilleure plus-value aux utilisateurs (et clients) tout en attachant une importance à la satisfaction des équipes projets.

Pour la petite histoire, le terme agile est apparu en 2001 avec le manifeste agile (texte rédigé par 17 experts reconnus pour leurs apports respectifs au développement d’applications informatiques sous la forme de plusieurs méthodes).

Quatre grandes valeurs en découlent :

  • les personnes (et leurs interactions) sont plus importantes que les processus et les outils
  • un logiciel qui fonctionne prime sur de la documentation
  • la collaboration est plus importante que le suivi d’un contrat
  • la réponse au changement passe avant le suivi d’un plan

Ces quatres grandes valeurs se traduisent par des principes concrets :

  • satisfaire le client en livrant tôt et régulièrement des logiciels utiles
  • accepter les changements même tard dans le développement
  • livrer fréquemment une application qui fonctionne
  • établir une collaboration régulière entre clients et développeurs
  • construire le projet avec des personnes motivées (en leur fournissant environnement et support et en leur faisant confiance) ;
  • favoriser les conversation de visu
  • mesurer la progression avec le logiciel qui fonctionne
  • instaurer un rythme de travail durable
  • rechercher une qualité conceptuelle et technique
  • rendre l’équipe autonome dans son organisation
  • à intervalles réguliers, réfléchir aux moyens de devenir plus efficace

Scrum se compose :

  • d’itérations très courtes
  • de séquences strictes
  • d’un rythme régulier

Scrum

Une des méthodes agiles les plus populaires se prénomme Scrum.

melee-scrum

Le mot anglais Scrum signifie « mêlée » en rugby. L’équipe projet est envisagée selon la métaphore sportive. Les joueurs portent ensemble le ballon vers un but précis : l’essai (la réalisation du produit).

Approche itérative et incrémentale

Scrum est une approche itérative et incrémentale. Itérative dans le sens où les différents sprints sont répétés sur la base d’un mode opératoire identique. Incrémentale dans le sens où chaque sprint permet de livrer un incrément du produit qui sera enrichi au fur et à mesure des sprints.

Backlog du produit

Toutes les fonctionnalités à développer sont classées par priorité et conservées dans ce que l’on appelle le backlog du produit. Celui-ci est placé sous la responsabilité du product owner.

Une histoire de sprints

Scrum se base sur une série d’itérations que l’on appelle des sprints et qui produisent une release (une version). Le contenu d’un sprint est défini par l’équipe et le product owner en fonction des priorités du backlog. Une fois les travaux de développement choisis, l’équipe s’engage à les réaliser pendant la période du sprint (entre deux semaines et un mois).

Pendant les sprints, des checkpoints sur le déroulement des tâches sont réalisés au gré des mêlées quotidiennes de l’équipe. Ces étapes permettent notamment au ScrumMaster (le garant du respect de Scrum) de procéder à des ajustements si nécessaires.

À la fin de chaque sprint, l’équipe met à disposition une version partielle du produit qui fonctionne : un incrément. Ce produit sera enrichi de manière incrémentale. La fin du sprint permet également d’évaluer l’incrément et d’ajuster le backlog du produit pour les prochains sprints.

Pour résumé : un ensemble d’incréments, chacun produit par un sprint donnera au bout d’un moment lieu à une release.

cycle-scrum

Scrum est différent d’un cycle de développement classique

Généralement le cycle de développement d’un produit est composé de phases et de jalons. Chaque phase est guidée par une activité clé (en général : analyse, spécification, développement, test), réalisée l’une après l’autre. Les jalons permettent de valider les travaux d’une phase « X » afin de passer à une phase « Y ».

Première originalité de Scrum : on y distingue une seule phase (le sprint), qui regroupe toutes les activités du projet (analyse, spécification, développement, test) et qui se répète successivement plusieurs fois (à chaque sprint) jusqu’à la livraison de la release.

Seconde originalité de Scrum : le contenu et les objectifs de chaque phase (sprint) ne sont pas pré-déterminés mais définis par les membres de l’équipe.

Avec Scrum, les jalons intermédiaires (mineurs) et finaux (majeurs) existent toujours :

  • le jalon intermédiaire est la validation du résultat d’un sprint
  • le jalon final intervient pour valider la production d’une release

Durée des releases

Généralement, il est conseillé de tabler une release sur trois mois avec quatre à six sprints de deux à trois semaines

Des sprints pour une release

Vous l’avez compris, la série de sprints donne lieu – lorsque l’équipe estime que l’incrément obtenu est suffisant pour faire l’objet d’une version présentable aux utilisateurs – à une release. Sa durée est définie en collaboration entre l’équipe et le product owner.

Il n’y a pas de chevauchement entre les sprints. Le nouveau démarre immédiatement après le précédent. L’équipe doit se tenir à la date de fin fixée en début de sprint. Même si l’objectif intermédiaire fixé n’est pas atteint, alors on livre en l’état l’incrément du produit, sans rallonger la durée du sprint.

Conclusion

Scrum casse la logique des cycles de développement classiques (finalisation de chaque activité à 100% avant de passer à la suivante). Cette méthode propose un cadre nettement plus flexible et pragmatique en acceptant que le produit évolue dans le temps. Cela nous offre de belles perspectives que je décortiquerai plus en détails dans de prochains articles.