Proyecto “PMP”Administrado y desarrollado utilizando Scrum

Integrantes y Roles

Si bien todos formamos parte del Team, se distribuyeron los roles de la siguiente forma:

Product Owner: Mariana de la Merced

Scrum Master: Federico Zaiatz

Team:

Leonardo Gorbliuk

Fernando Nardini

Reuniones Realizadas

A lo largo de los diferentes Sprints del proyecto, se realizaron las siguientes reuniones (con el objetivo de que el PO puede ir viendo los resultados parciales del producto, asi como tambien el Team pueda ir conociendo el feedback del mismo):

Sprint Planning Meeting

Daily Sprint Meeting

Sprint Review

Sprint Retrospective

Sprint Planning Meeting

Partiendo desde un Product Backlog inicial, el Team se reunia con el PO cada 2 semanas (en ciertas excepciones fueron 1 o 3), con el objetivo de:

Priorizar los User Stories del Product Backlog

Estimarlos, en base a la descripcion de los mismos relatada por el PO

Decidir qué Product Backlog Items entrarían dentro de la realización del próximo Sprint

Daily Sprint Meeting

Dado que los integrantes del Team nos encontrabamos en lugares físicos distintos, la reunion diaria nunca fue realizada en persona, sino por emails y/o por telefono.

Dada la naturaleza la comunicacion, no hemos podido garantizar una reunion diaria, dia por dia, durante todos los Sprints, lo que nos llevó en ciertas situaciones a problemas de comunicación y/o confusión sobre ciertos aspectos del producto.

Sprint Review

La Demo con el PO fue realizada en toda finalizacion del Sprint, y justo antes de la reunion de planeamiento del proximo Sprint.

Si bien existieron demos con devoluciones de ciertas funcionalidades, asi como también demos en las que no pudimos mostrarle al PO el total de la funcionalidad comprometida para dicho Sprint, todas fueron aprobadas, y pasaron satisfactoriamente los User Acceptance Tests (UAT) consensuados con el PO.

Sprint Retrospective

A lo largo de los sucesivos Sprints, el Team hizo reuniones retrospectivas para analizar que debía dejar de hacer, que debía seguir haciendo, y que debia comenzar a hacer para mejorar su productividad y ambiente, para el proximo Sprint.

Como resultados generales a lo largo de los diferentes Sprints, se obtuvieron:

Tener una mayor dedicación y proactividad desde el inicio del Sprint

Mejorar la comunicación entre los integrantes del Team

Seguir promoviendo la colaboracion entre los integrantes del Team frente a dificultades o situaciones no esperadas

Mejorar las estimaciones, teniendo en cuenta nuevas tecnologías y/o librerias a utilizar

Hacia los ultimos Sprints, seguir promoviendo la comunicacion entre los integrantes del Team

Administración: Aspectos generales

Para conocer el estado de evolución del producto, se iba actualizando y observando el Product Burndown, así como tambien una comparativa entre los items planificados vs los realmente finalizados.

Asimismo, dentro de cada Sprint, se realizaba un seguimiento de las horas pendientes de cada item dia a dia, y se lo reflejaba en el Sprint Burndown (comparandolo con el ideal esperado).

Por otro lado, para el momento de la estimacion, se partió de una velocidad para el equipo de 0.75, la cual se fue actualizando entre Sprints, según correspondiera.

Administración: Product Burndown

Administración: Estimado VS Real

En el siguiente gráfico pueden verse los Story Points estimados vs los reales, a lo largo de los diferentes Sprints.

Administración: Sprint Burndown I

A continuación se pueden observar dos Sprint Burndown distintos. En el primero (Sprint 4), se terminan con todas las taras comprometidas; y en el segundo (Sprint 2) quedando algunas pendientes (realizacion incompleta del Sprint).

Administración: Sprint Burndown II

Administración: Riesgos

Para la administración de riesgos, utilizamos una planilla con los siguientes datos:

ID, Descripcion, Criticidad, Probabilidad de Ocurrencia, Impacto, Mitigacion, Contingencia, Evolucion, Estado

La misma se actualizaba Sprint tras Sprint, e incluso dentro de cada Sprint, acorde a nuevos riesgos detectados, o a cambios en la probabilidad de ocurrencia, criticidad, etc.

Administración: Riesgos (cont.)

Entre los riesgos detectados, podemos destacar (ordenados por impacto, de mayor a menor):

Entrega tardía de los UAT

Posible atraso en las tareas por enfermedad de alguno de los integrantes del Team

Imposibilidad de tener el ambiente para la demo, disponible para la fecha acordada

Administración: Documentación

Para llevar a cabo el mantenimiento de la documentación involucrada en el proyecto se utilizó Subversion (Google Code). De esta manera se pudo proveer al cliente de acceso a toda la documentación actualizada en todo momento.

Desarrollo del Producto

El mismo fue realizado en Java (WEB), utilizando MySQL como motor de base de datos.

Como repositorio de fuentes, se utilizó Subversion provisto por Google Code.

Testing

Se realizaron tests de unidad a lo largo del desarrollo del producto, aunque los mismos no fueron automatizados.

La herramienta utilizada para el seguimiento de bugs fue provista por Google Code.

Documentación para el Cliente

A lo largo del proyecto, se le fue presentando al cliente:

UAT: tests de aceptacion de usuario. Los mismos definian la funcionalidad basica que tendria que cumplir el producto (analizados en la Sprint Review)

Minuta de Reunion: se detallan los items conversados y acordados en la ultima reunion con el cliente, para el o los próximos Sprints

Casos de prueba (con su ejecucion correspondiente)

FIN

MUCHAS GRACIAS!