Sur son blog, After the Bubble, Fabien Benoit regrette de ne pas trouver de développeur français parlant des problèmes de méthodologies de développement. Et il pose la question du “Combien de design?”. La réponse est comme bien souvent: “ça dépend…” Voici donc quelques éléments que je vous invite à compléter pour alimenter la réflexion.

Vue d’ensemble

Lorsque je discute méthodologie j’aime bien débuter avec le RUP, autant les outils rational me donne des boutons autant je trouve le RUP utile. Si vous avez l’occasion d’être formé à RUP ou d’avoir accès à la documentation RUP foncez. La méthode donne une vision d’ensemble du processus de développement notamment à travers ce fameux schéma:

Vous pouvez retourner le problème dans tous les sens, un projet informatique est une série d’activité qui (devrait) se déroule(r) dans l’ordre suivant:

Ces activités se répartissent en différentes phases:

– Inception (ou démarrage)

– Élaboration (ou conception)

– Construction (ou développement)

– Transition (ou recette et mise en production)

Selon la méthodologie chacune de ces activités ou phases sera plus ou moins importantes ou nommées différemment mais on fini toujours par les retrouver.

D’ailleurs je qualifierais le RUP de meta-méthodologie. En effet la première étape d’une démarche RUP consiste à le configurer pour instancier sa propre méthodologie. Rien n’empêche de faire de l’XP dans une démarche RUP.

Les cycles de vie d’un projet

Je viens d’affirmer que les activités devaient toujours se dérouler dans le même ordre mais ça n’empêche pas d’organiser leur déroulement de nombreuses manières.

Le cycle en cascade

Le cycle classique, les activités sont exécutés les unes après les autres une seule fois.

Gros défaut de ce cycle: Si les premières phases (inception/élaboration) se déroulent mal, on ne s’en rend compte que dans les phases de fin de projet (construction/transition) c’est l’effet tunnel.

Mais pour un projet simple avec peu d’incertitude c’est ce qui fonctionne le mieux.

Le cycle incrémental

Le projet est découpé en lot chaque lot est réalisé successivement ou en se chevauchant selon un cycle en cascade. Ce découpage permet de réduire la durée d’un cycle complet ce qui limite l’impact de l’effet tunnel.

Ce cycle permet de traiter des projets relativement complexes mais reste inefficace si le besoin évolue en cours de projet.

Le cycle itératif

Consiste à dérouler plusieurs fois de suite un cycle en cascade. A chaque nouvelle itération on affine les spécifications et on corrige les erreurs de l’itération précédente.

Ce cycle permet de s’adapter en cours de projet aux changements mais ne permet pas forcément de traiter de gros projet.

Le cycle en spirale

Il s’agit de combiner les cycles itératif et incrémental. A chaque nouvelle itération on ajuste ce qui a déjà été réalisé et on l’enrichit en traitant un spectre fonctionnel plus large.

Ce cycle est le plus adapté pour traiter des projets complexe et incertain. Gérer un projet de cette manière est bien plus compliqué que de suivre un simple cycle en cascade il nécessite donc à sa tête un chef de projet expérimenté.

Le cycle en Y

Utilisé par la méthode 2TUP de Valtech ce cycle propose de séparer en 2 branches les activités de recueil des besoins et d’analyse: une branche dédié au fonctionnel l’autre à la technique les deux pouvant se dérouler en parallèle.

Ce cycle est adapté aux projets nouvelles technologies car il permet de lever au plus tôt les incertitudes techniques caractéristiques de ce type de projet.

Il est compatible avec les autres approches.

Globalement les projets étant toujours incertains et complexe on ne fait plus des cycles en spirale, si en plus il y a du nouveau concernant les technologies utilisé, le cycle en Y est fortement recommandé.

Malheureusement tout cela n’est que la théorie, en pratique il se passe trop souvent ceci:

En raison de multiples contraintes les phases de recueil des besoins et de spécification sont réduites à leur portion congrue, les développements démarrent en avance de phase et comme ça coûte cher, on demande au développeur de faire la conception en même temps que les développements. On déploie et ensuite on teste.

Les méthodes agiles

Les méthodes agiles ont émergé en réaction à la situation décrite précédemment et partent des constats suivants:

– Les utilisateurs ont de grandes difficultés à exprimer leur besoin sous une forme exploitable par les équipes techniques.
– Les spécifications n’arrêtent pas de changer.

– Les projets l’engluent dans la gestion de projet et la rédaction de documents qui ne sont jamais lu.

– …

Le remède: exit les specs, exit la gestion de projet lourde, exit la doc.

La méthode agile la plus connue, XP, se base sur un cycle en spirale très condensé avec une injection permanente des besoins en direct par le client (client sur site).

Avec la méthode XP le formalisme lourd des méthodes non agile est remplacé par un ensemble de pratiques centré sur le développeur, au premier rang desquelles on trouve les tests unitaires, l’intégration continue et le refactoring.

Les méthodes agiles répondent bien au besoin de faire avancer un projet alors que le client ne sait pas exactement où il veut aller. Par contre il ne faut pas se leurrer, XP s’adresse à des développeurs expérimentés. Les tests unitaires et le refactoring ne sont pas des pratiques à la porté du développeur débutant. Évidemment la pratique du pair programming permet d’atténuer ce problème en associant un développeur débutant avec un autre plus expérimenté. Mais je n’ai encore jamais vu aucun manager accepter de mettre 2 ressources là où une seule peut suffire.

Enfin XP ne permet pas de connaître à l’avance les fonctionnalités, la durée et le coût d’un projet, ce qui reste le fantasme la préoccupation n°1 des décideurs. Cette question du coût, des délais et des fonctionnalités fera l’objet d’un autre billet.

Une méthode idéale ?

Il n’y en a sans doute pas, mais j’ai pu observer de bon résultat en combinant:

– Un cycle en spirale pour gérer les évolutions et maîtriser la complexité.

– Une approche en Y pour lever les incertitudes technologiques.

– Certaines pratiques XP pour garantir la qualité de l’application

Ce sont des pratiques qui sont de plus en plus répandues, en raison de leur relative complexité elles ont peu de chance d’aboutir sans s’appuyer sur des ressources expérimentés.

Combien de design ?

Avec une méthodologie agile et une équipe expérimenté capable de pratiquer le refactoring, c’est à dire du design en continue, on peut sans doute se passer du “Big Design Up Front”. Mais agile ou pas, un élément reste indispensable: le cahier des charges. De préférence sur 2-3 pages, allant à l’essentiel et permettant de donner une direction au projet plutôt qu’un fourre tout de 50 pages rédigé dans un langage juridique et qui tenterait de tout prévoir à l’avance.
Pour poursuivre la réflexion je vous invite à visiter la page: état de l’art des méthodologies sur le site de la direction des systèmes d’information du CNRS.