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.
Dans ce modèle en cascade où une fonctionnalité ne peut pas être implémentée n’importe quand et dépend des fonctionnalités précédentes, il n’est pas possible de réaliser facilement des changements de stratégie. Entre le début et la fin du projet se déploie un processus d’apprentissage que C. Midler (Management des projets et transformation de l’entreprise, 1993, Christophe Midler) décrit comme une dynamique irréversible où l’on passe d’une situation où on ne sait rien mais où tout changement est possible, à une autre où, au contraire, le niveau de connaissance a atteint son maximum mais où toutes les marges de manœuvre ont été utilisées. C’est d’ailleurs la raison principale pour laquelle les équipes qui travaillent sur ces projets détestent autant les demandes de changements. Ce modèle Waterfall ne cultive pas le changement. Au contraire, il prône l’immobilisme. Le système n’est souvent pas utilisable par le client tant que tout (ou presque) n’est pas terminé à 100%.
Les méthodes Agile partent du principe que spécifier et planifier dans les détails l’intégralité d’un système avant de l’implémenter (approche prédictive) est contre-productif. Les méthodes Agile reposent sur 4 valeurs et 12 principes qu’il est facile de retrouver sur internet. Les méthodes Scrum, Kanban et ScrumBan sont, à mon avis, les trois principaux modes d’accompagnement efficaces dans les projets d’infrastructures. Après avoir appris et expérimenté les méthodes Scrum et Kanban, c’est finalement Scrumban que j’ai adopté.
A l’origine, la méthode ScrumBan a été créé dans le but de faciliter la transition des équipes Scrum vers les concepts Lean (un ensemble de pratiques qui permettent de développer les compétences des personnes) et Kanban. Combinant les meilleures pratiques de Scrum et Kanban, ScrumBan est devenu un choix majeur. C’est un excellent mélange de la nature normative de Scrum et de la méthode d’amélioration des processus de Kanban. Cette combinaison permet à une équipe d’améliorer continuellement les processus.
Scrumban se caractérise par les particularités suivantes :
- On retrouve la « Team » et les rôles considérés comme nécessaires, c’est à dire le « Product Owner » et le « Scrum Master »
- Le « Daily Scrum Meeting » est préconisé pour être certain de rester focalisé sur les objectifs et pour revoir les tâches
- Les « Reviews » et « Restrospective Meeting » peuvent être faits, si nécessaire, pour l’amélioration continue et le partage de connaissance
- Il n’y a généralement pas de notion de « Sprint », le « WorkFlow » est comme en Kanban, mais avec des limites (Work In Progress – WIP)
- L’estimation des tâches peut être faite pour avoir une vision de la charge totale prévisionnelle
- Les membres de l’équipe peuvent être spécialisés
- Les changements peuvent être pris en compte immédiatement ou en échange d’une autre tâche, sans attendre la fin d’une notion de « Sprint » qui n’existe généralement pas
- Le « Product Backlog Items » est constitué de tâches de toutes tailles, sachant que leur émission découle d’une « User Story » présente dans le « Product Backlog »
- La priorisation des tâches reste nécessaire et conseillée