2.1 Le cycle en V et le modèle en cascade (Waterfall)

Le cycle en V

Le cycle en V est une variante du modèle en cascade, plus adaptée aux projets complexes. Il met un accent particulier sur la qualité en liant chaque phase de conception à une phase de test correspondante.

La branche gauche du V : la conception

Chaque étape de cette branche se concentre sur la définition du projet, allant du général au particulier.

• Spécifications des besoins : Définition de ce que le système doit faire.
• Conception générale : Création de l'architecture du système.
• Conception détaillée : Création du code et des modules individuels.

La branche droite du V : la validation et la vérification

Chaque étape de cette branche teste et valide le travail effectué sur la branche gauche, remontant du particulier au général.

• Tests unitaires : On vérifie que chaque module de code fonctionne correctement, en lien avec la conception détaillée.
• Tests d'intégration : On s'assure que tous les modules fonctionnent bien ensemble, en lien avec la conception générale.
• Tests de validation : On vérifie que le système complet répond aux besoins du client, en lien avec la phase de spécifications.
• Déploiement et acceptation : Le produit est livré, validé par le client et mis en service.

Le cycle en V permet de détecter les erreurs de conception et de développement plus tôt, ce qui rend le projet plus sûr, mais il reste rigide face aux changements de besoins.

Le modèle en cascade (Waterfall) 💧

Le modèle en cascade est l'approche la plus simple et la plus linéaire. Les phases s'enchaînent de manière stricte :

• Analyse des besoins : On définit en détail ce que le projet doit faire.
• Conception : On crée l'architecture du système, l'interface utilisateur et la base de données.
• Développement : L'équipe code le logiciel en se basant sur la conception.
• Tests : On s'assure que le logiciel fonctionne comme prévu et qu'il n'y a pas de bugs.
• Déploiement : On met le logiciel à la disposition des utilisateurs.

L'inconvénient majeur de cette méthode est sa rigidité : il est très difficile de revenir en arrière si un besoin change.

Avantages et Inconvénients des méthodes traditionnelles

Ces méthodes sont particulièrement pertinentes pour les projets dont le cahier des charges est figé et bien défini dès le départ, comme dans le développement de logiciels pour l'aérospatiale ou le médical. Elles offrent une structure claire et un contrôle rigoureux, facilitant la gestion des délais et des coûts.

Cependant, leur principal inconvénient est leur manque de flexibilité. Face à un changement d'exigence, il est difficile et coûteux de revenir en arrière, ce qui les rend peu adaptées à l'incertitude et à la complexité des projets IT modernes.

Pour aller plus loin :

Source: Kounnou

2.2 Les méthodologies Agiles : l'ère de la flexibilité

Les méthodes traditionnelles se sont révélées insuffisantes face à la rapidité des évolutions technologiques. Les méthodologies agiles sont une réponse à cette incertitude. Elles privilégient la collaboration, l'adaptabilité et la livraison incrémentale.

Le Manifeste Agile, rédigé en 2001, a formalisé les quatre valeurs clés :

• Les individus et leurs interactions plus que les processus et les outils.
• Des logiciels opérationnels plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation de contrats.
• L’adaptation au changement plus que le suivi d’un plan.

Le Scrum

Scrum est un framework agile très populaire. Son fonctionnement repose sur des cycles courts et itératifs appelés sprints, qui durent généralement de une à quatre semaines.

Les rôles clés

• Product Owner : Le représentant du client, il gère et priorise le Product Backlog pour maximiser la valeur livrée.
• Scrum Master : Le facilitateur de l'équipe, il garantit le respect du cadre Scrum et aide à résoudre les obstacles.
• Équipe de Développement : L'équipe auto-organisée et pluridisciplinaire qui réalise le travail.

Les artefacts

• Product Backlog : La liste priorisée de toutes les fonctionnalités et améliorations à faire sur le produit.
• Sprint Backlog : Le sous-ensemble de tâches que l'équipe s'engage à réaliser pendant le sprint en cours.

Les cérémonies (réunions)

• Sprint Planning : Planification des tâches à réaliser durant le sprint.
• Daily Scrum : Point quotidien de 15 minutes sur l'avancement et les blocages.
• Sprint Review : Démonstration des fonctionnalités terminées aux parties prenantes.
• Sprint Retrospective : Réunion d'amélioration continue de l'équipe.

Le Kanban

Kanban est une méthode agile qui se concentre sur la visualisation et l'amélioration continue du flux de travail, sans cycles fixes comme les sprints. Son but est de livrer continuellement de la valeur en limitant le travail en cours (WIP - Work In Progress).

Les principes de base

• Visualisation : Le tableau Kanban représente les étapes du processus (ex: À Faire, En Cours, À Tester, Terminé). Les tâches se déplacent de colonne en colonne.
• Limitation du WIP : On impose une limite au nombre de tâches qui peuvent être "En Cours" simultanément. Cela force l'équipe à se concentrer sur la finalisation des tâches avant d'en commencer de nouvelles.

Application

Kanban est idéal pour les équipes qui gèrent des tâches arrivant de manière imprévisible et continue, comme la maintenance applicative ou le support technique.

Pour aller plus loin :

Source: Agitips

Source: Project it!

Exercices Pratiques