Hello, présente-toi.
Moi c’est Nicolas, et je suis chez SEI depuis bientôt 6 ans.
En quoi consiste ton rôle ?
Je suis Chef de projet, avec une spécialisation en méthodologie de projet AGILE en tant que PO (Product Owner). Je viens tout juste également d’être certifié en tant que Scrum Master. Je m’occupe de mettre en œuvre la suite logicielle AKOLADE® chez nos clients et d’enrichir fonctionnellement le produit selon la road map et les besoins clients.
Et quelle est la particularité de ta casquette « méthode AGILE » ?
La méthode AGILE (dans notre cas, en SCRUM) fournit un cadre permettant d’améliorer les processus de conception et de réduire le taux d’échec, en étant continuellement au plus proche du besoin client. L’idée première est d’apporter de la valeur au client, le plus rapidement et fréquement possible.
Afin d’être toujours au plus près du besoin client et de minimiser les risques, nous travaillons en cycles courts de développement : les sprints. Effectivement, au fil du projet, le besoin peut être amené à évoluer. Les sprints sont composés de fonctionnalités appelées « US » (User Stories). Les US ayant le plus de valeur pour le client sont développées en priorité. De cette manière, on arrive progressivement à un produit « final » en ajustant au fur et à mesure le contenu des sprints et la priorité des US. Le maître mot est l’adaptation !
La particularité de ma casquette « méthode AGILE » en tant que PO est d’aller chercher et comprendre le besoin de l’utilisateur final. Je dois pouvoir alimenter et prioriser un product backlog pertinent. La valeur de chaque US est « évaluée » en fonction d’une roadmap générale établie conjointement avec le client. Les US ayant le plus de valeur sont alors positionnées en haut du backlog. Cela permet aux développeurs d’organiser les différents ajouts de fonctionnalités (US) qui vont constituer un sprint.
Chaque US livrée à la fin de chaque sprint est le produit d’un véritable travail d’équipe : le besoin est d’abord étudié par le PO auprès du client, est ensuite décrit dans une US, puis affiné avec l’aide des développeurs / testeurs. En effet l’US est présentée par le PO aux développeurs, et sa description est complétée / ajustée avec eux. La faisabilité et le temps de développement sont estimés par les développeurs (et par personne d’autre ! ) lors d’une séance de sprint planning. On utilise la plupart du temps la méthode du planning poker avec des cartes de jeu.
Les US sont ensuite développées selon le planning établi et les développeurs mettent en place les tests unitaires : le PO teste l’US, et fait un retour aux développeurs si elle ne correspond pas au besoin. Une fois les tests OK, l’US peut être embarquée dans la livraison intermédiaire ou de fin de sprint. L’US est également, dans un deuxième temps, testée par le client.
Sur quoi tu travailles en ce moment ?
Je travaille en ce moment sur le projet Assortment : une solution dédiée à l’assortiment omnicanal, co-construite avec notre client pilote ADEO. Une solution venant enrichir la suite AKOLADE®. Ce projet est mené par une équipe composée de membres de SEI et d’ADEO, le tout dans un esprit « one team ».
Une team SEI est entièrement dédiée au projet : elle est composée d’une directrice de projet et experte fonctionnelle, de 2 développeurs, d’un technicien infrastructure, d’une tech lead intégration et de moi-même en tant que PO ! Coté ADEO : 2 product leaders, un autre PO, un Scrum Master, un responsable intégration et une test leader viennent compléter l’équipe.
L’équipe Assortment bénéficie d’une superbe dynamique, nous nous donnons les moyens de faire du bon travail, sans être physiquement au même endroit. Cette méthodologie tend à nous réunir quotidiennement, et je passe la plupart de mes journées en visio avec l’équipe. C’est très stimulant !
Une journée type en méthode AGILE Scrum, ça ressemble à quoi ?
On débute chaque journée par un daily réunissant l’équipe au complet, afin que les développeurs évoquent les points de blocage sur les US réalisés / à venir durant le sprint en cours. On organise la journée et on fait passer des messages importants si besoin ! Le daily est « timeboxé » à 15 minutes. Cela oblige à aller à l’essentiel, on est donc beaucoup plus efficace. L’objectif est d’avoir un niveau d’information commun à travers l’équipe, de pouvoir vite voir si nous sommes toujours raccord pour arriver à tenir l’objectif du sprint. Et si ce n’est pas le cas, d’enclencher des actions rapidement afin de résoudre les « irritants ». Ce cérémonial permet en plus de favoriser la communication entre les membres de l’équipe.
Je fais également régulièrement des points de synchro avec le PO ADEO : nous mettons en commun le besoin utilisateur identifié par ADEO avec la road map produit de SEI. Et nous rédigeons les User Stories ensemble.
Puis on organise des séances de refinement avec les développeurs (et si besoin, avec les experts fonctionnels). Comme je l’expliquais précédemment, c’est à cette étape que nous affinons les US. Nous vérifions également que les développeurs ont toutes les informations requises afin de pouvoir effectuer le développement.
Impliquer les développeurs en amont permet de gagner un temps considérable, et donc en efficacité : les développeurs ont en leurs mains une US « mâture », et les surprises sont donc minimisées (problèmes de faisabilité, problèmes techniques, etc.).
Enfin, on prévoit des séances de workshop avec les utilisateurs finaux : on travaille généralement avec un pays pilote pour affiner le besoin.
Évidement d’autres cérémonies sont effectuées à chaque début / fin de sprint, telles que le sprint planning, la sprint review et la sprint retrospective.