Diapositiva 1

Diapositiva 2

Metodologa Scrum Grupo S2 Ariel Amantea 81968 Assefi, Ershad80670 Giachini, Andres82096 Victoriano, Oscar 81713 Taller de Desarrollo de Proyectos II 2 Cuatrimestre 2008

Diapositiva 3

Esta presentacin no pretende vender nada, simplemente exponer nuestra forma de realizar un proyecto asimilando una metodologa diferente para nosotros hasta el momento. No solo no esperamos que todo est correcto, sino que creemos que hay errores, queremos corregirlos y esperamos que as sea.

Diapositiva 4

Diapositiva 5

Product Backlog Sprint Backlog User Stories UAT Casos de Prueba Planilla de administracin de riesgos Minuta de Reunin Sprint Review Sprint Retrospective Etc.

Diapositiva 6

Aplicacin Web PHP Diseo en capas Framework MVC (iOnix) Apache HTTP Server MySQL

Diapositiva 7

Diapositiva 8

Diapositiva 9

Diapositiva 10

La administracin de riesgos fue quizs, uno de los puntos mas dbiles de la administracin. Dificultad para identificarlos (al principio no eran del todo claros) Fue uno de los documentos que menos vari en el transcurso del proyecto y no creemos que esto sea del todo representativo.

Diapositiva 11

Utilizamos como expresamos en la primer exposicin, el MSN (chat) para realizar las reuniones diarias. Los llamados telefnicos personales se incrementaron de forma notoria al final de cada sprint mientras se estabilizaba la versin que sera presentada en la revisin. Al comienzo del proyecto los mails de apoyo con instrucciones acerca de las herramientas utilizadas (principalmente el Framework) o detallando los problemas encontrados y las soluciones aplicadas fueron de gran utilidad (esto se vio potenciado por la incapacidad de encontrarnos cara a cara a la hora de desarrollar el aplicativo)

Diapositiva 12

Se especific un esquema de trazabilidad acorde a nuestras necesidades, logrando trazabilidad entre: Especificaciones vs. Cdigo Asociando cada commit a una tarea (ticket) de assembla (las cuales a su vez hacan referencia a una US y Sprint) Especificaciones vs. Pruebas Asociando cada caso de prueba y UAT a su US y Sprint correspondiente Especificaciones vs. Diseo Asociando cada seccin del documento de diseo a la US correspondiente.

Diapositiva 13

Mtodo de estimacin > Wideband Delphi Valor = optimista + 4*mas probable + pesimista / 6 Cada integrante estimaba y luego se refinaba hasta llegar a tener valores similares. Planificacin de tareas > creacin de tickets en assembla Permiti llevar un control del estado de las tareas, fechas de vencimiento, etc. Planificacin por sprint (Al principio de cada sprint se planificaban las tareas a realizar)

Diapositiva 14

Sprint Burndown Chart Product Burndown Chart Team Velocity

Diapositiva 15

A travs del sistema de tickets de assembla Por cada bug, se generaba un ticket asociado a una tarea. Permiti controlar los defectos, llevar estadsticas de bugs sin resolver, revisiones de sus estados, etc.

Diapositiva 16

El control de cambios se llev a cabo a travs de la implementacin de un comit de cambios, con un aprobador y varios analistas de cambios. El proceso fue el siguiente: 1 Se solicitaba el cambio al product owner del equipo 2 El product owner presentaba el cambio solicitado al aprobador a travs de la carga de un nuevo ticket en Assembla 3 El aprobador analizaba el cambio, discuta con el resto del equipo el impacto que poda llegar a tener y el costo para realizarlo. 4 Si el cambio se aprobaba, se lo planificaba para un sprint prximo, sino quedaba sujeto a una lista de priorizacin a futuro (los cambios no se desechaban). 5 Se informaba al solicitante la decisin adoptada.

Diapositiva 17

Diapositiva 18

La realizacin de la misma un lunes agregaba dos das de distensin en el equipo en el ritmo de trabajo, provocando olvidos y percepciones diferentes a las que se obtendran por ejemplo al realizarla un viernes (luego de todo el trabajo de la semana) Dificultad para respetar los tiempos de presentacin de situaciones y el anlisis de las mismas. Nos veamos tentados a analizar o cuestionar un tem al momento de presentarse el mismo. Propusimos que cada miembro lleve una bitcora personal de tems durante el sprint para evitar el olvido de las situaciones pasadas en los primeros das del sprint.

Diapositiva 19

Se presentaron dificultades al intentar evitar el encasillamiento de tareas por parte de los miembros a la hora de tomar tems. Si bien cada uno toma el que prefiera (respetando la prioridad de ser posible), generalmente cada uno tomaba las que mas conoca para agilizar el transcurso del sprint y no retrasarnos. Hubiera sido de gran ayuda el compartir el espacio fsico a la hora de realizarse el proyecto (pair programing, revisiones de cdigo, comentarios verbales, etc.), por lo cual recomendamos fuertemente que los miembros del equipo, de ser posible, compartan la misma habitacin (a la hora de trabajar) y que todos tengan contacto visual con todos.

Diapositiva 20

Encontramos en las primeras reuniones falta de preparacin para las review. Predomin una falta de fluidez, la cual, de alguna u otra manera, daba una imagen de timidez ante el cliente (algo para nada recomendable) y que perjudicaba el normal desenvolvimiento de la misma. Ante diferencias de opiniones entre los miembros del equipo, el cliente tenda a desconfiar de lo que se le presentaba y de la veracidad de nuestras respuestas.

Diapositiva 21

A pesar de no estar familiarizados con la metodologa y las restricciones presentadas por ser un proyecto acadmico, SCRUM demostr ser efectiva. El cliente estuvo constantemente informado y satisfecho (en mayor y menor medida ). Se logr en poco tiempo adquirir las costumbres que hacen a las bases de la metodologa e incorporar otras que son propias del proyecto dndole as flexibilidad y una customizacin que sera imposible con una estructura rgida e invariante de trabajo. Pero este es nuestro punto de vista, deberamos ahora preguntarles nosotros a nuestro cliente y a los presentes si desde su punto de vista

Diapositiva 22

Diapositiva 23

Se logr un buen trabajo a partir de la utilizacin de User Stories y User Acceptance Test, herramientas que el equipo de trabajo nunca haba utilizado antes, a pesar de que quedaron cuestiones a mejorar en ese aspecto. Se logr un trabajo coordinado y cohesivo con el uso de la metodologa Scrum, que permiti al equipo cumplir con todos los entregables, contabilizando un nico rechazo de una funcionalidad entregada en un sprint temprano. Dicho rechazo nos permiti comprender que debamos dedicar un mayor esfuerzo a la realizacin y ejecucin de los test de aceptacin, y sobre todo, a realizar con mayor anticipacin la preparacin del ambiente de aceptacin del producto. Cumplir siempre con lo pactado (incluso ms en algunas oportunidades) ayud a asegurar la confianza de nuestro cliente.

Diapositiva 24

A pesar de contar con un esquema de trazabilidad, el mismo result complejo de utilizar, por lo cual debera tratar de modificarse a futuro, a fin de hacerlo ms prctico y menos engorroso para los integrantes del equipo. El mtodo de estimacin utilizado no result de lo mas amigable para la metodologa utilizada. Debera contemplarse la utilizacin de story points como unidad de medida a futuro para una mayor compatibilidad con las herramientas de control provistas por Scrum. Debido a la naturaleza del trabajo, no pudo aplicarse Scrum en todo su amplio sentido. El ejemplo claro es el de las daily meeting, que por cuestiones obvias no fueron realizadas como la metodologa lo sugiere. Sin embargo, se ha comprobado que la metodologa es realmente til a pesar de estos detalles.

Diapositiva 25

Diapositiva 26

Diapositiva 27