Temario

Capítulo 1: Introducción al desarrollo ágil de Software

• ¿Qué es agilidad?
• ¿Por qué cambiar a marcos de trabajo ágiles?
• Metodologías Ágiles
• Desarrollo incremental e iterativo
• Primeros Pasos
• Cultura Ágil
• Manifiesto Ágil: valores y principios

Capítulo 2: SCRUM
• ¿Qué es Scrum?
• Pilares y Valores de Scrum
• Artefactos Scrum
• Roles
• Ciclo Scrum
• Scrum Escalado

Capítulo 3
• Diferencia entre gestión tradicional y ágil
• Planeación ágil
• Historias de usuario
• Mapa de historia de usuario
• División de historias de usuario
 ¿Qué es agilidad?
Agile es un “mindset”, es un camino de continua exploración, adaptación, aprendizaje y
mejora, que a partir del desarrollo iterativo e incremental busca entregar productos de mayor
valor, basado en la colaboración, la confianza y la motivación de las personas involucradas
¿Qué es agilidad?
¿Qué es agilidad?
 ¿Por qué cambiar a marcos de trabajo ágiles?
Seguir un plan: proyectos tradicionales
Retraso
Requerimiento Análisis Diseño Construcción Pruebas Producción

Control de cambio
Requerimiento Análisis Diseño Construcción Pruebas

vs
La respuesta al cambio
 ¿Por qué cambiar a marcos de trabajo ágiles?

1. Integración
2. Alcance
3. Tiempo
4. Costo
5. Calidad
Funcionalidad
6. Recursos Humanos
7. Comunicación
8. Riesgos
9. Adquisiciones
Valor de negocio
10. Interesados
¿Por qué cambiar a marcos de trabajo ágiles?
 ¿Por qué cambiar a marcos de trabajo ágiles?

• 20-50% de incremento en
la productividad
• + del 50% de incremento
en la calidad
• 30-75% más rapidez en
lanzar productos al
mercado
 ¿Por qué cambiar a metodologías ágiles?
Tamaño del
Proyecto Método Exitoso Con Riesgo Fallido

Ágil 39% 52% 9%

Todos
Cascada 11% 60% 29%

Ágil 18% 59% 23%

Grande
Cascada 3% 55% 42%
Ágil 27% 62% 11%
Medio
Cascada 7% 68% 25%
Ágil 58% 38% 4%
Pequeño
Cascada 44% 45% 11%
 Metodologías Ágiles

Visión sistemática,
principios y técnicas de
análisis para minimizar el Método de gestión de
tiempo de entrega proyectos

XP
Desarrollo

Técnica de visualización de
peticiones a ser resueltas Metodologías y prácticas
en el mínimo tiempo de desarrollo de software
posible

Continuos delivery
Kaizen
 Metodologías Ágiles
Hacerlo Ágil

•Scrum:  Desarrollo de proyectos ágiles, 

aplicando «buenas prácticas» para
estimular el trabajo en equipo y poniendo
foco en el valor que requiere el cliente.

•Kanban:  Gestión eficiente y ágil de

flujos de trabajo que máxime la
productividad. Reducir trabajo en
Progreso (WIP-Work in Progress)
Desarrollo Iterativo e Incremental
Incremental Evolutivo
Metodologías Ágiles
Primeros Pasos

Code Build Integrate Test Release Deploy Operate

Desarrollo ágil

Integración continua
Entrega continua
Despliegue continua

DevOps
Agile Devops
 Cultura Ágil

Tablero
Comportamientos y artefactos Kanban
Prácticas
Es lo que vemos Burndown Char

Reuniones de Pie

Satisfacer al cliente Simplicidad

Modelos mentales Entregar software funcional frecuentemente
Principios
¿Cómo racionalizamos? Los Requisitos pueden cambiar
Estructuras cognitivas Comunicación cara a cara Diseño Evolutivo

Valores y Creencias Individuos e interacciones Retroalimentación

En lo que creemos
Educación
Compromiso Coraje Respuesta ante el cambio Valores
Lo que es correcto Respeto Foco Apertura
 ¿Valores del Manifiesto Ágil?
EL manifesto Ágil surge
el 17 de febrero del
2001 y se creo Agile
Alliance, organización
para promover el
desarrollo ágil de
software
12 Principios del Manifiesto Ágil
12 Principios del Manifiesto Ágil
Capítulo 2: SCRUM

¿Qué es Scrum?

Valores y Pilares de Scrum

Eventos Scrum

Artefactos Scrum

Roles

Ciclo Scrum

Scrum Escalado
 ¿Qué es Scrum?

Es un marco de trabajo en el que se

busca solventar necesidades en
entornos complejos con altos niveles
de incertidumbre, a la vez de entregar
productos con el máximo valor en
intervalos cortos de tiempo
5 Valores de Scrum
3 Pilares de Scrum
 Eventos y Artefactos
15 min x día

Autoorganizados y Multifuncionales
Máximo 10% de la duración del Sprint
Se añade detalle, estimación y orden
a los elementos de la Lista de Productos
Identificar Riesgos El equipo de desarrollo es el responsable de la Estimación

Inspección, Adaptación y
Proyección del Sprint Backlog
Supervisión + Aprendizaje 3
1h x semana - 4h/mes
Feedback al Incremento del Producto
Criterios de Aceptación - Deuda Técnica

2
1

Incremento
Qué? Establecer Sprint Goal y seleccionar elementos de Lista de Productos para el Sprint del Producto 3
Cómo? trabajar para lograr el incremento del producto
Estimar Esfuerzo puntos de usuario, descomposición en tareas (estimar tiempo) Feedback al Equípo – Mejora Continúa
2h x semana - 8h/mes Inspeccionar personas, procesos y herramientas
Los Eventos aplican los pilres de Transparaencia, Inspección y Adaptación
Los Eventos son bloques de tiempo (Time boxes) con duración fija 45 min x semana - 3 h / mes
Artefactos de Scrum

Product Backlog Sprint Backlog Incremento

Requerimiento Requerimiento Requerimiento

Requerimiento Requerimiento Requerimiento
Requerimiento
Requerimiento
Requerimiento
Requerimiento

Requerimiento

Requerimiento
Artefactos de Scrum
1 Product Backlog: Que se tiene que hacer en el producto
• Lista Organizada de funcionalidades, defectos y capacitación que
se requiere para el producto (lo que lleve a un incremento)
• El P.B. es dinámico (respuesta al cambio) y evoluciona
• El P.B. Generalmente se escribe en forma de Historias de Usuario
• Los elementos del P.B. debe ser detallados, claros, estimados y
priorizados (refinamiento)
• Definir el estado terminado
• Incluye las deudas Técnicas de los Sprint
2 Sprint Backlog: Que se tiene que hacer en el sprint actual
• Conjunto de elementos seleccionados del P.B. para el Sprint, en
forma de tareas para el incremento del producto
• Toda nueva actividad que atente con el Sprint Backlog, debe ser
revisada con el product owner
• Fuente para generación de reportes de avance
3 Incremento del Producto:
• Elementos finalizados del P.B. en el Sprint + los incrementos anteriores Refinamiento Tasking
• Debe ser funcional y la decisión de liberar Release es del Product Owner
• Es revisado en el Sprint Review, debe cumplir con la defInición de Terminado
Product Backlog - Historias de Usuario
Características: modelo INVEST.
● Independencia.
● Negociables.
● Valiosa.
● Estimable.
● Pequeña.
Riesgo Alto Medio Bajo
● Verificable.

Cómo está conformada una Task? Modelo SMART:

S: Specific (Especifico).
M: Measurable (Medible en horas)
A: Achievable (Alcanzable máx 8 horas)
R: Relevant (Relevante minimo 2 horas)
T: Time-boxed (Bloque de tiempo). Si tengo una
tarea de 22 horas la divide en 8h para obtener un
total de 3 tareas
División de historias de usuario, producto mínimo viable
Sprint Backlog
Portafolio del Backlog
Estados en los Flujos de Scrum
Eventos

1 2 3 4
Eventos - Sprint Planning
Eventos – Daily Meeting >> Seg. Ejecución Sprint
Eventos – Sprint Review
Eventos – Sprint Retrospective
Eventos – Sprint Retrospective
Refinamiento
Dar claridad a las características de la lista de productos,
criterios de aceptación o concepto de terminado y se da
en cualquier momento por ejemplo en la construcción
del software
Ciclo Scrum

Días / Horas 8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00 4:00 5:00
Lunes
Martes
Miércoles
Jueves
Viernes

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
 Roles Scrum
• Maximizar el Valor del producto
• Responsable del Product Backlog (PB)
• Define claramente y Prioriza el PB
• Analizar requisitos, Aprobar y Explicar las
Historias de Usuario
• Definir los criterios de aceptación
• Generación de ROI
• Asegurar los recursos Financieros
• Aprueba los Release (lanzamientos)
• Conocimiento del negocio y Visión del
proyecto, empoderado y perceptivo
• Habilidad de Negociación y comunicación
• Evangeliza, Lidera y Guía la adopción de Scrum
• Facilitar técnicas de gestión
• Verifica que realicen los eventos dentro del time boxe
• Supervisa avance del equipo (Burdown Chart)
• Motiva cambios que optimicen los procesos,
incrementen la productividad y el Valor del producto
• Verificar si tienen los recursos (RH, conocimiento del
negocio, los objetivos) y las Herramientas.
• Interfaz entre los jefes y el Development Team
• Elimina impedimentos.
• Guía al equipo a ser autoorganizados y multifuncional
• Conformado de 3 a 9 personas
• Multidisciplinarios, profesionales
expertos técnicos en diferentes áreas,
(arquitectos, calidad, desarrollo de
software, base de datos)
• Autogestionados, autoorganizados y
autónomos
• Son transparentes y con Sinergia
• Administración, Compromiso y
enfoque en el Sprint Planning
• El Development Team estima el
esfuerzo en el Spint Backlog
• Desarrolla el Sprint Burdown Chart
 Roles Scrum

Consiste en los profesionales que desempeñan el trabajo de entregar un incremento de

producto “Terminado” que potencialmente se pueda poner en producción al final de cada
iteración
• Es auto organizado y multifuncional
• No existen títulos en scrum para los miembros del equipo.
• La responsabilidad del cumplimiento recae sobre todo el equipo.
• Crea entregables de alta calidad
• Estima las User Stories aprobadas por el PO
• Desarrolla la lista de tareas basados en las User Stories
• Calcula el esfuerzo de las tereas identificadas
• Desarrolla el Sprint Backlog y el Sprint Burdown Chart
 Ejercicio Práctico de Agilidad

Fábrica de aviones
El avión tiene que volar mas de 5 metros
El avión tiene que tener el número de serie en las alas
El avión tiene que tener el nombre del equipo en ambos lados
El avión tiene que tener 3 ventanas en cada lado
El avión tiene que tener 2 puertas en cada lado
 Ejercicio Práctico de Agilidad

Juguemos con Lego

Conozcan las piezas que se les entregaron

Haga un pato con solo 6 de las 10 piezas
Usen su imaginación y todos deben participar
Caso de Éxito IT Synergy
Ciclo Scrum
Ciclo Scrum

Contiene un listado de ítems o características del

producto a construir.
El dueño del producto es el responsable del listado de
características del producto, incluyendo disponibilidad y
orientación
Ciclo Scrum

Contiene el conjunto de características que debe cumplir un Product

Backlog Item para que el equipo de desarrollo pueda comprometerse
en su entrega, es decir, incluirla en el Sprint Backlog.

SI NO ESTA LISTA, NO SE INCLUYE!!!!

• Cuenta con el diseño de pantallas aceptados.

• Están los servicios de integración disponibles en el ambiente de
desarrollo.
• Se cuenta con los datos de prueba
• Se cuenta con la especificación técnica de los servicios.
• Las historias de usuarios cuentan con los criterios de aceptación.
• Están identificados las dependencias de las historias, los
servicios y pantallas.
Ciclo Scrum

Sprint
Corresponde al
bloque de tiempo
durante el cual se
construye un
incremento de
producto utilizable y
potencialmente
desplegable.
Cada Sprint empieza
inmediatamente
después de la
finalización del
Sprint previo.
Entre 1 a 4 semanas
Ciclo Scrum

Sprint
Corresponde al
bloque de tiempo
durante el cual se
construye un
incremento de
producto utilizable y
potencialmente
desplegable.
Cada Sprint empieza
inmediatamente
después de la
finalización del
Sprint previo.
Entre 1 a 4 semanas
Ciclo Scrum

Sprint Planning
El objetivo del Sprint Planning es identificar Qué es lo que el
equipo de desarrollo va a realizar durante el Sprint, y Cómo, es
decir, todos aquellos Product Backlog Items que el equipo se
comprometerá a transformar en un incremento funcional
potencialmente desplegable.

Participantes: Product Owner, Scrum Master, Development Team

Time box: 2 horas por semana de Sprint
 Ejercicio Práctico de Agilidad

Cuidado de animales del Zoológico

Cada participante debe mencionar el animal que eligió

Los participantes deben definir estimar la complejidad de bañar a
cada uno de los animales
Deben establecer el tiempo de duración del sprint
Deben realizar el sprint planning
Ciclo Scrum

Sprint
Ciclo Scrum

Sprint Backlog
Es el conjunto de elementos del Product Backlog seleccionados
para el Sprint. Es una predicción hecha por el Development
Team acerca de que funcionalidad formará parte del próximo
Incremento
Ciclo Scrum

Sprint Backlog
Ciclo Scrum

Sprint
Ciclo Scrum

Daily Scrum

El objetivo del Daily Scrum es incrementar la comunicación

dentro del equipo, explicar los compromisos asumidos a los
miembros del equipo y dar visibilidad de los impedimentos que
surjan del trabajo que está siendo realizado y que pueden
impedir lograr los objetivos.
Participantes: Scrum Master, Development Team, Product Owner (Opcional)
Time box: 15 minutos máximo
Ciclo Scrum

Sprint
Ciclo Scrum

Definition of Done

Cuando un Product Backlog Item o un incremento se describe

como terminado, todo el mundo debe entender lo que significa
terminado. Esto varía significativamente para cada equipo
Scrum, es importante que los miembros del equipo tengan el
entendimiento compartido de lo que significa que el trabajo
está completado para asegurar la transparencia.

Ejemplo:
• El desarrollo está 100% completado
• La funcionalidad fue probada por el desarrollador
• Se hizo el code review por otros programadores.
• Cumple con los criterios de aceptación establecidos en la historia de usuario
• El Product Owner revisó los desarrollos.
• No existen incidencias bloqueantes.
Ciclo Scrum

Sprint Review
Ciclo Scrum

Sprint Review

En la Sprint Review se revisa el resultado del Sprint. Cuando se

dice resultado nos referimos del producto utilizable y
potencialmente entregable. Los interesados utilizan y evalúan
durante la reunión estas funcionalidades y deciden si las
aceptan o rechazan.
Participantes: Scrum Master, Development Team, Product Owner y
StackeHolders
Time box: 1 hora por semana del Sprint
Ciclo Scrum

Sprint Retrospective
Ciclo Scrum

Sprint Retrospective

La Sprint Retrospective es el corazón de la mejora continua y las

prácticas emergentes. Mediante el mecanismo de introspección,
el equipo reflexiona sobre la forma en la que se realizó el trabajo
y los acontecimientos que sucedieron en el Sprint que acaba de
concluir para mejorar sus prácticas.
Participantes: Scrum Master, Development Team, Product Owner (Opcional)
Time box: 1 hora por semana del Sprint
Ciclo Scrum

Refinamiento

Refinamiento
Ciclo Scrum

Refinamiento

El Refinamiento no corresponde a un evento Scrum, pero si se

reconoce como una buena práctica. Esta reunión (no oficial) de
Scrum tiene como objetivo, presentar los próximos Product
Backlog Items que tienen la una alta probabilidad de formar
parte de los próximos Sprint y discutir aspectos sobre ellos.
Participantes: Scrum Master, Development Team, Product Owner
Time box: 5-10% de la duración del Sprint
 Ejercicio Práctico de Agilidad

Portal del Zoológico

Los participantes deben definir las historias épicas

Los participantes deben definir las historias de usuario
Los participantes deben definir el plan de liberación de producto
Deben realizar el sprint planning
 Ciclo Scrum

Ciclo de Vida Scrum

Scrum Proyect Time Line

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint
Planning Review & Planning Review & Planning Review & Planning Review & Planning Review &
Retro Retro Retro Retro Retro
Ciclo Scrum

Tableros Scrum

Task Board Burndown Chart

Ciclo Scrum

Tableros Scrum

Niko-Niko Satisfacción del Cliente

Scrum Escalado

Scrum Master

Product Owner
Scrum Team
Sprint
Backlog Scrum Master

Scrum Team
Product Backlog Sprint
Backlog

Scrum Master
Un producto Owner y un Product
Backlog para 2 o 5 equipos
Scrum Team
Sprint
Backlog
 Scrum Escalado
Scrum Master

Scrum Team
Product Product Sprint
Chief Product Owner Owner Backlog Backlog
Scrum Master

Scrum Team
Product Product Sprint
Product Backlog Owner Backlog Backlog

Scrum Master

Scrum Team
Product Product Sprint
Owner Backlog Backlog
Scrum Escalado

Modelos Agiles Escalados

SaFe DAD

Less Huge Nexus

Scrum Escalado
SaFe
Scrum Escalado
DAD
Scrum Escalado
LeSS Huge
Scrum Escalado
NEXUS
 Ejercicio Práctico de Agilidad

Retrospectiva del Portal del Zoológico

Los participantes deben elegir una actividad para hacer la retrospectiva

Pueden utilizar la pagina web www.funretrospectives.com
Todos deben participar en la planeación
Todos deben emitir su opinión
Capítulo 3: Requisitos Ágiles

Diferencia entre gestión tradicional y ágil

Planeación Ágil

Historias de usuario

Mapa de historia de usuario

División de historias de ssuario

Diferencia entre gestión tradicional y ágil

Planteamiento Análisis Diseño Programación Pruebas

Puesta en
Sprint Sprint producción
5 1

Requerimiento
Planteamiento
Priorizados Sprint Sprint
4 2
Sprint
3
Planeación ágil

Estrategia
Portafolio
Producto
Liberación
Iteración
Día
 Planeación ágil

Product Backlog

Epica Epica Epica

Característica Característica Característica Característica Característica Característica Característica Característica Característica

Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de

Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario
Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de
Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario

Historias de Historias de Historias de Historias de

Usuario Usuario Usuario Usuario
 Planeación ágil

Product Backlog

Proyecto Epica Epica Epica

Versión Característica Característica Característica Característica Característica Característica Característica Característica Característica

Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de

Sprint Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario

Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de Historias de

Sprint Backlog Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario Usuario
Planeación ágil

Valor de Negocio

Historias de Usuario DEEP

días
d
ida

• Detallado apropiadamente
r
Prio

Características • Estimado
semanas • Emergente
• Priorizado

meses
Épicas
Historias de Usuario

Una historia de usuario describe

Como la funcionalidad que será
rio]
[rol del usua valiosa para un usuario escrita
Quiero
[objetivo] en lenguaje comprensible para
Para poder todos, ayudando a facilitar la
[beneficio] administración de las
necesidades del negocio.
 Historias de Usuario

Como
rio]
[rol del usua
Quiero
[objetivo]
Para poder
[beneficio]

Historia de Usuario Criterios de aceptación

El criterio de aceptación es un checklist que define la aceptación del testing para una historia en particular.
 Historias de Usuario

ANVERSO REVERSO
5 Préstamo de Libro

Como bibliotecario quiero que los estudiantes
puedan pedir prestado un libro, indicando el número
de su carnet y la referencia del libro, siempre y
cuando no tengan ya tres libros en préstamo en ese
momento
Estimación: 4
Prioridad: 100 Dependiente de: 1,2
• Introducir un número de carnet incorrecto y probar si
indica error.
• Introducir un estudiante que ya tiene 3 libros en
préstamo y probar si indica error.
• Introducir los datos correctos y comprobar que el
número de ejemplares disponibles.
 Ejercicio Práctico de Agilidad

Creando un Product Backlog

Crear el formato de un Product Backlog (2 minutos)

Identificar los diferentes grupos de usuarios que pueden usar el portal (3 minutos)
Identificar la mayor cantidad de necesidades que tenga cada rol (10 minutos)

Tomar las necesidad mas importante y escribir la historia de usuario (3 minutos)

Identificar la prioridad para cada tarea historia de usuario (7 minutos)

Mapa de historias de Usuario

Es una técnica
descrita por vez por
Jeff Patton y consiste
en representar el
producto backlog en
dos dimensiones
 Planeación ágil

Menos opcional
Prioridad

Mas opcional
 Ejercicio Práctico de Agilidad

Creando un Product Backlog

Categoriza las necesidades (5 minutos)

Prioriza las necesidades (3 minutos)

Define el plan de entregas (3 minutos)

Ordena las historias de usuario según el plan de entregas (7 minutos)

 División de historias de usuario

SPIDR

Spikes Rules
Son pequeñas implementaciones prototípicas Las reglas de negocio o las normas
de una funcionalidad que se utiliza tecnológicas
típicamente para la evaluación y viabilidad de
nuevas tecnologías

Interfaces Data
Pueden ser por ejemplo, dispositivos o Se puede utilizar cuando las historias iniciales
sistemas operativos se refieren a una subconjunto de los datos
Paths pertinentes, por ejemplo bases de datos
Si hay varios caminos alternativos posibles en
un historia de usuario, una opción es crear
historias de usuario separadas de algunas de
estas rutas
http://www.agilisters.org/2019/04/enterprise-business-agility-
journey.html

https://www.youtube.com/watch?v=5adKRGdeU0c
https://www.youtube.com/watch?v=qRx8BkjY8lY&list=PLY8Zm0pEAjHnV-vZ46l17RB1NF7-GvRWx&index=12
powershell