Metodologías Ágiles - Scrum Julian Caruso Andrea Gauna Emilio Watemberg

Gestión Clásica de proyectos La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles. Criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado. Asume que el proyecto se desarrolla en un entorno estable y predecible. El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos. Divide el desarrollo en fases a las que considera “ciclo de vida”, con una secuencia de tipo: concepto, requisitos, diseño, planificación, desarrollo , cierre. División del trabajo en equipos de especialistas.

Manifiesto Ágil Aunque hay valor en los elementos en la derecha, valoramos más los elementos en la izquierda.

Objetivos de la gestión Ágil 1. Valor Innovación Flexibilidad 2. Reducción del tiempo de salida al mercado Solapamiento de las fases de desarrollo. Entrega temprana de las primeras partes del producto, que corresponden con las de mayor urgencia para el cliente. 3. Agilidad Capacidad para producir partes completas del producto en periodos breves de tiempo 4. Flexibilidad Capacidad para adaptar la forma y el curso del desarrollo a las características del proyecto, y a la evolución de los requisitos. 5. Resultados confiables La gestión ágil no tiene un carácter predictivo o de anticipación. No conoce de antemano el detalle del producto que va a desarrollar, y por eso su objetivo no es fiabilidad en el cumplimiento de los planes, sino en el valor del resultado.

Gestión Clásica vs. Ágil

Metodologías Ágiles ADT - Agile Database Techniques AM - Agile Modeling ASD - Adaptive Software Development AUP - Agile Unified Process Crystal FDD - Feature Driven Development DSDM - Dynamic Systems Development Method Lean Software Development Scrum TDD - Test-Driven Design XBreed XP - Extreme Programming Scrum

Donde Usar Scrum Proyecto complejo Proyecto simple Scrum

Scrum Scrum, basado en la teoría de control empírico de procesos, emplea un acercamiento iterativo e incremental para optimizar la predictibilidad y el control de riesgos. El control de procesos empírico se basa en 3 pilares: Transparencia Asegura que todos los aspectos que afectan los resultados de un proceso deben ser visibles a todos los involucrados. Inspección Los diferentes aspectos del proceso deben ser inspeccionados frecuentemente de manera de poder detectar variaciones inaceptables. Adaptación Si el inspector determina que alguno de los aspectos analizados esta fuera de los limites aceptables, y esto resultara en un producto inaceptable, debe ajustar el proceso o el material siendo procesado. Este ajuste debe ser realizado rápidamente para evitar que aumente la desviación. Scrum provee 3 puntos de inspección y adaptación clave durante las iteraciones (Sprint). El scrum diario, planeación de Sprint y retrospectiva del sprint.

El flujo

Componentes de Scrum El Equipo Reuniones Artefactos Reglas Roles

Roles Los equipos se componen de 3 roles principales El ScrumMaster (SM) Responsable de que el proceso sea comprendido y ejecutado correctamente El Dueño del Producto (PO - Product Owner) Responsable de maximizar el valor del trabajo realizado por el equipo. El Equipo Realizan el trabajo. El equipo consiste en desarrolladores con todas las habilidades necesarias para convertir los requerimientos del PO en un producto entregable para el final de la Sprint.

Roles – Scrum Master Facilitador y líder del equipo Remueve impedimentos del equipo Promueve valores, principios y prácticas scrum Solo uno por equipo Trabaja junto con el equipo Responsable del producto El SM puede ser un miembro del equipo de desarrollo, aunque no se recomienda por los requerimientos full-time de ambos roles. El SM NUNCA debería ser el PO.

Roles – Product Owner Representante del cliente y stakeholders (involucrados o interesados) Tiene autoridad para cambiar y/o definir el producto Acepta o rechaza el resultado del sprint Solo uno por equipo Trabaja junto con el equipo Propietario de la lista de requerimientos Prioriza los requerimientos Responsable de la rentabilidad del producto El PO puede ser un miembro del equipo de desarrollo, aunque esto no se recomienda ya que esta responsabilidad adicional reduciría su capacidad de trabajar con los stakeholders. El PO NUNCA debería ser el SM.

Roles – Equipo de desarrollo Pocos integrantes (7 +/- 2) Multifuncional e interdisciplinario Roles difusos Trabajan a tiempo completo en un sprint Auto-organizado y auto-disciplinado Definen y estiman tareas de cada requerimiento Propietario de la lista de tareas Comprometido y descentralizado

Componentes de Scrum Roles Time-Boxes Artefactos Reglas Reuniones

Reuniones – Sprint Planning Lista de requerimientos priorizados El equipo determina los requerimientos del sprint El equipo define y estima las tareas de cada requerimiento Primera actividad de un sprint La duración depende de la duración del sprint (máx 8 hs) Se genera el sprint backlog y el objetivo del sprint

Reuniones – Sprint Review Duración máx: 2 a 4 hs Demo del producto Finalidad: presentar al product owner las nuevas funcionalidades Participan todos: Scrum master, Product owner y Equipo Las funcionalidades no implementadas no se presentan Se genera feedback del producto

Reuniones – Sprint Retrospective Reflexión sobre sprint se responde a: ¿Qué fue lo bueno y malo del sprint? ¿ Qué cosas se pueden mejorar? Siempre al finalizar el sprint Participan todos: Scrum master, Product Owner y Team Se genera feedback Duración máxima: 1 hora

Reuniones – Daily Scrum Meeting Duración: 15 minutos Scrum master es el responsable Scrum master y equipo Tres preguntas: ¿Qué hice desde la última reunión diaria? ¿ Qué voy a hacer hasta la próxima reunión? ¿ Qué dificultades tengo para realizar mi labor? No se resuelven problemas, solo se identifican Misma hora y lugar (recomendado) Primera actividad del día (recomendado)

Componentes de Scrum Roles Reuniones Artefactos Reglas Artefactos

Artefactos – Elementos básicos Una lista con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. Esta lista se llama "Product Backlog". No hace falta que esta lista contenga todas las funcionalidades inicialmente. De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama "Sprint Backlog". Estas tareas serán realizadas en el siguiente mes. La “Burn Down Chat” es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Artefactos - Backlogs Product Backlog Sprint Backlog Es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su valor para el negocio (business value). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. El Product Owner es responsable de mantener este documento(contenido, disponibilidad, priorización). Nunca esta completo, evoluciona junto con el producto y su ambiente. Las tareas con prioridad mas alta contienen mas información, este nivel de detalle disminuye a medida que descendemos por el informe. Sprint Backlog Es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Se desarrolla principalmente en la Sprint Planning. Aunque se puede modificar durante el Sprint(período de la iteración). Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. A medida que se trabaja en una tarea, el tiempo estimado para finalizarla se actualiza. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. El Sprint Backlog debe ser un radiador de información, altamente visible y actualizado , de ser posible, en tiempo real.

Artefactos – Burn-Down Charts Product Burn Down Registra la suma de trabajo restante en el Product Backlog. La unidad de medición puede ser cualquiera que haya sido acordada por el equipo. En caso de que se requiera agregar o quitar trabajo al Backlog durante el desarrollo se puede mover el piso del gráfico para mantener la referencia. Estos cambios deben ser religiosamente documentados. La tendencia puede ser irregular durante las primeras iteraciones. Esta irregularidad disminuye si los miembros del equipo han trabajado juntos antes, conocen el producto ,dominio y la tecnología a utilizar en el mismo.

Artefactos – Burn-Down Charts (2) Sprint Backlog Burndown Es un grafico del trabajo restante a lo largo del tiempo restante del Sprint. Se crea sumando cada día el trabajo restante de todos los ítems del Sprint Backlog. No se considera el trabajo invertido en una tarea. El trabajo restante y las fechas son las únicas variables de interés. Siempre que sea posible el grafico debe estar a la vista del equipo.

Componentes de Scrum Roles Reuniones Artefactos Reglas Reglas

Reglas Una vez que se pasan las tareas más prioritarias del "Product Backlog" al "Sprint Backlog", estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas. Al final del mes, este periodo se le llama "Sprint", se tiene que tener un ejecutable con las funcionalidades del "Sprint Backlog". Es importante acordar y mantener un criterio de completo a lo largo del desarrollo. Este criterio denominado “Done”, es a lo que el equipo se compromete cuando decide hacer una tarea. Análisis/ Diseño Refractoring Programación I18N Documentación Testing funcional (Unit , UAT , Regresión) Testing no funcional (Performance, Estabilidad , seguridad , integración )

Resumen Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint.

Referencias Scrum Alliance Agile Alliance http://www.scrumalliance.org/ Agile Alliance http://www.agilealliance.org/ Comunidad Latinoamericana de metodologías Ágiles http://www.agiles.org/ Recursos http://www.agile-software-development.com http://www.scrumalliance.org/resources/598 http://jeffsutherland.com/scrum/