Le scope creep (dérive du contenu) est un fléau bien connu des projets informatiques. L'approche traditionnelle consiste à lutter contre ce phénomène en ajoutant plus de contrôle, plus de temps de réflexion et de préparation, plus d'implication des métiers, plus de précautions...
De son côté, l'approche Agile va consister à ne pas lutter contre le courant mais à avancer en se laissant porté afin de satisfaire le client et ses utilisateurs.
Pour le point de vue de l'approche traditionnelle sur le problème de la dérive du contenu (scope creep), nous vous recommandons l'article «comment empêcher que la dérive de contenu n’emporte au loin votre projet» de Duncan Haughey (traduit en français par Michel Operto sur son blog DantotsuPM).
Dans cet article, on identifie 5 causes à la dérive du contenu:
- Pauvre analyse des besoins
- Implication trop tardives des utilisateurs
- Sous-estimation de la complexité du projet
- Manque de contrôle du changement
- Sur-qualité
Dans le tableau ci-dessous, nous avons fait une comparaison entre les solutions de l'approche traditionnelle et celles de l'approche Agile aux causes de la dérive du contenu. L'objectif est de mettre en évidence l'opposition des types de solution recherchée: soit on ajoute des choses (contrôle, préparation...), soit on simplifie (lean).
| Causes |
Approche traditionnelle |
Approche agile |
| Pauvre analyse des besoins |
Passer plus de temps en réflexion et en préparation, meilleures spécifications des besoins, documentation exhaustive... |
Travailler par petits bouts (incréments), c'est plus simple. De plus, une meilleure compréhension de la part des développeurs et des utilisateurs des besoins réels est facilité par des livraisons et des démos fréquentes. |
| Implication trop tardives des utilisateurs |
Plus d'implication, plus de réunions, plus de documentations, développements de scénarios de test, plus de processus de validation... |
Dans SCRUM, il y a forcément une démo avec les utilisateurs en fin de Sprint (ie tous les 15 jours). |
| Sous-estimation de la complexité du projet |
Ajouter des provisions pour aléas, ajouter de la marge dans le planning, prévoir des ressources supplémentaires... |
Travailler par petits incréments réduit la complexité et favorise la recherche de solutions simples. |
| Manque de contrôle du changement |
Plus de processus (formulaire, validation, registre, analyse d'impact) |
Pendant une itération (Sprint) aucun changement n'est accepté, pour le reste on en discute pendant le planning de la prochaine itération avec le représentant des utilisateurs et du sponsor. |
| Sur-qualité |
Plus de management et de communication sur les enjeux |
L'équipe s'engage à livrer un produit fini tous les 15 jours (pas le temps de traîner). Chaque membre de l'équipe annonce ce qu'il va faire dans la journée (SCRUM) ce qui est aussi une forme d'engagement. |
En fait, il ne s'agit pas d'une comparaison mais d'un parallèle, car les 2 approches n'ont pas les mêmes contraintes. L'approche traditionnelle est plus adaptée dans le cadre d'un engagement de résultat (mode forfait) tandis que l'approche Agile correspond plus à un engagement de moyens.(Ce dernier point est souvent débattu.)
Mais la vraie question derrière le problème de la dérive du contenu est: Comment définit-on la réussite d'un projet ?
Est-ce le fait d'avoir respecté un engagement de délais et de coûts défini au début du projet ou d'avoir un client et des utilisateurs satisfaits à la fin du projet ? Ce n'est pas toujours la même chose...
Rétrolien(0)
 |
Blog PMA 
Adresse URI pour un rétrolien sur cet article
Flux RSS pour les commentaires
Affichez les commentaires
Ajoutez un commentaire
