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

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

2. TCAdmin® 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.

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

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

5. Reuniones • Reuniones Internas • Sprint Retrospective • Daily Meeting • Reuniones Externas • Reuniones de Avance • Sprint Planning Meeting • Sprint Review • Consultas / Acuerdos • Via mail

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

7. 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.

8. 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.

9. Herramientas • TargetProcess • User Stories • Test Cases • Bugs • Tasks, Times, Efforts • Indicadores y control de avance • SVN • Ant • Junit • Eclipse • WinCHM • Google Docs & Spreadsheets

10. 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

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

12. 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

13. Entregables • Binarios del sistema “TCAdmin” • Manual de usuario • Manual de despliegue

14. Herramienta de control: Target Process 2 Pantalla principal de Target Process 2 Nuestra experiencia con Scrum Defectos en la herramientadetectados y comunicados

15. Burndown chart Nuestra experiencia con Scrum

16. Dinámica de los bugs Nuestra experiencia con Scrum

17. 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.

18. 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.

19. 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.

20. 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.

21. Consultas Muchas gracias por su atención