Preparacion De Un Proyecto Scrum - Historial de revisiones

84.123.1.37: /* Plan inicial para los entregables */

2009-03-18T18:11:37Z

‎Plan inicial para los entregables

Leito: /* Ver también */

2008-09-26T12:12:33Z

‎Ver también

201.251.185.130: /* La visión del proyecto */

2008-08-15T19:59:27Z

‎La visión del proyecto

201.251.182.130: /* Backlog inicial del proyecto */

2008-08-12T15:39:46Z

‎Backlog inicial del proyecto

Admin en 18:52 31 jul 2008

2008-07-31T18:52:43Z

190.172.86.173: /* El caso de negocio */

2008-07-26T21:06:06Z

‎El caso de negocio

190.172.86.173: /* Logística */

2008-07-26T21:05:41Z

‎Logística

190.172.86.173: Página nueva: La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su obj...

2008-07-26T21:04:55Z

Página nueva: La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su obj...

Página nueva

La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.

La fase de "Preparación" contiene algunas tareas que son candidatas a realizar durante la etapa de iniciación de un proyecto. Esta fase de iniciar un proyecto Scrum se conoce a veces como '''Sprint 0'''.

===El caso de negocio===
Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.

Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el BacklogDelProducto es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.

Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.

Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.

===La visión del proyecto===
Scrum, como otras metodologías ágiles, no fomentan la documentación innecesaria. Sin embargo, es importante que el equipo completo comprenda la esencia del proyecto o producto que están intentando crear. Aquí es donde la Visión del Proyecto entra en juego. Debería ser lo más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Comunicar la visión es tan importante cómo tenerla. Un buen ejemplo de éxito sería poder preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto.

La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.

===Backlog inicial del proyecto===
A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el BacklogDelProducto enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].

===Plan inicial para los entregables===
El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entretables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.

Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
* cambio en las oportunidades del negocio.
* durante una [[Revision Del Sprint]] el grupo de usuarios puede encontrar que la funcionalidad mostrada podría entregar valor al negocio si fuera puesta en producción.
* demasiadas características para un entregable en el tiempo dado, de forma que se requiera más tiempo o menos características para el entregable.

Cuando se crea un plan de entregas:
* el negocio determina cuando se necesita un entregable, la funcionalidad que debe contener, el nivel de aceptación de la calidad y el costo.
* el equipo de desarrollo determina cuánto se tardara en construir ese entregable
* el equipo de desarrollo crea las estimaciones preliminares
* el equipo de desarrollo refina las estimaciones a medida que se incrementan las prioridades
* el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
* el negocio se centra en el valor entregado por cada entregable

===Constitución del equipo===
Una vez que todos los roles del equipo están identificados, el equipo debería juntarse para una reunión de kick off, en la cual se deberían tratar:
* el alcance del proyecto
* una revisión rápida del backlog
* cualquier discusión técnica
* acuerdos iniciales sobre cómo el equipo trabajará junto (por ejemplo, a qué hora son las reuniones diarias)

===Logística===
Hay ciertas tareas de organización y logística que deben completarse al iniciar un proyecto ágil:
* tener un área o lugar disponible para el equipo
* tener las reuniones de kick off con el equipo
* planificar las reuniones con el usuario por adelantado, y agregarlas a las agendas de las personas
* crear una "pizarra de trabajo" en el área del equipo
* llenar las parades libres en el área del equipo con pizarras
* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de ControlDeVersiones, conectividad de red e Internet, entornos de desarrollo y test, etc...
* comprar café y snacks!

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

← Revisión anterior		Revisión del 12:12 26 sep 2008
Línea 61:		Línea 61:
	==Ver también==		==Ver también==
	* [[Proceso De Desarrollo Con Scrum]]		* [[Proceso De Desarrollo Con Scrum]]
		+	* [http://www.infoq.com/news/2008/09/sprint_zero What is a Sprint zero? Why was it introduced?]

← Revisión anterior		Revisión del 19:59 15 ago 2008
Línea 18:		Línea 18:
	La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.		La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.

		+	===Definición de Terminado===
		+	El equipo debe acordar una [[Definicion De Terminado]], es decir, cuándo podrá considerar que cada una de las historias y tareas se encuentran terminadas.

	===Backlog inicial del proyecto===		===Backlog inicial del proyecto===

← Revisión anterior		Revisión del 18:52 31 jul 2008
Línea 1:		Línea 1:
		+	[[Category:Scrum]]
	La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.		La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.

@@ Línea 25: / Línea 25: @@
 ===Plan inicial para los entregables===
-El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entretables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.
+El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entregables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.
 Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
@@ Línea 39: / Línea 39: @@
 * el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
 * el negocio se centra en el valor entregado por cada entregable
 ===Constitución del equipo===

@@ Línea 20: / Línea 20: @@
 ===Backlog inicial del proyecto===
-A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el BacklogDelProducto enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].
+A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el [[Backlog Del Producto]] enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].
 ===Plan inicial para los entregables===

@@ Línea 6: / Línea 6: @@
 Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.
-Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el BacklogDelProducto es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.
+Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el [[Backlog Del Producto]] es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.
 Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.
 Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.
 ===La visión del proyecto===

@@ Línea 55: / Línea 55: @@
 * crear una "pizarra de trabajo" en el área del equipo
 * llenar las parades libres en el área del equipo con pizarras
-* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de ControlDeVersiones, conectividad de red e Internet, entornos de desarrollo y test, etc...
+* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de [[Control De Versiones]], conectividad de red e Internet, entornos de desarrollo y test, etc...
 * comprar café y snacks!
 ==Ver también==
 * [[Proceso De Desarrollo Con Scrum]]