Ciclo de Vida de Proyecto Agil

 Funcionalidades (Integrar y Probar)

 Desarrollo
 Liberar
 Retroalimentación y Revision
 Aceptada

Ciclo de Entrega Agil

« Inicio
[ Definición de Requerimientos ]
[ Requerimientos de Alto Nivel ]

« Puesta en Producción
Se Acepta? Si / No
Probar

 Siguientes Interacciones
 Ajustes y Seguimiento
 Recopilación e Incorporación de Cambios

 REVISION CONTINUA para Clientes, Desarrolladores y Usuarios

Ciclo Tipico de Scrum

 Product Backlog
 Sprint Backlogs ( 2 – 4 semanas) / Se recomienda 2 semanas [ Lo que sale de cada
Sprint es Incremento)
 Daily Scrum Meetings (24 horas)
 Potentially Shippable Product Increment

Artefacto Scrum

Historial del Usuario

 En una cara se plasma lo que el cliente quiere como lo quiere y para que lo quiere

Formato
 Title – The title should be 10 words or less
 Description – As a ( Yo como )
 I would like to ( Me gustaría )
 So that ( Para que )
 Prioridad ( High – Medium – Low )
Product Backlog
 Es un documento dinamico que incorpora las constantes necesidades del sistema y
se mantiene durante todo el ciclo de vida (hasta el demise del sistema)
« Listado de funcionalidad del sistema
« Priorizadas
« Documento vivo
« Accesible a todos los roles
« Todos pueden contribuir y aportar elementos
« Mientras exista un producto, el Product Backlog tambien existe

JIRA (Sistema de comunicación sistematica / Alta de requerimientos)

ID Prioridad Modulo Descripción Estado Por

Sprint Planning Meeting

« Se selecciona los requerimientos del Product Backlog que entrarán en el sprint

« Se hace un listado
« Planificación

Se divide en dos reuniones

« Primera Reunion:
Se establece la meta del sprint
Se identifica la funcionalidad que se va a construir en el sprint

« Segunda reunión
Se identifican y estiman las tareas para desarrollar
Se crea un sprint backlog
Las tareas son distribuidas por decisión de los miembros del equipo
Los miembros del equipo se comprometen a cumplir con la meta del sprint

« Entradas
Product Backlog actualizado
Feedback ultimo sprint

Sprint Backlog

« Especifica la serie de tareas que se van a desarrollar según los requisitos señalados
en un sprint y lograr al final del mismo un incremento de la funcionalidad
« PILA DE PRODUCTOS / PILA DE SPRINT
 SPRINT

« Es el periodo de tiempo durante el que se desarrolla un incremento de

funcionalidad. Constituye el nucleo de SCRUM, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeñas “carreras”.
« Duracion maxima entre 15 a 30 dias
« Durante el sprint no se puede modificar el trabajo que se ha acordado en el
Backlog
« Solo es posible cambiar el curso de un sprint, abortandolo, y solo lo puede
hacer el SCRUM Master si decide que no es viable por alguna de las razones
siguientes:
o La tecnología acordada no funciona
o Las circunstancias del negocio han cambiado
o El equipo ha tenido interferencias

Daily Stand UP

Preguntas:
 Que es lo que se hizo desde la ultima reunion?
 Que es lo que hizo hoy?
 Que barreras tienes?

Sprint Review

o Al final del Sprint, se realiza una reunion donde se presenta al product owner y a
los implicados todas las funcionalidades implementadas
o El product owner trata con los aistentes y con el team las posibilidades
modificaciones en el product backlog
o Al final de la reunion se interroga individualmente a todos los asistentes para
recabar impresiones, sugerencias de cambio y mejora, y su relevancia.

Incremento del Producto

El incremento es la suma de todos los elementos del Producto Backlog completados

durante un Sprint y el valor de los incrementos de todos los Sprints anteriores

Al final de un Sprint, el nuevo Incremento debe de estar “Terminado”, lo que significa que
debe de estar en condiciones de uso y cumplir con la definición de Terminado

Un incremento es un cuerpo de trabajo inspeccionable realizable

Sprint Retrospective

Se lleva a cabo despues del Sprint Reviem y antes de la proxima Sprint Planning Meeting
El Scrum Master hace que el Team revise, su proceso de desarrollo Scrum, para hacerlo
mas eficaz y eficiente para el próximo Sprint. El ScrumMaster hace dos preguntas:
« Que hicimos bien?
« Que podemos mejorar?
El ScrumMaster no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor
forma de trabajar con Scrum.