A G I L E

Agenda

1. Agile vs Waterfall2. Introduccion a Scrum3. Ceremonias en Scrum4. Roles en Scrum5. Actividad práctica

Agile vs Waterfall

#RutaDelSoftware

Waterfall - Cascada• Adaptado desde la industria de la

construcción

• Primer enfoque metodológico formal en la industria del software

• Secuencial

• Estructurado

• No adaptativo

• No iterativo

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Agile software development

• Iterativo e incremental

• Adaptativo

• Entregas contínuas

• Se incluye al cliente en el proceso de desarrollo

• Individuos motivados, no presionados

• Equipos auto-gestionados

Desarrollo ágil de software

Algunas metodologías ágiles

Lean Software Development

Introducción a Scrum

Scrum

Scrum es una forma ágil de administrar un proyecto, usualmente de desarrollo de software.

El desarrollo ágil con Scrum es usualmente percibido como una metodología, pero seria mejor verlo como un Framework para manejar un proceso.

Conceptos Básicos de Scrum

#RutaDelSoftware

Historia de UsuarioUna Historia de Usuario es una descripción de una funcionalidad que debe incorporar un sistema, y cuya implementación aporta valor al cliente.

Scrum - Product BacklogEl product Backlog es el corazón de Scrum. Es donde empieza todo. Es, básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente.

Scrum - Sprint

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones desde 2 semanas hasta un mes).

Scrum - Sprint BacklogEl Sprint backlog es un segmento del Product Backlog.

Representa las historias a las que el equipo se compromete durante este Sprint.

El equipo decide cuántas historias incluirá en el Sprint, no el Dueño de Producto ni nadie más.

Scrum - Release

Las releases son entregas definidas por el Product Owner, que contienen un cierto número de user stories. Una release tiene un momento de inicio y un momento de fin, y se usa para organizar el esfuerzo del equipo. Normalmente, el Product Owner selecciona las stories a incluir, y decide cuando la release está lo suficientemente completa como para ser entregada.

Roles

#RutaDelSoftware

• Representante de las personas interesadas en los resultados del proyecto.

• Define los objetivos del producto.• Brinda la información necesaria al equipo.• Negocia con el equipo y con stakeholders las prioridades y fechas.• Valida el producto entregado.• Define el MVP (producto mínimo viable).

Product Owner

• Facilita las Daily Meetings, Retrospectivas, Demos, y demas ceremonias.

• Hace lo posible para remover los bloqueantes que pueda tener el equipo.

• Punto de contacto con el Product Owner.

Scrum Master

• Trabajan juntos para entregar los incrementos que fueron solicitados y comprometidos, en forma auto organizada y empoderada.

• Siguen un objetivo común, se adhieran a las mismas reglas y tienen respeto a todos los miembros del equipo.

• Grupos pequeños, entre 4 y 9 participantes.

Team

Team

• Compromiso

• Coraje

• Foco

• Apertura

• Respeto

Stakeholders

Managers

Otros Roles

Ceremonias

#RutaDelSoftware

Daily Standup Meeting

Sprint Review (Demo)

Sprint Retrospective

Resumen

#RutaDelSoftware

#RutaDelSoftware

www.kahoo.it code:

Break!!

Taller

Taller!Un millonario compró una isla,la cual está completamente inhabitable.

El equipo deberá edificar una seriede construcciones (USs), para poder hacerde esta isla un lugar habitable para el cliente.

Se dispondrán de 3 iteraciones (sprints) paraterminar el proyecto de construcciónde lo que el cliente desea.

Existen 28 USs de las cuales el equiposeleccionará las que crea más prioritariasy puedan completar en el transcurso de3 iteraciones.

Organización del proyectoCada Sprint se desarrollara de la siguiente forma:

Sprint Planning 2 minutos

Desarrollo 5 minutos

Daily meeting 1 minuto

Desarrollo 5 minutos

Sprint Review 2 minutos

BacklogPuerto GranjaPuente Barco

Transporte terrestre Cancha de tenis

Helipuerto Cancha de futbolMansión Laguna artificialBarracas Purificadora de aguaAeropuerto SubmarinoPileta HelicópteroFaro AviónTorre de control Hotel Casino ResortObservatorio Bar en la playaRefineria Teatro

Casa de huéspedes Casa de aguas termalesCentral eléctrica Mirador

Daily Standup Meeting• Cada día durante un Sprint, el equipo tiene un Daily Scrum Meeting (o stand-up)

con pautas específicas:• Comienza precisamente a tiempo incluso si faltan algunos miembros del Equipo de

Desarrollo• Debe ocurrir al mismo tiempo y lugar todos los días• Es limitada (timeboxed) a quince minutos• Cualquier persona es bienvenida• Cada miembro del equipo responde a tres preguntas:

– ¿Qué hice ayer que ayudó al equipo de desarrollo a cumplir la meta de Sprint?– ¿Qué haré hoy para ayudar al equipo de desarrollo a cumplir con la meta de

Sprint?– ¿Veo algún impedimento que impida que yo o el Equipo de Desarrollo

alcancemos el objetivo de Sprint?• Cualquier impedimento (por ejemplo, escollo, riesgo, emisión, dependencia tardía,

suposición demostrada sin fundamento) identificado en el Scrum diario debe ser capturado por el Scrum Master y exhibido en la junta Scrum del equipo o en una solución compartida resuelta, ROAM), con una persona acordada designada para trabajar hacia una resolución (fuera del Daily Scrum).

• No debe haber discusiones detalladas durante el Daily Scrum.

Participan todos los miembros del equipo.

Se realiza al principio de cada sprint, con el objetivo de:

• Definir el alcance del trabajo a realizar durante el sprint• Confeccionar el Sprint Backlog con el subconjunto de ítems del Product

Backlog que se completaran en el sprint

Se divide el tiempo en dos partes:

• En la primer mitad se seleccionan los ítems del backlog que se completaran en el sprint

• En la segunda mitad el equipo descompone las historias en subtareas.

Algunos ítems pueden ser divididos si se determina que no pueden resolverse en un solo sprint. Otros pueden quitarse del sprint backlog si se determina que no podrá cumplirse con todo lo definido en la primer mitad de la ceremonia

Una vez definido el sprint backlog, el equipo se compromete a completarlo durante la duracion del sprint

Sprint Planning

Al final de un Sprint, el equipo lleva a cabo dos eventos: el Sprint Review y el Sprint Retrospective.

En la Sprint Review, el equipo:

• Revisa el trabajo que se completó y el trabajo planeado que no se completó• Presenta el trabajo completado a las partes interesadas (es decir, “la demo”)

• Directrices para las revisiones de Sprint:– No se puede demostrar el trabajo incompleto– La duración recomendada es de dos horas para Sprint de dos semanas (pro-rata

para otras duraciones de Sprint)

Sprint Review

En la Retrospectiva Sprint, el equipo:

• Reflexiona sobre el pasado Sprint• Identifica y acuerda acciones continuas de mejora de procesos

Directrices para las retrospectivas de Sprint:

• Dos preguntas principales se hacen en la Retrospectiva Sprint: ¿Qué fue bien durante el Sprint? ¿Qué se podría mejorar en el próximo Sprint?

• La duración recomendada es de una hora y media para un Sprint de dos semanas (pro-rata para otras duraciones de Sprint)

Este evento es facilitado por el Scrum Master

Sprint Retrospective

GlobalLogicLatinoamerica

GlobalLogic_LA

GlobalLogic Latinoamerica

GlobalLogicLatam

GlobalLogicArgentina

¡GRACIAS!#RutaDelSoftware

alberto.fierro@globallogic.comeliana.rubolino@globallogic.comfacundo.savio@globallogic.comfederico.biondi@globallogic.comhelena.brites@globallogic.comjonathan.ortiz@globallogic.comjonathan.rodriguez@globallogic.comjuan.berdugo@globallogic.comjulian.arocena@globallogic.comnicolas.sigal@globallogic.comsantiago.herrera@globallogic.com