1- Inconvénients des méthodologies lourdes
Les méthodologies traditionnelles "En cascade", "RUP Rationale Unified Process" ou CMMI sont assez lourdes et souffrent de certains inconvénients que nous allons illuster sur la méthodologie "En Cascade" :
Les méthodologies traditionnelles mettent l'accent sur l'élaboration de spécifications les plus détaillées possibles. Spécifications qui seront consignées dans des documents d'analyses détaillées. Or, on a beau aller dans le maximum de détails, il y a des spécifications que l'on découvre tardivement. Les utilisateurs peuvent ne pas se rendre compte au départ de tous leurs besoins, ce n'est qu'après les premières utilisations du système qu'ils se rendent compte qu'il manque des fonctionnalités importantes. Donc des retours en arrière sont souvent obligatoires, mais pas toujours possibles dans le modèle en cascade.
Puisque les spécifications fonctionnelles changent souvent, la conception sous-jacente change obligatoirement. Or souvent il est difficile de changer une conception surtout quand il s'agit de modifier le modèle de données. Cette difficulté à modifier la conception a posteriori conduit assez souvent à une "usine à gaz" et à des architectures non optimisées.
Etant donné que les spécifications changent et la conception reste figée, la réalisation risque de rentrer dans un cycle de développpement très long dépassant toutes les prévisions. Et c'est la phase de test qui fait les frais de ce rallongement du cycle de réalisation. Les tests sont effectués à la va-vite ou ne sont pas du tout effectués. C'est le client qui teste en cours d'utilisation.
Quant au déploiement, il est souvent redouté car synonymes de mauvaises surprises. En effet, le client ne voit aucune version du logiciel avant ce déploiement qui peut avoir lieu plusieurs mois après les premières spécifications. Donc, il y a un grand risque que le logiciel déployé ne correspondent plus aux besoins du moment.
De manière générale, les méthodologies lourdes souffrent des problèmes suivants :
- Quand les spécifications ne sont pas claires ou ont changé
- Peur de passer à la phase suivante
- Les changements coûtent de plus en plus cher
- L'utilisateur n'obtient pas ce qu'il souhaite
- Le contrôle qualité souffre
- Temps insuffisant pour tester
- Intégration tardive signifie bugs de dernière minute
- La perte de temps
- 52% des exigences ne sont jamais implémentées
- 64% des fonctionnalités rarement utilisées
- Statistiquement les projets dépassent le temps initial prévu
- Seuls 32% des projets réussissent
- Très mauvaise visibilité sur la progression
- Retard de livraison signifie retard de paiement
Source : scrumusergroup.ca
Source : The Standish Group XP 2002
Source : The Standish Group, Chaos Report 2009
2- Ebauche de solution : méthodes itératives
Pour pallier à tous ces inconvénients, les méthodes dites "Agile" ont adopté une approche itérative que l'on peut illuster comme suit :
Le tableau suivant résume les différences entre les méthodologies classiques et les méthodes Agile :
| Approche en Cascade | Approche Agile |
|---|---|
| Par phase | Itérative et incrémentale |
| Logiciel opérationnel en phase finale | Logiciel opérationnel après chaque itération |
| Des personnes différentes impliquées en diverses phases. Le contexte est perdu. | Les mêmes personnes sont impliquées durant toutes les phases. |
| Vérification effectuée en phase finale | Développement dirigé par la vérification |
| Planning prédictif | Planning adaptatif |
| Peu de visibilité. Dirigé par les documents. | Plus de visibilité. Dirigé par le développement. |
| Modifications acceptées à certaines phases seulement. | Modifications acceptées tout au long du processus. |
A suivre ...
Aucun commentaire:
Enregistrer un commentaire