Les résultats produits sont directement reliés aux conversations:•Que nous avons•Que nous n’avons pas•Que nous n’avons pas fait correctement
Mon blog dit : « un pas vers la simplicité ». Je vais donc rester simple et vous donner deux(2) recommandations pour une meilleure compréhension des besoins et pour faire en sorte de livrer des fonctions/itérations/projets conformes aux attentes des clients.
Définition des responsabilités client-développeur
Un des plus gros changements à apporter pour améliorer la compréhension des besoins est de définir les responsabilités du client et celles de l’équipe du développement. La voici :
- Le « quoi » est la responsabilité du client (ou du directeur de programme)
- Le « comment » est la responsabilité de l’équipe de développement
Ces responsabilités ne sont pas toujours respectées avec comme impact que le développeur ne produit pas le résultat voulu, que la solution développée ne soit pas évolutive ou que le développeur prend des décisions d’affaires.
Client : Les développeurs ont le droit de « comprendre » ce qu’ils font : il est beaucoup plus utile d’expliquer pourquoi que d’essayer de déterminer la façon de l’implanter. Si le développeur comprend l’objectif, le résultat sera plus conforme aux attentes. Pour améliorer l’évolution d’une solution, il est aussi important de fournir des informations sur les objectifs à moyen ou long terme s’ils sont connus : ceci donne de bonnes indications sur l’architecture d’une solution aux développeurs même si les fonctions ne sont pas développées immédiatement.
Développeur : Le « client » détermine les besoins, il connait ses besoins et ses objectifs d’affaire. Vous avez le droit de suggérer des façons de faire afin d’accélérer le travail par exemple, mais surtout ne jamais imposer votre façon de voir les choses. Vous devez informer le client des impacts si nécessaire mais garder en tête que votre responsabilité est « comment » développer.
Critères d’acceptation
Trop souvent, on prend les besoins, on livre et le client n’est pas satisfait parce qu’il manque une option ou une règle d’affaire que vous auriez dû connaître, etc… «Je ne connais pas tout de ce que je ne connais pas»
Et si vous faites une liste des critères d’acceptation AVANT le développement? Au moment de la revue, les critères sont déjà établis donc tout le monde va maintenant compiler les changements pour la prochaine itération.
Il est certain que dans un mode Agile, les besoins se précisent au fur et à mesure du développement, il en est ainsi pour les critères. Ceci donne l’opportunité de combiner les visions sur une base quotidienne et ne plus avoir de surprise quand c’est livré. Les changements sont toujours la bienvenue parce qu’ils font partie de la normalité, ils ne sont plus traités en exception.
Si vous mettez en pratique ses 2 conseils, vous aurez amélioré la compréhension des besoins et la relation avec le client.
User Stories
Pour aller plus loin dans les besoins avec les méthodes Agile, habituellement les besoins sont consignés sous forme de User Story. Par définition un user story est une petite fonction mesurable et testable.
Souvent elles ont la forme de :
Exemple :
« En tant qu’utilisateur, je peux ajouter un produit dans mon panier d’achat. »
Elle permet de décrire en une ou deux phrases une fonctionnalité qui représente la fonction du point de vue de l’utilisateur, elle est complétée par les critères d’acceptation qui peuvent être sous cette forme :
– « Vérifier que l’utilisateur est authentifié sur le système » ;
– « Vérifier que le panier d’achat est présenté à l’utilisateur avec le produit qui vient d’être ajouté » ;
Pour en savoir plus sur les user stories :
User Story (Slideshare)
User Story vs Use case : soyez Agile !
Agilité: 10 stratégies pour avoir des User Stories suffisamment petites
Jeux d’innovation pour améliorer la compréhension des besoins
Cet article Souviens-toi du Futur… Mon Ombre et moi: mettre l’Expérience Utilisateur au cœur du Jeu ! propose des jeux d’innovation pour mieux cadrer le contenu d’une release et pour en apprendre davantage sur l’expérience d’utilisation des solutions par les utilisateurs.
Agile pour tous 
1 commentaire