Manifiesto Agil - Valores

Valoramos las personas sobre los procesos

Valoramos el software funcionando que la
documentacin
Valoramos la colaboracin con nuestros
clientes sobre los contratos
Valoramos mas la adaptacin al cambio
que la planificacin estricta

12 Principios

Nuestra mayor prioridad es satisfacer al cliente: Entrega temprana y

continua de software con valor

Cliente feliz

Feedback continuo

Valor = Beneficio econmico

Aceptamos que los requisitos cambien

Mayor adaptacin en cualquier momento del proyecto

Entregar lo que el cliente realmente necesita

Entregar software funcional frecuentemente

Feedback continuo con el cliente

Vamos bien?

Que necesitas?

12 Principios

Trabajar conjuntamente el rea de negocio y TI

Mayor colaboracin y resolucin de problemas

Mayor confianza entre miembros del equipo

Los mejores proyectos se desarrollan con individuos motivados

Mayor motivacin

Satisfacer las necesidades de las personas

Confianza como poltica de reduccin de costes

comunicacin cara a cara, es la mejor comunicacin

Evitar malos entendidos

Llegar antes a un acuerdo

Importancia de la comunicacin no verbal

12 Principios

Atencin continua + Excelencia Tcnica + Buen diseo = Mejora de la Agilidad

Pensar en la calidad desde el principio

Se nos simplificara nuestros mantenimientos

Viviremos mas tranquilos y mas felices

Las mejores arquitecturas, requisitos y diseos emergen de equipos auto

organizados

Mayor responsabilidad + Mayor autonoma + Mayor conciencia = Aumento de la

motivacin

Decidir como hacer las cosas, por los que mejor saben hacerlas

A intervalos regulares, hay que reflexionar sobre como ser mas efectivo para
mejorar

Mejora continua

Mayor conciencia de fortalezas y debilidades

SCRUM: Introduccin
Los primeros en aplicar SCRUM en sus
respectivas empresas

SCRUM: Introduccin
Primera vez donde se habla de
SCRUM

SCRUM: Introduccin
Ambos colaboraran posteriormente
para fusionar todas las ideas junto
con su experiencia y mejores
practicas de la industria para dar lugar
a lo que hoy conocemos como
SCRUM

SCRUM: Introduccin
Se publica el primer libro sobre SCRUM

SCRUM: Introduccin
Se funda la SCRUM ALLIANCE

SCRUM: Introduccin
Se funda scrum.org

SCRUM: Introduccin
Se funda scrum.org

SCRUM: Introduccin
Se ingresan algunas mejoras respecto
a la gua original

SCRUM en 5 minutos

La iteracin en SCRUM la vamos a llamar SPRINT

Duracin en 2 y 4 semanas

De ritmo continuo, es decir de la misma duracin, sostenible

El inicio de un SCRUM es a partir de una idea de negocio por uno

o mas stakeholder
Con todas esas ideas se armar una pila del producto
El rol que gestiona la pila del producto es llamado Dueo del
Producto o Product Owner

Su rol es comunicarse y gestionar todas las expectativas de los stakeholder

Prioriza las necesidades y requerimientos de los stakeholders

SCRUM en 5 minutos

Posteriormente cada SPRINT debe entregar un incremento de mi producto

Entregar un pedacito de software funcionando

Es una de las salidas que va tener cada SPRINT

Aparece el rol del equipo de construccin

Es el encargado de ir entregando pedacitos de software funcional

Estos equipos son pequeos, autorganizados y multidisciplinados

Pequeos menos a 9 integrantes

Pila del SPRINT

Es la entrada para el equipo de construccin

La pila del SPRINT es el subconjunto de funcionalidades que estn dentro de la pila del producto

El equipo se concentrara sobre la pila del SPRINT

La pila del SPRINT tiene definidas las tareas concretas a realizar

La definicin de la pila de SPRINT se realiza en la reunin denominada Reunin de Planificacin

La Reunin de Planificacin se realiza entre el equipo de construccin y el dueo del producto

SCRUM en 5 minutos

Reuniones de sincronizacin de equipo de construccin

Se renen todos los dias por 15 minutos

Que hicieron el da anterior? Que van hacer hoy? Tienen algn tipo de impedimento?

El objetivo de esta reunin es fomentar la comunicacin y sincronizacin

Reunin de Demo o de Revisin

Se realizar al final de un ciclo SPRINT

Es una de las primeras reuniones que se debe realizar al final de un ciclo SPRINT

Reunin de Retrospectiva

La ultima reunin a realizar despus del SPRINT

Analiza las problemticas y la forma de trabajar del mismo equipo

Puede asistir cualquier otra persona que el equipo decida

Reunin de Refinamiento

Se realiza durante el ciclo SPRINT

Se rene el equipo de construccin y el dueo del producto para ir trabajando y refinando los requisitos del
siguiente SPRINT

Esta reunin puede ser de forma continua o por nica vez en el ciclo del SPRINT

SCRUM en 5 minutos

Rol Scrum Master

Encargado de que se cumpla proceso

Encargado de remover impedimentos

Resolver los conflictos internos del equipo

Resolver los conflictos externos con el dueo del producto o stakeholders

Definicin de Listo (Definition of ready)

Asegurar que los requisitos que entran al SPRINT estan bien definidos o refinados

Es un conjunto de requisitos que tiene que cumplir un item del Product backlog para que ingrese dentro del SPRINT

Definicin de Terminado (Definition of Done)

Lista que tiene que cumplir cada uno de los elementos del SPRINT para considerarlo terminado

Ejemplo:

Que se haya versionado el codigo fuente

Que se haya realizado las pruebas QA con el usuario
Que se haya realizado pruebas de performance
Que se haya realizado pruebas de UX

La calidad del producto depende de cuan minuciosa es esta lista de terminado

Artefactos de Scrum
Los Artefactos en Scrum son todas aquellas
herramientas que nos sirven para utilizar el
marco de trabajo de la mejor manera
posible. Veremos cuales son estos
artefactos y su utilidad dentro del marco.

Artefactos de Scrum

Artefactos de Scrum
Pila de Producto

Product backlog

Es el conjunto de requisitos o caractersticas que debe tener

nuestro producto. Contendr todo lo que se considere aporta
valor, aunque estar priorizado de arriba a abajo, donde
arriba estarn los elementos ms prioritarios y por ello, ms
detallados y desgranados. En la parte inferior podremos tener
elementos o requisitos que todava no estn muy claros.
Se puede aplicar pareto que dice que con el 20% de
funcionalidades de puede aportar el 80% del valor a nuestros
clientes

Artefactos de Scrum
PBI vs Historia de usuario

PBI vs Historia de usuario

Vamos a ver qu tipo de elementos son los

que pueden incluirse dentro de la Pila de
Producto. La gua de Scrum nos habla que
dentro de esta Pila de producto lo que hay
son Elementos de la pila del Producto, PBI
de sus siglas en ingls Product Backlog
Item.

Artefactos de Scrum
PBI vs Historia de usuario

Pila de Producto

Puede ser casos de uso

Historias de usuarios

Cualquier otra cosa

No se debe confundir la PBI con la historia de usuario,

pues la historia de usuario es un recordatorio de una
conversacin pendiente, mientras que el PBI es un
item detallado y con requisitos concretos.

Artefactos de Scrum
PBI vs Historia de usuario

Formato de Historia de Usuario

Artefactos de Scrum
PBI vs Historia de usuario

Formato de Historia de Usuario

Como: Usuario de la plataforma Miriadax

Quiero:Poder visualizar un video

Para: Poder aprender todo lo que en el se indica

Criterios de aceptacin de la historia

Dado: Un video detenido en el minuto 1

Cuando: Pulso el botn de play

Entonces:El video empieza a funcionar incrementando su

contador de tiempo en un segundo.

Artefactos de Scrum
Pila de Sprint
Es el conjunto de requisitos o caractersticas
que debe tener nuestro producto. Contendr
todo lo que se considere aporta valor, aunque
estar priorizado de arriba a abajo, donde
arriba estarn los elementos ms prioritarios
y por ello, ms detallados y desgranados. En
la parte inferior podremos tener elementos o
requisitos que todava no estn muy claros.

Artefactos de Scrum
Incremento de Producto

El incremento de producto es el resultado

de cada Sprint. Las dos caractersticas ms
importantes que debe reunir este
incremento:

Tiene que ser potencialmente puesto en

produccin

Aadir valor a nuestro cliente

Artefactos de Scrum
Incremento de Producto
Para ser potencialmente puesto en
produccin implica que debe tener
entornos de:

Automatizacin de pruebas

Despliegue continuo

Validacin de software

Reuniones Scrum
Los eventos o reuniones que suceden en
Scrum para conseguir mayor eficiencia

Reuniones Scrum

Reuniones de planificacin
Tiene una duracin de 8 horas para sprints de un
mes. Para sprints ms cortos la duracin es
severamente ms corta. Veamos a continuacin
en qu consisten este tipo de reuniones.

Reuniones Scrum

Reuniones de planificacin
Tiene una duracin de 8 horas para sprints de un mes. Para sprints ms cortos la
duracin es severamente ms corta. Veamos a continuacin en qu consisten este
tipo de reuniones.

Esta reunin se realiza al inicio del Sprint para planificar el trabajo de las prximas
semanas

Se va necesitar la pila de productos

La salida es la pila de Sprint

La reunin es el equipo de construccin con el dueo del producto y facilitada por el

Scrum Master

Para el Sprint de 2 semanas el tiempo dedicado para esta reunion es 2 hrs.

Se realizan dos subreuinones:

Reunin estratgica: El dueo del producto le habla al equipo de construccin

Reunin tctica, donde el equipo de construccin tendra que desgranar las tareas del Sprint

Reuniones Scrum

Reuniones de planificacin

Reuniones Scrum

Reuniones diarias
El objetivo tras esta reunin, es la de facilitar la transferencia de informacin
y colaboracin entre los miembros del equipo. Con esto se mejora la
productividad del equipo, ya que, nos permite ayudarnos unos a otros

Para que el equipo del construccin se sincronice

Se realiza al inicio del da

Para identificar posibles impedimentos y bloqueos a lo largo del da

Como entrada se necesita el tablero con el progreso que estamos llevando

Se realiza de pie en 15 minutos

Se renen el equipo de construccin y el Scrum Master, se puede invitar al

dueo del producto eventualmente

Reuniones Scrum

Reuniones diarias

Reuniones Scrum

Reuniones de Retrospectiva
Con el objetivo de mejorar la productividad y la calidad del producto que estamos
desarrollando, el equipo hace el ejercicio de analizar como est ejecutando las
tareas durante la iteracin. Veamos en el siguiente vdeo como es esta reunin.

Sirven para inspeccionar el proceso y el equipo, que hicimos bien y que podemos
mejorar

Se realiza al final el Sprint. Debe realizarse despues de la Reunin Demo.

De entrada a esta reunin debemos tener la lista de los problemas presentados

durante el Sprint

Se obtendr un plan de accin de mejora continua

Los participantes son el equipo de construccin, el Scrum Master y eventualmente

el dueo del producto, se recomienda que tambin asista el dueo del producto.

Para un Sprint de 2 semanas se recomienda una reunin de 2 horas.

Reuniones Scrum

Reuniones de Retrospectiva

Reuniones Scrum

Reuniones de Revisin Demo

Revisar que se ha completado y que no durante el sprint.

Feedback para mejorar el producto en las siguientes iteraciones.

Se realiza al finalizar el sprint

Presentar la demo a los interesados del incremento de software

terminado en el sprint.

Obtenemos feedback y mejoras

Asisten el dueo del producto, el equipo de construccin y el

Scrum Master. Puede participar cualquier otro interesado.

Para un sprint de 2 semanas la reunin debe ser de una hora

Reuniones Scrum

Reuniones de Revisin Demo

Reuniones Scrum

Reuniones de Refinamiento
El refinamiento (refinement) de la Lista de Producto es el acto de aadir detalle,
estimaciones y orden a los elementos de la Lista de Producto.

Esta reunin sirve para mejorar los elementos que tenemos en la pila de
producto. Estos elementos se realizaran en el siguiente sprint.

Se realiza durante el sprint

Como entrada debemos tener los elementos de la pila de producto

Como salida obtendremos elementos refinados, es decir elementos mas

pequeos y aadiendo mas detalle a estos elementos para que el equipo se
entere en que consisten.

Asstiran el dueo del producto, el equipo constructor y el Scrum Master.

Pueden reunirse 1 hora en un sprint de 2 semanas o

Reunirse en forma diaria de 15 a 20 minutos

Reuniones Scrum

Reuniones de Refinamiento

Roles en Scrum
Product Owner

Dueo del Producto (Product Owner - PO)

El dueo de producto es el responsable de mantener la visin del
producto que se va a construir maximizando la cantidad de valor
entregado al finalizar cada Sprint

Se encargara de mantener el backlog convenientemente

actualizado y priorizado con las funcionalidades mas importantes
en la parte de arriba

Asiste a la reunin de planificacin

Asiste a la reunin de revisin demo al final del sprint

Es responsable de aceptar los requisitos que entraran como los

que no entraran en el siguiente sprint

Roles en Scrum
Scrum Master

Scrum Master (SM)

El Scrum Master es un rol con un conjunto de responsabilidades muy
variadas. Realiza labores de facilitador de reuniones, as como
acompaante del equipo para ayudarle a resolver las problemticas que
se vaya encontrando a lo largo del proyecto.

Facilitar y liderar las reuniones

Cuidar de que todos los roles cumplan sus funciones

Mantener los artefactos de la mejor manera

Resolver cualquier conflicto

Es un rol muy enfocado en la persona, debe tener skill especficos como

buenas herramientas de comunicacin, as como resolucin de
conflictos.

Roles en Scrum
Scrum Team

Equipo de construccin (Scrum Team ST )

Equipo de construccin son los encargados de construir el
producto. Si estamos hablando de equipos de construccin de
software estar formado por desarrolladores, diseadores,
arquitectos, testers y cualquier persona que est implicada de
una u otra manera en la construccin del producto.
Deben cumplir 3 caractersticas:

Deben ser pequeos (9 max.), para evitar problemas de

comunicacin.

Multidisciplinares, puedan construir el producto adecuado.

Autoorganizados, el equipo decide como van a realizar las

tareas del proyecto. Se asignan y estiman estas tareas

Roles en Scrum
Stakeholder

Stakeholder (Usuarios y Clientes SH )

Otro elemento fundamental son los clientes y usuarios. Son
todas aquellas personas que de una manera u otra utilizan
el resultado de nuestro producto. Si hablamos de
aplicaciones de software sern los usuarios y clientes que
se conectarn a la aplicacin para utilizarla. Debemos
distinguir a usuario (cualquier persona que utilice la
aplicacin) de cliente (aquella persona que realmente paga
por ella)

El dueo del producto es el encargado de hablar con estas

personas y mantener su visin de manera actualizada para
que trasmita en forma adecuada al equipo de construccin.

Roles en Scrum
Estimacin gil

Puntos de historia
Existen diferentes tcnicas y herramientas para estimar.
Tambin existen diferentes unidades en las que
hacerlo. Veamos algunas de estas a continuacin.

La estimacin se basa en la puntuacin de la

complejidad de la tarea, tomando como base una
tarea sencilla que se le podra asignar un nivel de
complejidad 1 y a otra tarea se le puede asignar un
nivel de complejidad 4, es decir 4 veces mas
complejo que la primera tarea. A esto tipo se le
denomina estimacin relativa.

Roles en Scrum
Estimacin gil

Tipos de estimaciones
Existen diferentes tcnicas y herramientas para estimar.
Tambin existen diferentes unidades en las que
hacerlo. Veamos algunas de estas a continuacin.

La estimacin se basa en la puntuacin de la

complejidad de la tarea, tomando como base una
tarea sencilla que se le podra asignar un nivel de
complejidad 1 y a otra tarea se le puede asignar un
nivel de complejidad 4, es decir 4 veces mas
complejo que la primera tarea. A esto tipo se le
denomina estimacin relativa.

Roles en Scrum
Kanban Historia

1945 termina la II Guerra Mundial

1946 y 1970 Toyota trabaja en los sistemas Just in Time, El
Justo a Tiempo. Inspirado en como trabajaban los
Supermercados.

Tres pilares:

Sistema de arrastre, donde se solicita solo lo necesario, cuando

se solicita y en la cantidad exacta.
Flujo Continuo, donde se elimina los problemas que detienen el
flujo de distribucin.
Tiempo TAKT, es el tiempo en producir el componente de un
sistema, a velocidad constante y sincronizado con lo requerido.

Roles en Scrum
Kanban Historia
Estos sistemas trabajan con tableros Kanban
para visualizar los flujos de trabajo, aqu
tenemos la asociacin de Kanban con el
mundo Lean.
El Just In Time es conocido como el Sistema
de Produccin Toyota, Toyota Production
System. Su principal objetivo es Eliminar
Desperdicios, su impulsor fue Taicho Ohno.

Roles en Scrum
Kanban Historia
Principios del Just In Time

Mejora continua, proceso de pequeos cambios

que tratan de ir al origen del problema para
determinar las causas que las produjeron.
Respeto por las personas y el trabajo en
equipo.
Largo plazo, pensar en largo plazo incluso
sacrificando objetivos financieros a corto plazo.

Roles en Scrum
Kanban Historia

El proceso adecuado, producirn

resultados adecuados
Aade valor a tu organizacin
desarrollando a las personas y
colaboradores
Resolver problemas races de forma
continua lleva al aprendizaje organizacional

Roles en Scrum
Kanban Historia

1990 se populariza el sistema Lean

Roles en Scrum
Kanban Historia
Cuando se escribio este libro en 1990, Toyota era
la mitad del tamao de General Motors. Hoy
Toyota est pasando a GM como el fabricante de
automviles ms grande del mundo y es la
empresa global ms consistentemente exitosa
de los ltimos cincuenta aos. Este clsico de
gestin fue el primer libro que revel el sistema
de produccin lean de Toyota que es la base
para su xito duradero.

Roles en Scrum
Kanban Historia
En este libro se acuo por primera vez el
termino Lean manufacturing ('produccin
ajustada', 'manufactura esbelta', 'produccin
limpia' o 'produccin sin desperdicios'). Es un
modelo de gestin enfocado a la creacin de
flujo para poder entregar el mximo valor para
los clientes, utilizando para ello los mnimos
recursos necesarios: es decir ajustados.

Roles en Scrum
Kanban Historia
Toyota logro ajustar los tiempos de operacin
a un tercio y las horas de ingeniera a la
mitad.

Roles en Scrum
Kanban Historia

1997 Microsft Secrets, donde se habla de

aplicaciones similares del sistema de
Toyota al desarrollo del software, aun no se
habla de los sistemas Lean.

Roles en Scrum
Kanban Historia

2001 se escribe el Manifiesto Agile

2003 se escribe Lean Software
Development

Roles en Scrum
Kanban Historia
Lean Software Development

Eliminacin de desperdicios
Eliminacin de burocracia en el desarrollo de
productos
Fomentar el aprendizaje mediante ciclos cortos y
frecuentes
Iteraciones rpidas para conseguir entregar valor a
los clientes rpidamente

Roles en Scrum
Kanban Historia
Lean Software Development
De esta manera:

Se obtiene feedback que tire (pull) de los

productos
En lugar de requisitos y planes rgidos que
empujen (push) el trabajo de desarrollo.

Roles en Scrum
Kanban Historia
Lean Software Development
Destaca los siguientes principios de
desarrollo Lean:

Optimizacin del todo

Eliminacin de desperdicios

Calidad en la construccin

Roles en Scrum
Kanban Historia
Lean Software Development
Destaca los siguientes principios de desarrollo Lean:

Optimizacin del todo

Eliminacin de desperdicios

Calidad en la construccin

Aprender constantemente

Entregar rpido

Involucrar a todo el mundo

Roles en Scrum
Kanban Historia

2004-2005 David J. Anderson, implementa

primer sistema Kanban para la creacin de
software en Microsoft
2006 Aparece Kanban como metodologa de
mejora de procesos y no solo como un sistema
para visualizar los flujos de trabajo.
2007 se presenta Kanban como enfoque para
el cambio organizacional

Roles en Scrum
Kanban Historia

2009 Se presenta en un seminario una

manera de utilizar Kanban junto con
Scrum, se bautizara como Scrumban.

Roles en Scrum
Kanban
3 Principios

Empieza donde quiera que ests, siempre es

un buen momento para cambiar

KAIZEN = Mejora Progresiva

Cambios evolutivos e incremental, poco a poco.

Respeto por los roles actuales, contrario a
Scrum

Roles en Scrum
Kanban
5 Practicas

Visualizar el flujo de trabajo

Nos obliga a pensar:

Fases de las tareas

Limites de las tareas

Personas implicadas con las tareas

Roles en Scrum
Kanban

Limitar el trabajo W.I.P (Working in

progress)

Enfocarnos en tener un flujo de trabajo

pequeo

Roles en Scrum
Kanban

Gestionar el flujo de trabajo

Identificar donde tenemos el cuello de botella

para intentar mejorar este flujo

Polticas explicitas, esto quiere decir que deben

estar documentadas visible y accesible, as
como sencillas de entender, as fomentaremos
la comunicacin. Se recomienda que estn
visibles al lado del tablero.

Roles en Scrum
Kanban

Mejora colaborativa, mejora continua.

Se aplica principios Lean

Establecer revisiones de los resultados cada

cierto tiempo.

Es emprico, no existe recetas para todo el

mundo

Roles en Scrum
Kanban
A partir de estas 5 practicas sencillas lo que
se puede hacer es inspeccionar los
resultados y adaptarnos a el.

Roles en Scrum
Kanban
Clases de Servicios
Es la agrupacin de diferentes tareas en funcin del
tratamiento que le vamos a dar a cada uno de ellos.
Ejemplo de clases de servicio

Urgente

Normal

Con tiempo definido

Roles en Scrum
Kanban
Clases de Servicios
De acuerdo a las clases de servicios determinadas
se les dar una prioridad correspondiente.
Las tareas de tipo urgente van en las primeras
lineas del tablero.
Cada clase de servicio debe tener su polticas de
atencin explicitas.

Roles en Scrum
Kanban
Cuando iniciemos un tablero Kanban

Definir tipos de tareas (clases de servicios)

Que tratamiento le daremos

Con que prioridad las manejaremos

Que polticas vamos a asociar a cada una

de ellas