<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: El rol de propietario de producto</title>
	<atom:link href="http://www.scrummanager.net/blog/2010/01/121/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.scrummanager.net/blog/2010/01/121/</link>
	<description>Por el equipo de colaboradores de Scrum Manager</description>
	<lastBuildDate>Wed, 21 Jul 2010 17:02:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Andoni</title>
		<link>http://www.scrummanager.net/blog/2010/01/121/comment-page-1/#comment-21</link>
		<dc:creator>Andoni</dc:creator>
		<pubDate>Fri, 29 Jan 2010 15:40:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrummanager.net/blog/?p=121#comment-21</guid>
		<description>Muy bueno y acertado.
Por mi parte tengo una pregunta a cerca del product Owner. 
En un principio el Product Owner forma parte del equipo de scrum y ayuda siempre que sea requerido por el equipo a la hora de resolver dudas, tanto durante la reunión del sprint como durante el sprint en sí. Sin embargo, por lo que tengo entendido, el product Owner no va a ver el resultado de lo que se desarrolla hasta el final del sprint donde los desarrolladores presentan su trabajo.
Como veríais el hecho de que, en caso de tener tiempo, el Product Owner realmente &quot;testease&quot; o &quot;revisase&quot; las historias de usuario desarrolladas a lo largo del sprint sin esperar al final? 
De esta forma nos aseguramos de que la historia de usuario esta correctamente desarrollada y además el Product Owner seguro que estará más cerca del equipo. En la reunión de revisión del sprint se presentarían todas las historias finalizadas e integradas con la aplicación.

Muchas gracias</description>
		<content:encoded><![CDATA[<p>Muy bueno y acertado.<br />
Por mi parte tengo una pregunta a cerca del product Owner.<br />
En un principio el Product Owner forma parte del equipo de scrum y ayuda siempre que sea requerido por el equipo a la hora de resolver dudas, tanto durante la reunión del sprint como durante el sprint en sí. Sin embargo, por lo que tengo entendido, el product Owner no va a ver el resultado de lo que se desarrolla hasta el final del sprint donde los desarrolladores presentan su trabajo.<br />
Como veríais el hecho de que, en caso de tener tiempo, el Product Owner realmente &#8220;testease&#8221; o &#8220;revisase&#8221; las historias de usuario desarrolladas a lo largo del sprint sin esperar al final?<br />
De esta forma nos aseguramos de que la historia de usuario esta correctamente desarrollada y además el Product Owner seguro que estará más cerca del equipo. En la reunión de revisión del sprint se presentarían todas las historias finalizadas e integradas con la aplicación.</p>
<p>Muchas gracias</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Antonio Quintas</title>
		<link>http://www.scrummanager.net/blog/2010/01/121/comment-page-1/#comment-19</link>
		<dc:creator>Antonio Quintas</dc:creator>
		<pubDate>Mon, 25 Jan 2010 13:40:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrummanager.net/blog/?p=121#comment-19</guid>
		<description>Totalmente de acuerdo con Claudia</description>
		<content:encoded><![CDATA[<p>Totalmente de acuerdo con Claudia</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Claudia Ruata</title>
		<link>http://www.scrummanager.net/blog/2010/01/121/comment-page-1/#comment-14</link>
		<dc:creator>Claudia Ruata</dc:creator>
		<pubDate>Tue, 19 Jan 2010 14:49:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrummanager.net/blog/?p=121#comment-14</guid>
		<description>Una excelente y sencilla explicación sobre la diferencia entre Product Manager y Product Owner, así como la necesidad de contar con un único responsable por este último rol.

Felicitaciones !!</description>
		<content:encoded><![CDATA[<p>Una excelente y sencilla explicación sobre la diferencia entre Product Manager y Product Owner, así como la necesidad de contar con un único responsable por este último rol.</p>
<p>Felicitaciones !!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Juan Palacio</title>
		<link>http://www.scrummanager.net/blog/2010/01/121/comment-page-1/#comment-13</link>
		<dc:creator>Juan Palacio</dc:creator>
		<pubDate>Mon, 18 Jan 2010 15:20:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrummanager.net/blog/?p=121#comment-13</guid>
		<description>Sí, la importancia de la responsabilidad del &quot;cliente&quot; en el proyecto es algo que se suele olvidar (en realidad desconocer).
Sin duda la forma de implicarse o participar en el proyecto es diferente si la gestión es de carácter predictivo o ágil, pero en los dos casos, si el cliente se limita a pedir (muchas veces, sin saber muy bien qué y para qué) y luego a esperar al final a ver que le dan, el proyecto ya tiene muchos puntos en contra.

Me gusta mucho la separación de procesos primarios que hace la ISO 12207, en los que todos son responsabilidad del proveedor (suministro, desarrollo, operción y mantenimiento) menos uno: adquisición.
Las tareas y responsabilidades de la adquisición son algo diferentes en gestión ágil y predictiva, pero son muy importantes, y muchas veces la principal causa del fracaso de un proyecto está en el cliente.

Un saludo!</description>
		<content:encoded><![CDATA[<p>Sí, la importancia de la responsabilidad del &#8220;cliente&#8221; en el proyecto es algo que se suele olvidar (en realidad desconocer).<br />
Sin duda la forma de implicarse o participar en el proyecto es diferente si la gestión es de carácter predictivo o ágil, pero en los dos casos, si el cliente se limita a pedir (muchas veces, sin saber muy bien qué y para qué) y luego a esperar al final a ver que le dan, el proyecto ya tiene muchos puntos en contra.</p>
<p>Me gusta mucho la separación de procesos primarios que hace la ISO 12207, en los que todos son responsabilidad del proveedor (suministro, desarrollo, operción y mantenimiento) menos uno: adquisición.<br />
Las tareas y responsabilidades de la adquisición son algo diferentes en gestión ágil y predictiva, pero son muy importantes, y muchas veces la principal causa del fracaso de un proyecto está en el cliente.</p>
<p>Un saludo!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Angel Agueda</title>
		<link>http://www.scrummanager.net/blog/2010/01/121/comment-page-1/#comment-12</link>
		<dc:creator>Angel Agueda</dc:creator>
		<pubDate>Mon, 18 Jan 2010 06:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrummanager.net/blog/?p=121#comment-12</guid>
		<description>Muy interesante y muy importante. Coincido con David y Rodrigo en la importancia crítica de este rol en los proyectos. En PMBoK no queda tan nitididamente dibujada esta figura, pero sí en PRINCE2 aunque con atribuciones distintas pues se separa la resonsabilidad sobre la justificación de negocio del proyecto y el conocimiento sobre las funcionalidades que debe tener el sistema a construir.
Me ha gustado mucho el comentario de Rodrigo respecto a la importancia del Product Owner como motivador o animador del equipo. Sin duda su conocimiento, pero también su relación con el equipo puede tener un efecto importantísimo de motivación o desmotivación.
Por último comentar que la duración del podcast me ha parecido muy adecuada. Media hora es un tiempo suficiente para explicar y debatir sobre un concepto si está bien centrado, como ha sido el caso.
¡Enhorabuena!</description>
		<content:encoded><![CDATA[<p>Muy interesante y muy importante. Coincido con David y Rodrigo en la importancia crítica de este rol en los proyectos. En PMBoK no queda tan nitididamente dibujada esta figura, pero sí en PRINCE2 aunque con atribuciones distintas pues se separa la resonsabilidad sobre la justificación de negocio del proyecto y el conocimiento sobre las funcionalidades que debe tener el sistema a construir.<br />
Me ha gustado mucho el comentario de Rodrigo respecto a la importancia del Product Owner como motivador o animador del equipo. Sin duda su conocimiento, pero también su relación con el equipo puede tener un efecto importantísimo de motivación o desmotivación.<br />
Por último comentar que la duración del podcast me ha parecido muy adecuada. Media hora es un tiempo suficiente para explicar y debatir sobre un concepto si está bien centrado, como ha sido el caso.<br />
¡Enhorabuena!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
