Aplicación de la metodología ágil Aplicación de la metodología ágil ““Scrum”Scrum”Proyecto: Proyecto: TCAdminTCAdmin

BOERR, Federico – BOERR, Federico – 80.98280.982GASTAUD, Hernán – GASTAUD, Hernán – 82.53982.539

UEHARA. Adrián – UEHARA. Adrián – 82.72682.726VENDITTI, Sebastián – VENDITTI, Sebastián – 84.61484.614

Alumnos:Alumnos:

75.47 – Taller de Desarrollo de Proyectos II75.47 – Taller de Desarrollo de Proyectos II

Proyecto “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

AdriánFedericoHernánSebastián

Carolina

Federico

Hernán

Carolina

Reuniones

• Reuniones Internas– Sprint Retrospective– Daily Meeting

• Reuniones Externas– Reuniones de Avance– Sprint Planning Meeting– Sprint Review

• Consultas / Acuerdos– Via mail

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 – Para las User Stories

• Hours – 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– User Stories– Test Cases– Bugs– Tasks, Times, Efforts– Indicadores y control de avance

• SVN• Ant• Junit• Eclipse• WinCHM• Google Docs & Spreadsheets

Trazabilidad• SVN

– 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–Times

Pruebas

• Unitarias– Automatizadas– Utilizando Junit

• Funcionales– 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

Entregables

• Binarios del sistema “TCAdmin”• Manual de usuario• Manual de despliegue

Nuestra experiencia con Scrum Herramienta de control: Target Process 2

Defectos en la herramienta detectados y comunicados

Pantalla principal de Target Process 2

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