Etre un Client sur site ou un Product Owner efficace

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
Auteur : Simon Baker
Source : Being an effective Onsite Customer or Product Owner
Date : 31/08/2005

Traducteur : Fabrice Aimetti
Date : 17/11/2010


Traduction :

Les projets Agile demande une Réelle Implication du Client. Pour être un Client sur site ou un Product Owner efficace, vous devez être soit un vrai client, soit être en mesure de représenter fidèlement le vrai client. Vous devez accepter le statut élevé que vous détenez et accepter les responsabilités qui l'accompagnent (Responsabilité Acceptée). Vous devez être un intervenant et un membre à part entière de l'équipe. Vous devez être accessible et vous devez participer au projet de manière proactive et continue. Vous devez reconnaître que grâce à vos actions - écrire des stories et des tests d'acceptation, prioriser des user stories selon la valeur métier, décider quelles user stories doivent être ensuite développées, fournir des retours rapidement, .... - vous pilotez effectivement le projet et vous êtes finalement le responsable de la valeur métier livrée. En tant que véritable force motrice du projet, votre présence doit être visible, verbale et objective.

La communication est une valeur "agile" et la collaboration est un comportement intrinsèque qui contribue à la réussite des équipes agiles. En tant que Client sur site, vous devez démontrer dès le départ que vous êtes un membre comme les autres de l'équipe. Respectez les rendez-vous de l'équipe. N'évitez pas les activités liées au métier, par exemple, écrire des stories pour les développeurs. Les développeurs peuvent vous aider dans cette activité particulière, mais en tant que représentant métier et décideur sur ce qui constitue de la valeur ajoutée pour l'entreprise, vous devez prendre les décisions métier et veiller à ce que les exigences soient clairement communiquées et comprises. Certaines des informations à forte valeur ajoutée sont transmises au travers de simples conversations qui se produisent tout le temps dans la War Room. Vous pouvez ramasser ces pépites par effet d'osmose si vous êtes au même endroit que l'équipe. Communiquez la vision du projet à l'équipe en utilisant des objectifs clairs et ambitieux (Larsen, LaFasto) afin que l'équipe soit mieux préparée pour les réaliser.

Vous devez avoir des ambitions élevées et demandez un code complet et démontrable à la fin de chaque itération. Insistez sur une grande couverture des tests (entre 80 et 100%), des tests unitaires et d'acceptation automatisés, des builds automatisés, une intégration continue et une visibilité claire sur l'état d'avancement. Présentez à l'équipe des défis qui dynamiseront leurs efforts. Ne fixez pas des objectifs irréalisables et soyez toujours prêt à écouter, à négocier et à accepter des compromis. Ne fixez pas des délais impossibles à tenir ou attendez-vous à ce que les développeurs réduisent la qualité de leur travail. Un développement qui est précipité devra inévitablement être débogué ultérieurement, donc le coût du projet sera plus élevé.
Définissez des priorités claires fondées sur la valeur métier et vous aurez une équipe qui saura livrer les stories de plus grande valeur ajoutée en premier. Mais comprenez et évaluez les risques avant de juger. Les priorités sont relatives, donc si vous dites que tout a une "priorité maximale", vous ne faites pas votre travail correctement. Dans cette situation, vous pouvez vous attendre à recevoir un ensemble arbitraire de user stories complètes et incomplètes à la fin. Insistez pour connaître le coût d'une story avant de la prioriser. Demandez aux développeurs d'estimer les user stories à l'aide d'une échelle d'unités telle que les points de story (cette technique fournit des estimations relatives rapidement, mais comprenez qu'il y aura une plus grande tolérance à l'inexactitude compte tenu de la taille et une ambiguïté potentielle sur les user stories à ce stade). Vous avez le droit de changer d'avis, mais prenez une décision et évitez de faire des changements aléatoires. Les changements se produiront pour de nombreuses et différentes raisons, donc réévaluez régulièrement et rapidement vos priorités.

Pour simplifier la planification, vous devez définir les fonctionnalités sous forme de user stories de sorte que l'équipe puisse les estimer. Apprenez à écrire des user stories correctement et pratiquez en les détaillant au fur et à mesure des discussions et des conversations avec les développeurs. Pratiquez et exprimez ces détails sous forme de tests d'acceptation.

Apportez du soutien, des encouragements et de la reconnaissance à l'équipe à la fois par vos paroles et vos actions. Saisissez toutes les occasions et ne vous économisez pas jusqu'à la fin du projet. Cela motivera les membres de l'équipe à faire de leur mieux pour vous au fur et à mesure que le projet progresse.