A G I L E
Agenda
1. Agile vs Waterfall
2. Introduccion a Scrum 3. Ceremonias en Scrum 4. Roles en Scrum
5. 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 Usuario
Una 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 Backlog
El 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 Backlog
El 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 serie
de construcciones (USs), para poder hacer de esta isla un lugar habitable para el cliente.
Se dispondrán de 3 iteraciones (sprints) para terminar el proyecto de construcción
de lo que el cliente desea.
Existen 28 USs de las cuales el equipo seleccionará las que crea más prioritarias y puedan completar en el transcurso de 3 iteraciones.
Organización del proyecto
Cada 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
Backlog
Puerto Granja
Puente Barco
Transporte terrestre Cancha de tenis
Helipuerto Cancha de futbol
Mansión Laguna artificial
Barracas Purificadora de agua
Aeropuerto Submarino
Pileta Helicóptero
Faro Avión
Torre de control Hotel Casino Resort
Observatorio Bar en la playa
Refineria Teatro
Casa de huéspedes
Casa de aguas termales
Central 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]
