Gestion de Projet
Traditionnellement, 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 plus précise. Voici les étapes principales du processus de développement d’un système dans ce contexte :
- Analyse des besoins avec le client (Requirement)
- Définitions des livrables, spécifications des fonctionnalités (Design)
- Établissement d’un budget et d’un échéancier (Planning)
- Début du cycle de développement: création d’une première fonctionnalité (Implementation)
- Validation et correction (Verification)
- Maintenance de cette fonctionnalité au fil du temps (Maintenance)
Typiquement, le processus recommence son cycle entre les étapes 4 à 6, jusqu’à ce que le système soit livré au client. Suite à la livraison, chacune des mises à jour de développement suit à nouveau ces étapes. Ce modèle est plus connu sous le nom de « Waterfall model », dans lequel 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 le modèle le plus souvent utilisé, mais il présente plusieurs lacunes importantes.
Connaître les besoins du client
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.
Manque de flexibilité
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 [3] 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%.
Dans le cadre d’un projet d’infrastructure de Système d’Informations, il est possible d’intégrer de l’agilité dans un modèle Waterfall. Les spécifications sont enrichies au fur et à mesure des phases « Conception » et « Réalisation » avec l’expérience acquise. Le transfert de compétence se fait tout au long des itérations en incluant les personnes concernées dans l’équipe projet. Des tests permettent de valider les fonctionnalités implémentées et les recettes de chaque itération valident la finition du système ou sous-système réalisé durant l’itération pour permettre leur facturation.
Les phases « Conception » et « Réalisation » peuvent être finalisées en une ou plusieurs itérations en fonction du nombre de fonctionnalités et exigences listées (Product Backlog). Les fonctions sont ordonnancées, dans le « Product Backlog », en fonction de leur valeur ajoutée métier, du « coût » estimé de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l’ordre ainsi défini selon les contraintes de l’équipe et les éventuelles dépendances entre les fonctions. L’objectif de l’approche Agile consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d’accélération du « Time to market ».