« LeSS - Le Product Owner » : différence entre les versions

De Wiki Agile
← Modification précédente
VisuelWikicode
Aucun résumé des modifications
Aucun résumé des modifications
 
(14 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Portail LeSS]]
[[Category: Portail Product Owner]]
[[Category: Portail Product Owner]]
Ligne 4 : Ligne 5 :
Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)]<br />
Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)]<br />
----
----
Traducteur : [http://www.les-traducteurs-agiles.org/traducteurs/ Nicolas Mereaux]<br />
Traducteur : Nicolas Mereaux<br />
Date : 23/06/2019<br />
Date : 23/06/2019<br />
----
----
Ligne 14 : Ligne 15 :
<br/>
<br/>
== Le Product Owner à grande échelle ==
== Le Product Owner à grande échelle ==
S’il est une chose assez répandu dans le développement de produit à grande échelle c’est que différentes personnes tirent dans différentes directions et pour des sous-groupes de se focaliser sur des sur-optimisations au niveau local. Avoir un seul Product Owner avec un seul Backlog de Produit permet de maintenir un [[Less_-_Focus_sur_le_produit_global|focus sur le produit global (fr)]].<br />
S’il est une chose assez répandue dans le développement de produit à grande échelle c’est que différentes personnes tirent dans différentes directions et pour des sous-groupes de se focaliser sur des sur-optimisations au niveau local. Avoir un seul Product Owner avec un seul Backlog de Produit permet de maintenir un [[Less_-_Focus_sur_le_produit_global|focus sur le produit global (fr)]].<br />
<br />
<br />
Dans les traditionnels groupes produit à grande échelle, nous trouvons d’une part un groupe (souvent des responsables produits - ''product managers'' -) focalisé vers l’extérieur et d’autre part un groupe (généralement les développeurs) focalisé vers l’intérieur - et jamais aucun des deux ne se rejoignent. Dans LeSS, le Product Owner unique dispose de beaucoup de temps pour se focaliser vers l’extérieur - les clients et leurs priorités - tout en étant aussi en capacité de prendre du temps pour se focaliser vers l’intérieur - les équipes. Il agit en tant que connecteur, faisant se réunir ensemble les équipes et les clients/utilisateurs afin que les équipes deviennent encore plus [[Less_-_Centré_client|orientées client (fr)]]).<br />
Dans les traditionnels groupes produit à grande échelle, nous trouvons d’une part un groupe (souvent des responsables produits - ''product managers'' -) focalisé vers l’extérieur et d’autre part un groupe (généralement les développeurs) focalisé vers l’intérieur - et jamais aucun des deux ne se rejoignent. Dans LeSS, le Product Owner unique dispose de beaucoup de temps pour se focaliser vers l’extérieur - les clients et leurs priorités - tout en étant aussi en capacité de prendre du temps pour se focaliser vers l’intérieur - les équipes. Il agit en tant que connecteur, faisant se réunir ensemble les équipes et les clients/utilisateurs afin que les équipes deviennent encore plus [[Less_-_Centré_client|orientées client (fr)]]).<br />
Ligne 21 : Ligne 22 :
<br />
<br />
== Priorisation plus que Clarification ==
== Priorisation plus que Clarification ==
Il y a deux flux d’informations-clés dans Scrum qui sont liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des éléments dans le Backlog de Produit. Dans le premier flux (priorisation), les informations liées aux centres de profits, aux clients stratégiques, aux risques métiers, et à d’autres préoccupations métiers sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pou détailler le comportement et les qualités intrinsèques des éléments, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.<br />
Il y a deux flux d’informations-clés dans Scrum qui sont liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des éléments dans le Backlog de Produit. Dans le premier flux (priorisation), les informations liées aux centres de profits, aux clients stratégiques, aux risques métiers, et à d’autres préoccupations métiers sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pour détailler le comportement et les qualités intrinsèques des éléments, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.<br />
<br />
<br />
Un Product Owner LeSS porte une réflexion accrue sur la priorisation mais collabore avec les équipes sur la clarification. De plus, il encourage et aide les équipes à entrer en communication directe avec les véritables utilisateurs et clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.<br />
Un Product Owner LeSS porte une réflexion accrue sur la priorisation mais collabore avec les équipes sur la clarification. De plus, il encourage et aide les équipes à entrer en communication directe avec les véritables utilisateurs et clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.<br />
Ligne 50 : Ligne 51 :
L’illustration suivante montre le Product Owner dans différentes organisations :<br />
L’illustration suivante montre le Product Owner dans différentes organisations :<br />
<br />
<br />
[[Fichier:Who-is-the-po-fr.jpg.jpg|800px|Qui est le PO]]<br />
[[Fichier:Who-is-the-po-fr.jpg.jpg|800px|Qui est le PO|link=]]<br />
<br />
<br />
Dans tous les cas, un super Product Owner est une personne passionnée par le produit.<br />
Dans tous les cas, un super Product Owner est une personne passionnée par le produit.<br />
Ligne 61 : Ligne 62 :
== Cinq types de relations ==
== Cinq types de relations ==
Le Product Owner doit être en mesure de comprendre et travailler pour améliorer les cinq types de relations clés impactées par l’adoption de LeSS :
Le Product Owner doit être en mesure de comprendre et travailler pour améliorer les cinq types de relations clés impactées par l’adoption de LeSS :
[[Fichier:Les différents types de relation du Product Owner.png|600px|Les différents types de relation du Product Owner]]<br />
[[Fichier:Les différents types de relation du Product Owner.png|600px|Les différents types de relation du Product Owner|link=]]<br />
<br />
<br />
<ul>
<ul>
<li><p>'''Product Owner &harr; équipes'''</p>
<li><p>'''Product Owner &harr; Équipes'''</p>
<p>The teams are there to help the Product Owner create the best possible product for the customer. They need to know what to build next and whether or not what they have already built has hit the mark. The Product Owner needs to know what the teams need and how she can help them.</p>
<p>Les équipes sont là pour aider le Product Owner à créer le meilleur produit possible pour le client. Elles doivent savoir quoi construire par la suite et si oui ou non ce qu’elles ont déjà réalisé a déjà atteint l'objectif. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.</p></li>
<p>Les équipes sont là pour aider le Product Owner à créer le meilleur produit possible pour le client. Elles doivent savoir quoi construire par la suite et si oui ou non ce qu’elles ont déjà réalisé a déjà fait mouche. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.</p></li>
<li><p>'''Product Owner &harr; Clients'''</p>
<li><p>'''Product Owner&lt;–&gt;Customers'''</p></li>
<p>Le Product Owner et les équipes essayent de créer le meilleur produit possible pour le client. Le client a besoin de savoir quand il aura les fonctionnalités qu’il souhaite, et peut être aussi le raisonnement sous-jacent aux priorités. Impliquez-les le plus possible en étant transparent. Le Product Owner doit apprendre leurs véritables objectifs ou problèmes en étant avec eux (ou entrevoir quelque chose au-delà même de leur vision) et collecter l’information qui l'aidera à bien prioriser.</p></li>
<li><p>'''Product Owner &lt;-&gt; Clients'''</p>
<li><p>'''Équipes &harr; Clients'''</p>
<p>The Product Owner and teams are trying to create the best possible product for the customer. The customer needs to know when they will have features they care about, and perhaps the reasoning behind the priorities. Involve them as much as possible by being transparent. The Product Owner needs to learn their real goals or problems with them (or envision something beyond their vision) and collect the information that will help him prioritize well.</p>
<p>Les équipes essayent de créer le meilleur produit pour le client. Elles doivent connaître le contexte des fonctionnalités et avoir une connaissance détaillée du domaine. Idéalement, les équipes co-créent les solutions directement avec les clients en capturant l’essence même (plutôt que la surface) des objectifs et des problèmes des clients. Les équipes doivent confirmer avec les clients qu’elles ont bien compris les exigences clarifiées ensemble.</p></li>
<p>Le Product Owner et les équipes essayent de créer le meilleur produit possible pour le client. Le client a besoin de savoir lorsqu’il aura les fonctionnalités qu’il souhaite, et peut être aussi quelles sont les raisons sous-jacentes aux priorités. Impliquez-les le plus possible en étant transparent. Le Product Owner doit apprendre leurs vrais objectifs ou leurs vrais problèmes avec eux (ou prévoir quelque chose au-delà de leur vision) et collecter l’information qui les aidera à bien prioriser.</p></li>
<li><p>'''Product Owner &harr; Hiérarchie'''</p>
<li><p>'''Teams&lt;–&gt;Customers'''</p></li>
<p>La hiérarchie au-dessus du groupe produit (responsables portefeuilles, cadres dirigeants, etc.) devraient considérer le Product Owner comme étant la personne qui a la responsabilité finale quant à la réussite du produit et qui doit en rendre compte. Il est responsable pour donner de la visibilité sur l'état d'avancement du développement et concrétiser le mandat (peut-être implicite) de la hiérarchie pour optimiser les impacts souhaités (par exemple, le ROI et les parts de marché). Le Product Owner, avec le soutien des Scrum Masters implique la hiérarchie pour aider à améliorer la structure de l’organisation.</p></li>
<li><p>'''équipes &lt;-&gt; clients'''</p>
<li><p>'''Product Owner &harr; Scrum Masters'''</p>
<p>The teams are trying to create the best possible product for the customer. They need to know the context for features and have detailed domain knowledge. Ideally, teams co-create solutions directly with customers by grasping the customers’ essential (rather than superficial) goals and problems. Teams need to confirm with customers that they fully understand the requirements they are clarifying together.</p>
<p>Les relations décrites ci-dessus font partie intégrante de l’art d’être Product Owner (ou “product ownership”), mais celle-ci est différente. Elle concerne les connaissances et le comportement du Product Owner. Les Scrum Masters doivent connaître les préoccupations, les questions et les obstacles du Product Owner afin d’être en mesure de l’aider. Un bon Scrum Master doit être une oreille bienveillante ou une épaule amicale sur laquelle pleurer. Les Scrum Masters éduquent et donnent du feedback au Product Owner afin qu’il puisse s’adapter en conséquence.</p></li></ul>
<p>Les équipes essayent de créer le meilleur produit pour le client. Elles doivent connaître le contexte des fonctionnalités et avoir une connaissance détaillée du domaine. Idéalement, les équipes co-créent les solutions directement avec les clients en capturant l’essence même (plutôt que le seul côté superficiel) des objectifs et des problèmes des clients. Les équipes doivent confirmer avec les clients qu’elles ont bien compris les exigences clarifiées ensemble.</p></li>
<li><p>'''Product Owner&lt;–&gt;Higher Management'''</p></li>
<li><p>'''Product Owner &lt;-&gt; encadrement plus haut dans la hiérarchie'''</p>
<p>Higher management beyond the product group (portfolio managers, C-level executives, etc.) should view the Product Owner as having the final accountability and responsibility for product success. She is responsible for making the development status visible and realizing higher management’s (perhaps implicit) mandate to optimize desired impacts (e.g., ROI and market share). The Product Owner, with support from Scrum Masters, engages higher management’s help to improve the organizational design.</p>
<p>Les supérieurs hiérarchiques au-dessus du groupe produit (responsables portefeuilles, cadres dirigeants, etc.) devraient considérer le Product Owner comme étant la personne qui a la responsabilité finale quant à la réussite du produit et qui doit en rendre compte. Il est responsable pour rendre le statut du développement visible et concrétiser le mandat des supérieurs hiérarchiques (qui est peut être implicite) pour optimiser les impacts souhaités (par exemple, le ROI et la part de marché). Le Product Owner, avec le support des Scrum Masters implique ces supérieurs hiérarchiques dans l’aide qu’ils peuvent apporter pour améliorer la structure de l’organisation.</p></li>
<li><p>'''Product Owner&lt;-&gt;Scrum Masters'''</p></li>
<li><p>'''Product Owner &lt;-&gt; Scrum Masters'''</p>
<p>The relationships above are directly related to “product ownership,” but this one is different. It relates to Product Owner knowledge and behavior. The Scrum Masters need to know the Product Owner’s concerns, questions, and obstacles so they can help. A good Scrum Master can be a friendly ear or a shoulder to cry on. Scrum Masters educate and feed back so Product Owners can adapt.</p>
<p>Les relations décrites ci-dessus font partie intégrante de l’art d’être Product Owner (ou “product ownership”), mais celle-ci est différente. Elle concerne les connaissances et le comportement du Product Owner. Les Scrum Masters doivent connaître les préoccupations, les questions et les obstacles du Product Owner afin d’être en mesure de l’aider. Un bon Scrum Master doit être une oreille bienveillante ou une épaule amicale sur laquelle pleurer. Les Scrum Masters éduquent et donnent des retours d’informations au Product Owner afin qu’il puisse s’adapter en conséquence.</p></li></ul>
 
== LeSS Meetings ==
 
== Les réunions LeSS ==
 
When we introduce LeSS, a frequent question is, “How is one Product Owner going to manage all of those meetings with all of those teams?” Fortunately, the concern behind that question is based on a misunderstanding. The one Product Owner in LeSS only attends single meetings even though there are multiple teams. And the number of team members at those single meetings is manageable. If there are just two teams, everyone can effectively attend and participate. If there are many teams, only two representatives from each team may attend.
 
Lorsque nous présentons LeSS, une question qui revient souvent est : “Comment un seul Product Owner peut-il gérer toutes ces réunions avec toutes ces équipes ?”. Fort heureusement, l’inquiétude qui se cache derrière cette question est qu’elle est basée en fait sur un malentendu. Le seul et unique Product Owner en LeSS assiste uniquement à des réunions individuelles même si c’est avec plusieurs équipes. Et le nombre d’équipiers dans ces réunions est gérable. S’il y a seulement deux équipes, tout le monde peut effectivement être présent et participer. S’il y a plusieurs équipes, deux représentants seulement de chaque équipe peut être présent.
 
What LeSS meetings does the Product Owner attend and what is their average duration in a typical two-week Sprint?


== Les Réunions LeSS ==
Lorsque nous présentons LeSS, une question qui revient souvent est : "Comment un seul Product Owner peut-il gérer toutes ces réunions avec toutes ces équipes ?". Fort heureusement, l’inquiétude qui se cache derrière cette question est qu’elle est basée en fait sur un malentendu. Le seul et unique Product Owner en LeSS assiste uniquement à des réunions individuelles même si c’est avec plusieurs équipes. Et le nombre d’équipiers dans ces réunions est gérable. S’il y a seulement deux équipes, tout le monde peut effectivement être présent et participer. S’il y a plusieurs équipes, deux représentants seulement de chaque équipe peuvent être présents.<br/>
<br/>
Quelles sont les réunions LeSS auxquelles un Product Owner assiste et quelles sont les durées moyennes dans un Sprint type de deux semaines ?
Quelles sont les réunions LeSS auxquelles un Product Owner assiste et quelles sont les durées moyennes dans un Sprint type de deux semaines ?
 
* [[LeSS_-_La_Planification_du_Sprint_(1ère_partie)|La Planification du Sprint (1ère partie) (fr)]] - 1 heure.
* [https://less.works/less/framework/sprint-planning-one.html Sprint Planning One] - 1 hour.
* [[LeSS_-_L%27Affinage_du_Backlog_Produit|L’Affinage Global du Backlog Produit (fr)]] - 4 heures.
* [https://less.works/less/framework/product-backlog-refinement.html Overall Product Backlog Refinement (PBR)] - 4 hours
* [[LeSS_-_La_Revue_de_Sprint|La Revue de Sprint (fr)]]] - 2 heures.
* [https://less.works/less/framework/sprint-review.html Sprint Review] - 2 hours.
* [[LeSS_-_La_Rétrospective_Globale|La Rétrospective Globale (fr)]] - 1,5 heure.
* [https://less.works/less/framework/overall-retrospective.html Overall Retrospective] - 1.5 hours.
Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines.<br/>
 
<br/>
---
Le Product Owner ne participe pas aux réunions spécifiques des équipes que sont : [[LeSS_-_La_Planification_du_Sprint_(2ème_partie)|la Planification du Sprint (2ème partie) (fr)]], [[LeSS_-_La_Mêlée_Quotidienne|la Mêlée Quotidienne (fr)]], [[LeSS_-_L%27Affinage_du_Backlog_Produit|les Affinages de backlog faits par les équipes (fr)]], [[LeSS_-_La_Rétrospective|les Rétrospectives des équipes (fr)]].
 
* [http://www.les-traducteurs-agiles.org/2017/03/09/less-la-planification-du-sprint-1ere-partie.html La Planification du Sprint (1ère partie)] - 1 heure.
* [http://www.les-traducteurs-agiles.org/2018/01/26/less-l-affinage-du-backlog-produit.html L’Affinage du Backlog Produit] - 4 heures
* [http://www.les-traducteurs-agiles.org/2017/08/30/less-la-revue-de-sprint.html La Revue de Sprint] - 2 heures.
* [http://www.les-traducteurs-agiles.org/2017/04/13/less-la-retrospective-globale.html La Rétrospective Globale] - 1.5 heures.
 
So the total time spent in LeSS events is, on average, about eight hours in a two-week Sprint.
 
Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines.
 
The Product Owner does not attend the team-specific meetings: [https://less.works/less/framework/sprint-planning-two.html Sprint Planning Two], [https://less.works/less/framework/daily-scrum.html Daily Scrums], [https://less.works/less/framework/product-backlog-refinement.html team PBRs], [https://less.works/less/framework/retrospective.html team Retrospectives].
 
Le Product Owner ne participe pas aux réunions spécifiques d’équipe que sont : [http://www.les-traducteurs-agiles.org/2017/03/10/less-la-planification-du-sprint-2eme-partie.html La Planification du Sprint (2ème partie)], [http://www.les-traducteurs-agiles.org/2017/04/17/less-la-melee-quotidienne.html La Mêlée Quotidienne], [http://www.les-traducteurs-agiles.org/2018/01/26/less-l-affinage-du-backlog-produit.html les affinages de backlog faits par l’équipe], [http://www.les-traducteurs-agiles.org/2017/04/15/less-la-retrospective.html les rétrospectives d’équipe].
Récupérée de "https://wikiagile.coach/LeSS_-_Le_Product_Owner"