Spécifications avancées - Historique des versions

Fabrice Aimetti le 19 mai 2023 à 09:54

Fabrice Aimetti — Fri, 19 May 2023 09:54:26 GMT

← Version précédente		Version du 19 mai 2023 à 09:54
Ligne 11 :		Ligne 11 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	... le [[Backlog%20Produit\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		... le [[Backlog%20Produit\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg\|link=]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg\|link=]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti le 17 août 2018 à 11:19

Fabrice Aimetti — Fri, 17 Aug 2018 11:19:14 GMT

← Version précédente		Version du 17 août 2018 à 11:19
Ligne 1 :		Ligne 1 :
	[[Category: Jim Coplien]]		[[Category: Jim Coplien]]
	[[Category: Jeff Sutherland]]		[[Category: Jeff Sutherland]]
			[[Category: Published Patterns]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteurs : Jim Coplien avec l'aide de Jeff Sutherland<br /> Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />		Auteurs : Jim Coplien avec l'aide de Jeff Sutherland<br />
			Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />		Traducteur : Fabrice Aimetti<br />
			Date : 15/02/2012<br />
	----		----
	''Traduction :''<br /> <br /> ... le [[Backlog%20Produit\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		Traduction :<br />
			<br />
			... le [[Backlog%20Produit\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti le 30 juin 2018 à 18:33

Fabrice Aimetti — Sat, 30 Jun 2018 18:33:30 GMT

← Version précédente		Version du 30 juin 2018 à 18:33
Ligne 1 :		Ligne 1 :
	[[Category: Jim Coplien]]		[[Category: Jim Coplien]]
			[[Category: Jeff Sutherland]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	<div id="content_view" class="wiki" style="display: block"> Auteurs : Jim Coplien avec l'aide de Jeff Sutherland<br /> Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />		<div id="content_view" class="wiki" style="display: block"> Auteurs : Jim Coplien avec l'aide de Jeff Sutherland<br /> Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />

Fabrice Aimetti le 26 juin 2018 à 12:28

Fabrice Aimetti — Tue, 26 Jun 2018 12:28:51 GMT

← Version précédente		Version du 26 juin 2018 à 12:28
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />
	----		----
	''Traduction :''<br /> <br /> ... le [[~~BACKLOG~~%~~20PRODUIT~~\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		''Traduction :''<br /> <br /> ... le [[Backlog%20Produit\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti le 26 juin 2018 à 12:27

Fabrice Aimetti — Tue, 26 Jun 2018 12:27:59 GMT

← Version précédente		Version du 26 juin 2018 à 12:27
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />
	----		----
	''Traduction :''<br /> <br /> ... le [[BACKLOG%20PRODUIT\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		''Traduction :''<br /> <br /> ... le [[BACKLOG%20PRODUIT\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [[El%C3%A9ments%20du%20Backlog%20Produit\|Élément du Backlog Produit]] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti le 26 juin 2018 à 12:27

Fabrice Aimetti — Tue, 26 Jun 2018 12:27:39 GMT

← Version précédente		Version du 26 juin 2018 à 12:27
Ligne 1 :		Ligne 1 :
	[[Category: Jim Coplien]]		[[Category: Jim Coplien]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	<div id="content_view" class="wiki" style="display: block"> Auteurs : ~~[/Jim%20Coplien~~ Jim Coplien] avec l'aide de Jeff Sutherland<br /> Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />		<div id="content_view" class="wiki" style="display: block"> Auteurs : Jim Coplien avec l'aide de Jeff Sutherland<br /> Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns)<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />
	----		----
	''Traduction :''<br /> <br /> ... le [[BACKLOG%20PRODUIT\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		''Traduction :''<br /> <br /> ... le [[BACKLOG%20PRODUIT\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti le 26 juin 2018 à 12:26

Fabrice Aimetti — Tue, 26 Jun 2018 12:26:54 GMT

← Version précédente		Version du 26 juin 2018 à 12:26
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 15/02/2012<br />
	----		----
	''Traduction :''<br /> <br /> ... le [/BACKLOG%20PRODUIT BACKLOG PRODUIT] est en place et le Product Owner travaille sur les [/El%C3%A9ments%20du%20Backlog%20Produit Eléments du Backlog Produit] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>		''Traduction :''<br /> <br /> ... le [[BACKLOG%20PRODUIT\|BACKLOG PRODUIT]] est en place et le Product Owner travaille sur les [[El%C3%A9ments%20du%20Backlog%20Produit\|Eléments du Backlog Produit]] (PBI).<br /> <br /> '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.'''<br /> <br /> <span style="display: block; text-align: justify">Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:VagueSpec.jpg\|VagueSpec.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:EnablingSpecs.jpg\|EnablingSpecs.jpg]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.</span>

Fabrice Aimetti : Page créée avec « Category: Jim Coplien Category: Portail Product Owner
Auteurs : [/Jim%20Coplien Jim Coplien] avec l'aid... »

Fabrice Aimetti — Tue, 26 Jun 2018 12:26:23 GMT

Page créée avec « Category: Jim Coplien Category: Portail Product Owner <div id="content_view" class="wiki" style="display: block"> Auteurs : [/Jim%20Coplien Jim Coplien] avec l'aid... »

Nouvelle page

[[Category: Jim Coplien]]
[[Category: Portail Product Owner]]
<div id="content_view" class="wiki" style="display: block"> Auteurs : [/Jim%20Coplien Jim Coplien] avec l'aide de Jeff Sutherland Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/enabling-specification Enabling Specification] (Published Patterns) 
----
Traducteur : Fabrice Aimetti Date : 15/02/2012 
----
''Traduction :'' ... le [/BACKLOG%20PRODUIT BACKLOG PRODUIT] est en place et le Product Owner travaille sur les [/El%C3%A9ments%20du%20Backlog%20Produit Eléments du Backlog Produit] (PBI). '''Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.''' Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception. Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs. Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également : [[Image:VagueSpec.jpg|VagueSpec.jpg]] '''''Par conséquent :''''' '''le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.''' "Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification. [[Image:EnablingSpecs.jpg|EnablingSpecs.jpg]] Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un [/El%C3%A9ments%20du%20Backlog%20Produit Élément du Backlog Produit] écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.

Spécifications avancées - Historique des versions

Fabrice Aimetti le 19 mai 2023 à 09:54

Fabrice Aimetti le 17 août 2018 à 11:19

Fabrice Aimetti le 30 juin 2018 à 18:33

Fabrice Aimetti le 26 juin 2018 à 12:28

Fabrice Aimetti le 26 juin 2018 à 12:27

Fabrice Aimetti le 26 juin 2018 à 12:27

Fabrice Aimetti le 26 juin 2018 à 12:26

Fabrice Aimetti : Page créée avec « Category: Jim Coplien Category: Portail Product Owner Auteurs : [/Jim%20Coplien Jim Coplien] avec l'aid... »

Fabrice Aimetti : Page créée avec « Category: Jim Coplien Category: Portail Product Owner
Auteurs : [/Jim%20Coplien Jim Coplien] avec l'aid... »