1 Metodología Scrum Grupo S2 Ariel Amantea Assefi, Ershad80670 Giachini, Andres82096 Victoriano, Oscar Taller de Desarrollo de Proyectos II 2º Cuatrimestre 2008

2

3 Product Backlog Sprint Backlog User Stories UAT Casos de Prueba Planilla de administración de riesgos Minuta de Reunión Sprint Review Sprint Retrospective Etc.

4 Aplicación Web PHP Diseño en capas Framework MVC (iOnix) Apache HTTP Server MySQL

5

6

7

8 La administración de riesgos fue quizás, uno de los puntos mas débiles de la administración. 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.

9 Utilizamos como expresamos en la primer exposición, el MSN (chat) para realizar las reuniones diarias. Los llamados telefónicos personales se incrementaron de forma notoria al final de cada sprint mientras se estabilizaba la versión que sería presentada en la revisión. 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)

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

11 Se especificó un esquema de trazabilidad acorde a nuestras necesidades, logrando trazabilidad entre: Especificaciones vs. Código Asociando cada commit a una tarea (ticket) de assembla (las cuales a su vez hacían referencia a una US y Sprint) Especificaciones vs. Pruebas Asociando cada caso de prueba y UAT a su US y Sprint correspondiente Especificaciones vs. Diseño Asociando cada sección del documento de diseño a la US correspondiente.

12 Sprint Burndown Chart Product Burndown Chart Team Velocity

13 A través del sistema de tickets de assembla Por cada bug, se generaba un ticket asociado a una tarea. Permitió controlar los defectos, llevar estadísticas de bugs sin resolver, revisiones de sus estados, etc.

14 El control de cambios se llevó a cabo a través de la implementación 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 través de la carga de un nuevo ticket en Assembla 3 – El aprobador analizaba el cambio, discutía con el resto del equipo el impacto que podía llegar a tener y el costo para realizarlo. 4 – Si el cambio se aprobaba, se lo planificaba para un sprint próximo, sino quedaba sujeto a una lista de priorización a futuro (los cambios no se desechaban). 5 – Se informaba al solicitante la decisión adoptada.

15

16 La realización de la misma un lunes agregaba dos días de distensión en el equipo en el ritmo de trabajo, provocando olvidos y percepciones diferentes a las que se obtendrían por ejemplo al realizarla un viernes (luego de todo el trabajo de la semana) Dificultad para respetar los tiempos de presentación de situaciones y el análisis de las mismas. Nos veíamos tentados a analizar o cuestionar un ítem al momento de presentarse el mismo. Propusimos que cada miembro lleve una bitácora personal de ítems durante el sprint para evitar el olvido de las situaciones pasadas en los primeros días del sprint.

17 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 conocía para agilizar el transcurso del sprint y no retrasarnos. Hubiera sido de gran ayuda el compartir el espacio físico a la hora de realizarse el proyecto (pair programing, revisiones de código, comentarios verbales, etc.), por lo cual recomendamos fuertemente que los miembros del equipo, de ser posible, compartan la misma habitación (a la hora de trabajar) y que todos tengan contacto visual con todos.

18 Encontramos en las primeras reuniones falta de preparación 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 tendía a desconfiar de lo que se le presentaba y de la veracidad de nuestras respuestas.

19 A pesar de no estar familiarizados con la metodología y las restricciones presentadas por ser un proyecto académico, 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 metodología e incorporar otras que son propias del proyecto dándole así flexibilidad y una customización que sería imposible con una estructura rígida e invariante de trabajo. Pero este es nuestro punto de vista, deberíamos ahora preguntarles nosotros a nuestro cliente y a los presentes si desde su punto de vista…

20

21 Se logró un buen trabajo a partir de la utilización de User Stories y User Acceptance Test, herramientas que el equipo de trabajo nunca había 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 metodología 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 debíamos dedicar un mayor esfuerzo a la realización y ejecución de los test de aceptación, y sobre todo, a realizar con mayor anticipación la preparación del ambiente de aceptación del producto. Cumplir siempre con lo pactado (incluso más en algunas oportunidades) ayudó a asegurar la confianza de nuestro cliente.

22 A pesar de contar con un esquema de trazabilidad, el mismo resultó complejo de utilizar, por lo cual debería tratar de modificarse a futuro, a fin de hacerlo más práctico y menos engorroso para los integrantes del equipo. El método de estimación utilizado no resultó de lo mas amigable para la metodología utilizada. Debería contemplarse la utilización 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 metodología lo sugiere. Sin embargo, se ha comprobado que la metodología es realmente útil a pesar de estos detalles.

23

24

25