Détails sur les backlogs et les sprints en méthode Agile

Hello

une amie a un problème avec un presta web qui lui a fait un site "méthode agile". Moi je dis que le site n'est pas "fait" mais j'aimerais savoir comment on documente les backlogs et les sprints dans la méthode en question ?

 

Je reprends la gestion d'un site commandé il y a deux ans, toujours pas livré le client est furax, le presta aussi sur le thème "on aurait du mettre en prod il y a 18 mois maintenant on facture". Le "cdc" (moi j'appelle ça une déclaration d'intention, pas un CDC) dit que

"L'ensemble du projet sera basé sur une méthodologie agile."

... a priori Scrum, parce que

"Attribution des rôles
Product Owner : Un membre de l'équipe de du client . Il sera en charge de définir les priorités et de prendre les décisions lors de potentiels arbitrages.
Scrum Master et Proxy Product Owner : Un membre de notre équipe sera en
charge du respect de la méthodologie et des relations avec le Product Owner."

et
"Construction du backlog. Pour chacune des 3 phases, un product backlog découpant
l'ensemble des fonctionnalités et éléments à réaliser sera définit.
- Sprints : Le projet sera organisé sur la forme de sprints hebdomadaire"

(les fautes sont d'origine)

Mon problème actuel : je n'ai aucune spec / règle de gestion en dehors du CDC. Des trucs quand même relativement importants comme la gestion des bons de réduction, des retours, etc, ne semblent pas avoir été abordés. Les test cases sont fantomatiques, vides de consistance, sans référence aux règles de gestion à appliquer.

Donc n'étant pas une experte de la méthode agile pour un site e-commerce standard pour une PME de 5 personnes je voudrais savoir si, en théorie, toutes ces specs à construire lors des backlogs et des runs doivent être documentées et formellement validées par le Product Owner, ou si on se contente de faire des photographies des posts it sur un tableau blanc.

... sachant que le Product Owner a quitté la boite.

Amha, il y a des torts des deux côtés, ayant l'habitude de bosser à l'ancienne, j'aime bien des specs claires et (presque) complètes sur les fonctionnalités à mettre en place.

 

Si tu lis bien, je ne compte pas trop sur le CDC (qui est, en pratique, inexistant). Je cherchais justement à identifier où et comment étaient documentés les besoins, les règles de gestion, etc. et la validation des tests.

Cela dit, je ne vois pas comment on peut lancer un projet de création de site e commerce en se disant juste "on bosse pour tant d'argent dans tant de temps" sans avoir rien pour estimer les jours/hommes nécessaires pour sortir un site qui aura les fonctionnalités requises. Je n'ai même pas ça dans le soi-disant CDC, et une couverture fonctionnelle "par la négative" puisque le doc précise les domaines comme le seo ou le crm qui sont "pour plus tard". Je ne vois pas très bien comment on peut faire un site sans SEO et le rajouter plus tard ...

Et quand le projet fournit zéro valeur (pas possible de mettre en ligne) dans 5 fois le temps prévu ?

Pour te donner une idée, 15 mois après la signature, on a des filtres simples de produits comme "produits de telle marque" qui sortent des résultats faux et ne correspondant pas aux listes de produits dans le back-office (back-office dont ils ont aussi la responsabilité).

Je n'en ai strictement aucune idée, d'où ma question sur la documentation.

Ce n'est pas la question de savoir qui est le coupable. Quand ça foire à ce point là, c'est toujours un peu partagé. De plus, je ne dirais pas les choses comme ça.

Comme tu l'écris plus bas, il faut comprendre ce qu'on fait, et vu les profils du client, c'est évident qu'ils ne pouvaient pas savoir, comprendre les implications d'une telle méthode, ni le boulot à faire pour sortir des demandes correctes.

Dans ce contexte, je pense qu'une agence qui facture l'équivalent de 60 smigs locaux pour faire un site e-commerce très standard dans ses fonctionnalités, et qui attend qu'un client qui n'a aucune expérience de projet IT sorte tout seul la liste de tous les process et ne s'inquiète pas quand il n'y a pas de "user story" du type "commande livrée incomplète suite à manque de disponibilité d'un produit" manque à une obligation de conseil de base, Agile ou pas Agile. On est largement au delà du problème de transparence.

Et si j'ai bien tout suivi, au moins là dessus, le Scrum Master a manqué à son rôle de "s'assurer que tout marche bien".

Ils ont tout développé from scratch. On n'a pas la sécurité d'un CMS dont on n'aurait qu'à valider les paramètres et les éventuels développements spécifiques. Le CDC fantome dit que les besoins spécifiques (non documentés dans le dit CDC) excluent le recours à un CMS. Sur quelle base ont-ils décidé ça ? A part le fait de ne pas avoir de compétences sur Prestashop, Joomla, WooCommerce ou Magento ?

Quoi qu'il arrive, on ne va pas continuer comme ça. Je précise que "je reprends la gestion" inclut "je fais un point d'avancement et je vois si on envoie tout de suite les avocats ou si on peut sauver quelque chose".

Donc j'ai besoin de savoir ce qui a été documenté en specs et en tests. Sachant qu'on leur a vendu un suivi sous Jira et que je me retrouve avec deux feuilles excel....

Je te remercie pour ton retour. J'ai pu discuter avec d'autres personnes hier soir et j'ai une vision très claire, maintenant .