Faber&Co

L’objectif du projet est d’inspecter l’incrément produit avant sa mise en production, d’organiser la résolution des bugs, de mettre en place une démarche qualité et d’organiser le déploiement des nouvelles fonctionnalités.

Contexte

En tant que Product Owner chez Faber & Co Real Estate, une entreprise (virtuelle) basée à Londres spécialisée dans la vente de biens immobiliers, je suis responsable de gérer le développement et l’amélioration du site vitrine de l’entreprise. La première version du site, actuellement en ligne, reçoit de plus en plus de visites et de nombreux biens vont être prochainement mis en ligne pour étoffer le catalogue produit.

Dans ce contexte, il est devenu stratégique pour l’entreprise de faire évoluer le site en intégrant de nouvelles fonctionnalités adaptées aux besoins des acheteurs potentiels, notamment en facilitant la navigation parmi les biens proposés, en aidant à la recherche d’un bien spécifique et en favorisant la prise de contact et de rendez-vous avec des agents immobiliers.

1 / Inspection de l’incrément produit

L’équipe a presque terminé le premier sprint, et il est temps de tester les user stories pour passer les features en production.

Le premier sprint s’est focalisé sur l’ajout d’une option de recherche pour permettre aux clients de mieux naviguer parmi les biens présentés sur le site. Après avoir testé le site dans sa version de pré-prod mise à disposition par l’équipe, je constate que 11 sur 16 critères d’acceptation sont invalidés.

En cette fin de sprint, une seule user story est donc validée sur les trois testées.

2 / Réflexions sur les solutions à mettre en place

Etant donné les difficultés rencontrés en cette fin de sprint, nous décidons avec l’équipe de mettre en place différentes actions pour faire face aux situations rencontrées et rebondir rapidement.

Solutions à mettre en place :

• Mettre en place d’un cahier de recette pour réaliser le suivi des tests et remonter les bugs efficacement ;
• Retravailler le backlog pour améliorer les critères d’acceptation ;
• Recalculer la vélocité de l’équipe pour éviter les retards ;
• Ré-organiser les sprints pour aligner l’équipe sur des objectifs précis ;
• Mettre en place du Pair programming et de spécifications techniques sur certaines user stories pour éviter les blocages et les retards ;
• Réaliser un audit de qualité web pour améliorer la qualité de notre travail.

2 / Mise en place d’un cahier de recette

Pour faciliter les tests et la communication sur les bugs avec l’équipe, je prépare un cahier de recette détaillant les tests et les résultats constatés afin d’aider à leurs corrections.

Les tickets sont définis de la manière suivante :

• Une description succincte du test ;
• Le résultat attendu : le comportement souhaité par l’interface ou la fonctionnalité ;
• Le résultat obtenu : le comportement réel de l’interface ou la fonctionnalité pendant le test ;
• L’état : si le test a réussi, a échoué ou si il est encore en cours ;
• La criticité : le degré de gravité (majeur ou mineur) du bug pour permettre la priorisation des tickets ;
• La user story liée au test pour faciliter le suivi des tests.

En commentaire, des captures d’écran sont ajoutées pour apporter des informations supplémentaires sur les tests échoués et aider l’équipe à leur correction.

3 / Audit qualité web

En complément des bugs relevés lors de l’inspection du produit, nous décidons avec l’équipe de réaliser un audit pour identifier les points majeurs impactant la qualité du site et améliorer la qualité de notre travail.

Pour cela nous décidons d’utiliser la checklist Opquast. Un certain nombres de règles sont sélectionnées et rassemblées dans un référentiel qualité. Elles nous permettent de couvrir les composants clés de notre site. Pour répondre à notre nouveau référentiel qualité, le site est soumis à un audit et le cahier de recette est complété avec les tests qualité invalidés par le site.

En parallèle, les critères d’acceptation des users stories sont retravaillés et affinés pour intégrer les nouvelles règles de qualité mises en place.

4 / Affinage du backlog

Une fois les tests et l’audit qualité réalisés, différentes actions correctives sont réalisées pour affiner le backlog.

Tâches réalisées :

• Réécriture des user stories sous le modèle : « En tant que, Je veux que, Pour » ;
• Réécriture des critères d’acceptation en respectant le modèle Gherkin « Étant donné, Quand, Alors » ;
• Intégration des règles de qualité Opquast aux critères d’acceptation ;
• Ajout de maquettes détaillées pour aider à la compréhension des user stories ;
• Remontés des tickets de bugs dans le backlog ;
• Attribution des story points pour chaque ticket par l’équipe ;
• Priorisation des tickets et des user stories.

5 / Mise à jour du planning de releases

Les nouveaux tickets de bugs et de qualité à traiter affectent l’organisation de nos prochains sprint, il est temps de mettre à jour le planning de releases.

Etant donné les nombreux bugs et tickets de qualité remontés dans le cahier de recette, et la baisse de la vélocité de l’équipe passée de 17 à 15, il est nécessaire de mettre à jour du planning de releases pour qu’il soit réaliste et proportionné par rapport à la charge de travail que peut supporter l’équipe.

Tâches réalisées :

• La réorganisation de chaque sprint par objectif ;
• Prise en compte de la nouvelle vélocité de l’équipe ;
• Étiquetage sur les tickets nécessitant des spécifications techniques de la part de l’équipe technique ;
• Étiquetage sur les tickets nécessitant d’être traités par deux développeurs travaillant en binôme (pair programming) ;
• Étiquetage sur les tickets nécessitant des stratégies de release particulières dans les sprints à venir (bêta, soft launch, etc.) ;

<planning de release>

6 / Organisation de la Sprint Review

Le sprint arrive à sa fin, nous devons maintenant organiser la Sprint Review.

La Sprint review va nous permettre de faire un état des lieux de l’incrément, de discuter du déroulement du sprint, des objectifs et surtout de présenter le travail réalisé et les actions envisagées.

Nous présentons donc :

• le travail accompli durant le sprint avec les user stories validées, celles qui ne sont pas validées et les causes ;
• une démonstration du produit et de ses nouvelles fonctionnalités ;
• les développements à venir sur les prochains sprints.

Les livrables de ce projet ont été validé par le mentor m’accompagnant sur le projet de formation. Le projet dans son ensemble a été validé par un évaluateur au cours d’une soutenance réalisé en Novembre 2023.