Demostrar y validar sprint

1- EQUIPO PRINCIPAL SCRUM

Scrum Master: Cule Rojas Denis

Product Owner: Taquiri Palomino Eudis

Equipo De Desarrollo:

• Anaya Yaranga, Juan
• Escalante Gomez, Robert
• Gutierrez Chura, Luis Alberto
• La Madrid Martínez, Ayrton César
• Pérez Leyva, Luis
• Salvador Perez

2- ENTREGABLES DEL SPRINT

3- SPRINT BACKLOG

4- CRITERIOS TERMINADOS

• El diseño de gestionar alumnos y profesores fue aprobado por el stakeholder
• El diseño de gestionar asistencia de profesores fue aprobado por el stakeholder
• El funcionamiento del sistema fue aprobada porque es fácil manejable para el stakeholder y la secretaria

5- CRITERIOS DE ACEPTACIÓN

6- CLIENTE

7- CRONOGRAMA DE PLANIFICACION DE LANZAMIENTO

SEGUNDO LANZAMIENTO

JUNIO

SM	LU	MA	MI	JU	VI	SA	DO
22						1	2
23	3	4	5	6	7	8	9
24	10	11	12	13  Lanzamiento 2	14	15	16
25	17	18	19	20	21	22	23
26	24	25	26	27	28	29	30

Lanzamiento 2: 13 de junio

8- RIESGOS IDENTIFICADOS

• Poco conocimiento de php
• Mal uso de las metodologías del desarrollo del software
• Falta de disponibilidad del stakeholder
• Poco conocimiento de parte del stakeholder y los usuarios respecto a lo tecnológico
• Falta de coordinación en el grupo respecto al tiempo
• Ausencia de integrantes por motivos de trabajo
• Falta de solvencia económica
• Poco conocimiento en el área de control de pago del colegio
• La información está expuesta a ser manipulada por cualquier usuario externo
• La información está guardada sólo en hojas de cálculo
• Falta de conocimiento de frameworks en front-end

9- DEPENDENCIAS

Una vez que el Equipo Scrum ha seleccionado Historias de Usuarios para un determinado Sprint, debería entonces considerar las dependencias, incluyendo las relacionadas con la disponibilidad de las Personajes o Personas, así como las dependencias técnicas.

10- RECOMENDACIONES  SCRUM GUIDANCE BODY

https://www.tenstep.ec/portal/images/pdfs/Suscripciones_TenStep/Silver/SCRUMstudy_GUIA_SBOK_espanol.pdf (Capitulo 9.5, Una Guia para el Conocimiento Scrum (GUIA SBOK™ ), “Estimar Tareas”, pag.215-209)

HERRAMIENTAS

 1- REUNIONES DE REVISIÓN DEL SPRINT

Los miembros del equipo principal de Scrum y los stakeholders relevantes participan en las reuniones de revisión del sprint para aceptar los entregables que cumplan con los criterios de aceptación de las historias de usuario y rechazar los entregables no aceptables. Tales reuniones se convocan al final de cada sprint.

SALIDAS

 1- ENTREGABLES ACEPTADOS

Los entregables que cumplen con los criterios de aceptación de las historias de usuario son aceptados por el Product Owner. El objetivo de un sprint es crear entregables potencialmente enviables o incrementos del producto que cumplan con los criterios de aceptación definidos por el cliente y el Product Owner. Estos se consideran entregables aceptados que pudieran ser entregados al cliente y así se desea. Se mantiene una lista de entregables aceptados y se actualiza después de cada reunión de revisión del sprint.

2- RIESGOS ACTUALIZADOS

• Poco conocimiento de php
• Mal uso de las metodologías del desarrollo del software
• Falta de disponibilidad del stakeholder
• Poco conocimiento de parte del stakeholder y los usuarios respecto a lo tecnológico
• Falta de coordinación en el grupo respecto al tiempo
• Ausencia de integrantes por motivos de trabajo
• Falta de solvencia económica
• Poco conocimiento en el área de control de pago del colegio
• La información está expuesta a ser manipulada por cualquier usuario externo
• La información está guardada sólo en hojas de cálculo
• Falta de conocimiento de frameworks en front-end
• Falta de conocimiento en la metodologia programacion extrema
• Poco conocimento en desarrollar las tareas y historias de usuario en el diseño xp

3- CRONOGRAMA DE PLANIFICACION DE LANZAMIENTO

SEGUNDO LANZAMIENTO

JUNIO

SM	LU	MA	MI	JU	VI	SA	DO
22						1	2
23	3	4	5	6	7	8	9
24	10	11	12	13  Lanzamiento 2	14	15	16
25	17	18	19	20	21	22	23
26	24	25	26	27	28	29	30

Lanzamiento 2: 13 de junio

4- DEPENDENCIA ACTUALIZADAS