Agile Manifesto

Escrito en 2001
Satisfacer al cliente
Mediante entrega temprana y continua de software con valor
Aceptamos los cambios
Entrega continua
De 2 semanas a 2 meses
Técnicos y negocio
Trabajan juntos!
Individuos motivados
La mejor comunicación es
cara a cara
Progreso = software
funcionando
Trabajo a ritmo sostenible
Por sobre

Traer trabajo o irse Agendar reunión con

feliz con la calidad fechas arbitrarias y
lograda no realistas

Entregar alcance de Entregar 100% de

calidad alcance

Tener una base Alcanzar el

rentable para todo el presupuesto para
proyecto construcción

Buscar como Quedarse en el día a

mejorar día
Excelencia técnica
Y buen diseño

La calidad no es negociable!

Alcance

CALIDAD

Coste Tiempo
Maximiza trabajo no
realizado

20%

80%

Ley de Pareto
Equipos auto-organizados
Tradicional Agil

Jefe

Facilitador
 Retrospectiva/Kaizen

• Que funcionó bien

• Que se puede mejorar

• Como se puede mejorar (acciones ejecutables!)

 Como aplicarlo?

• Cultura

• Buena fe (Bona Fide)

• Confianza

• Empatía
Time-boxing
Time-boxing
Tarea 1

Tarea 2

Marco de tiempo

Tarea 3

Tarea 4
Sprint
Protegido!
 Sprint
Tarea 1

Tarea 2 - Protegido!
- La calidad no puede disminuir
1-4 semanas - El alcance puede ser clarificado
Y renegociado entre el equipo y
Tarea 3 el dueño del producto

Tarea 4

Tarea 5

Tarea 6
Iterativo, incremental
Cascada

Habemus software!
Iterativo, incremental
Agil

Más software!

Software
Software
Software …
Software
Definición de listo
 Definición de listo

• No queda más por desarrollar en la tarea.

• Se escribieron tests unitarios.
• Se escribieron tests de integración.
• Se escribieron Pruebas de aceptación automáticas.
• El código fue revisado por otros desarrolladores (pull requests).
• Los tests pasan.
• El dueño del producto da el visto bueno.
• Se despliega a producción.
 Los roles
Como colaboran los integrantes
Equipos
Independientes
 Roles
Especialistas Generalistas

• Desarrollador front
• Desarrollador Back
• Fullstack Devops
• Tester o QA
• Diseñador
• Infraestructura
• Diseñador
 Roles
Equipos completos!

DevOps

Scrum Product
Master Owner
 Roles
Responsabilidades

• Conseguir documentación o recursos

que necesite el equipo.
• Protegerlos de problemas, interrupciones
u otras personas.
• Asegurarse de que el equipo mantenga
buenas relaciones tanto dentro como fuera.

Scrum
Beneficio esperado
Master
• Equipo auto-gestionado
 Roles
Responsabilidades

• Conversar con todos los stakeholders y entender

sus problemas o necesidades.
• Define la visión a seguir.
• Escribir y mantener el backlog.
• Priorizar el backlog y así el desarrollo.
• Revisar el producto y evaluar si se continua o
el equipo vuelve a la pizarra (con él incluido).
• Anticipar necesidades de los clientes.
Product
Owner Beneficio esperado

• Una visión clara del camino a seguir.

 Roles
Equipos completos!

DevOps Responsabilidades

• Crear y desplegar sistemas

• Modelar
• Programar
• Testear
• Desplegar
• Monitorear
• Enseñar

Beneficio esperado

• Un resultado tangible.
• Nivelación de desarrolladores menos
experimentados.
Los artefactos de
SCRUM
Herramientas en el día a día de SCRUM
Product Backlog/pila de
producto
Historia 1

Historia 2
Product Owner

Historia 3

Historia 4

Historia 5

Historia 6
 Sprint Backlog
Historia 1

Historia 2

1-4 Semanas

Historia 3

Historia 4

Historia 5

Historia 6
Incremento de producto

Historia 1

Historia 2

1-4 Semanas

Historia 3

Historia 4
Las ceremonias de
SCRUM
Los hitos recurrentes
 Hitos
Planificación de
Daily meeting
sprint

Revisión del
Laboratorio
sprint

Retrospectiva
 Planificación

2 horas 4 horas

2 Semanas 4 Semanas
 Que?
Historia 1

Historia 2

Historia 3

Historia 4

Historia 5

Historia 6
 Como?
Historia 1

Historia 2

2 Semanas

Historia 3

Historia 4

Historia 5

Historia 6
Daily Meeting
15 mins
Revisión/Demo

1.5 horas 3 horas

2 Semanas 4 Semanas
Revisión/Demo
Retrospectiva

2 horas - 4 horas
Laboratorio

4 horas - 8 horas
Kanban
Apoyo para sprints
 Kanban
Por hacer En progreso Listo

Historia 4 Historia 5
Historia 1

Historia 2

Historia 3
 Kanban
Sprint Backlog En progreso Esperando revisión A desplegar Listo

Historia 1 Historia 4 Historia 7 Historia 8 Historia 11

Historia 2 Historia 5 Historia 9 Historia 12

Historia 3 Historia 6 Historia 10 Historia 13

 Kanban
Sprint Backlog En progreso Esperando revisión Listo

Historia 1 Historia 4 Historia 7 Historia 8

Historia 2 Historia 5 Historia 9

Historia 3 Historia 6 Historia 10

 OKR
Objective key results
 Lineamiento/Autonomía
Tenemos problema x!
Construyan x! Resuélvanlo

Lineamiento

Autonomía
 OKR

• Es un sistema de objetivos utilizado por google y otros

• Es una herramienta simple para alinear a los equipos

• Es sencillo de medir

• Generalmente cambian cada 3 meses

 Como es un OKR?

• Voy a (objetivo) cuyo desempeño será medido por

(mediciones)

• El objetivo debe ser claro y cuantificable! Si no es

cuantificable no es un OKR

• Como regla general, las mediciones deben ser de 2 a 5

 Ejemplo de OKR

• Comunicar a nuestros clientes nuestros nuevos

productos.

• Enviar correo recurrente a usuarios de la base de datos

y tener una tasa de apertura de al menos 10%.

• Obtener datos de usuarios que compran físicamente y

cargarlos en la base de datos, al menos un 15% de las
compras registradas libres.
 Ejemplo de OKR

• Automatizar el proceso de solicitud de horas en el registro

civil y mejora

• Tener un sistema de toma de horas online para abril.

• Comenzar el redireccionamiento del tráfico a la

plataforma en mayo.

• Cerrar inscripciones manuales en Junio.

Empresas
Historias de usuario y
épicas
Como redactar los requerimientos
 Qué es una historia de
usuario?

• La representación de un requerimiento en una o dos

frases.

• Son una forma corta de redactar los requerimientos.

• Estás NUNCA deben ir solas, siempre deben ir

acompañadas de pruebas de aceptación y discusiones
con los stakeholders y/o Dueño de producto.
“Como (rol en la app), deseo (capacidad) de
manera que (valor).”

–Historia de usuario
 Ejemplos de historias
• Como administrador, necesito gestionar mi inventario
para poder pedir renovación de inventario cuando este
baje de un límite determinado.

• Como redactor, necesito comunicar a mi audiencia mis

pensamientos, de manera de poder generar audiencia y
poder monetizar.

• Como usuario, necesito configurar mis preferencias, para

poder dar un toque de personalidad
Ejemplos de historias, misma
capacidad, distinto valor

• Como administrador, necesito gestionar mi inventario, de

manera de identificar mejor la merma.

• Como administrador, necesito gestionar mi inventario, de

manera de poder organizar la distribución de este.

• Como administrador, necesito gestionar mi inventario, de

manera de poder pedir renovación de stock cuando sea
necesario.
 INVEST
• Independiente (Independent)

• Negociable (Negotiable)

• Valuable (Valuable)

• Estimable (Estimable)

• Pequeña (Small)

• Demostrable (Testable)
 Que es una épica?

• Una historia de usuario muy grande!, no cabe en un

sprint.

• Una agrupación de historias que están fuertemente

relacionadas.
 Como estimar
nuestras historias
Fibonacci, tallas de poleras
 Porque estimamos?

• Para entregar un pronóstico, no es un compromiso!

• Para que el equipo no sé sobre-comprometa.

• Para dividir a historias más pequeñas.

 Fibonacci

• 1, 2, 3, 5, 8, 13…

• Teoría de la información! A mayor tamaño, más difícil de

estimar.

• Se asigna una unidad mínima de tiempo.

 Tallas

• XS, S, M, L, XL, XXL

• Teoría de la información! A mayor tamaño, más difícil de

estimar.

• Se asigna una unidad mínima de tiempo.

• La siguiente talla duplica la anterior.

 Cómo?

• Todos al mismo tiempo!

• El más alto explica por qué.

• El más bajo explica por qué.

• Si no hay acuerdo, se asigna el intermedio.

 Extreme
programming
Programación extrema!
 Bases
Equipo completo

Propiedad colectiva Estándar de código

TDD

Tests Pair
Refactor Planificación
Aceptación Programming

Diseño
simple

Integración Continua Paso sustentable

Despliegue continuo (pequeños)

Equipo completo
Equipo completo
Equipo completo
Equipo completo
Tests de aceptación
Tests de aceptación
Planificación
Planificación: qué y cómo?
Historia 1

Historia 2

2 Semanas

Historia 3

Historia 4

Historia 5

Historia 6
Despliegue continuo
 Despliegue continuo
Historia 1

Historia 2

2 Semanas

Historia 3

Historia 4

Historia 5

Historia 6
 Despliegue continuo
Historia 1

Historia 2

2 Semanas

Historia 3

Historia 4
 Despliegue continuo

Historia 2

Historia 1
Historia 3

Historia 4
 Despliegue continuo

Historia 2
Historia 3

Historia 4
 Despliegue continuo

Historia 3

Historia 4
Despliegue continuo
TDD: Test driven
development
TDD o desarrollo guiado
por pruebas
Integración continua
 Integración continua

Historia 2

Historia 1
Historia 3

Historia 4
Integración y despliegue
continuo
Paso sostenible
Paso sostenible
Paso sostenible
Burnout
Paso sostenible
Estándar de código
Estándar de código
Estándar de código
Estándar de código

Solución Complejidad
Estándar de código

Pull Requests Editor config

Linters Patrones
Propiedad colectiva
Propiedad colectiva

Feature

Feature
Feature
Propiedad colectiva

Feature
Refactor o mejora de
arquitectura continua
 Refactor
Alcance

CALIDAD

Coste Tiempo
Diseño simple: KISS
Diseño complejo

El gran monolito!
Diseño simple
MS1

MS3

MS2

MS4
Pair programming
Pair programming

VS

Lobo solitario
Pair programming

Menos distracciones
Nivelación de desarrolladores
Compartir conocimiento
Propiedad colectiva
Mayor calidad
Mejor relación entre integrantes del equipo
Incentiva la colaboración
Pair programming

4 horas
Pair programming

4 horas