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

De Wiki Agile
Aller à la navigation Aller à la recherche
VisuelWikicode
Page créée avec « Auteur : The LeSS Company B.V.<br /> Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)]<br /> <hr /> Traducteur : [http://www.les-traduct... »
 
Aucun résumé des modifications
 
(31 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Portail Product Owner]]
Auteur : The LeSS Company B.V.<br />
Auteur : The LeSS Company B.V.<br />
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 />
<hr />
----
Traducteur : [http://www.les-traducteurs-agiles.org/traducteurs/ Nicolas Mereaux]<br />
Traducteur : Nicolas Mereaux<br />
Date de traduction : 23/06/2019<br />
Date : 23/06/2019<br />
<hr />
----
 
Traduction :<br />
 
<br />
The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.
[[LeSS - Portail Framework]]<br />
 
<br />
Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une équipe Scrum solo. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de s’assurer un retour sur investissement (ROI) maximum au niveau du produit.
Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une unique équipe Scrum. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de garantir un retour sur investissement (ROI) maximum au niveau du produit.<br/>
 
<br/>
== Scaled Product Owner ==
 
== Le Product Owner à grande échelle ==
== Le Product Owner à grande échelle ==
 
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 />
It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports [https://less.works/less/principles/whole-product-focus.html whole-product focus].
<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 />
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 [http://www.les-traducteurs-agiles.org/2018/10/11/less-focus-sur-le-produit-global.html focus sur le produit global].
<br />
 
Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité.<br />
In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more [https://less.works/less/principles/customer-centric.html customer focused].
<br />
 
== Priorisation plus que Clarification ==
Dans les groupes produit à grande échelle rencontrés traditionnellement, 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 [orientées clients]https://less.works/less/principles/customer-centric.html).
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 />
In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.
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 />
 
<br />
Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité.
Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations liée au passage de relais, (2) encourager la co-création de solutions aux problèmes réels des clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux.<br />
 
<br />
== Prioritization over Clarification ==
Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités stratégiques.<br />
 
<br />
== Priorisation plus que clarification ==
== Trouver un Product Owner en fonction de votre type de développement ==
 
There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.
 
Il y a deux flux d’informations-clés dans Scrum liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des items 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 business 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 items, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.
 
A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, she encourages and helps the teams enter into a direct conversation with true users and customers for clarification. She acts as a connector, not an intermediary.
 
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 vrais utilisateurs et les vrais clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.
 
Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.
 
Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations par le passage de relais, (2) encourager la co-création de solutions aux problèmes des vrais clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux.
 
It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.
 
Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités ou stratégiques.
 
== Find a Product Owner Given Your Type of Development ==
 
== Trouver un Product Owner selon votre type de développement ==
 
=== Step 1: Know Your Development Type ===


=== Étape 1 : connaître votre type de développement ===
=== Étape 1 : connaître votre type de développement ===
 
Trouver le bon type de Product Owner dépend de la connaissance de votre type de développement :
Finding the right Product Owner depends on knowing the type of development you are doing:
 
Trouver le bon type de Product Owner dépend de la connaissance du type de développement que vous faîtes :
 
* '''Product development'''—For external customers or a market.
* '''Internal (product) development'''—For one or more users within the company. The development group is usually called IT or Systems Development.
* '''Project development'''—Usually for one external customer. The work is organized and contracted as a project of some kind although that does not necessarily mean a fixed scope/date/cost project contract. The development company is usually an outsourcer or systems-integrator. The customer, or client company, includes both the purchasing entity and the users, who are not always in the same department.
* '''Développement de produits''' pour des clients externes ou un marché
* '''Développement de produits''' pour des clients externes ou un marché
* '''Développement (de produit) à usage interne''' pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
* '''Développement (de produit) à usage interne''' pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
* '''Développement d’un projet''' généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’elle soit bien que cela ne signifie pas pour autant un contrat pour le projet avec un(e) périmètre/date/coût fixe. L’entreprise de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les clients, qui ne sont pas nécessairement dans le même département.
* '''Développement d’un projet''' généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’il soit bien que cela ne signifie pas pour autant un contrat du projet basée sur le triangle  périmètre/date/coût. La société de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les utilisateurs, qui ne sont pas nécessairement dans le même département.<br />
 
<br />
=== Step 2: Finding the right Product Owner ===
 
=== Étape 2 : trouver le bon Product Owner ===
=== Étape 2 : trouver le bon Product Owner ===
 
'''Développement de produits''' - l’entreprise aura soit (1) une unité métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. On ne gère pas non plus le travail d’un groupe de développement traditionnel.<br />
'''Product development'''—The company will have either (1) a business unit driving the product initiative (e.g., Retail Banking), or (2) a Product Management department driving the initiative. Traditional Product Management is responsible for customer and competitor analysis, product vision, coarse-grained feature selection and prioritization, product roadmap, and other non-technical activities. They don’t manage the work of a traditional development group.
<br />
 
Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier.<br />
'''Développement de produits''' - l’entreprise aura soit (1) une unité opérationnelle métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. Il ne gère pas non plus le travail d’un groupe de développement traditionel.
<br />
 
'''Développement (de produits) à usage interne''' - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) qui est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des véritables utilisateurs.<br />
Where to find a Product Owner for a group adopting LeSS? If there’s a Product Management department, then a Product Manager can be a good choice. Otherwise, look for a person from the business unit that’s driving the initiative. The important thing to keep in mind is that the Product Owner for product development should come from the business side.
<br />
 
'''Développement d’un projet''' - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs.<br />
Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité opérationnelle métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier.
<br />
 
Une variante habituelle à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver une personne expérimentée au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation.<br />
'''Internal (product) development'''—A good Product Owner for internal product development in LeSS is (1) from within the group that will use the system, and (2) is closely involved in and deeply experienced in doing the real work that the system will support. They are very close to the real users.
<br />
 
L’illustration suivante montre le Product Owner dans différentes organisations :<br />
'''Développement (de produits) à usage interne''' - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des vrais utilisateurs.
<br />
 
[[Fichier:Who-is-the-po-fr.jpg.jpg|800px|Qui est le PO|link=]]<br />
'''Project development'''—The key point is that a Product Owner is from the company receiving the system and, as with internal development, is involved in and deeply experienced in the hands-on work, close to users.
<br />
 
Dans tous les cas, un super Product Owner est une personne passionnée par le produit.<br />
'''Développement d’un projet''' - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs.
<br />
 
Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même rapidement démarrer une adoption de LeSS avec un Product Owner ''temporaire'' qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, déployable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est extrêmement important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme "faux Product Owner" pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérennise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque d'aboutir à la création d’un produit de seconde classe.<br />
A common variant for both internal and project development is when the system will be used by many departments. Then, a good choice is an experienced, hands-on individual from one of the major user departments who is interested in taking on the role and has political savvy.
<br />
 
Une variante que l’on rencontre habituellement à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver un individu expérimenté au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation.
 
The following figure shows the Product Owner in different organizations:
 
L’illustration suivante montre le Product Owner dans différentes organisations :
 
<figure class>
[[File:https://less.works/img/framework/who-is-the-product-owner-in-different-types-of-development.png.pagespeed.ce.yMQPDhMzEA.png|Who is the Product Owner in Different Types of Development]]
<figcaption>
[https://less.works/img/framework/who-is-the-product-owner-in-different-types-of-development.png [Download PNG]]
 
[[Fichier:Who-is-the-po-fr.jpg.jpg|600px|Qui est le PO]]
 
In all cases, a great Product Owner has a passion for the product.
 
Dans tous les cas, un grand Product Owner est une personne ayant une passion pour le produit.
 
When it is impossible to find the right Product Owner immediately, you can quickly start a LeSS adoption with a ''temporary'' Product Owner who understands what’s going on and can perform the mechanics of the role but is not from the business side. Let the teams complete several Sprints under the temporary Product Owner until the major kinks are worked out and — this is important — the development teams can deliver a truly ‘done’, shippable increment (or something close) every Sprint. Why? The product teams will be more likely to find and inspire the right longterm Product Owner if they can show a compelling new capability that offers very tangible business benefit. It’s terribly important that everyone understand that the temporary Product Owner is a placeholder. We often use the term “fake Product Owner” to indicate just how damaging this temporary Product Owner can be. Because the fake PO is not only not the best Product Owner but also she can cause damage trying to fill a role for which she is not qualified. She must be replaced as soon as possible to avoid the risk of creating a second-class product.
 
Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même démarrer une adoption de LeSS avec un Product Owner ''temporaire'' qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, livrable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est - terriblement - important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme “faux Product Owner” pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérénise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque de voir aboutir à la création d’un produit de seconde classe.
 
=== Step 3: Give Authority and Responsibility to a Real Product Owner ===
 
=== Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner ===
=== Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner ===
 
Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel qui livre le résultat d’un travail basé sur un périmètre et une date contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraison, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale.<br />
Product Owner is not a new name for a traditional project manager who delivers a scope and date contract of work. Rather, a Product Owner must have the independent authority to choose and change content, release dates, priorities, vision, etc. Of course she collaborates with stakeholders, but a real Product Owner has final decision-making authority.
<br />
 
Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel dont le travail est de livrer le résultat d’un travail basé sur un périmètre et une date donnée contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraisosn, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale.
 
== Five Relationships ==
 
== Cinq types de relations ==
== Cinq types de relations ==
The Product Owner needs to understand and work to improve five key relationships that are affected by LeSS adoption:
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|link=]]<br />
<figure class>
<br />
[[File:https://less.works/img/framework/xproduct-owner-relationships.png.pagespeed.ic.xwDr0aHR79.webp|Product Owner Relationships]]
<figcaption>
[https://less.works/img/framework/product-owner-relationships.pdf [Download PDF]]
 
[[Fichier:Les différents types de relation du Product Owner.png|600px|Les différents types de relation du Product Owner]]
 
<ul>
<ul>
<li><p>'''Product Owner&lt;–&gt;Teams'''</p></li>
<li><p>'''Product Owner &harr; Équipes'''</p>
<li><p>'''Product Owner &lt;-&gt; équipes'''</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>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>
<li><p>'''Product Owner &harr; Clients'''</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à 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>
<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;Customers'''</p></li>
<li><p>'''Équipes &harr; Clients'''</p>
<li><p>'''Product Owner &lt;-&gt; Clients'''</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>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>
<li><p>'''Product Owner &harr; Hiérarchie'''</p>
<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>
<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>'''Teams&lt;–&gt;Customers'''</p></li>
<li><p>'''Product Owner &harr; Scrum Masters'''</p>
<li><p>'''équipes &lt;-&gt; clients'''</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>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 é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].

Dernière version du 29 août 2023 à 20:10

Auteur : The LeSS Company B.V.
Source : Product Owner (LeSS)

Traducteur : Nicolas Mereaux
Date : 23/06/2019

Traduction :

LeSS - Portail Framework

Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une unique équipe Scrum. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de garantir un retour sur investissement (ROI) maximum au niveau du produit.

Le Product Owner à grande échelle

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 focus sur le produit global (fr).

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 orientées client (fr)).

Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité.

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

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.

Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations liée au passage de relais, (2) encourager la co-création de solutions aux problèmes réels des clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux.

Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités stratégiques.

Trouver un Product Owner en fonction de votre type de développement

Étape 1 : connaître votre type de développement

Trouver le bon type de Product Owner dépend de la connaissance de votre type de développement :

  • Développement de produits pour des clients externes ou un marché
  • Développement (de produit) à usage interne pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
  • Développement d’un projet généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’il soit bien que cela ne signifie pas pour autant un contrat du projet basée sur le triangle périmètre/date/coût. La société de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les utilisateurs, qui ne sont pas nécessairement dans le même département.


Étape 2 : trouver le bon Product Owner

Développement de produits - l’entreprise aura soit (1) une unité métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. On ne gère pas non plus le travail d’un groupe de développement traditionnel.

Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier.

Développement (de produits) à usage interne - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) qui est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des véritables utilisateurs.

Développement d’un projet - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs.

Une variante habituelle à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver une personne expérimentée au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation.

L’illustration suivante montre le Product Owner dans différentes organisations :

Qui est le PO

Dans tous les cas, un super Product Owner est une personne passionnée par le produit.

Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même rapidement démarrer une adoption de LeSS avec un Product Owner temporaire qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, déployable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est extrêmement important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme "faux Product Owner" pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérennise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque d'aboutir à la création d’un produit de seconde classe.

Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner

Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel qui livre le résultat d’un travail basé sur un périmètre et une date contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraison, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale.

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 : Les différents types de relation du Product Owner

  • Product Owner ↔ Équipes

    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.

  • Product Owner ↔ Clients

    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.

  • Équipes ↔ Clients

    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.

  • Product Owner ↔ Hiérarchie

    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.

  • Product Owner ↔ Scrum Masters

    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.

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.

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 ?

Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines.

Le Product Owner ne participe pas aux réunions spécifiques des équipes que sont : la Planification du Sprint (2ème partie) (fr), la Mêlée Quotidienne (fr), les Affinages de backlog faits par les équipes (fr), les Rétrospectives des équipes (fr).

Récupérée de "https://wikiagile.coach/index.php?title=LeSS_-_Le_Product_Owner&oldid=18424"