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

[Marie-Aude]

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 ?

 

[erwinol2]

Méthode agile, c'est hyper vague, il y a beaucoup de méthodes agiles. C'est SCRUM ? Prince2 ?
Quand tu parles de backlog, tu parles de Product Backlog ou de Sprint backlog ?
Que veux-tu dire par "documenter" ?

 

[Marie-Aude]

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.

 

[passion]

L'Agilité p-e une bonne solution à condition effectivement d'encadrer le contexte.
Les informaticiens aiment bien employer des mots anglophones, ça fait plus : "tais-toi... tu ne peux pas comprendre et ça permet d'enfumer si le client ne comprend pas la méthodologie !"
ça à l'air d'être plus ou moins le cas.
On ne parle plus de chef de projet, de client... mais scrum master, product owner mais les rôles restent les mêmes.
Une méthode Agile peut être utilisée mais dans un contexte précis.
Je m'explique...
Il faut tout d'abord un CDC pour délimiter les fonctionnalités et le périmètre de chacune d'entre elles ensuite pour le dev de chaque fonctionnalité, effectivement une méthode Agile peut être employée. De cette façon, le client peut voir l'évolution et participer/valider cette fonctionnalité.
Une fois validé, on passe à la fonctionnalité suivante and so far...

ça demandera TOUJOURS plus de temps car il faut prendre en compte les allers-retours clients et ça peut demander des modifs car le client appréciera plus facilement une fonctionnalité en test bêta. Mais c'est là que le CDC interviendra pour recadrer le client et faire un avenant contrat si nécessaire.

Un projet Agile coutera plus cher car il prend en compte la demande évolutive client.

Travailler en Agilité dans une équipe, c'est la merde assurée. Il n'y a plus de hiérarchie mais on parle plutôt d'un pôle de compétences où tous les collaborateurs peuvent intervenir pour faire bénéficier l'équipe de leurs idées et point de vue. C'est partir du principe que l'utilité commune prime sur la compétence d'une personne en particulier. C'est partir du principe que c'est formateur pour monter en compétences

 

[erwinol2]

Il y a beaucoup d'approximations dans tout ça.

Déjà pour moi, trop compter sur le cahier des charges est une erreur quand tu es supposé agile. Ton projet va évoluer dans le temps.

En traditionnel (Waterfall), tu fixes ce que tu veux et puis ton budget et ta deadline en découlent.
En agile (SCRUM ici), tu fixes le budget et la deadline et c'est le résultat que tu obtiens en fin de compte qui est variable, en fonction du déroulement des sprints et des virages qui auront été pris durant le projet.

Le Product Owner est supposé maximiser la valeur apportée et donc prendre des décisions au fil de l'eau (agilitié, inspection, adaptation) de manière à sortir le projet qui fournit le plus de valeur possible dans le contexte fixé (budget / deadline).

Le problème que je vois ici c'est qu'avec un PO chez vous et un Proxy PO chez le presta, c'est compliqué à moins que chacun joue son rôle à fond. Ce fonctionnement leur permet de ne pas totalement faire preuve de transparence et ne te permet pas d'identifier les problèmes à l'avance (d'où ta situation). Ca va en fait à l'encontre des valeurs du SCRUM.

Ton prédécesseur a bien assisté à toutes les reviews (démos) à la fin de chaque sprint ? Il en a vu l'avancement ? A pu commenter le backlog et avoir une vision sur le projet au fil du temps ?

Si oui, il y a eu un gros manque d'engagement de votre côté. Sinon il y a eu un problème de transparence du leur.

D'ailleurs c'est pour ça que SCRUM fonctionne très bien pour des projets internes mais est plus compliqué à mettre en place avec des prestataires. Je suis Product Owner de 2 produits et SCRUM nous permet de délivrer un maximum de valeur tout en responsabilisant l'équipe. Mais ça nécessite d'abord de comprendre ce qu'on fait

 

[Marie-Aude]

Déjà pour moi, trop compter sur le cahier des charges est une erreur quand tu es supposé agile. Ton projet va évoluer dans le temps.

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 ...

Le Product Owner est supposé maximiser la valeur apportée et donc prendre des décisions au fil de l'eau (agilitié, inspection, adaptation) de manière à sortir le projet qui fournit le plus de valeur possible dans le contexte fixé (budget / deadline).

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é).

Ton prédécesseur a bien assisté à toutes les reviews (démos) à la fin de chaque sprint ? Il en a vu l'avancement ? A pu commenter le backlog et avoir une vision sur le projet au fil du temps ?

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

Si oui, il y a eu un gros manque d'engagement de votre côté. Sinon il y a eu un problème de transparence du leur.

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 .