Etude pour améliorer un site et méthode agile

Ce billet fait suite à la conférence organisée par Adobe.

J’ai trouvé le débat intéressant, et j’espère ne pas avoir été le seul de cet avis ;).

Un des sujets dont on a parlé : comment faire cohabiter intelligemment l’analyse ergonomique, les tests utilisateurs, avec la vie du site, la road map ?

Une option, qui me semble particulièrement intéressante, est de mettre en oeuvre une approche agile.

On pilote le projet en le faisant évoluer par petites itérations, au lieu du « big bang » de 18 mois.

Et bien, on peut doit tout à fait travailler en parallèle une approche orienté utilisateur, qui sera synchronisée avec les itérations mise en oeuvres avec la méthode agile.

C’est une très bonne pratique.

Par contre, on ne peut mettre en oeuvre une telle méthode que si l’entreprise qui héberge le projet est convaincu de l’intérêt d’une telle méthode, au niveau des décideurs.

Autre retour d’expérience qui m’a semblé fondamental : quand on accompagne une refonte, ou un projet e-commerce, il est très important d’accompagner le client sur l’ensemble de la durée de vie du projet.

Il arrive malheureusement souvent que les résultats des études utilisateurs ne soient pas bien mises en oeuvre : elles restent dans un tiroir…

2 commentaires

  1. SCRUM, AGILE oui oui c’est bien beau tout ca, mais il faut adopter le comportement des porc-épics lorsqu’ils s’accouplent : Etre prudent !

    Back to serious : Les Sprint de SCRUM c’est des cycles de 3 semaines, disons pour faire simple que 2X3 pour specifications (on part d’une expression de besoin qu’il faut nettoyer et qui demande une rédaction au moins utilisable que nous appellerons SFG (comme Spec Fonct Gen) et SFD (detaillées) et la oups on code à nouveau 2X3 semaines (entre le design détaillé, les use case, le code, les tests unitaires et l’assemblage pour arriver à un package « déployable sur un environnement de prod (redondé et 99,999 de dispo, le 3iem cycle de 2X3 dedié aux tests d’intégration (parfois il y a des webServices externes, des stores locators, bref des trucs qui sont pas dans la platforme) et vite passé. Un peu de test de pour les Opérations (histoire de s’assurer que tout ceci pourra être monitoré et déployé) et hop passage en prod. Ah oui les Test Utilisateurs … ben en // sur un autre environnement …
    Ca commence à faire pas mal … à traiter vite et bien
    je resume 2X3s pour spec, 2X3 pour dev, 2X3 pour tests 2X3 pour Users test et Performance = 12 semaines.
    A réserver à des équipes « velues » si on veut avoir autre chose que des goodies en terme d’apport sur du SCRUM.
    Moi c’que j’en dis …

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *