Méthode en cascade et méthode agile, Kezako ?

En matière de production de contenus e-learning et serious-game, deux types de méthodologie projet cohabitent actuellement chez les éditeurs. Elles se nomment « méthode en cascade » et « méthode agile ». En quoi consistent-elles ? Quelles sont les différences entre les deux ? Quels sont les avantages et inconvénients de chacune d’entre elle pour vous, clients ? C’est ce que je vous invite à découvrir dans cet article.

Méthode en cascade

C’est le type de méthode le plus utilisé aujourd’hui dans tous les domaines qui nécessitent de concevoir avant de produire quelque chose. Pour parvenir à un produit fini, on passe par plusieurs phases du cadrage du projet jusqu’à la livraison finale.

Le principe est simple : on ne passe à la phase suivante que lorsque la précédente est validée. Autre principe : on ne revient pas en arrière (d’où le terme « cascade »)

Cette méthode présente de nombreux avantages, notamment celui de sécuriser le planning du projet puisque l’on verrouille chacune des étapes les unes après les autres : on s’entend sur ce que l’on va faire (cadrage), on le conçoit dans les grandes lignes (conception générale) puis dans le détail (conception détaillée) avant de le produire (production), de le tester (tests/corrections) et de le livrer (livraison).

Elle permet également de bien s’entendre sur les attendus du projet et elle est très facile à expliciter à un groupe de travail. Enfin, bien menée, elle permet d’éviter les dérives en termes de planning : il est facile de visualiser que si une étape se décale, les suivantes sont impactées.

L’inconvénient principal côté client final, est une certaine rigidité du modèle. Ainsi, par exemple, dans le domaine du e-learning, la conception générale consiste à rédiger un document, appelé synopsis, ou conducteur, ou découpage pédagogique selon les prestataires. Ce document liste l’ensemble des objectifs pédagogiques et prévoit un ensemble d’activités a réaliser (animation, interactivité, vidéo, quiz etc.).

Or, il n’est pas rare qu’au moment de la conception détaillée (la rédaction des storyboards associés) voire de la production, le client se rende compte d’un oubli d’un objectif ou d’un message clé. Ceci suppose donc de remettre en question la conception générale pourtant validée…

Ici la plupart du temps, deux cas de figures :

  • Soit le prestataire a une certaine lattitude en terme de planning et/ou de budget et peut se permettre ce retour en arrière et l’accepte.
  • Soit le planning est déjà très serré et/ou les budgets très justes, et il ne peut tout simplement pas accepter sous peine de mettre en danger la rentabilité globale du projet ou la date de livraison finale.

La plupart du temps, budgets et plannings sont calés au plus juste des deux côtés, ce qui empêche toute modification. Conséquence : à la moindre demande de modification, des frictions se créent qui mettent à mal les relations entre les deux partenaires.

Une première solution à ceci serait tout simplement qu’en début de projet, prestataire et client se réservent une marge de manoeuvre (en terme de planning et de budget) à chaque phase du projet pour justement permettre ces ajustements le moment venu, sans créer de friction.

Une autre solution consiste à mettre un peu d’agilité dans les process, ce que certains prestataires ont commencé à intégrer.

Méthode agile

Avec ce type de méthode, le principe de découpage en étapes reste le même, mais chaque étape est elle-même subdivisée en itérations. A chaque itération, d’une durée à définir en début de projet (souvent 15 jours), une version intermédiaire d’un document ou du produit est livrée et soumise à discussion. La construction se fait donc par couche successive.

Pour la production de serious games par exemple, cette méthode est particulièrement adaptée. Un prototype est réalisé très tôt sur lequel les fonctionnalités, les briques de gameplay et les scénarii sont implémentés tout au long du projet, en mode incrémental. Ainsi, client et prestataire peuvent très vite se rendre compte de ce à quoi le produit va ressembler au final.

Comme avec une méthode en cascade, le projet commence par une phase de cadrage. A partir de la phase de conception, la rédaction des éléments puis la production se font par itérations successives.

Ce type de méthode s’appuie sur un principe collaboratif : client et prestataire travaillent main dans la main et créent le produit final par ajustements successifs.

L’inconvénient majeur de cette méthode est qu’elle nécessite une mobilisation continue de la part du client final car il est totalement impliqué dans la rédaction et la construction. Ce peut être délicat à gérer, notamment dans le cas, fréquent, où un Comité Projet de plusieurs membres doit se prononcer.

L’avantage évident est le fait que, ainsi impliqué, le client a une vue très claire sur l’état d’avancement. De plus, il peut réagir très vite si par exemple une fonctionnalité une fois développée ne semble pas optimale.

Pour toute information sur les méthodes agiles, je vous conseille l’ouvrage de Véronique ROTA Gestion de projet vers les méthodes agiles aux Editions Eyrolles (2009 – 2ème éd.)

Qu’en est-il aujourd’hui côté éditeurs ?

C’est la méthode en cascade qui est le plus utilisée aujourd’hui par les éditeurs e-learning et serious games du marché. Mais, conscients de ses limites, certains commencent à injecter un peu d’agilité dans leur process : ils mixent les deux méthodes. Cadrage et conception restent en cascade mais, à partir du prototype, le client est invité à suivre la production au plus près. Régulièrement, il se prononce sur l’état d’avancement du projet, teste les nouvelles fonctionnalités implémentées.

Pour plus d’informations sur ces outils et méthodes, je vous invite à lire l’ouvrage « Concevoir un serious game », rédigé par mes soins, dont la sortie est prévue le 04 avril 2011 aux Editions FYP.


Publié

dans

par

Étiquettes :