Your SlideShare is downloading. ×
El manifiesto y los principios ágiles
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

El manifiesto y los principios ágiles

570
views

Published on

Charla informativa en el club de programadores. …

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
570
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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