Está en la página 1de 9
PROYECTO: Desarrollo de una Aplicación Web para la Institución Newport Implementando la Metodología SCRUM 0

PROYECTO:

Desarrollo de una Aplicación Web para la Institución Newport Implementando la Metodología SCRUM

Tabla de contenido

1. Introducción

 

2

1.1

Propósito

2

2. Descripción General de la Metodología

2

2.1

Fundamentación

2

2.2

Valores de trabajo

2

3. Personas y roles del proyecto

3

4. Artefactos

 

3

4.1

Incremento

4

4.2

Gráfica de avance (Burn Down)

4

4.3

Reunión de para generar el Product Backlog

4

4.4

Reunión

para generar la planeación del Sprint

5

4.5

Reunión

de Trabajo

7

1.

Introducción

Este documento describe la implementación de la metodología de trabajo SCRUM en el proyecto de Desarrollo de la Aplicación Web Newport Institute. Incluye junto con la descripción de este ciclo de vida iterativo e incremental para el proyecto, los artefactos o documentos con los que se gestionan las tareas de adquisición y suministro:

requisitos, monitorización y seguimiento del avance, así como las responsabilidades y compromisos de los participantes en el proyecto.

Reporte Final del Sprint 1

Desarrollo de la Aplicación Web Newport Institute

Nº de Sprint:

1

Planificación

Fecha de entrega:

20-oct-2014

Descripción de la metodología de trabajo

Descripción de la metodología de trabajo

1.1 Propósito

Reportar la forma de trabajo que fue adoptada por el equipo para la implementación de la metodología

Scrum y para describir el proceso que siguió en el

desarrollo y control del primer sprint.

2.

Descripción General de la Metodología

2.1

Fundamentación

Las principales razones del uso de la metodología SCRUM para la implantación de este proyecto son:

Sistema modular: Las características de la aplicación NEWPORT INSTITUTE permiten desarrollar una base funcional mínima y sobre ella ir incrementando las funcionalidades o modificando el comportamiento o apariencia de las ya implementadas.

Entregas frecuentes y continuas al cliente de los módulos terminados, de forma que puede disponer de una funcionalidad básica en un tiempo considerable y a partir de ahí un incremento y mejora continua de la aplicación.

Satisfacer al cliente.

Dar bienvenida a los cambios de requisitos.

inicialmente

-

Es

posible

que

el

sistema

incorpore

más

funcionalidades

de

las

identificadas.

- Es posible que durante la ejecución del proyecto se altere el orden en el que se desean recibir los módulos o historias de usuario terminadas.

2.2 Valores de trabajo

Fueron elegidos por votación por el equipo Scrum donde se concluyó que deben ser practicados por todos en el desarrollo del proyecto con la finalidad de lograr el objetivo establecido y llevar a cabo con éxito la metodología. Estos valores son:

Autonomía del equipo

Respeto en el equipo

Responsabilidad y auto-disciplina

Foco en la tarea

Información transparencia y visibilidad.

3.

Personas y roles del proyecto

Rol

Miembro

Scrum Master

Martha Leticia Sánchez López

Product Owner

María Esmeralda Pérez Piñón

Analista/documentadora

Diana Fernanda Díaz León

Diseñador

Jurhiata Joel Ibarra Garnica

Programador

Miguel Ángel Rodríguez Guzmán

Programador

Ignacio Alan Moreno Álvarez

Programador

Antonio Abraham Ochoa Avalos

Téster

Celeste Álvarez Aguirre

Programador

Miguel Ángel Ramírez Rodríguez

El Scrum Master:

o

Ayuda al resto del equipo Scrum a seguir su proceso.

o

Trabaja con el Product Owner para mantener actualizado el product Backlog.

o

Tiene una buena comprensión de Scrum.

o

Actúa como coach para el Equipo Scrum

El Product Owner

o

Es responsable de decidir qué trabajo deberá ser realizado.

o

Registra en el product Backlog las historias de usuario que definen la aplicación.

o

Mantenimiento actualizado de la pila del producto en todo momento durante la ejecución del proyecto.

o

Incorporación / eliminación /modificaciones de las historias o de su orden de prioridad.

El equipo de desarrollo

o

Encargados de realizar el trabajo necesario para poder entregar el incremento del proyecto.

o

Conocimiento y comprensión actualizado de la pila del producto

o

Confección de la pila del sprint.

o

Auto-asignación del trabajo.

4. Artefactos

Product Backlog

Sprint Backlog

Sprint

Incremento

Gráficas para registro y seguimiento del avance.

Gráfica de avance o Burn Down

Comunicación y reporte de reuniones.

Reunión para generar el product backlog

Reunión de planificación de sprint

Reuniones de Trabajo

4.1 Incremento

Parte de la aplicación que se produjo en un sprint y entrega al cliente completamente terminado y operativo.

4.2 Gráfica de avance (Burn Down)

Muestra el estado de avance del trabajo del sprint en curso.

Gráfico de esfuerzo Esfuerzo Pendiente 16 14 12 10 8 6 4 2 0 Horas
Gráfico de esfuerzo
Esfuerzo Pendiente
16
14
12
10
8
6
4
2
0
Horas de trabajo pendientes

4.3 Reunión de para generar el Product Backlog

Reunión para determinar las funcionalidades o historias de usuario que se van a incluir en el Sprint.

Generada por el Product Owner Esmeralda, Srum Master Martha y por el equipo de desarrollo. Esta reunión se realizó el viernes 03-octubre-2014

Donde se determinó ¿Cuáles son los módulos más importantes para el cliente? ¿Cuáles son las historias que formaran parte de cada uno de los módulos y cuál es su prioridad? Seguimiento que se hiso ese día:

- El Product Owner (Esmeralda) menciono al resto del equipo Scrum cuáles son los requerimientos generales del proyecto así como lo que más le importan al cliente.

- El product Owner anota estos requisitos en el pizarrón, posteriormente los miembros del equipo dieron su opinión de cuáles son los que tienen mayor prioridad que otros, en los casos de que no coincidieran todos con la prioridad se pedía su explicación de porqué considera que sea de mayor o menor prioridad, terminando su explicación, el resto decía porque si estaban de acuerdo o no, en casos de que no cedieran de opinión se determinó por mayoridad de votación.

- Los miembros del equipo se auto-asignaron a los responsables de cada H.U de acuerdo a las habilidades que cada uno tiene y tomando en cuenta los roles que desempeñan.

- El Scrum actuó como moderador en esta toma de decisiones.

- A si se fue realizando la actividad de ir generando todo el product backlog hasta finalizarlo.

4.4

Reunión para generar la planeación del Sprint

El propósito de la planificación de Sprint es proporcionar al equipo suficiente información para que determinen como van trabajar durante las 2 semanas que dura el sprint.

Esta planificación de Sprint produjo concretamente:

Una meta de Sprint

Trabajar con compromiso y responsabilidad con la finalidad de entregar a tiempo y forma el primer sprint del Diseño de la Base de Datos satisfaciendo así los requerimientos del cliente.

Una lista de miembros (y su nivel de dedicación)

Miembro

Dedicación

Martha Leticia Sánchez López

100%

María Esmeralda Pérez Piñón

100 %

Diana Fernanda Díaz León

95%

Jurhiata Joel Ibarra Garnica

95%

Miguel Ángel Rodríguez Guzmán

85%

Ignacio Alan Moreno Álvarez

85%

Antonio Abraham Ochoa Avalos

85%

Celeste Álvarez Aguirre

85%

Miguel Ángel Ramírez Rodríguez

85%

Un Product Backlog

Es una lista de requisitos priorizado, o historias, o funcionalidades (que el cliente quiere, donde se usa su terminología).

Product Backlog

Nombre del Proyecto:

Newport Institute

Product Backlog Nombre del Proyecto: Newport Institute 03/10/2014 Fecha de Comienzo: Objetivos Generales y Alcance:

03/10/2014

Fecha de Comienzo:

Objetivos Generales y Alcance:

Desarrollar

un Sitio web para gestionar y administrar personal y alumnos inscritos en el Instituto Newport.

Sitio web debe permitir a usuarios hacer exámenes clasificatorios en línea y almacenar los datos generados en una B.D.

Permite registrar calificaciones de exámenes de los usuarios, así como la consulta de calificaciones por medio de los alumnos.

El personal del Instituto que administra el sitio web, podrá dar de alta, baja, modificar y consultar personal y alumnos

 

Definición de Tareas y Actividades

 

Id

     

Estimación

 

Descripción

Responsable

Estado

Sprint

H.U

     

(hrs)

 
 

Diseño de la Base de Datos

Mitad de equipo

5

1

001

Diseñar el diagrama contextual

Juri

Terminado

3

 

002

Diseñar diagrama entidad-relación

Juri

Terminado

3

 

003

Diseñar diagrama relacional

Juri

Terminado

3

 

004

Implementación de la base de datos

Juri

Terminado

2

 
 

Comunicación de la base de datos con el servidor web

Antonio / Ignacio / Miguel A / Miguel

     

005

Terminado

3

 
       

Fig. 1 Formato implementado para el Product Backlog.

Un Sprint Backlog

Este consiste en dividir las Historias de usuario en tareas que van a desarrollar el equipo en la iteración.

Sprint 1

que van a desarrollar el equipo en la iteración. Sprint 1 Sprint Inicio Duración 1 06/10/2014
que van a desarrollar el equipo en la iteración. Sprint 1 Sprint Inicio Duración 1 06/10/2014

Sprint

Inicio

Duración

el equipo en la iteración. Sprint 1 Sprint Inicio Duración 1 06/10/2014 2 Semanas Sprint Backlog

1

06/10/2014

2 Semanas

Sprint Backlog

Estad Horas del Sprint/Esfuerzo por tarea Id. H.U. Requerimiento/Tareas Responsable o 0 1 2 3
Estad
Horas del Sprint/Esfuerzo por
tarea
Id. H.U.
Requerimiento/Tareas
Responsable
o
0
1
2
3
4
5
6
7
8
001
Definir entidades y atributos de cada entidad
JURI
T
002
Ya con las entidades definidas, aplicar
cardinalidad a cada una de las entidades
JURI
T
002
Se hace una relación entre las entidades
JURI
T
002
Se aplica cardinalidad a cada una de ellas
JURI
T
002
Se le asignan los atributos correspondientes a
cada entidad
JURI
T
003
Se asocia en una tabla cada una de las
entidades con sus atributos correspondientes
JURI
T
Se definen la/las llave(s) primaria(s) de cada
003
JURI
T
entidad
003
Se hace una relación de las entidades, relación
que se hizo en el diagrama anterior
JURI
T
003
Se le asigna la llave foránea adecuada a una de
las entidades
JURI
T
Se crea la base de datos en el manejador que se
004
JURI
T
eligió
004
Se crean cada una de las entidades (tablas)
JURI
T
A
004
cada una de ellas se les asigna como mínimo
una llave primaria (primary key)
JURI
T
A
cada uno de los atributos (campos de la
004
tabla) se les debe de asignar un tipo de dato
con un un tamaño de campo específico
JURI
T
004
Se deben de asignar también los campos de las
llaves foráneas
JURI
T
004
Se asignan como índice las llaves foráneas
JURI
T
004
Se hacen las relaciones, definiendo como
"CASCADA" cada una de las relaciones
JURI
T
004
Las relaciones deben hacerse entre llaves
primarias y llaves foráneas
JURI
T
005
Montar base de datos en servidor
Antonio /
Ignacio /
Miguel A /
Miguel
T
005
Crear un usuario que tenga privilegios sobre la
base de datos
Antonio /
Ignacio /
Miguel A /
Miguel
T
005
Se crea archivo de conexión en lenguaje PHP
Antonio /
Ignacio /
Miguel A /
Miguel
T
005
Crear formulario de login a la base de datos
Antonio /
Ignacio /
Miguel A /
Miguel
T
005 Crear consulta para verificar la existencia del usuario Antonio / Ignacio / Miguel A
005
Crear consulta para verificar la existencia del
usuario
Antonio /
Ignacio /
Miguel A /
Miguel
T
005
Crear archivo de validación de sesión
Antonio /
Ignacio /
Miguel A /
Miguel
T
005
Crear interfaz para terminar conexión
Antonio /
Ignacio /
Miguel A /
Miguel
T

Fig. 2 Formato de implantación de Sprint Backlog

• Una fecha concreta de entrega del Sprint La duración del sprint es: 2 semanas Fecha de Inicio: 06-10-2014 Fecha de entrega: 20-10-2014

• Un lugar y momento definidos para el Scrum Diario Lugar: salón F2 Hora: 1:00 pm a 1:15pm

Donde el Scrum Master supervisa la reunión y anota las necesidades o impedimentos que puedo detectar el equipo.

Un lugar y momento definidos para reuniones de Trabajo

Lugar: salón J4 Hora: 11:00 am a 2:00 pm Día: Viernes

Una Estructura de Trabajo La comunicación dentro del equipo será informal, a través de correo electrónico, redes sociales y dialogo cara a cara.

Unos Aspectos a Evaluar dentro del equipo:

- Puntualidad a las reuniones de trabajo

- Responsabilidad individual

- Organización ene l trabajo

- Compromiso en la entrega de trabajos individuales y por equipo.

4.5 Reunión de Trabajo

Esta tiene como objetivo ir desarrollando las actividades del sprint donde participa todo el equipo de Scrum.

Seguimiento que se dio:

-El Scrum Master realiza el pase de lista en la hora acordada, anotando retardos y ausencias de miembros del equipo. - Posteriormente se ilustra la planificación del sprint, donde se observa el orden de las actividades a elaborar. -Se llevaron a cabo las actividades de acuerdo a la planeación tomando en cuenta las horas planeadas, pero en caso de no alcanzar se a largo el tiempo de dedicación. -Scrum Master se encarga de proporcionar todo lo necesario para que no haiga impedimentos de no trabajar y de registrar los conflictos o impedimentos presentes para la terminación de alguna actividad. -En caso de no concluir todas las actividades de ese día se propone otro día de trabajo o si cada responsable individualmente realiza su tarea pero con una fecha de entrega.

Reunión 10-oct-2014

o

El Scrum Master realiza el pase de lista a la 11:00 am.

o

El Scrum master se encargó de leer lo que es la H.U al resto del equipo Scrum

o

El encargado de esa H.U pasa a diseñar el diagrama contextual de la BD en el pizarrón, pidiendo posteriormente la opinión de los demás miembros del equipo de desarrollo, donde se consideraron algunos cambios por la votación de la mayoría del equipo. (conflictos que se presentó, no podían llegar a un acuerdo de las relaciones entre las entidades).

o

El diseñador va generando en diseño del modelo entidad relación con el apoyo de reto del equipo scrum.

o

Finalmente se concluye con el diseño del diagrama relacional con su respectiva Normalización donde todo el equipo participo en su creación y el diseñador se encargó de ilustrarlo en el pizarrón.

o

El documentador se encargó de ir pasando los diseños en papel.

o

Mientras el equipo de desarrollo trabajaba, los tésters se encargaron de crear las historias de prueba para las Historias terminadas.

Reunión 17-oct-2014

o

El Scrum Master realiza el pase de lista a la 11:00 am.

o

El diseñador se encargó de realizar la H.U 004, crear la base de datos en el manejador de base de datos.

o

Los programadores se encargaron de realizar la H.U 005 de la conexión de la base de datos con el servidor.

o

Los tésters realizaron las pruebas de las H.U terminadas.

o

El Scrum master y el product Owner actualizaron el product backlog y apoyaron al resto del equipo en sus actividades.

Grafica de Asistencia a reuniones de Trabajo

3 2 Asistencia Retardo faltas 1 0 Miguel Miguel Celeste Antonio Jurhiata Maria Martha Diana
3
2
Asistencia
Retardo
faltas
1
0
Miguel
Miguel
Celeste
Antonio
Jurhiata
Maria
Martha
Diana
Ignacio
Anguel
Anguel
Alvarez
Abraham
Joel Ibarra
Esmeralda
Leticia
Fernanda
Alan
Rodriguez
Ramirez
Aguirre
Ochoa
Garnica
Perez
Sanchez
Diaz Leon
Moreno
Guzman
Rodriguez
Avalos
Piñon
Lopez
Avila