Administrado y desarrollado utilizando Scrum 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!