Aplicación de la metodología ágil “Scrum” 75.47 – Taller de Desarrollo de Proyectos II Aplicación de la metodología ágil “Scrum” Proyecto: TCAdmin BOERR, Federico – 80.982 GASTAUD, Hernán – 82.539 UEHARA. Adrián – 82.726 VENDITTI, Sebastián – 84.614 Alumnos:

Proyecto “TCAdmin” TCAdmin® Construcción de una herramienta que permita crear, almacenar y registrar resultados de la ejecución de casos de prueba de sistemas informáticos. Desarrollo del proyecto utilizando la metodología ágil scrum. Adaptación del proceso de desarrollo para cumplir con los artefactos solicitados. TCAdmin®

Proceso de desarrollo Scrum Metodología ágil. No tiene muchas herramientas de gestión. Framework simple. Componentes: Roles Artefactos Meetings

El equipo de trabajo Hernán Federico Adrián Carolina Federico Hernán Sebastián Carolina Carolina

Reuniones Reuniones Internas Reuniones Externas Consultas / Acuerdos Sprint Retrospective Daily Meeting Reuniones Externas Reuniones de Avance Sprint Planning Meeting Sprint Review Consultas / Acuerdos Via mail Reuniones Internas: Sprint Retrospective: Se trata de una reunión en la que el equipo analizaba la conclusión del Sprint que acababa de finalizar, y determinaba lo que podría cambiarse en el próximo Sprint para hacerlo más agradable y productivo. A diferencia de la Sprint Review, en la que se analizaba el "qué" se estaba construyendo, en la retrospectiva se hacía foco en el "cómo" se está construyendo. Esta reunión podría comenzarse haciendo que cada persona respondiera las siguientes 2 preguntas, mientras el ScrumMaster tomaba nota: ¿Qué fue bien durante el Sprint que acaba de finalizar? ¿Qué puede mejorarse en el siguiente Sprint? Reuniones Externas: Reuniones de Avance: Los días lunes que caían a mediados de cada sprint (cada 2 semanas) se hacían reuniones de avance con el cliente para discutir acerca de la evolución, prioridades sobre funcionalidades, y demás cuestiones relativas al proyecto en cuestión. Los resultados de estas reuniones de avance eran registrados en el documento creado para tal fin (Informe de Avance). Sprint Planning Meeting: Durante esta reunión el Product Owner describía los aspectos de más alta prioridad para el equipo. El equipo debía realizar todas las preguntas necesarias para poder determinar, luego de la reunión, qué tareas serían movidas desde el Product Backlog al Sprint Backlog. Después de la reunión de planificación del sprint, el equipo se reunía por separado para discutir lo que escucharon y decidir cuánto se puede realizar durante el sprint que comenzaba. Sprint Review: Al final de cada sprint se realizaba una reunión de revisión. Durante esta reunión, el equipo muostraba lo que logró realizar durante el sprint. Normalmente, esta toma la forma de una demostración de las nuevas características. Durante esta revisión del sprint se evaluaba el proyecto contra el objetivo determinado para el sprint durante la reunión de planificación. Lo ideal era que el equipo haya completado cada product backlog item puesto en el sprint backlog. Durante el transcurso de cada sprint, si el equipo o el cliente tenían dudas, las mismas eran resueltas por email.

Artefactos Product Backlog Committed Backlog Sprint Backlog Estimated work remaining Impediment Backlog Sprint Burn Down Chart Product Burn Down Chart

Cómo lo llevamos adelante Para llevar a cabo el proyecto, adaptamos la metodología a nuestra disponibilidad. Los artefactos fueron complementados para cumplir con los requerimientos de la materia. Por la diferencia de seniority con la tecnología que decidimos utilizar, la cantidad de documentación que debíamos mantener, y el tiempo disponible; decidimos dividirnos en dos sub-equipos. Uno de desarrollo y otro de administración del proceso y documentación.

Estimación Story points Hours Para las User Stories Para los Sprint Backlog Items A la hora de realizar estimaciones, hicimos las mismas bottom-up al 50% con PERT. Op+4Me+Pe 6 Donde cada sub-team estimaba sus tareas.

Herramientas TargetProcess SVN Ant Junit Eclipse WinCHM User Stories Test Cases Bugs Tasks, Times, Efforts Indicadores y control de avance SVN Ant Junit Eclipse WinCHM Google Docs & Spreadsheets Para cada herramienta, comentar: ¿Qué es?, características principales (haciendo foco en las utilizadas). Cómo la utilizamos. Pros/contras. Licencia (si corresponde).

Trazabilidad SVN TargetProcess Al hacer commit, se enumeran las User Stories/Bugs a las que corresponden los cambios realizados. TargetProcess En la herramienta, cada user story (requerimiento) es un ítem del backlog, que tiene asociado tareas (tomadas por miembros del equipo y con sus respectivos casos de prueba) para lograr la trazabilidad. El siguiente mapa muestra cómo se logra la trazabilidad en el proyecto: Feature Release Iteration User Story Test Cases Test Plans Test Runs Tasks Times Bugs

Pruebas Unitarias Funcionales Automatizadas Utilizando Junit Manuales Gestionadas con TargetProcess Ejecutadas periódicamente

Documentación Plan de Proyecto Plan de Riesgos Minutas de Reunión User Stories User Acceptance Tests Configuración y versionado Plan de Comunicación Interno Sprint Retrospective Plan de Comunicación Externo Informe de Avance Sprint Planning Meeting Sprint Review Plan de proyecto: Contenía toda la información sobre el proyecto, especificando cómo se realizaría cada tarea y la ubicación de cada artefacto/herramienta a utilizar. De esta forma se permitió a cada miembro del equipo tener a su alcance toda la información necesaria. Plan de Riesgos: En este artefacto se describieron los posibles riesgos de recursos, técnicos, o del negocio implicados en el proyecto, y se formulaba un plan para abordarlos, con medidas de mitigación y correctivas para afrontar cada uno de ellos. El plan era actualizado periódicamente. Se apuntaba a revisar y mantener la lista de riesgos al menos a principio de cada sprint y a mediados del mismo. El responsable de la administración de riesgos era Sebastián. Para administrarlos se utilizó una Lista de Riesgos. En la misma se asignó a cada riesgo identificado un Id, un título, una probabilidad de ocurrencia, un impacto, la exposición que existía dados estos dos últimos valores, y una descripción. Adicionalmente se escribió un plan de contingencia para los riesgos cuya exposición alcanzaba el 75%, y un plan de mitigación para los que poseían exposición que llegaba al 50%. Minutas de reunión: Se redactaban luego de cada reunión (ya sea formal o informal). Describían participantes, fecha y hora, acuerdos, compromisos - próximos pasos, y una agenda de lo realizado durante la reunión. Las User Stories se mantuvieron simples. Estaban compuestas por un nombre y una descripción, que definía “cómo quiero que un <rol> realice <requerimiento> para que <valor de negocio>”. Luego, las User Acceptance Tests permitían definir y acordar con el cliente cómo se realizaría la funcionalidad asociada a cada User Story. Plan de Comunicación Interno: Sprint Retrospective: Se trata de una reunión en la que el equipo analizaba la conclusión del Sprint que acababa de finalizar, y determinaba lo que podría cambiarse en el próximo Sprint para hacerlo más agradable y productivo. A diferencia de la Sprint Review, en la que se analizaba el "qué" se estaba construyendo, en la retrospectiva se hacía foco en el "cómo" se está construyendo. Esta reunión podría comenzarse haciendo que cada persona respondiera las siguientes 2 preguntas, mientras el ScrumMaster tomaba nota: ¿Qué fue bien durante el Sprint que acaba de finalizar? ¿Qué puede mejorarse en el siguiente Sprint? Plan de Comunicación Externo: Informe de Avance: Los días lunes que caían a mediados de cada sprint (cada 2 semanas) se hacían reuniones de avance con el cliente para discutir acerca de la evolución, prioridades sobre funcionalidades, y demás cuestiones relativas al proyecto en cuestión. Los resultados de estas reuniones de avance eran registrados en este documento, creado para tal fin. Sprint Planning Meeting: Durante esta reunión el Product Owner describía los aspectos de más alta prioridad para el equipo. El equipo debía realizar todas las preguntas necesarias para poder determinar, luego de la reunión, qué tareas serían movidas desde el Product Backlog al Sprint Backlog. Después de la reunión de planificación del sprint, el equipo se reunía por separado para discutir lo que escucharon y decidir cuánto se puede realizar durante el sprint que comenzaba. Sprint Review: Al final de cada sprint se realizaba una reunión de revisión. Durante esta reunión, el equipo muostraba lo que logró realizar durante el sprint. Normalmente, esta toma la forma de una demostración de las nuevas características. Durante esta revisión del sprint se evaluaba el proyecto contra el objetivo determinado para el sprint durante la reunión de planificación. Lo ideal era que el equipo haya completado cada product backlog item puesto en el sprint backlog.

Entregables Binarios del sistema “TCAdmin” Manual de usuario Manual de despliegue Sistema de administración de casos de prueba TCAdmin Manual de despliegue del sistema: documento conteniendo guía de instalación, requerimientos de hardware, requerimientos de software y acceso al sistema. Manual de usuario: explicación del modo de uso de cada funcionalidad del sistema y una lista de preguntas frecuentes (FAQs).

Nuestra experiencia con Scrum Herramienta de control: Target Process 2 Pantalla principal de Target Process 2 Defectos en la herramienta detectados y comunicados

Nuestra experiencia con Scrum Burndown chart

Nuestra experiencia con Scrum Dinámica de los bugs

Ventajas del uso de Scrum Cliente altamente comprometido. La documentación propuesta por la metodología es mínima  Foco en el producto. Pocos roles necesarios  Adecuado para equipo reducido en integrantes. Entregas parciales y flexibilidad del cliente al priorizar funcionalidad permitieron ajustarse a la disponibilidad de los recursos.

Desventajas del uso de Scrum La documentación requerida por la cátedra era mayor a la que Scrum especifica. Esto llevó a la necesidad de definir cómo encararíamos cada artefacto adicional y las herramientas para gestionarlos. El equipo de trabajo no se encontraba físicamente junto, lo cual dificultaba la transmisión de información y el trabajo en forma integrada. El product owner era un miembro más del equipo de desarrollo, generando conflictos de intereses inevitables. Esto se consideró entre los riesgos. Sin embargo, el mismo se veía reducido por la elevada experiencia del cliente (Carolina) que no necesitaba a su “abogado” y sabía lo que quería.

Lecciones aprendidas Resulta imprescindible que toda la información esté disponible para todos los miembros en todo momento. Además, deben estar correctamente definidos los canales de comunicación tanto internos como externos para que la información llegue a quien lo necesita: Chats, mails Documentos online Herramienta de gestión del proyecto Tuvimos una experiencia de uso del proceso de desarrollo “Scrum” como metodología de trabajo aplicada a un proyecto real. No se debe confiar en que existirá una conexión a Internet durante las reuniones  Llevar copias de los docs offline  Google docs es incómodo y destruye los documentos al exportarlos  SVN. Aprender una tecnología nueva o desconocida puede llevar más tiempo del que uno estima. Al principio las estimaciones fueron poco precisas y se llegaba muy justo con los tiempos. Luego fuimos mejorando en base a experiencias anteriores. Las reuniones de varias horas durante el fin de semana fueron muy beneficiosas para el equipo, debido a las escasas y cortas reuniones semanales posibles. El product burn down chart no fue significativo debido a la forma en que se distribuyó el trabajo en el tiempo. Deberíamos haber modificado las métricas para que sean más representativas de la realidad.

Problemas encontrados Síndrome del estudiante: La dedicación era mucho mayor cerca del final del Sprint. Subestimación: Las estimaciones pobres causaban trabajo no planificado, especialmente ante tecnologías desconocidas y/o bibliotecas de funciones a utilizar.

Consultas Muchas gracias por su atención