Auteur/autrice : Gilbert MOISIO

Scrum est un framework, ou cadre de travail, qui inclut la notion d’itérations courtes (sprints) pour réaliser un produit morceau par morceau. Ces itérations sont rythmées par des réunions appelées « cérémonies », comme les daily scrum qui sont des réunions quotidiennes que je conserve en ScrumBan, les revues de sprint qui se produisent à la fin d’une itération ou encore les rétrospectives pour améliorer la façon de travailler de l’équipe.

Dans la méthodologie Scrum, trois rôles sont proposés et je les conserve en ScrumBan : le Product owner (PO), le Scrum master (SM) et l’équipe de réalisation (Team). Le PO est identifié en tant que détenteur du besoin. Dans le domaine des infrastructures, il est fréquent de proposer que ce rôle appartienne au client. Le SM est le garant de la méthodologie, mais il est aussi celui qui va débloquer les situations. Il facilite et provoque les événements Scrum lorsqu’il le faut (daily meeting, revues de sprint, planification…). Enfin, l’équipe de réalisation est là pour implémenter le produit selon les User Stories présentes dans le backlog de sprint.

Dans le modèle Waterfall, le cycle de développement et de livraison d’un système suit une liste d’étapes en ordre séquentiel. Cette façon de faire à l’avantage de fournir un plan projet définit dès le départ, ce qui résulte la plupart du temps en une gestion budgétaire précise. Chaque composante du système est développée séquentiellement, et menée à terme avant qu’une autre fonctionnalité ne soit programmée. C’est un modèle qui a été systématiquement utilisé, mais qui présente plusieurs lacunes importantes, dont il conviendrait de s’affranchir lorsque le contexte client le permet.

En général, l’analyse des besoins du client se fait conjointement avec lui, sur une période qui pourra varier considérablement et s’étendre parfois jusqu’à plusieurs semaines, voire plusieurs mois. Or, ce modèle Waterfall ne tient pas compte de la variable temps. Une fonctionnalité mise en place, testée puis livrée dans le système, arrivera à destination plusieurs semaines ou mois après qu’elle ait été définie et pensée, pour répondre à un besoin au moment où l’analyse a été faite. Cependant, la réalité du client peut changer rapidement. Ce modèle d’implémentation ne tient pas compte des besoins changeants du client, de sa réalité d’affaire qui est en mouvement au fil du temps, et des technologies émergentes. Le résultat est que la fonctionnalité est bien livrée selon les spécifications initialement documentées, mais ne correspond plus nécessairement aux besoins réels du client.