Posts Tagged ‘Product owner’

h1

Scrum Master! Scrum Master! et le Product owner dans tout cela!

janvier 2, 2013

Scrum se répand de plus en plus dans les équipes de développement.
Les scrum master sont formés en place, et sont la plupart du temps les anciens chef de projet.

Mais le Product Owner est oublié dans cette transformation. L’équipe de développement parle au développement avec le Scrum Master, c’est un bon moyen pour démarrer la mise en place des pratiques Scrum et de former l’équipe. Mais les équipes métier ou leurs représentants ne sont pas complètement intégrés et restent trop éloignés des développeurs.

« Utiliser les product owner dans les projets !! » sera mon cri du jour. Et pas un product owner pour 50 personnes mais pour les 8 à 10 personnes qui forment une équipe.

Ces organisations proviennent peut être du fait que le rôle et l’importance du PO sont mal compris. Après tout, quelles sont les activités d’un PO?
Un product owner a un rôle, au risque de me répéter, INDISPENSABLE pour une équipe Scrum. Voici ci-dessous une liste non exhaustive de ses attributions:

De manière générale:

  • Le PO est le pourvoyeur de la vision du produit fini pour ses équipes. Il identifie les thèmes, les épics et les users stories permettant de livrer un produit fini. Il priorise, fournit la valeur métier et accepte de faire des trade off, ajouter et retirer des user stories. Il élabore les critères d’acceptation qui permettront de finaliser les US, et travaille avec un testeur pour élaborer les tests fonctionnels qui seront automatisés. Il prépare une stratégie de test en collaboration avec le Scrum Master et le testeur.

Plus particulièrement:

  • Design de l’interface graphique: Travail en collaboration avec le marketing, un ergonome et un graphiste pour élaborer la nouvelle interface graphique, découpe cette nouvelle interface graphique en User Story pour implémentation.
  • Décrit les besoins métiers et organise ses story maps.
  • Travaille son backlog, l’affine en permanence et fournit les valeurs métiers de chacune des User story
  • Communique sa vision à l’équipe de développement, et dialogue avec elle dès que nécessaire
  • Participe à l’élaboration du planning de sprint, aux démonstrations et rétrospective de l’équipe.
  • Communique très régulièrement avec ses clients internes ou externes, améliore sa connaissance du métier et de ses clients.
  • Teste les versions intermédiaires
  • Accepte  ou rejette les user story développées, trace et suit la résolution des défauts identifiés

Alors ? Comment peut-on se passer de ce rôle au sein d’une équipe de développement aujourd’hui ? Moi, je ne sais plus faire sans.

Publicités
h1

Agile product ownership in a nutshell

janvier 2, 2013

Je ne peux que me faire le relais de cette vidéo, elle explique tout ce qu’il faut aux néophytes et pour les autres c’est un excellent refesher!!

h1

Le métier n’a pas le temps !

janvier 2, 2013

Me voici dans le monde du conseil et les raisons pour lesquelles les clients font appel à nous sont systématiquement les mêmes. « Nous sommes de plus en plus soumis à des contraintes. Nos projets grossissent et se démultiplient avec un nombre croissant de plateformes à supporter…Nous n’y arrivons plus. Comment peut-on réduire nos coûts et nos délais avec l’agilité? »

Les premières choses que je cherche à comprendre chez ces clients sont leur organisation et l’empreinte des méthodes qualités qu’ils utilisent. Certains clients multiplient les méthodes qualités sans pour autant parvenir à de bons résultats.

La seconde chose que j’essaie de comprendre est la collaboration qui existent entre les différentes équipes. Et chez la plupart d’entre eux la collaboration entre le métier et les équipes de développement est quasiment inexistante… les équipes d’assemblage et d’intégration sont sous l’eau et les développeurs avancent sans intégration continue…

Effectivement il est temps de se poser les bonnes questions et de prendre du recul, et de commencer à tracer la route vers le succès, car le succès est possible.

D’ailleurs doit on parler d’agilité ou de pratiques agiles, ou tout simplement de pragmatisme.

Est-il normal que les personnes métiers n’interviennent pas en cours de développement et n’est pas de droit de regard?
Dans mes activités de développement, le métier est indispensable. C’est lui qui est porteur de la vision du produit fini, qui a la connaissance du client final, de ses attentes et de ses usages.
Quand je fais cette remarque, on me répond systématiquement:
Client: « Le métier n’a pas le temps. »
Moi: « Mais que fait le métier? »
Client: « Il prépare les spécifications de la prochaine version. »
Moi: « Mais vous avez déjà 2 versions en suspend, que vous ne parvenez pas à terminer. A quoi cela sert-il? »

Le vieux proverbe français s’est toujours vérifié: « A vouloir courrir après 2 lièvres à la fois, on risque d’en attraper aucun. »
1 – Concentrer vos forces vives sur les problèmes actuels et non futurs. Certains utilisent le concept de War room pour sortir des applications en retard et critiques. L’objectif est de réunir dans une même salle, le métier, les développeurs, les testeurs, intégrateurs… et de fixer les problèmes les uns après les autres. C’est un moyen efficace pour sortir des situations de crise.
2 – Le métier n’est vraiment pas disponible, utilisez alors un représentant ayant de bonnes connaissances métier. Il aura un rapport privilégié avec le métier et sera présent en permanence avec les équipes de développement.
3 – Instaurer des lieux, des moments de rencontre et d’échanges entre les développeurs et le métier. Les développeurs ont besoin de comprendre les aboutissants du produit pour faire du soft de qualité. Ne vous privez pas des idées des développeurs.
4 – Demander à voir régulièrement les productions réalisées en cours de développement, il est beaucoup plus facile de corriger une erreur tout de suite, quand le développeur se souvient encore du code, et qu’il a le nez dedans, plutôt que quand le développement est terminé.
Le développeur sera obligé de compiler et livrer son code de manière régulière et corrigera de lui-même les problèmes qu’il aura trouvé en le testant avant de vous le montrer. Et hop! une partie de bugs et défauts en moins.

A tous les amis agilistes, vous reconnaîtrez ici les notions d’équipe intégrée, de product owner, pluridisciplinaire, de démonstration, d’intégrations régulières et de démonstration. C’est déjà un très bon début pour qui veut progresser.

La réduction des coûts commence par la réalisation de logiciel correspondant aux besoins du client. Aller à l’essentiel est un bon moyen de réduire les délais, ce qui mécaniquement réduit les coûts des projets.
Intégrer et démontrer sont des activités indispensables pour obtenir du feedback régulier et obtenir des validations partielles sur les créations de l’équipe de développement.