SCRUM est un cadre de développemen de projets. SCRUM n’est pas forcément lié à l’informatique bien que ce soit l’endroit où on en entends le plus parler.

Le but de SCRUM est un cadre de travail simple, léger et flexible. Qui est l’une des raisons pour laquelle il est souvnet associé à AGILE.

Le but de SCRUM est de donner un maximum de transparence et de clarté sur le projet à tous ses membres, ainsi que de permettre une évolution constante du produit et de la productivité et motivation de l’équipe.

Lire la documentation officielle de Scrum

Le framework Scrum pure est en vérité assez simple, vous pouvez le trouver dans plusieurs langues sur le site officiel ScrumGuides.org :

Création du projet scrum initial

  1. Définir l’équipe scrum qui doit être composée de moins de 10 personnes et doit inclure 1 product owner (représentant du client), 1 scrum master (soutien organisationnel à l’équipe) et des développeur·euse·s qui vont créer le produit. Il est possible, en particulier dans de très petites équipes qu’une personne ait plusieurs de ces rôles.
  2. Définition d’un objectif clair au projet, voir Les objectifs SMART
  3. Découper l’objectif en plus petits éléments (par exemple “Analyse”, “Design initial”, “Authentification”, etc) L’ensemble de ces petits éléments est appellé le product backlog et est dérivé de la roadmap du produit et de ses exigences. Voir User Stories.
  4. Création d’une charte de qualité appellée definition of done, qui indique les critères requis pour qu’une tâche soit considérée comme réellement terminée. Par exemple cela peut inclure, les tests unitaires, la qualité du code, etc.
  5. Définition de la durée d’un “sprint” unité de temps de travail. Cette durée peut varier entre quelques heures (hackathon par exemple) et 1 mois (gros projet). Pour des projets scolaires il est recommandé de choisir une durée d’une semaine car les deadlines sont souvent tendues.

Déroulement d’un sprint

  1. Définition de l’objectif d’un sprint. Par exemple, “Structure de base de l’application”
  2. Sélectionner les éléments du product backlog à intégrer dans le sprint pour atteindre l’objectif.
  3. Décrire les tâches pour chaque éléments du sprint et définir quelles persones y seront associées.
  4. Développement du sprint pendant toute la durée définie. Et tous les jours durant le développement une mini réunion de quelques minutes pour que l’équipe s’accorde sur quoi elle travaille, les éventuels problèmes, etc. Cette réunion est appellée le daily scrum.
  5. Une fois le temps du sprint écoulé, on présente le travail respectant la charte de qualité (definition of done) fournit au product owner et on ajuste éventuellement le product backlog en conséquence. C’est le sprint review.
  6. Ensuite, sans le product owner, l’équipe fait une réunion pour discuter de comment le développement s’est passé, ce qui était bien, ce qui pourrait être améliorer dans l’organisation, etc. C’est le sprint retrospective.
  7. On recommence à l’étape 1 d’un sprint, et on continue comme ceci jusqu’à ce que l’objectif du projet soit rempli.

Ne pas tomber dans le "dark scrum"

Martin Fowler et Ron Jeffries, deux des 17 auteurs du manifeste agile, ont exprimé des dérives importantes du modèle SCRUM auquel il faut faire attention.

Scrum est une méthodologie générale, mais elle n’est pas toujours agile et peut vite être détournée en quelque chose qui n’est ni agile, ni scrum, c’est le dark scrum.

  • Scrum transformé en méthode de micro-management, le boss est toujours présent à toutes les réunions journalières et empèche l’équipe de s’organiser.
  • La definition of done n’est pas suffisante ou appropriée et devrait intégrer des principes d’Extreme Programming (XP) tel que l’intégration continue, le développement guidé par les tests, le refactoring, etc. Cela permet d’assurer que le code reste maintenable et robuste.