Curso gratuito de Agile y scrum

Formación IT
Agile y Scrum
2019 por Rafael Hernampérez

Indice
• Introducción a la agilidad
• Proyectos ágiles
• Agilidad Vs Waterfall
• SCRUM
• Introducción
• Roles
• Artefactos
• Actividades
• Otras metodologías ágiles
• La agilidad y el mundo real
• Contenido adicional

Introducción a la agilidad
STP (Sistema de Producción de Toyota)
• Creado entre 1946 y 1975 por Toyota
• Diseñado originalmente para la manufacturación de coches, pero ha sido
extendido a otros ámbitos
• El STP está basado en la filosofía Kaizen
• Creado a partir de los principios del Jidoka y del Just-in-Time
• El objetivo es reducir los inventarios y defectos en las plantas de Toyota y
de sus proveedores
• Énfasis en la mejora continua y el compromiso del empleado
• El STP sentó las bases del Lean
• El Toyotismo, tras la crisis del petróleo en 1973, reemplazó el Fordismo
como sistema de producción en cadena

Kaizen trabaja con la idea de que toda persona y sus ideas son un activo para la empresa. En crear un
entorno en el que se fomente el respeto mutuo y la comunicación abierta.
Las mejoras sólo se pueden propiciar cuando la gente está dispuesta a expresar sugerencias
¿Qué es Kaizen?

Principios del Kaizen
• La mejora continua involucra a todos
• La culpa no tiene cabida en el Kaizen
• Se basa en hacer pequeños cambios de forma constante
• Trae consigo resultados concretos, tanto cualitativos como cuantitativos,
en un lapso relativamente corto y a un bajo costo, apoyado en la sinergia
que genera el trabajo en equipo.
• Elementos clave:
• Trabajo en equipo
• Compromiso a todos los niveles
• Comunicación y participación vertical y horizontal
• Identificación y eliminación de desperdicios
• Mejora continua de los procesos

Anécdotas
Curiosamente, Lean y JIT no fueron popularizados por
los japoneses, si no por los estadounidenses.
Concretamente, fue el MIT en 1990, a través de un
best-seller llamado “La máquina que cambió el
mundo”.
El libro “Microsoft Secrets” ya hablaba de cómo el
gigante de Redmond ya utilizaba técnicas lean y el
uso de JIT en el control de calidad y la reducción de
burocracia.

Proyectos ágiles
Naturaleza de las ingenierías
• Funcionalidades muy limitadas
• Diseño fijo
• Materia prima estable y estándar
en el tiempo
• Tiempo de vida útil muy longevo
• Gestión de proyectos Waterfall
• Funcionalidades poco limitadas
• Diseño voluble
• Materia prima cambiante en el
tiempo
• Tiempo de vida útil muy corto
• Gestión de proyectos Agile
Ingeniería de Caminos Ingeniería del Software

Proyectos ágiles
Manifiesto ágil
http://agilemanifesto.org
1) Individuos e interacciones
2) Producto en funcionamiento
3) Colaboración con el cliente
4) Respuesta al cambio
1) Procesos y herramientas
2) Documentación
3) Negociación de contratos
4) Cumplir la planificación

Proyectos ágiles
Principios del manifiesto
1. Nuestra principal prioridad es satisfacer al cliente a través de la
entrega temprana y continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en períodos de un
par de semanas hasta un par de meses, con preferencia en los
períodos breves.
4. Las personas del negocio y los desarrolladores deben trabajar juntos
de forma cotidiana a través del proyecto

Proyectos ágiles
5. Construcción de proyectos en torno a individuos motivados, dándoles
la oportunidad y el respaldo que necesitan y procurándoles confianza
para que realicen la tarea.
6. La forma más eficiente y efectiva de comunicar información de ida y
vuelta dentro de un equipo de desarrollo es mediante la conversación
cara a cara.
7. El software que funciona es la principal medida del progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los
patrocinadores, desarrolladores y usuarios deben mantener un ritmo
constante de forma indefinida.

Proyectos ágiles
9. La atención continua a la excelencia técnica y al buen diseño
enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que no
se hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos
que se auto-organizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser
más efectivo y ajusta su conducta en consecuencia.

Proyectos ágiles
Puntos fuertes
Time to market
Despliegues pequeños e incrementales
Adopción de usuario
Genera feedback continuo
Minimiza los desperdicios
Gestión de expectativas
Establece expectativas claras
Calidad de producto
Mejora la calidad del producto
Experiencia de usuario
Aporta visibilidad
Flexibilidad ante el cambio
Ante el cambio se adapta
rápidamente y lo adopta

Proyectos ágiles
El paraguas Agile

Agile Vs Waterfall
El triángulo de la gestión de proyectos
Agile Waterfall

Agile Vs Waterfall
Ciclo de vida

Agile Vs Waterfall
Evolución del producto
AgileWaterfall

Agile Vs Waterfall
Equipos de trabajo
Agile Waterfall

Agile Vs Waterfall
Métricas a lo largo del tiempo

Agile Vs Waterfall
Riesgos del proyecto
Agile Waterfall

SCRUM - Introducción
¿De dónde proviene SCRUM?
Scrum es una formación en la que ambos equipos luchan por obtener el balón
Si algún integrante del equipo cede, el Scrum se derrumba
Coordinación
Confianza /
apoyo
Sincronización
Mismo objetivo

Ciclo de vida

Componentes

SCRUM - Roles
Product Owner
✓ Define las funcionalidades o
características en el Product Backlog
✓ Da prioridad a las características de
acuerdo a su valor para el negocio
✓ Ajusta las características y prioridades
en cada iteración según lo necesario
✓ Decide las fechas de release y el
contenido
✓ Es responsable del beneficio del
producto (ROI)
✓ Acepta o rechaza los trabajos “DONE”

SCRUM - Roles
Actividades del Product Owner

SCRUM - Roles
Scrum Master
✓ Refuerza los valores, principios y
prácticas de SCRUM
✓ Elimina los impedimentos (Facilitador)
✓ Asegura la funcionalidad y
productividad del equipo
✓ Promueve la colaboración y
comunicación entre los miembros del
equipo
✓ Protege a los equipos de interferencias
externas
✓ Contribuye de forma activa al éxito
como miembro del equipo SCRUM

SCRUM - Roles
Actividades del Scrum Master

SCRUM - Roles
Equipo
✓ Compuesto por 7 ± 2 miembros
✓ Dedicado
✓ Enfocado en el objetivo
✓ Multifuncional
✓ Auto-organizado
✓ Altamente colaborativo
✓ Transparencia
✓ Estima los items del Backlog
✓ Se compromente con el Sprint
Backlog
✓ Monitoriza su progreso

SCRUM - Artefactos
Artefactos
Product Backlog Lista priorizada de todo el trabajo del proyecto, la cual se
reprioriza al comienzo de cada sprint
Sprint Backlog Lista de historias priorizadas y estimadas del Product
Backlog y tareas que el equipo se ha comprometido a
entregar en el próximo Sprint
Sprint Goal Descripción en una frase, escrita de forma colaborativa por el
equipo, que explica el objetivo a conseguir por el equipo
durante el Sprint
Sprint Iteración de trabajo durante el cual se ha implementado un
incremento de funcionalidad en el producto
Velocity Cantidad de puntos de historias de usuario que el equipo
puede entregar en un Sprint
Burn Down Chart Gráfico que muestra el progreso durante y al final del Sprint

SCRUM - Artefactos
Product Backlog
“Lista priorizada del trabajo deseado en el proyecto, el cual se reprioriza al
comienzo de cada Sprint”

SCRUM - Artefactos
Historias de usuario
✓ Cuentan una historia
✓ Describen una funcionalidad a alto nivel
✓ Se escriben en lenguaje de negocio, no en
terminología técnica
✓ Describen el nivel más simple de
funcionalidad
✓ Describen el “qué”, no el “cómo”
✓ Se escriben conjuntamente por IT y negocio
✓ Son suficientemente concisas para ser
entregadas en un Sprint
✓ Representan una pequeña parte de una
funcionalidad del usuario final
✓ Incluyen el Criterio de Aceptación
HISTORIA DE USUARIO
Realizar pedido de venta
Como vendedor
Quiero registrar los
productos y cantidades que
me solicita un cliente
Para crear un pedido de venta
(Yo,) como <rol>
Quiero <objetivo/acción>
Para (así) <razón/beneficio>
“Requerimientos desde el punto de vista
de las necesidades del usuario”
Como un <rol>
Necesito <funcionalidad>
Con la finalidad de <razón/resultado>

SCRUM - Artefactos
Criterios de aceptación
✓ Incluyen todos los test funcionales
necesarios para la Historia de Usuario
✓ Tienen suficiente detalle para escribir los
scripts de test
✓ Se presentan para todas las Historias de
Usuario y sirven como complemento a los
requerimientos
✓ Incluyen los criterios funcionales y no
funcionales
✓ Se escriben en lenguaje de negocio para
que los contactos de negocio puedan
confirmar
Dado (que) <condiciones>
Cuando <una acción es realizada>
Entonces <éste será el resultado>

SCRUM - Artefactos
Árbol de requisitos

SCRUM - Artefactos
Criterio de “DONE” (HECHO)
Código completado El código para la historia de usuario se ha completado, probado
unitariamente y desplegado para las pruebas funcionales
Pruebas completadas Las pruebas funcionales para las historias de usuario se han realizado
y no se han detectado defectos críticos o de alto impacto
Aprobado por el Product
Owner
La funcionalidad demostrada durante la Demo del Sprint cumple con
los riterios de aceptación y está firmada por el Product Owner
✓ Lo que se ha producido tiene la suficiente calidad y cumple con los requisitos del cliente
✓ Un sprint está acotado en el tiempo y está hecho al final del slot previsto para el mismo. Un
Sprint no debería extenderse, ya que el progreso es medido por la cantidad de historias de
usuario hechas al final del Sprint. Las historias no hechas al final del Sprint serán abordadas
durante el siguiente Sprint.
¿Cuándo se considera “DONE” en una historia de usuario?

SCRUM - Artefactos
Burndown Chart
✓ Es un gráfico que muestra la velocidad a la que el equipo está produciendo a través de
las historias de usuarios
✓ Representa el esfuerzo total en relación a la cantidad de trabajo entregado en cada
iteración
✓ Puede representar el esfuerzo por proyecto (varios sprints) o por un sprint en particular

SCRUM - Actividades
Actividades

SCRUM - Actividades
Daily (Daily Stand Up ó Daily Scrum Meeting)
“El valor está en completar historias”
✓ En el mismo lugar
✓ Al mismo tiempo
✓ Cada día
✓ Duración máxima de 15 minutos
✓ Se invita a todo el mundo
✓ Solamente el Equipo, el Scrum Master
✓ y el Product Owner pueden hablar
✓ NO SE RESUELVEN PROBLEMAS.
✓ Se identifican para otra sesión de
trabajo
Reglas
✓ ¿Qué logramos ayer?
✓ ¿Qué vamos a hacer hoy?
✓ ¿Qué nos impide avanzar?
Las 3 preguntas clave

SCRUM - Actividades
Sprint Review
✓ Demo de historias completadas
✓ Se realiza al final del Sprint
✓ Se muestra el producto funcionando, no Powerpoints
✓ Tiempo limitado a no más de 90 minutos por semana de Sprint
✓ Se recogen ideas y feedbacks
✓ Se evalúa el progreso del objetivo
✓ Asistentes: los stakeholders, los interesados, el Equipo, El Scrum Master y el Product Owner, que es
quien presenta el resultado
Reglas

SCRUM - Actividades
Sprint Review
“Vamos a demostrar el progreso logrado en el Sprint”
✓ El Scrum Master presenta el Sprint Goal
✓ El Scrum Master revisa el número de
historias de usuario que se han
completado y las que no
Introducción Sprint
✓ El Equipo muestra el resultado para
cada historia
✓ El Product Owner da feedback a las
historias mostradas
✓ El Product Owner acepta las historias
de usuario como “DONE” o las rechaza
como incompletas
✓ El Product Owner prioriza las historias
de usuario rechazadas en el Product
Backlog
Demo Sprint

SCRUM - Actividades
Retrospectiva
¿Cómo podemos mejorar nuestra forma de trabajar?
No se trata de criticar lo que está mal: se trata de hacer propuestas para mejorar

SCRUM - Actividades
Retrospectiva
“Sin actuaciones, la retro no tiene sentido”
✓ Se revisa la Retrospectiva anterior
✓ Se realiza al final de cada Sprint
✓ Se discuten las formas de adaptarse y
mejorar como equipo
✓ Duración entre 30 y 60 minutos
✓ Se identifican 2 a 3 áreas de enfoque
✓ Se asignan responsables
✓ Se proponen actuaciones
✓ Asistentes: el Equipo, el Scrum Master y
el Product Owner
Reglas
✓ ¿Qué fue bien en el último Sprint?
✓ ¿Qué podría haber ido mejor en el
Sprint?
✓ ¿Qué podemos hacer para
mejorar el próximo Sprint?
Las 3 preguntas clave

SCRUM - Actividades
Técnicas para la retrospectiva

SCRUM - Actividades
Sprint Planning
✓ En el mismo lugar
✓ Al mismo tiempo
✓ De tiempo limitado (máx. 4 horas)
✓ Asistentes: el Equipo, el Product Owner y el
Scrum Master, que es el que dirige la reunión
Reglas
✓ Revisión del Product Backlog
✓ Priorización del Product Backlog
✓ Revisión del Sprint anterior
✓ Construcción del Sprint Backlog para el
siguiente Sprint
Tareas

SCRUM - Actividades
Sprint Planning
“A partir de la prioridad del Product Backlog estimaremos el coste de cada historia de usuario y
planificaremos el sprint acorde a la capacidad del equipo en el sprint”
✓ El Product Owner propone dos historias
de usuario del Product Backlog
✓ El Equipo estima cada historia que
creen que pueden ejecutar en el
próximo Sprint
✓ El Equipo crea la priorización para el
Sprint Backlog y el timeline para realizar
las historias
Priorización del Sprint
✓ El Equipo se compromete a hacer las
historias de usuario en el sprint y crea el
Sprint Backlog
✓ El Equipo refina las historias y las
secciona en post-its
✓ El Equipo define en una frase el Sprint
Goal y se aprueba por todos los
miembros
✓ El Equipo coloca los post-its en la
columna “TO DO” del Kanban
Sprint Planning

SCRUM - Actividades
Estimación del Sprint Planning

SCRUM - Actividades
Estimación de las Historias de Usuario
✓ La unidad para medir el esfuerzo de una
tarea es el punto de historia
✓ Es preferible el punto de historia a la
estimación clásica por tiempos
✓ El equipo define qué representa un punto
de historia, basado en su experiencia, en la
dificultad, en el volumen, etc.
✓ Ejemplos de punto de historia: pantallas de
login, frutas (por tamaño), fragmentos de
tiempo (ej. 4 horas), etc...
Puntos de Historia
✓ El equipo evalúa la estimación de una tarea
tomando como medida los puntos de
historia. Normalmente se usan cartas
Fibonacci
✓ Si la tirada es muy similar, se escoge la
puntuación promedio
✓ Si hay mucha diferencia entre la carta más
alta y la más baja, los miembros de estas
cartas deben argumentar su estimación
✓ Se repite el proceso hasta obtener un
consenso
Estimación

SCRUM - Actividades
Velocidad
✓ La velocidad se calcula promediando el número puntos de historias completadas en sprints
anteriores
✓ Es un valor que convierte en tiempo los puntos de historia, basados en un esfuerzo relativo
✓ Sirve de guía para determinar la capacidad máxima a realizar en cada Sprint y así estimar y priorizar
las tareas
✓ Sirve para estimar orientativamente la fecha de finalización del proyecto
Velocidad

SCRUM - Actividades
Agenda del Sprint

Otras metodologías ágiles
XP (eXtreme Programming)
• Niveles extremos de productividad
• Actividades: Codificación, Testing (TDD), Escucha y Diseño
• Valores: comunicación, simplicidad, feedback, respeto y valor
• Managers, clientes y desarrolladores son socios de mismo nivel en un equipo colaborativo
• Planning game: reunión en cada iteración (una semana), cuyo proceso es:
• Release planning: Determinar los requisitos incluidos y que deben ser liberados
• Iteration planning: Planifica las actividades y tareas de los desarrolladores
• Algunas características clave:
• Desarrollo iterativo e incremental: llevar a cabo pequeñas mejoras, unas tras otras
• Pruebas unitarias continuas: Frecuentemente repetidas y automatizadas
• Programación en pareja: Dos personas en un mismo puesto. Revisión constante del código y de las
pruebas unitarias
• Frecuente integración entre el equipo y el cliente/usuario: Trabajo conjunto
• Corrección de todos los errores antes de añadir una nueva funcionalidad
• Refactorización del código: Reescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento

TDD (Test Driven Development)
• Proceso Agile de desarrollo de software basado en pruebas
• Los requisitos se convierten en casos de pruebas muy específicos, por lo que el software es mejorado para superar únicamente los
nuevos tests
• Ciclo de TDD:
• Añadir una prueba: cada nueva característica comienza por escribir una prueba. Escribir una prueba define una funcionalidad o
mejora, acompañada de una historia de usuario o de un caso de uso
• Ejecutar todas las pruebas y ver si la nueva prueba falla: valida que que la nueva prueba es una característica no existente y
que es necesario desarrollarla
• Escribir el código: desarrollo del código para superar la prueba
• Ejecutar las pruebas: el nuevo código se ajusta al resultado de la prueba
• Refactorizar el código: limpieza y optimización del código tras sucesivas versiones
• Repetir: El ciclo se repite con cada nueva prueba

Lean Software Development
• Fue concebido en 2003 a través de un libro
• No es una metodología. Es una síntesis de
principios y una filosofía para construir
software
• Fue inspirado por el STP de Toyota
Principios del Lean Software Development
• Optimizar el todo
• Eliminar desperdicios
• Calidad en la construcción
• Aprender constantemente
• Entregar rápido
• Involucrar a todo el mundo
• Seguir mejorando

La agilidad y el mundo real
El mundo real
• Las ideas y la filosofía de Scrum son aceptados, pero no se implementan al 100%
• Negocio suele asumir el rol de Product Owner y ésto genera problemas:
• Gobierno, control y jerarquía organizacional
• Visión Waterfall: tiempo y coste fijos, pero no el alcance
• Falta de implicación e interés con el equipo
• Cambios de alcance y prioridades durante el sprint
• Toma de decisiones técnicas
• Los miembros de un equipo trabajan en más de un proyecto. Esto limita el tiempo de su colaboración en los
problemas del proyecto. Las ideas y la info se diluyen.
• No todo se hace en el sprint, debido a las limitaciones y procesos. Lo más común es el testing y la documentación.
Se pierde el feedback y se resuelve tarde.
• Waterfall genera inercia:
• Planificaciones, presupuestos y requisitos Vs Sprints e historias de usuario
• Dependencias con otros equipos estancos y especializados (arquitectura, diseño…)
• Creación de documentación para mitigar riesgos
• Desarrollo no está involucrado en el proceso de los requerimientos
• Las releases son muy poco frecuentes, debido a costes, tiempos y riesgos
• Los grupos de operaciones y releases son cuellos de botella
• Operaciones y desarrollo son grupos distintos y especializados
• A Negocio no le gusta los cambios y las releases

Factores de fracaso

Pros y Contras de SCRUM

Viabilidad de proyectos con SCRUM

WATER-SCRUM-FALL

¿Por qué Water-Scrum-Fall?
• Lo más habitual son implementaciones híbridas Waterfall y Scrum
• Water define el trabajo por adelantado. Los riesgos son:
• Muchos requerimientos tempranos son muchos requerimientos erróneos
• Los usuarios no siempre comunican bien lo que quieren o necesitan
• El desarrollo se enfoca menos en el valor para el cliente y más en cumplir su contrato
• El desarrollo es menos cross-functional. Análisis, Desarrollo y QA debe trabajar junto
• Los equipos usan Scrum para desarrollar software en Medio Del Proceso
• Deben construir un equipo cross-functional: analista, desarrollador y tester
• Deben incluir el testing durante el sprint: feedback y resolución rápidos = - coste
• Deben involucrar a Negocio durante toda la construcción
• Deben aceptar que el cambio puede ocurrir
• Fall significa establecer puertas para limitar la frecuencia de releases de software:
• Traer a operaciones y a desarrollo a un marco común de trabajo
• Identificar y eliminar cuellos de botella en las releases: cross-functional
• Agregar a los sprints más actividades de releases: testing en preproducción, migración de datos,
testing de seguridad y rendimiento
• Construir objetivos compartidos liderados por negocio

Contenido adicional
Herramientas
https://kanbanize.comhttps://trello.com
http://sprintometer.com
https://www.icescrum.com
https://www.atlassian.com/software/jira https://www.visualstudio.com/es/tfs/

Contenido adicional
Enlaces y libros
• Agile en castellano: http://agile-spain.org
• Manifiesto ágil: http://agilemanifesto.org/iso/es/manifesto.html
• SCRUM Official Site: https://www.scrum.org
• SCRUM Alliance: https://www.scrumalliance.org
• KANBAN (Wikipedia): https://es.wikipedia.org/wiki/Kanban
• XP: http://www.extremeprogramming.org
• XP practices: http://ootips.org/xp.html
• TDD (Wikipedia): https://en.wikipedia.org/wiki/Test-driven_development
• Intro to TDD: http://www.agiledata.org/essays/tdd.html
• Lean Soft. Dev. (Wikipedia): https://es.wikipedia.org/wiki/Lean_software_development
• Water-Scrum-Fall: http://www.slideshare.net/harsoft/water-scrumfall-isrealityofagileformost
• Explicando Scrum a mi abuela: http://geeks.ms/jorge/2007/05/09/explicando-scrum-a-mi-abuela/
• Blog de Jerónimo Palacios: https://jeronimopalacios.com
• Blog de Javier Garzas: http://www.javiergarzas.com
LIBROS
• Scrum desde las trincheras
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
• Kanban y Scrum
http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf
• Flexibilidad con Scrum (Juan Palacio)
http://www.scrummanager.net/files/flexibilidad_con_scrum.pdf
• Gestión de Proyectos Scrum Manager (Juan Palacio)

Formación IT
MUCHAS GRACIAS
2019 por Rafael Hernampérez

Curso gratuito de Agile y scrum

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Curso gratuito de Agile y scrum

Similar a Curso gratuito de Agile y scrum (20)

Último

Último (19)

Curso gratuito de Agile y scrum