Introducción a Agile

Hugo Brunetta
¿Qué es ser ágil?

“Ser ágil, es HACER cuando

NO SABES todo lo que
necesitas SABER para
HACER”
Pete Behrens Scrum Alliance
¿Qué es Agile?

“Agile” no es una metodología sino un conjunto de

valores y principios que fueron establecidos en 2001, a partir
de la reunión que realizaron 17 personas en busca de
puntos en común con relación a las mejores prácticas para
el desarrollo de Software.

Esta reunión dio como resultado el denominado: Manifiesto

para el desarrollo ágil de software
Gestión Tradicional de Proyectos Proyectos Ágiles
 Valores Ágiles

1. Valorar más a los individuos y sus interacciones que a los

procesos y las herramientas
2. Valorar más el software funcionando que la
documentación exhaustiva
3. Valorar más la colaboración con el cliente que la
negociación contractual
4. Valorar más la respuesta ante el cambio que seguir un
plan
Valorar más a los individuos y sus interacciones que a los
procesos y las herramientas

• Las herramientas mejoran la eficiencia, pero sin personas con

conocimiento técnico y actitud adecuada, no se producen
resultados.

• Las empresas suelen predicar muy alto que sus empleados son lo
más importante, pero la realidad es que en los años 90 la teoría de
producción basada en procesos, la reingeniería de procesos ha
dado a estos más relevancia de la que pueden tener en tareas que
deben gran parte de su valor al conocimiento y al talento de las
personas que las realizan.
Valorar más el software funcionando que la
documentación exhaustiva

• Poder ver anticipadamente cómo se comportan las funcionalidades

esperadas sobre prototipos o sobre las partes ya elaboradas del sistema
final ofrece una retroalimentación muy estimulante y enriquecedora que
genera ideas imposibles de concebir en un primer momento.

• El manifiesto no afirma que no hagan falta. Los documentos son soporte

del software, permiten la transferencia del conocimiento, registran
información histórica, y en muchas cuestiones legales o normativas son
obligatorios, pero se resalta que son menos importantes que los
productos que funcionan.
Valorar más la colaboración con el cliente que la
negociación contractual

• Un contrato no aporta valor al producto. Es una formalidad que

establece líneas divisorias entre responsabilidades, que fija los
referentes para posibles disputas contractuales entre cliente y
proveedor.

• En el desarrollo ágil el cliente es un miembro más del equipo, que

se integra y colabora en el grupo de trabajo.
Valorar más la Los principales valores de la gestión ágil son la
respuesta ante anticipación y la adaptación; diferentes a los de la
el cambio que gestión de proyectos ortodoxa: planificación y
control para evitar desviaciones sobre el plan.
seguir un plan
 Principios del Manifiesto Ágil

1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y

continua de “productos” con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos “producto” funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al período de tiempo más corto posible.
4. Los responsables del negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y
el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y
entre sus miembros es la conversación cara a cara.
Principios del Manifiesto Ágil

7. El “producto” funcionando es la medida principal de progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los promotores,
desarrolladores y usuarios debemos mantener un ritmo constante de forma
indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a
continuación, ajustar y perfeccionar su comportamiento en consecuencia
Cómo aplicar la
metodología Agile a tu
proyecto
1. Identifica tus objetivos comerciales.
2. Analiza la cultura de la empresa.
3. Detecta el impacto potencial en tus
clientes (internos o externos)
4. Determina los recursos disponibles en
tu empresa.
5. Apóyate en líderes de tu empresa.
6. Implementa procesos con base en
Agile.
SCRUM
¿Qué es Agile y Scrum?

A efectos de simplificar decimos que, por ejemplo, SCRUM

es una metodología Ágil.

Esto quiere decir que la metodología SCRUM se alinea con

los valores y principios expresados en el Manifiesto y por
tanto es una metodología que sigue un enfoque ágil de
gestión de proyectos.
Sprint =
Pique
¿Qué es un Sprint?
Un sprint es un período breve de
tiempo fijo en el que un equipo
de scrum trabaja para completar
una cantidad de trabajo
establecida.
Los sprints se encuentran en el
corazón de las metodologías
scrum y ágil, y hacer bien los
sprints ayudará a tu equipo ágil a
desarrollar el mejor proyecto con
menos dolores de cabeza.
¿Cómo se hace un
sprint en Scrum?

• Un daily sprint en Scrum no es

más que planificar cada día una
iteración, convocar cada mañana
al empezar la jornada una reunión
con el equipo.
• Cada día vamos resolviendo
problemas y asignado tareas para
cada uno. Así, la flexibilidad del
proyecto alcanza su punto más
álgido
Reunión Kick-Off

Convocamos al equipo, les asignamos tareas e intentamos averiguar cómo podría cada uno afrontar sus
actividades. Por ejemplo, ¿qué recursos va a necesitar para este primer sprint? ¿Cuánto tiempo le va a llevar cada
actividad? ¿Necesita trabajo de otras personas para sacar adelante esta primera fase de planificación?

Además, es importante compartir con todos los miembros los datos y requerimientos que tienes en el momento
de arrancar el proyecto. Así como informar de lo que se quiere conseguir con el proyecto. De este modo, damos
un sentido a la labor de todos y seguimos objetivos comunes.

Asimismo, cada uno tiene un nivel de incertidumbre que también debemos poner sobre la mesa. De esta forma,
podremos planificar esta primera iteración o sprint de la forma más realista posible.
Reuniones individuales y primera planificación

Durante esta planificación surgirán más preguntas que intentaremos ir resolviendo en

reuniones individuales con cada responsable de actividad. De esta manera, estaremos
negociando tiempo y recursos de cada tarea, coordinando la ayuda que cada uno necesitará
de todo el equipo.

Además, durante estas reuniones individuales darás respuesta también a muchas de las
preguntas que hayan surgido durante la reunión Kick-off.
Da comienzo al desarrollo del proyecto

A través del primer sprint. Una vez hayas planificado el sprint

y distribuido las tareas a cada persona, pon en
funcionamiento las actividades según los requerimientos,
recursos y dudas aclaradas que tengas. Así, al mismo tiempo
que pasas a la acción también vas a ir descubriendo otras
tareas que tendrás que ir planificando en próximos sprint.
¿Qué es un backlog del producto?

El backlog de un producto El equipo de desarrollo

Los elementos más
es una lista de trabajo saca trabajo del backlog
importantes se muestran
ordenado por prioridades del producto en la medida
al principio del backlog del
para el equipo de de sus capacidades, ya sea
producto para que el
desarrollo que se obtiene de forma continua
equipo sepa qué hay que
de la hoja de ruta y sus (kanban) o por iteraciones
entregar primero.
requisitos. (scrum).
 Diagrama de Proceso SCRUM

Scrum Master
24 H

Sprint
1-4
Product Owner Equipo Semanas Revisión Sprint +
Retrospectiva Sprint

Product Reunión Sprint Fin del

Backlog Planeamiento Backlog Trabajo
Sprint
 Una historia de
usuario es una
representación de un
requisito escrito en
una o dos frases
utilizando el lenguaje
¿Qué es una común del usuario.
User Storie? Las historias de
usuario son
utilizadas en las
metodologías de
desarrollo ágiles para
la especificación de
requisitos.
Proyecto: Nuevo Producto de
Seguros
Contexto

• La compañía de seguros
decide lanzar un nuevo
producto de seguro de hogar
que cubra daños por
desastres naturales.
• Para desarrollar este
producto, deciden utilizar la
metodología Scrum.
Definición de Roles
• Product Owner (PO): Responsable de definir la visión del producto, priorizar el
backlog y asegurarse de que el equipo trabaje en las tareas más valiosas. En
este caso, puede ser un gerente de producto de la compañía.

• Scrum Master (SM): Facilita el proceso Scrum, ayuda a resolver impedimentos y

asegura que el equipo siga los principios ágiles. Este rol puede ser ocupado por
un líder de proyecto o un facilitador.

• Equipo de Desarrollo (Development Team): Un grupo multifuncional que trabaja

en el desarrollo del producto. Esto podría incluir actuarios, desarrolladores de
software, expertos en riesgos, etc.
 Product Backlog

El PO crea una lista priorizada de características y requisitos necesarios para el nuevo

producto de seguro de hogar, por ejemplo:

• Investigación de mercado.
• Definición de coberturas.
• Diseño de pólizas.
• Desarrollo de la plataforma de gestión.
• Integración con sistemas de terceros.
• Pruebas de usabilidad.
Sprint Planning

El equipo selecciona las tareas del product backlog que se

completarán en el próximo sprint (una iteración de trabajo que
normalmente dura 2-4 semanas).

Se define un objetivo claro para el sprint, como "Desarrollar un

prototipo funcional de la plataforma de gestión"
Priorización del • ¿Qué va primero? ¿Qué
segundo?...
Product Backlog
Backlog Grooming

Ahora es responsabilidad de todo el equipo, Scrum Master e

incluso del Product Owner de estimar, por orden de
prioridad, las User Stories y de esta forma tener una visión
de cuán difícil será completar esa funcionalidad en un sprint.
Sprint

El equipo trabaja en las tareas seleccionadas.

Cada día, tienen una reunión diaria (Daily Standup) de 15 minutos

para discutir el progreso, planificar el trabajo del día y resolver
cualquier impedimento.
Ejemplo de Actuarios diseñan las coberturas y tarifas.

tareas en un Desarrolladores crean la interfaz de usuario de la plataforma.

sprint: Expertos en riesgos validan los escenarios de desastres naturales.
Sprint Review
• Al final del sprint, el equipo presenta lo que ha completado a
los stakeholders (interesados). Reciben feedback sobre el
producto.

• Ejemplo: Mostrar un prototipo de la plataforma de gestión con

funcionalidades básicas.
Sprint Retrospective
• El equipo reflexiona sobre el sprint pasado y discute qué
funcionó bien y qué necesita mejorar.

• Ejemplo: Deciden mejorar la comunicación entre los actuarios

y los desarrolladores para la siguiente iteración.
Retrospectiva
Scrum
Sólo sirve lo que está
completamente terminado