42
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
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
[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]
