Charla informativa en el club de programadores. Se privilegió una lenguaje llano.

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

18. Algunas metodologías ágiles
Scrum
Kanban
XP
Cristal Clear
(…)

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

23. Kanban (final)

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

26. Scrum (3ra parte)
Product
Backlog
Sprint
planning
Sprint
Backlog
Sprint
review
Sprint
retrospective
Daily
meeting
SPRINT

27. Scrum (final)

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

34. Algunos libros interesantes (y gratuitos)
sobre el tema

35. Algunos links útiles
Sitios sobre Agile:
 http://www.agilemanifesto.org
 http://manifesto.softwarecraftsmanship.org
 http://www.agilealliance.com
 http://www.scrumalliance.org
 http://www.agiles.org
Herramientas:
 http://www.trello.com
 http://www.atlassian.com/jira
 http://www.versionone.com

36. ¿ Comentarios ?
¿ Consultas ?

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

38. Muchas gracias
Pablo Gil
pablo.a.gil@gmail.com
http://www.eldba.com