Beneficios Fiuba4Android Grupo 6: María Ciminieri Celeste Guzmán Leonardo Pittelli Product Owner: Alejandro Molinari Taller de desarrollo de proyectos Segundo Cuatrimestre de 2011

Agenda Metodología de Trabajo Tecnologías y herramientas Interacción entre aplicaciones Trazabilidad Lecciones Aprendidas

Metodología de trabajo Scrum Pero no al 100% Planilla Product Sprint Backlog No cumplimos al 100% la metodología sino que la adaptamos según nuestras necesidades y posibilidades. Por los distintos horarios de cada uno y porque no todos trabajábamos todos los días en el proyecto, las daily meetings fueron en su mayoría por mails y Skype. Buscamos repositorios con herramientas, elegimos Assembla pero como nadie lo había utilizado y no sabíamos cuan flexible era (y para no perder información importante) buscamos varias planillas y elegimos 1 para seguir el proceso y lo definimos como un riesgo.

Planilla product sprint backlog I Riesgo materializado Descripción Consecuencia Fecha Act. Plan de mitigación Resp. Estado Observaciones Desconocimiento de Assembla como herramienta de organización Se podría perder información valiosa. 26-sept.-11 Llevar planillas de excel externas a modo de backup Scrum Master Cerrado Realizando el primer Sprint se fue aprendiendo y se optó por aplicar el plan de mitigación para errores y tiempo. Se decidió seguir utilizando archivos externos para la administración hasta el final del proyecto. El riesgo finalmente se materializó a mediados del primer Sprint. A la hora de armar el informe de avance nos resultó mucho más útil y completa la planilla que habíamos elegido y nos decidimos por continuar con ella y abandonar Assembla. Pudimos entonces contrarrestar el impacto mediante el uso de los documentos que surgieron del plan de mitigación.

Planilla product sprint backlog II La planilla tiene varias secciones, una de ellas es el product backlog donde teníamos todas las USs y resultaba muy útil a la hora de priorizar con el product owner y definir cuáles iban a ser parte del Sprint.

Planilla product sprint backlog III Otra parte importante era la del Sprint Backlog. Ahí descomponíamos cada US en tareas y cada día que se trabajaba en alguna de ellas nos ocupábamos de reestimar el esfuerzo restante. Las tareas las teníamos como tickets en Assembla también para la trazabilidad del código pero no manejábamos esfuerzo restante ahí. Además el gráfico de arriba mostraba una tendencia de cómo íbamos y nos preocupaba o tranquilizaba fácilmente con sólo mirarlo. También llevábamos en la misma planilla las horas estimadas y consumidas en cada Sprint.

Planilla product sprint backlog IV Planilla vs. Assembla Mejor control de información. Personalización a nuestras necesidades. Acceso rápido y sin Internet. Imposibilidad de edición simultánea. Incompatibilidades entre editores. En esta comparación se ven las ventajas y desventajas de haber utilizado la planilla. En caso de haber usado Assembla en lugar de la planilla estarían invertidas las ventajas y desventajas. Cuando tuvimos que decidir cómo seguir hicimos este mismo análisis y nos pareció más valioso «ganar los más» que «perder los menos».

Tecnologías y herramientas Las tecnologías utilizadas fueron eclipse como IDE, assembla como repositorio y para cierta parte de trazabilidad. Para la aplicación android usamos el Android development kit y ADT el plugin que integra android con Eclipse. Para la aplicación BackOffice usamos el framework Grails y una Base de Datos MySQL.

Interacción entre las aplicaciones Este es un diagrama básico de la interacción entre las aplicaciones. Por un lado está el administrador que a través de internet accede al servidor de la aplicación que maneja por detrás la Base de Datos. Por otro lado el usuario final a través del celular, donde tiene alojada la aplicación que descargó desde el market interactúa con ella y cuando hay que pedir información al BackOffice el paquete grailsConection es el que hace el pedido a través de internet y el servidor el que le contesta los datos en un JSON para que el celular se encargue de mostrarlo.

Trazabilidad Assembla + PSB Hitos - Assembla + PSB Commits Assembla User Stories Tareas Sprints Bugs Código Assembla + PSB Hitos - Assembla + PSB Commits Assembla Planilla de errores y mejoras Planilla de errores y mejoras Commits – Assembla + Planilla de errores y mejoras

Lecciones aprendidas I Manejo del esfuerzo comprometido A medida que pasaron los Sprints, nos fuimos comprometiendo cada vez con más trabajo pensando en el tiempo que teníamos y que íbamos a tener y las funcionalidades que quedaban, hasta que en el tercer sprint se nos complicó y para el cuarto disminuimos la cantidad de esfuerzo comprometido. Fue una buena decisión porque el cuarto Sprint fue el de menor trabajo comprometido pero con más problemas y el segundo con más tiempo invertido. Creemos que gracias a eso fue que llegamos al final del proyecto con un quinto Sprint muy tranquilo y todo lo que nos pidió el cliente.

Lecciones aprendidas II Estimamos tiempos y problemas Reestimando en cada Sprint Tomando siempre la estimación del Sprint 1 Relacionado con lo anterior es que estimamos horas para cada Sprint basándonos en Story Points realizados y horas consumidas en los anteriores Sprints. Esto hizo que en el último Sprint la estimación aumentara debido a que se incluyó para estimar el Sprint anterior donde hubo problemas, generando una sobreestimación. En el gráfico de la izquierda se ve cuánto de más trabajamos en cada Sprint según lo que habíamos estimado para cada uno teniendo en cuenta los anteriores. A la derecha se ve cómo hubiera sido eso mismo si siempre hubiésemos utilizado la estimación del Sprint 1. No nos hubieran sobrado horas en el último Sprint. Con esto no queremos decir que mantener la primer estimación durante todo el proyecto hubiese sido lo correcto. Quizás para los Sprints con tareas más complicadas tener en cuenta un posible desvío y para los Sprints con tareas más simples no hubiera resultado mejor pero nunca puede saberse eso de antemano. Por algo es una estimación.

Lecciones aprendidas III Investigo, luego negocio Vino bien tener idea de las próximas tareas que podía pedir el cliente e investigarlas antes de ir a la reunión para saber cuán difíciles podían resultar y poder contestarle si sus pedidos eran factibles sin comprometernos con algo imposible. Además ayudó a resolver en el momento dudas que podían surgir al comenzar con esas tareas y complicarse por el feeedback (por ejemplo: carga y almacenamiento de imágenes de rubros y beneficios en Android) Fue un muy buen ejercicio usar esa investigación para intentar contrarrestar la actitud del cliente de pedir features sin conocer el costo. Ver cómo manejar la situación y cómo contestarle de forma que un cliente (sin entendimiento técnico, aunque fuera de manera actuada) pudiera entender.

Lecciones aprendidas IV Gráficos poco relevantes 2 bugs!! El mostrar información de bugs por día en los informes de avance no agregaba información. Era importante para mostrar que se tenía el control, pero al ser siempre pocos los bugs los gráficos no aportaban mucho. La planilla resultaba más útil para el día a día y el gráfico era sólo para el informe.

Lecciones aprendidas IV Gráficos poco relevantes Mirando la planilla y los colores era mucho más fácil ver cantidad de defectos y cosas a resolver que en un gráfico como el de los informes.

Lecciones aprendidas V ¿Atrasados en tiempo y adelantados en esfuerzo? 10 hs por debajo de lo estimado Durante el Sprint 2 surgió esa pregunta. ¿Cómo podía ser que estuviéramos atrasados en tiempo pero adelantados en esfuerzo? La explicación que encontramos fue que la estimación de horas estaba dada en base a la velocidad del equipo en el Sprint 1 y en ese Sprint hubo mucho esfuerzo de investigación y aprendizaje de la tecnología que en el Sprint 2 ya no era tan necesario. Tendencia indicaba que se iba a llegar bien días

Lecciones aprendidas VI Retrospectivas útiles Las retrospectivas nos resultaron útiles, ayudaron a reflexionar y a aplicar cambios en los siguientes sprints. Tratamos de mejorar siempre “lo que no estuvo bien” de la retrospectiva anterior y mantener “lo que estuvo bien”. Mejorar lo que no estuvo bien. Continuar con lo que estuvo bien

Lecciones aprendidas VII Desconocimiento de la tecnología y mala estimación Elección Nos complicamos al querer hacer el globito sobre el mapa y no el cartelito. Cuando nos dimos cuenta, ya nos habíamos comprometido con el cliente y no podíamos volver para atrás. Quizás faltó el análisis del impacto y la dimensión de la elección de cómo hacerlo antes de comenzar la tarea que debió ser propuesta como una mejora y no intentar realizarla dentro del Sprint.

Lecciones aprendidas VII Desconocimiento de la tecnología y mala estimación Exceso de 40 horas Finalmente se llegó. Nos excedimos en tiempo porque todo el equipo terminó trabajando en lo mismo para lograrlo, pero ayudó a que el cliente quedara conforme con la funcionalidad.

Lecciones aprendidas VIII ¿Test automatizados? ¿Hace falta? En una reunión surgió esa pregunta. La conclusión a la que llegamos es que en un principio es más costoso pero a medida de que pasan los Sprints el costo se mantiene prácticamente constante mientras que, sin tests automatizados, el costo es acumulativo y creciente. Además con tests automatizados podemos asegurar que todo sigue funcionando luego de introducir algún cambio simplemente corriendo los tests. O, en caso de que alguno falle, es más fácil encontrar el problema.

Lecciones aprendidas IX Mucha información pero... Entonces?? Descripción Consecuencia Exp. Plan de mitigación Plan de Contingencia Resp. Tendencia Acciones tomadas Los integrantes del equipo no están dedicados full-time al proyecto Retraso en el calendario por falta de disponibilidad. 0,2 Elegir las tareas para cada Sprint de manera adecuada a los tiempos disponibles.   Scrum Master Se trabajó mucho durante el fin de semana y las tareas se fueron cerrando correctamente. Uso de distintos sistemas operativos por parte de los desarrolladores Incompatibilidades que retrasen el desarrollo. 0,06 Unificar sistema operativo y versión de todos los desarrolladores Se continua con los archivos paralelos La gestión de riesgos es crucial en todo proyecto para tomar acciones preventivas, formalizarlos mediante los informes de avance, es una buena práctica compartirlos con el cliente, y es una buena forma para pasarle al cliente impedimentos a resolver. Pensando en eso, acordamos agregar una flecha de tendencia y una columna de acciones tomadas para permitirle al cliente y al responsable un mejor seguimiento y la elaboración de planes de mitigación y contingencia adecuados.

¡Vamos a la demostración!

¿Preguntas?

¡Muchas gracias!