Diferencia entre revisiones de «Preparacion De Un Proyecto Scrum»
(→Logística) |
(→Plan inicial para los entregables) |
||
| (No se muestran 5 ediciones intermedias de 5 usuarios) | |||
| 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 6: | Línea 7: | ||
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. | 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 | + | 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. | 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. | 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=== | ===La visión del proyecto=== | ||
| 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=== | ||
| − | A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el | + | 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=== | ===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 " | + | 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: | 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 38: | Línea 39: | ||
* el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint) | * 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 | * el negocio se centra en el valor entregado por cada entregable | ||
| − | |||
===Constitución del equipo=== | ===Constitución del equipo=== | ||
| Línea 60: | Línea 60: | ||
==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 actual del 18:11 18 mar 2009
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.
Contenido
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 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
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.
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
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
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:
- 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 Control De Versiones, conectividad de red e Internet, entornos de desarrollo y test, etc...
- comprar café y snacks!
