Your SlideShare is downloading. ×
0
Una revolución aún en curso
El manifiesto y los principios ágiles
Pablo Gil
pablo.a.gil@gmail.com
http://www.eldba.com
De qué vamos a hablar…
 Motivos históricos que llevaron a plantear una
nueva forma de trabajar
 El manifiesto ágil y sus...
El desarrollo de software “al inicio”
Hasta la adopción de los microchips, el hardware
existente y su alto costo limitaba ...
Se intenta dar una solución al caos
 Una nueva rama de la ciencia, denominada
“ingeniería del software” comienza a estudi...
Ventajas de la metodología “en
cascada”
 Es particularmente
apropiado para
proyectos estables o
de alto riesgo y
donde lo...
Pero se verifican nuevos problemas
 La realidad es que el mundo en
el que vivimos es
esencialmente variable.
 Son muy po...
La solución: convivir con el caos
 Las metodologías ágiles no intentan controlar el caos,
sino convivir con él
 Esto se ...
El manifiesto ágil
 Fue redactado en el año 2001 en Utah por 17
personas, entre ellos estaban los creadores de
metodologí...
Los 12 principios ágiles
1. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de so...
Los 12 principios (2da parte)
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promue...
Los principios (final)
Es evidente que es exigencia que los equipos ágiles
tengan ciertas características para poder cumpl...
En resumen, qué puede considerarse
“metodología ágil”
 Inicialmente, se definió “ágil” a una metodología
que propiciaba e...
¿ Y qué hay de Lean ?
 Lean deriva de la experiencia de Toyota en la
búsqueda del proceso de fabricación adecuado
 Se ba...
Lean (final)
 Lean identifica 7 tipos básicos de desperdicios (el
último se agregó más tarde):
 Sobreproducción
 Espera...
Lean Software Development
 Creado por el matrimonio Mary y Tom Poppendieck
 Adaptaron el proceso de fabricación de Toyot...
Lean Software Development (final)
 A partir de esto, desarrollaron 7 principios:
 Eliminar los desperdicios
 Ampliar el...
¿ Agile y Lean son sinónimos?
 Si bien no son sinónimos, ambas de sustentan en
los mismos principios. Podríamos decir que...
Algunas metodologías ágiles
Scrum
Kanban
XP
Cristal Clear
(…)
Una metodología ágil: XP
 Fue creado por Ken Brent como resultado de un
proyecto desarrollado para Chrysler
 XP fomenta ...
XP (2da parte)
 XP prevé distintos roles:
 Programmer, es el responsable de diseñar y construir la
solución técnica (no ...
XP (final)
 Prácticas
:
• juego de planificación
• Programación en parejas
• Metáfora
• Entregas pequeñas
• Propiedad col...
Otra metodología ágil: Kanban
 Kanban es una implementación de metodología
lean
 Se basa en tarjetas que identifican las...
Kanban (final)
Otra metodología ágil: Scrum
 Scrum es un marco metodológico que se adapta
particularmente bien ya que es simple
 Su sim...
Scrum (2da parte)
 La metodología
reconoce tres
etapas:
 Pre-juego
 Juego
 Post-juego
El tiempo de desarrollo se divid...
Scrum (3ra parte)
Product
Backlog
Sprint
planning
Sprint
Backlog
Sprint
review
Sprint
retrospective
Daily
meeting
SPRINT
Scrum (final)
Scrumban: Scrum + Kanban
 Es adecuado cuando los equipos no solo realizan
desarrollo sino también soporte
 Se adosan dos...
Cómo conviven Scrum, Kanban y XP
en un mismo equipo?
 Scrum es un marco metodológico que propicia
agilidad, pero que por ...
Más allá del manifiesto ágil:
Software Craftmanship
 Esencialmente reconocen que el trabajo del desarrollador es
comparab...
¿ Agile funciona realmente ?
 Antes de definir si funciona o no, es necesario saber cuándo
un proyecto funciona o no. Si ...
¿ Son eficaces las metodologías ágiles
?
 Las metodologías ágiles son particularmente eficaces
en aquellas realidades don...
Algunos peligros al adoptar
metodologías ágiles
 Las metodologías ágiles imponen un cambio de
paradigma no solo en el mod...
Algunos libros interesantes (y gratuitos)
sobre el tema
Algunos links útiles
Sitios sobre Agile:
 http://www.agilemanifesto.org
 http://manifesto.softwarecraftsmanship.org
 ht...
¿ Comentarios ?
¿ Consultas ?
Si quieren saber más sobre Scrum
 Está programado un curso de Scrum, con
ejemplos de potenciamiento con Kanban, XP y
Lean...
Muchas gracias
Pablo Gil
pablo.a.gil@gmail.com
http://www.eldba.com
Upcoming SlideShare
Loading in...5
×

El manifiesto y los principios ágiles

622

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
622
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "El manifiesto y los principios ágiles"

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. Algunas metodologías ágiles Scrum Kanban XP Cristal Clear (…)
  19. 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. 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. 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. 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. 23. Kanban (final)
  24. 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. 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. 26. Scrum (3ra parte) Product Backlog Sprint planning Sprint Backlog Sprint review Sprint retrospective Daily meeting SPRINT
  27. 27. Scrum (final)
  28. 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. 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. 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. 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. 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. 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. 34. Algunos libros interesantes (y gratuitos) sobre el tema
  35. 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. 36. ¿ Comentarios ? ¿ Consultas ?
  37. 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. 38. Muchas gracias Pablo Gil pablo.a.gil@gmail.com http://www.eldba.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×