Discussion :

[Thomas1434]

Bonjour à tous !

Alors voilà, mon entreprise vient d'adopter la méthodologie Agile. Nous sommes l'équipe pilote.

A priori (même si évidemment on progresse chaque jour), tout se passe plutôt pas mal au sein de l'équipe. Par contre, côté utilisateurs, c'est pas trop ça. Il y a, je pense, de la bonne volonté mais le niveau d'implication est loin d'être celui attendu.

Pour la fin du mois, on me demande d'organiser une sorte 'rétro' qui, on l'espère, servirait d'électrochoc.

_Qui inviter ? (manageurs, utilisateurs réguliers, etc.)
_Comment leur faire prendre conscience de leur importance (jeux, mise en situation, etc.) ?
_Quelles solutions pour les impliquer davantage (forum, wiki, meeting réguliers, etc.) sans que cela devienne trop contraignant
_Etc.

N'hésitez pas à me demande plus d'infos si nécessaire et à partager vos liens et expériences

Un grand merci !

[emmaus]

Salut thomas,
je sais pas vraiment ce que tu cherches à transmettre à ton équipe mais s'il s'agit de leur faire prendre conscience des avantages de cette méthode, tu peux commencer par lire ceci : http://ineumann.developpez.com/tutor...m/agile_scrum/
bonne réussite pour la suite.

[Luckyluke34]

Hello

Normalement, tu dois avoir un Product Owner qui représente les utilisateurs, possède le pouvoir de décision fonctionnel et tient les cordons de la bourse. Il est indispensable qu'il soit présent aux réunions de fin d'itération aux côtés du Scrum Master et de l'équipe.

Concernant l'implication des utilisateurs finaux, j'ai envie de dire que ce n'est pas trop de la responsabilité de l'équipe. Le Scrum Master peut essayer de susciter un intérêt en invitant du monde aux démos, mais il faut bien leur faire comprendre qu'ils n'ont qu'un pouvoir de suggestion. C'est le Product Owner qui a le dernier mot. En bon chef de produit, c'est aussi le PO qui devrait motiver et évangéliser sur le logiciel.

Donc inviter des utilisateurs et managers en fin de sprint : oui, mais que pour la démo. Leurs retours sont importants mais ils doivent savoir qu'ils ne seront pas forcément implémentés tels quels.

Garder les "invités" pour la partie rétrospective, je l'ai déjà fait, c'est gênant pour l'équipe parce que la rétro est censée se concentrer sur leur travail en interne pendant le sprint écoulé, pas sur des questions fonctionnelles pour le futur. Ca, c'est le boulot du PO qui le fait à un autre moment, à part, loin de l'équipe de dev.

[Luckyluke34]

Sur le Product Owner lui-même, j'ai ce bouquin qui est très bien mais je ne me souviens plus s'il parle de l'interaction avec les utilisateurs, je checkerai ce soir

https://www.amazon.com/Agile-Product...sap_bc?ie=UTF8

[Luckyluke34]

PS : j'avais cru voir Scrum dans la question, c'est pour ça que j'ai répondu là-dessus. Mais je m'aperçois que tu n'as pas précisé la méthode ?

[randriano]

Très bonne question ce sujet.

On a beau vouloir être agile, le client n'est pas très réactif! J'ai expérimenté cela avec des clients qui étaient des organismes publics, très bureaucratiques. On a beau avoir un Product Owner des deux côtés, le prestataire qui développe le produit et une personne de contact chez le ministère qui est en quelque sorte un Product owner aussi, mais au final il se dit qu'il n'est pas décideur du tout, il y a une hiérarchie de validation!

[el_slapper]

le problème de l'agile, c'est que tout le monde doit l'être pour que ça marche.

J'étais sur un projet en waterfall(une refonte complète, ça se prêtait assez bien au waterfall, ce qui n'est pas si fréquent). et puis l'équipe agile a un besoin urgent tout de suite sur mon périmètre, et je dois abandonner mon planning, passer une semaine à les sortir de la mouise, avant de revenir à mon petit waterfall. Que j'ai quand même réussi à livrer dans les temps, mais ce fut fort juste. Mes chefs étaient furax. Et je les comprends.

[Vincent PETIT]

Salut,

N'hésitez pas à me demande plus d'infos si nécessaire et à partager vos liens et expériences

Attention Ce qui va suivre n'est pas une blague Dans cette discussion https://www.developpez.net/forums/d1.../#post10257875

Un projet agile ça se passe comme ça :

Client : J'ai besoin d'une table
MOA : on a besoin d'une table
MOE : Fait une table
Développeur : j'ai fait une table
MOE : il a fait une table
MOA : voilà votre table
Client : mais la table passe pas ma porte ...
MOA : faut que la table passe la porte (voyons c'est évident)
MOE : La table doit passer la porte !
Développeur : Voilà, la table passe la porte
.
.
.

Et côté client, car je suis dans une très très grosse boîte, bah ça se passe comme ça :

Client : J'ai enfin eu la table, elle passe la porte cette fois !
Chef d'agence : Mince on a pas spécifier la hauteur...
Chef de groupe : Oups il manque un pied
Chef d'équipe : Aie... elle est ronde
L'équipe d'utilisateurs : Nan mais quelle bande de con, on demande 5 chaises et on se retrouve avec une grande table ronde, à 3 pieds et qui fait 2m de haut !
Chef d'équipe : On va faire modifier et faire un découpage en 5
Chef de groupe : On va profiter de la modification pour changer la couleur, car l'éclairage de la pièce est trop sombre
Chef d'agence : Bonne idée, et un bord de table droit serait un plus pour la mettre contre un mur.
Client : Il faudrait faire 5 trous carrés, et surtout carrés, dans la table pour améliorer l'éclairage et ajouter un bord droit quelque part dans dans le coin de la table ronde ! Et attention a ce que ça passe dans la porte cette fois ci !
.
.
.

Arriver à créer de l'implication avec des utilisateurs qui subissent ça, ça va être compliqué.

[randriano]

Salut,

Attention Ce qui va suivre n'est pas une blague Dans cette discussion https://www.developpez.net/forums/d1.../#post10257875

Je ne pense pas que c'est du cycle V qu'ils font mais un Agile à leur manière (pas forcément Scrum ou une méthodologie connue).

Faire de l'Agile avec autant d'intermédiaires est effectivement difficile: MOE - MOA.

un cauchemar pour les développeurs qui subissent tout => cela ne devrait pas être le cas avec un bon Product Owner en méthodo Scrum!