Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47)...

Taller de Desarrollo de Proyectos II (75.47)Grupo 2 Taller de Desarrollo de Proyectos II (75.47)

Presentación Final

ERNESTO GIMENO79684

PABLO BESADA79763

SANTIAGO PETERSEN

82689

PATRICIO FAGALDE

83810

Grupo 2

Taller de Desarrollo de Proyectos II (75.47)Grupo 2

Temario

Proceso de desarrollo ¿Por qué lo elegimos? ¿Qué resultado obtuvimos?

Equipo de Trabajo: Organización Métricas Desvíos no planificados Cambios de Alcance Lecciones Aprendidas Demostración


Proceso de Desarrollo

Se eligió un proceso de desarrollo iterativo e incremental basado en la utilización de user stories y UAT’s

¿Por qué lo elegimos? Mayor flexibilidad ante requerimientos incompletos Mejor respuesta a los cambios de requerimientos por parte del cliente Mayor experiencia del equipo con este tipo de ciclo de vida de proyectos Tiende a involucrar al cliente en el proyecto


Proceso de Desarrollo

¿Qué resultado obtuvimos? Se pudieron manejar sin grandes inconvenientes los cambios en los requerimientos La adaptación del equipo de trabajo fue muy rápida ya que todos estaban familiarizados con el proceso de desarrollo El cliente se involucró en el proyecto desde el inicio y participó en las decisiones del proyecto bajo el rol de product manager La documentación que se generó fue suficiente pero no excesiva ni redundante, aportando valor al proyecto.


Equipo de Trabajo

El equipo de trabajo se organizo en 2 roles: Desarrollador: Patricio, Ernesto y Pablo Documentador y Tester: Santiago

Las tareas se asignaron por medio de reuniones de trabajo semanales.

Cada integrante seleccionaba de la lista de User Stories a desarrollar, los que quería realizar y se comprometía a terminarlos antes de la siguiente reunión.


Métricas

Avance del proyecto tomado al final de la quinta iteración: Lineas

Grafico de Avance del Proyecto

0

20

40

60

80

100

120

0 1 2 3 4 5 6

Iteracion

Pu

nto

s

TOTAL

UAT Disponible

UAT Aceptado

US Desarrollado

US Aceptado


Métricas

Avance del proyecto tomado al final de la quinta iteración: Barras

Grafico de Avance del Proyecto

0

20

40

60

80

100

120

0 1 2 3 4 5

Iteracion

Pu

nto

s

TOTAL

UAT Disponible

UAT Aceptado

US Desarrollado

US Aceptado


Métricas

Evolución de bugs tomado al final de la quinta iteración

Gráfico de Calidad

0

5

10

15

20

25

30

35

1 2 3 4 5

Iteración

Ca

ntid

ad

Bugs Totales

Bugs Corregidos


Desvíos no planificados

En la última iteración no se llegó con la aplicación estabilizada y hubo que dedicar para este fin, esfuerzo que estaba asignado al cierre del proyecto.

Se resolvió con “horas extra” de parte del equipo de trabajo y reasignación de tareas.


Cambios de Alcance

Al comenzar la última iteración (16-11-09) el cliente realizó una serie de pedidos de cambio.

Dadas las características del proyecto, la gestión del cambio es tratada en la misma reunión de avance, quedando reflejado el pedido y el control de cambios en la minuta del día:1. Última actividad de foros: Listado de los últimos posts de

los foros a los que pertenece.

Este pedido ya estaba contemplado en la implementación del US Ver novedades, ya que se notifica sobre la actividad en los foros. El cliente pide que en las novedades sobre los foros, aparezca el link al mismo.


Cambios de Alcance

2. Novedades de otros contactos: Lista de amigos que han aceptado contactos en la última semana.

Se agrega al US “Ver novedades” el aviso de que un contacto se relacionó con un usuario, incluyendo el link al perfil público de éste último para facilitar la solicitud de relación.

3. Gente que podrías conocer: Sugerir contactos de contactos: hasta 5 que al menos haya cursado 1 materia en común de las aprobadas en el último cuatrimestre.

Luego de un breve intercambio sobre el costo de este cambio, el cliente lo desestima.


Cambios de Alcance

4. Solicitudes pendientes: Si existen, alertar al usuario con un acceso directo a la lista de solicitudes pendientes de contactos ya desarrollada.

Ya se encuentra implementado.

5. Cumpleaños: Listado de cumpleaños de tus contactos de la semana actual.

El cliente le asigna baja prioridad y debido a todos los pedidos de cambio ya aceptados por el equipo de trabajo, desiste de este pedido.


Cambios de Alcance

1 cambio es desestimado por el cliente debido a su alto costo.

4 cambios aceptados (80%). 3 cambios que entran en la siguiente iteración

(60%). 1 cambio aceptado nunca es implementado debido a

la baja prioridad asignada por el cliente Sólo 1 cambio aceptado y planificado implica un

trabajo significativo para el equipo (20%). Resultado: Cliente satisfecho, equipo de trabajo

contento.


Lecciones Aprendidas

Prevenir con anterioridad incumplimientos en algún entregable e incluirlo dentro como riesgo, predispuso mejor al cliente para aceptar la demora.



Sincronizar las reuniones con el cliente con las reuniones de trabajo del equipo simplificó mucho la distribución de tareas para cada semana.



Se le dio poca importancia a las pruebas unitarias luego de las primeras iteraciones. Esto trajo algunos problemas con errores inesperados en las últimas iteraciones.



Si el equipo se arma de a pares, igualmente es conveniente que haya alguien cumpliendo un rol de coordinador que esté atento al avance del trabajo comprometido. Puede ser un rol rotativo para evitar el desgaste propio de la función.



Si el equipo de trabajo va a estar distribuido geográficamente, no planificar el proyecto como si el equipo de trabajo pudiera estar permanentemente en contacto.



Si el equipo de trabajo va a estar asignado a múltiples proyectos (en nuestro caso, varias materias además de la jornada laboral) no planificar el proyecto como si el equipo de trabajo estuviera asignado full time al proyecto y disponible para reunirse en cualquier momento.



Con iteraciones de 2 semanas conviene escribir los UAT de la próxima iteración en paralelo. Si se presentan los UAT a mitad de iteración el cliente va a incluir cambios que no podemos rechazar.



Tener al cliente involucrado en el proyecto facilitó la gestión de cambios ya que éste comprendía el costo que implicaba incorporar algunas funcionalidades.



Evitar por todos los medios posibles llegar a la entrega de una iteración “estabilizando” la aplicación hasta unas horas antes de la entrega. El riesgo que se toma (probabilidad x impacto) es muy grande, Y EL CLIENTE LO NOTA.


Preguntas

Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47)...

Documents

Transcript of Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47)...