Design et méthode agile, incompatibles ?

Gestion de projet web : entre gestion traditionnelle et méthode agile

La gestion de projet web traditionnelle

Dans une approche traditionnelle de gestion de projet web, l’équipe projet rédige un cahier des charges fonctionnel et technique. Celui-ci est fourni au client pour validation et “contractualise” le périmètre fonctionnel à réaliser. Il reprend le détail des modules, l’arborescence, le workflow et la temporalité du projet. A la validation du client, le chef de projet et le designer définissent un nombre de pages à réaliser pour couvrir l’ensemble des fonctionnalités mentionnées (page d’accueil, pages de contenu CMS, pages actualités, etc.).

Les étapes de la gestion de projet traditionnelle sont :

La gestion de projet avec la méthode agile

Il existe une deuxième manière de gérer un projet web : la méthode agile. L’approche philosophique de cette méthode s’inscrit dans une toute autre démarche. La construction du projet est incrémentale et itérative sur des cycles de production courts (sprints de 10 à 15 jours ouvrés maximum). Elle s’appuie sur un développement « brique par brique » de l’interface. L’équipe projet - dans une démarche de priorisation - peut affiner par retouches successives les fonctionnalités développées, jusqu’à une livraison finale jugée opérationnelle par le client.

Rappel des 4 fondamentaux de la méthode agile :

• Les individus et interactions plutôt que les process et outils ;
• Travailler la conception plutôt que la documentation ;
• Collaborer et planifier avec le client ;  
• Etre réactif au changement plutôt que de suivre un plan.

« Etre réactif au changement », le design est-il soumis à la même règle ?

Si l’on suit à la lettre l’esprit de la méthode agile, il est courant que des fonctionnalités pensées en amont soient abandonnées ou ajoutées en cours de projet. Le design devrait donc logiquement lui aussi être réévalué et s’adapter en conséquence. Un fonctionnement intéressant mais difficile à reproduire en agence où les objectifs clients et les contraintes des plannings internes ne permettent pas une création au compte goutte du design.

Nous allons donc voir les solutions qu'il est possible de mettre en place pour allier design et méthode agile.

Solution n°1 : avoir une vision d’ensemble 

En amont du projet et de la priorisation du sprint, il est conseillé de créer un schéma du parcours utilisateur (appelé communément diagramme UML). Celui-ci permet d’avoir une vision globale du projet et la charge de travail potentielle d’écrans à réaliser. 

Les arborescences traditionnelles sont rarement suffisantes en agile. Elles donnent une illustration hiérarchisée des pages, certes, mais trop peu d’informations sur la complexité du parcours utilisateur. Elles figent donc une structure sans prendre en compte l'interaction des fonctionnalités entre elles. Leurs utilisations peuvent cependant être complémentaires. Grâce au diagramme UML, le designer et le "scrum master" (le coordinateur du projet en méthode Agile) peuvent alors se projeter sur les maquettes à forte valeur ajoutée, réfléchir sur les interactions et donner une vision du projet.

Solution n°2 : le “meeting d’affinage” : priorisation et planification 

Planifiée à mi-sprint (ou quelques jours avant le lancement du sprint 1) cette réunion organisée avec l’équipe projet et le client, permet de réévaluer le product backlog et les priorités fonctionnelles pour le prochain sprint. 

Le scrum master doit qualifier les fonctionnalités du premier sprint avec le client et les distinguer selon : 

• Le besoin : éléments prioritaires.
  • L’application ne peut pas fonctionner sans ces éléments ;
  • Les éléments sont à trop forte valeur ajoutée pour l’utilisateur pour être écartés. 
• L’utilité : éléments importants mais non essentiels au développement. Ces éléments peuvent être retenus par l’équipe si le bénéfice consommateur est supérieur à l’effort de réalisation de l’équipe technique. En d’autres termes, le temps nécessaire pour le développer. 

L’équipe projet et le client priorisent donc ensemble les fonctionnalités pour le premier sprint. La participation du webdesigner est ici recommandée. L'objectif étant d'apporter une réponse ergonomique aux fonctionnalités priorisées. A l’issue de ce travail, les premières maquettes sont créées autour des besoins prioritaires du sprint.

Avant la création, l’utilisation de wireframes et zoning pour débattre des idées est fortement conseillée. La marge d’erreur de conception est ainsi limitée. Le designer aura quelques jours pour créer, justifier ses choix, effectuer les allers-retours puis enfin, valider avec le client les maquettes regroupées en “packs de créations”. 

Toujours veiller à conserver un coup d’avance pour ne pas pénaliser l’intégration et le développement des écrans au lancement du sprint (comme sur ce schéma d’un projet type en méthode agile illustrant le rôle du design avec le client). 

Solution n°3 : créer les maquettes à forte valeur ajoutée 

Le défi du webdesigner est d’adapter ses créations au cycle court de l’agile. Il doit faire preuve de flexibilité et d'adaptabilité afin de concentrer ses efforts sur la création d'écrans à forte valeur ajoutée.

Que se passe-t-il si l’on ajoute ou supprime des fonctionnalités d’un sprint à l’autre ?

Le designer devra mettre en valeur les fonctionnalités prioritaires du sprint et être proactif sur celles à venir afin de limiter l’impact sur l’ergonomie en cas de changement. Etre agile en somme ! Il devra maquetter le produit progressivement et ne créer que les écrans qui auront de la valeur à court terme. De cette façon, cela permettra d’avancer au même rythme que la construction du backlog. Cela donne de la flexibilité sur changements imprévus, sans perdre de vue l’objectif final du client.

Sources :

Source: UX Republic, 31 dec. 2015
Source: Wikiversité - Modélisation UML , 2017
Source: Interne - Novaway, 2018