Correction d'article

Dans un billet précédent, je commentais un article du JDNet sur Scrum. Voici la version améliorée...

L'auteur de l'article m'avait suggéré dans un commentaire sur ce billet de proposer des améliorations. C'est ce que j'ai fait. Mais comme il ne se manifeste pas et que l'article n'a pas été modifié sur le site du JDNet, je vous livre ma version améliorée, paragraphe par paragraphe.

Xavier Borderie vient de me signaler (16 février) qu'il a repris la quasi-totalité de ma réécriture et que la nouvelle version est en ligne.

Voilà ce que je lui ai proposé, paragraphe par paragraphe. L'article commençait par :

Scrum tire son nom du terme anglais "mêlée", au Rugby, afin de s'approprier la force d'impact caractéristique de ces petites formations (qui peuvent impliquer jusqu'à quatre tonnes de pression), et comparer la méthode qu'il désigne à cette technique de reprise de phase de jeu après une infraction. Conçue en 1993 et formalisée en 1995, cette méthode de développement (ou de gestion de projet) est souvent utilisée conjointement à la démarche XP.

Je propose : Scrum est un terme anglais qui signifie "mêlée" au rugby. Le nom a été choisi pour l'analogie que constituent les réunions quotidiennes de Scrum avec la mêlée, cette technique de reprise du jeu après une faute qui remet une équipe de rugby sur de bons rails par un effort collectif. Conçue en 1993 et formalisée en 1995, en plein essor actuellement, cette méthode de développement (orientée gestion de projet) inclut souvent des pratiques venant de XP.

Ensuite,

L'idée de Scrum est de supposer que rien n'est clairement défini au début du projet : les spécifications ne sont pas terminées ou pas encore comprises, des outils ou technologies inconnues entre en jeu, ... De fait, selon les besoins pour maîtriser avant tout ce que doit être le projet, Scrum ne suit pas un processus linéaire, et un membre de l'équipe peut devoir changer d'activité en cours de route.

Je propose : L'idée à la base de Scrum est de tenir compte de la réalité de la plupart des projets pour lesquels il n'est pas possible de tout définir au début du projet : les spécifications seront modifiées et précisées, des outils ou technologies inconnues entreront en jeu, les plans seront mis à jour ... De fait, pour s'adapter aux changements qui ne manqueront pas d'arriver, Scrum ne suit pas un processus prédictif et les travaux à faire sont ajustés régulièrement au cours du projet, notamment à la fin de chaque itération, appelée Sprint.

Scrum implique donc des horaires et délais flexibles, de petites équipes (6 ou 7 membres), de fréquentes mises au point et une intense collaboration entre les différentes personnes impliquées - des caractéristiques ici encore proches de la mêlée. Le "gestionnaire" est nommé ScrumMaster, est a à charge de faciliter le processus et son implémentation. L'équipe définit les détails, et le ScrumMaster se charge de les faire respecter.

Scrum implique une intense collaboration entre les différentes personnes impliquées -des caractéristiques ici encore proches de la mêlée. Le directeur de produit (product owner) est le représentant des clients et utilisateurs, il définit les priorités pour la réalisation. Le "gestionnaire" est nommé ScrumMaster, il a pour charge de faciliter l'application de Scrum par l'équipe. L'équipe s'engage pour la réalisation de fonctionnalités et le ScrumMaster la motive pour y arriver.

Il continuait :

Le processus Scrum repose sur trois journaux ou "backlog" : * backlog de produit : une liste des fonctionnalités générales pour le produit, définie par le client ou le chef de projet, * backlog de release : tirée du backlog de produit, une liste de fonctionnalités d'une version intermédiaire, définie par l'équipe, * backlog de sprint : le processus se décompose en série de "sprints". Ce backlog recense les items du sprint en cours, ou du prochain, indiqué en nombre d'heures.

Le processus Scrum repose sur deux journaux ou "backlog" :

  • backlog de produit : une liste des fonctionnalités pour le produit, définie par le directeur de produit,
  • backlog de sprint : ce backlog recense les tâches du sprint en cours.

Un projet utilisant Scrum est divisé en périodes d'activité de quatre semaines au plus, chaque période étant nommée Sprint. Chaque Sprint doit présenter des réunions quotidiennes de moins de 30 minutes permettant au ScrumMaster de connaître le travail accompli par chacun depuis la dernière réunion, les obstacles rencontrés, et le travail prévu d'ici la prochaine réunion - rien de plus.

Un projet utilisant Scrum a son cycle de vie composé de Sprints successifs. Un Sprint dure au plus quatre semaines. Pendant un Sprint des réunions quotidiennes de moins de 15 minutes (appelées Scrum) permettent à toute l'équipe de faire le point sur le travail accompli par chacun depuis la dernière réunion, les obstacles rencontrés, et le travail prévu d'ici la prochaine réunion -rien de plus.

Un Sprint se décompose en quatre activités qui s'enchaînent : développer (écrire le code, le tester, le documenter), boucler (préparer le code à être évalué et intégré), vérifier (constater le travail accompli face aux prévisions), ajuster (modifier les requis ou backlogs). Chaque Sprint se termine par une revue de Sprint, pour évoluer le travail accompli et restant, et modifier au besoin les différents backlogs.

Pendant un Sprint l'équipe développe un produit partiel. Elle déroule toutes les activités nécessaires pour cela : analyser, concevoir, développer, tester, documenter, intégrer. Chaque Sprint se termine par une revue de Sprint, pour que le directeur de produit évalue, au cours d'une démonstration, le produit partiel obtenu et modifie au besoin le backlog de produit.

Et pour conclure, l'article disait :

En définitive, Scrum introduit une méthode pour suivre un processus itératif non linéaire très proche des besoins et réalités des petites équipes.

En définitive, Scrum introduit des règles pour suivre un processus itératif empirique permettant d'obtenir un produit très proche de besoins qui évoluent et ainsi de maximiser la valeur pour les clients.