Introducción a la innovación y transformación digital con metodologías ágiles
El manifiesto y los principios ágiles
1. Una revolución aún en curso
El manifiesto y los principios ágiles
Pablo Gil
pablo.a.gil@gmail.com
http://www.eldba.com
2. De qué vamos a hablar…
Motivos históricos que llevaron a plantear una
nueva forma de trabajar
El manifiesto ágil y sus 12 principios
Ágil y Lean – Lean aplicado al desarrollo de
software
Algunas metodologías ágiles (scrum, xp,
kanban)
Software craftmanship
Eficacia de las metodologías ágiles
Algunos datos útiles (libros, links)
Presentación del curso de scrum
3. El desarrollo de software “al inicio”
Hasta la adopción de los microchips, el hardware
existente y su alto costo limitaba las posibilidades
ofrecidas a los programadores, por lo que la mayoría era
muy especializado y muchas veces trabajaban sin otro
método que el de codificar y corregir
Pero hacia los años ’60 estas
limitaciones desaparecieron, y se
hizo necesario pensar a un
proceso más formal que evitara los
problemas más comunes del
desarrollo:
•Imprecisión en la planificación
y
estimación de costos
•Baja calidad del software
4. Se intenta dar una solución al caos
Una nueva rama de la ciencia, denominada
“ingeniería del software” comienza a estudiar e
una implementar alguna metodología que de
alguna manera intentan “controlar el caos”.
Estas metodologías están caracterizadas por
intentar controlar el caos definiendo en modo
estricto las distintas etapas de desarrollo.
Una de las metodologías que más éxito tuvo fue
la “waterfall” (en cascada) que preveía distintas
fases bien definidas, y donde para pasar a una
fase sucesiva era necesario cumplir con
condiciones bien definidas
Ejemplos de estas metodologías “hard” son
5. Ventajas de la metodología “en
cascada”
Es particularmente
apropiado para
proyectos estables o
de alto riesgo y
donde los
requerimientos no se
modifiquen con
frecuencia
Es simple y fácil de
entender y de usar
Es fácil de gestionar
ya que cada fase
tiene sus entregables
bien definidos
Las
responsabilidades en
cada fase están bien
Análisis
Diseño
Codificación
Pruebas
Implementació
n
6. Pero se verifican nuevos problemas
La realidad es que el mundo en
el que vivimos es
esencialmente variable.
Son muy pocos los proyectos
donde los requisitos son
inmutables desde el inicio hasta
el fin
Incluso si los requisitos se fijan
al inicio, distintas variables
intervienen obligando a veces a
cambiar enfoque (ej: nuevo
hardware, nuevas leyes
regulatorias)
Generalmente el cliente no
sabe con exactitud qué es lo
que realmente desea y muchas
veces se termina desarrollando
algo que al cliente no le sirve.
Esto provoca tener que
renegociar los eventuales
7. La solución: convivir con el caos
Las metodologías ágiles no intentan controlar el caos,
sino convivir con él
Esto se logra entre otras cosas incorporando al cliente
como miembro o por lo menos como alguien que
trabaja codo a codo con el equipo de desarrollo.
Al mismo tiempo se aceptan y en cierto modo se
alientan los cambios a las especificaciones, ya que
éstas aseguran que el equipo está desarrollando
realmente lo que el cliente necesita
Sumado a las entregas periódicas cada poco tiempo,
contribuye a aumentar la confianza entre
desarrolladores, cliente y sponsors
Para asegurar poder responder a los cambios, se hace
8. El manifiesto ágil
Fue redactado en el año 2001 en Utah por 17
personas, entre ellos estaban los creadores de
metodologías hoy consideradas ágiles
Ellos acordaron que si bien no compartían una
metodología única, si lo hacían con cuatro valores:
Definieron también 12 principios derivados de estos valores
Terminan aclarando que: “aunque valoramos los
elementos de la derecha, valoramos más los de la
Valoramos sobre
Individuos e
interacciones
procesos y herramientas
Software funcionando documentación
exhaustiva
Colaboración con el
cliente
negociación contractual
Respuesta ante el
cambio
seguir un plan
9. Los 12 principios ágiles
1. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software 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 software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible.
4. Los responsables de 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
10. Los 12 principios (2da parte)
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces
de 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.
11. Los principios (final)
Es evidente que es exigencia que los equipos ágiles
tengan ciertas características para poder cumplir con el
espíritu del manifiesto, entre las que se mencionan:
Coraje
Auto-Gestión
Visibilidad – Feedback
Colaboración con el cliente
Confianza
Desarrollo sostenible
Excelencia y calidad
Simplicidad
Adaptación al cambio
12. En resumen, qué puede considerarse
“metodología ágil”
Inicialmente, se definió “ágil” a una metodología
que propiciaba el desarrollo iterativo e incremental
de funcionalidades realizado por parte de equipos
auto-organizados y donde se favoreciera el
contacto con el cliente
Más adelante, se amplió esta definición : una
metodología ágil “enfatiza la colaboración cercana
entre un grupo de programadores y expertos en el
negocio; comunicación cara a cara; entrega
frecuente de valor de negocio; grupos pequeños y
autoorganizados y modos de manejar el código en
el equipo para que los inevitables cambios de los
13. ¿ Y qué hay de Lean ?
Lean deriva de la experiencia de Toyota en la
búsqueda del proceso de fabricación adecuado
Se basa en satisfacer la demanda de los clientes
construyendo solo la cantidad necesaria en el
menor tiempo posible, estudiando para ello como
eliminar o por lo menos minimizar los desperdicios
trabajando sobre las causas del mismo
Al mismo tiempo, se intenta minimizar el trabajo
que no agrega valor al producto
Y mantener un ritmo continuo y sostenible
Otro principio importante era el de “cero errores”,
parando la línea de producción cuando se detecta
14. Lean (final)
Lean identifica 7 tipos básicos de desperdicios (el
último se agregó más tarde):
Sobreproducción
Esperas (tiempos con inactividad)
Transporte de material innecesarios
Sobre procesamiento o procesamiento ineficiente
Exceso de inventario
Movimientos innecesarios
Defectos
Creatividad de los empleados no utilizada
A diferencia del enfoque tradicional de mejora de
procesos (que busca identificar las deficiencias
locales), el enfoque “lean” busca suprimir las
actividades sin valor agregado
15. Lean Software Development
Creado por el matrimonio Mary y Tom Poppendieck
Adaptaron el proceso de fabricación de Toyota al
desarrollo del software , adaptando los desperdicios
al desarrollo del software:
Defectos = bugs
Espera y transporte = falta de automación / testing
manual
Complejidad, Sobreproducción: gold plating
Esperas = meetings inútiles
Complejidad = complejidad técnica / deuda técnica
Espera, transporte = procesos pesados / burocracia
Inventario = funcionalidades incompletas
16. Lean Software Development (final)
A partir de esto, desarrollaron 7 principios:
Eliminar los desperdicios
Ampliar el aprendizaje
Decidir lo más tarde posible
Reaccionar tan pronto como sea posible
Potenciar el equipo
Crear la integridad
Mirar todo el conjunto
"Piensa en grande, actúa en pequeño,
equivócate rápido; aprende con rapidez“
17. ¿ Agile y Lean son sinónimos?
Si bien no son sinónimos, ambas de sustentan en
los mismos principios. Podríamos decir que Lean
cuando se estructura se acerca a Agile, y que
Agile cuando se ejecuta teniendo en cuenta sus
principios y no solo sus formas, se acerca a
Lean.
Hay que tener en cuenta que cuando se escribió
el manifiesto ágil, el proceso de fabricación de
Toyota ya se usaba desde hacía varios años y
era relativamente bien conocido, por lo que no es
impensable que los firmantes hayan sido
influenciados por el mismo
De hecho cualquier proceso lean será al mismo
19. Una metodología ágil: XP
Fue creado por Ken Brent como resultado de un
proyecto desarrollado para Chrysler
XP fomenta los valores de comunicación,
simplicidad, retroalimentación y coraje
Es un conjunto de buenas prácticas que se
potencian entre ellas.
Brent pensaba en los principios y prácticas de XP
como controles de un tablero de comando, y
probó a ver qué sucedía cuando ponía todos
estos controles “al máximo”
La observación interesante fue que algunas
prácticas potenciaban a otras, por lo que más
20. XP (2da parte)
XP prevé distintos roles:
Programmer, es el responsable de diseñar y construir la
solución técnica (no distingue entre roles como
arquitecto, etc)
Manager, encargado de asegurar las condiciones para
que el proyecto pueda llegar a buen fin
Customer, determina qué construir y cuándo hacerlo. Es
miembro del equipo
Tester, asegura que se cumplan las pruebas de
aceptación y ayuda a diseñarlas
Tracker, encargado de tomar métricas del equipo para
que este tenga datos para reflexionar
Coach, es el responsable del proceso.
21. XP (final)
Prácticas
:
• juego de planificación
• Programación en parejas
• Metáfora
• Entregas pequeñas
• Propiedad colectiva
• Integración continua
• Diseño simple
• Semanas de 40 horas
• Pruebas
• Cliente in situ
• Refactoring
• Estándares de programación
22. Otra metodología ágil: Kanban
Kanban es una implementación de metodología
lean
Se basa en tarjetas que identifican las distintas
tareas que el grupo va tomando
Esas tarjetas se van moviendo según un workflow
definido a distintas columnas que identifican el
estado de la misma
Se pueden definir secciones que identifican
situaciones especiales (ej urgente, prioridad alta,
etc) u otras agrupaciones (ej diferentes productos)
Uno o más miembros del equipo van tomando
esas tareas y las van moviendo conforme va
avanzando su cumplimiento
24. Otra metodología ágil: Scrum
Scrum es un marco metodológico que se adapta
particularmente bien ya que es simple
Su simplicidad al mismo tiempo permite la
adopción de todos los principios ágiles o hacer
un mix de varias metodologías
Supone un equipo formado por tres roles:
Scrum master, encargado de facilitar el funcionamiento del
equipo y de mantener la metodología
Product owner, que tiene la visión del negocio y decide
qué porción del sistema se desarrolla primero teniendo en
cuenta el valor que otorga al negocio
Equipo que diseña y desarrolla el producto.
25. Scrum (2da parte)
La metodología
reconoce tres
etapas:
Pre-juego
Juego
Post-juego
El tiempo de desarrollo se divide en
períodos de tiempo fijos (sprint) donde se
planifica y estima lo que se realizará, se
desarrollará, se demostrarán las
funcionalidades agregadas al producto y
se razonará sobre los hechos salientes y
los errores cometidos, con el fin de
mejorar la performance del equipo.
Orientad
o a la
planifica
ción
Orientado
al valor
Valores fijos
Valores estimados
A
AC T
C T
28. Scrumban: Scrum + Kanban
Es adecuado cuando los equipos no solo realizan
desarrollo sino también soporte
Se adosan dos tableros, uno scrum para el
desarrollo y otro kanban para el soporte
Los incidentes que se tratan por kanban son
estimados en puntos de historia a medida que
van surgiendo
En el sprint planing el equipo se compromete a
realizar una cierta cantidad de puntos de historia
en ese sprint, es responsabilidad del scrum
master no superar esos puntos durante el sprint
para evitar desviaciones.
29. Cómo conviven Scrum, Kanban y XP
en un mismo equipo?
Scrum es un marco metodológico que propicia
agilidad, pero que por sí mismo no lo asegura.
Aplicar las prácticas XP ayudan a asegurar las
prácticas ágiles al interno de los proyectos Scrum
Además, algunos de los trabajos que un equipo
realiza durante un sprint no pueden ser
programados durante el sprint planing porque no
pueden ser previstos (por ejemplo, interacción con
consultor externo, detección de nuevos
impedimentos, etc) o si bien pueden ser previstos
(como corrección de bugs críticos de releases
anteriores) no pueden ser cuantificados y
estimados durante el sprint planning. Para esto es
30. Más allá del manifiesto ágil:
Software Craftmanship
Esencialmente reconocen que el trabajo del desarrollador es
comparable con el del artesano, por lo que es necesario seguir
algunas prácticas de estos profesionales para su dominio. Por
ejemplo, la práctica del aprendista de un desarrollador con
experiencia.
Su lema es “elevando el nivel” (raising the bar)
Proponen en su manifiesto (presentado en el año 2008):
Terminan agregando que “Para lograr los items de la izquierda,
consideramos que los item de la derecha son indispensables”
No solo sino también
Individuos e interacciones Una comunidad de
profesionales
Software funcional Software bien hecho
Colaboración con el cliente Alianzas productivas
Responder al cambio Agregar valor constantemente
31. ¿ Agile funciona realmente ?
Antes de definir si funciona o no, es necesario saber cuándo
un proyecto funciona o no. Si pensamos que un proyecto
tiene que ser ejecutado en el tiempo pactado, con los
costos pactados y las características pactadas de
antemano, entonces NO funcionará nunca, ya que por
filosofía se aceptan los cambios propuestos por el cliente.
Si en cambio se trata de establecer o mejorar una relación
de confianza con los desarrolladores y el cliente y demás
stakeholders, en ese caso funciona siempre que el equipo
sea responsable y trabaje en modo profesional
Esto significa que en estructuras que no se rigen por
parámetros meritocráticos, la adopción de agile procurará
más problemas que soluciones
Como uno de los puntos primordiales del con metodología
32. ¿ Son eficaces las metodologías ágiles
?
Las metodologías ágiles son particularmente eficaces
en aquellas realidades donde los requisitos cambian
con frecuencia.
También son óptimas para realidades donde se requiere
mucha creatividad.
No menos importante, son eficaces donde los miembros
del equipo y el cliente están dispuestos a correr riesgos
para lograr una calidad final del producto por encima de
la norma.
No sorprende que se hable de agile y lean en campos
que no tienen que ver con el desarrollo pero si con las
características mencionadas:
Agile security, Agile marketing, Agile Start-Up, Agile analytics, Agile
33. Algunos peligros al adoptar
metodologías ágiles
Las metodologías ágiles imponen un cambio de
paradigma no solo en el modo de programar, sino
también en el modo de entender la supervisión de los
equipos
Realizar implementaciones superficiales confundiendo
metodologías y procesos ágiles con herramientas,
certificaciones, etc… Agile es básicamente un
paradigma mental y comportamental.
Suponer que por la simple adopción de una
metodología ágil, las personas involucradas en los
equipos cambiarán el propio modo de actuar, o que lo
harán en modo más profesional
Intentar adoptar agile solo en pequeños grupos de la
37. Si quieren saber más sobre Scrum
Está programado un curso de Scrum, con
ejemplos de potenciamiento con Kanban, XP y
Lean
El curso es teórico con ejercitaciones prácticas
Dividido en 8 módulos:
Introducción al proceso de scrum
El equipo y sus roles
Cultura del grupo
Historias de usuario
El proceso de scrum visto más en detalle
Rituales de Scrum
Mejora continua