el manifiesto y los principios ágiles

Click here to load reader

Upload: pablo-gil

Post on 13-Jun-2015

633 views

Category:

Documents


4 download

DESCRIPTION

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

TRANSCRIPT

  • 1. Una revolucin an en curso El manifiesto y los principios giles Pablo Gil [email protected] http://www.eldba.com

2. De qu vamos a hablar Motivos histricos 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 metodologas giles (scrum, xp, kanban) Software craftmanship Eficacia de las metodologas giles Algunos datos tiles (libros, links) Presentacin del curso de scrum 3. El desarrollo de software al inicio Hasta la adopcin de los microchips, el hardware existente y su alto costo limitaba las posibilidades ofrecidas a los programadores, por lo que la mayora era muy especializado y muchas veces trabajaban sin otro mtodo que el de codificar y corregir Pero hacia los aos 60 estas limitaciones desaparecieron, y se hizo necesario pensar a un proceso ms formal que evitara los problemas ms comunes del desarrollo: Imprecisin en la planificacin y estimacin de costos Baja calidad del software 4. Se intenta dar una solucin al caos Una nueva rama de la ciencia, denominada ingeniera del software comienza a estudiar e una implementar alguna metodologa que de alguna manera intentan controlar el caos. Estas metodologas estn caracterizadas por intentar controlar el caos definiendo en modo estricto las distintas etapas de desarrollo. Una de las metodologas que ms xito tuvo fue la waterfall (en cascada) que prevea distintas fases bien definidas, y donde para pasar a una fase sucesiva era necesario cumplir con condiciones bien definidas Ejemplos de estas metodologas hard son 5. Ventajas de la metodologa en cascada Es particularmente apropiado para proyectos estables o de alto riesgo y donde los requerimientos no se modifiquen con frecuencia Es simple y fcil de entender y de usar Es fcil de gestionar ya que cada fase tiene sus entregables bien definidos Las responsabilidades en cada fase estn bien Anlisis Diseo Codificacin 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 solucin: convivir con el caos Las metodologas 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 peridicas 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 ao 2001 en Utah por 17 personas, entre ellos estaban los creadores de metodologas hoy consideradas giles Ellos acordaron que si bien no compartan una metodologa nica, si lo hacan con cuatro valores: Definieron tambin 12 principios derivados de estos valores Terminan aclarando que: aunque valoramos los elementos de la derecha, valoramos ms los de la Valoramos sobre Individuos e interacciones procesos y herramientas Software funcionando documentacin exhaustiva Colaboracin con el cliente negociacin 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 tardas 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 ms 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 ejecucin del trabajo. 6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la conversacin 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 atencin continua a la excelencia tcnica y al buen diseo 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 diseos emergen de equipos auto-organizados. 12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia. 11. Los principios (final) Es evidente que es exigencia que los equipos giles tengan ciertas caractersticas para poder cumplir con el espritu del manifiesto, entre las que se mencionan: Coraje Auto-Gestin Visibilidad Feedback Colaboracin con el cliente Confianza Desarrollo sostenible Excelencia y calidad Simplicidad Adaptacin al cambio 12. En resumen, qu puede considerarse metodologa gil Inicialmente, se defini gil a una metodologa 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 Ms adelante, se ampli esta definicin : una metodologa gil enfatiza la colaboracin cercana entre un grupo de programadores y expertos en el negocio; comunicacin cara a cara; entrega frecuente de valor de negocio; grupos pequeos y autoorganizados y modos de manejar el cdigo 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 bsqueda del proceso de fabricacin 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 lnea de produccin cuando se detecta 14. Lean (final) Lean identifica 7 tipos bsicos de desperdicios (el ltimo se agreg ms tarde): Sobreproduccin 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 fabricacin de Toyota al desarrollo del software , adaptando los desperdicios al desarrollo del software: Defectos = bugs Espera y transporte = falta de automacin / testing manual Complejidad, Sobreproduccin: gold plating Esperas = meetings intiles Complejidad = complejidad tcnica / deuda tcnica 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 ms tarde posible Reaccionar tan pronto como sea posible Potenciar el equipo Crear la integridad Mirar todo el conjunto "Piensa en grande, acta en pequeo, equivcate rpido; aprende con rapidez 17. Agile y Lean son sinnimos? Si bien no son sinnimos, ambas de sustentan en los mismos principios. Podramos 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 fabricacin de Toyota ya se usaba desde haca varios aos 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 metodologas giles Scrum Kanban XP Cristal Clear () 19. Una metodologa gil: XP Fue creado por Ken Brent como resultado de un proyecto desarrollado para Chrysler XP fomenta los valores de comunicacin, simplicidad, retroalimentacin y coraje Es un conjunto de buenas prcticas que se potencian entre ellas. Brent pensaba en los principios y prcticas de XP como controles de un tablero de comando, y prob a ver qu suceda cuando pona todos estos controles al mximo La observacin interesante fue que algunas prcticas potenciaban a otras, por lo que ms 20. XP (2da parte) XP prev distintos roles: Programmer, es el responsable de disear y construir la solucin tcnica (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 cundo hacerlo. Es miembro del equipo Tester, asegura que se cumplan las pruebas de aceptacin y ayuda a disearlas Tracker, encargado de tomar mtricas del equipo para que este tenga datos para reflexionar Coach, es el responsable del proceso. 21. XP (final) Prcticas : juego de planificacin Programacin en parejas Metfora Entregas pequeas Propiedad colectiva Integracin continua Diseo simple Semanas de 40 horas Pruebas Cliente in situ Refactoring Estndares de programacin 22. Otra metodologa gil: Kanban Kanban es una implementacin de metodologa lean Se basa en tarjetas que identifican las distintas tareas que el grupo va tomando Esas tarjetas se van moviendo segn 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 ms miembros del equipo van tomando esas tareas y las van moviendo conforme va avanzando su cumplimiento 23. Kanban (final) 24. Otra metodologa gil: Scrum Scrum es un marco metodolgico que se adapta particularmente bien ya que es simple Su simplicidad al mismo tiempo permite la adopcin de todos los principios giles o hacer un mix de varias metodologas Supone un equipo formado por tres roles: Scrum master, encargado de facilitar el funcionamiento del equipo y de mantener la metodologa Product owner, que tiene la visin del negocio y decide qu porcin del sistema se desarrolla primero teniendo en cuenta el valor que otorga al negocio Equipo que disea y desarrolla el producto. 25. Scrum (2da parte) La metodologa reconoce tres etapas: Pre-juego Juego Post-juego El tiempo de desarrollo se divide en perodos de tiempo fijos (sprint) donde se planifica y estima lo que se realizar, se desarrollar, se demostrarn 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 cin 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 tambin 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. Cmo conviven Scrum, Kanban y XP en un mismo equipo? Scrum es un marco metodolgico que propicia agilidad, pero que por s mismo no lo asegura. Aplicar las prcticas XP ayudan a asegurar las prcticas giles al interno de los proyectos Scrum Adems, 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, interaccin con consultor externo, deteccin de nuevos impedimentos, etc) o si bien pueden ser previstos (como correccin de bugs crticos de releases anteriores) no pueden ser cuantificados y estimados durante el sprint planning. Para esto es 30. Ms 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 prcticas de estos profesionales para su dominio. Por ejemplo, la prctica del aprendista de un desarrollador con experiencia. Su lema es elevando el nivel (raising the bar) Proponen en su manifiesto (presentado en el ao 2008): Terminan agregando que Para lograr los items de la izquierda, consideramos que los item de la derecha son indispensables No solo sino tambin Individuos e interacciones Una comunidad de profesionales Software funcional Software bien hecho Colaboracin 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 cundo un proyecto funciona o no. Si pensamos que un proyecto tiene que ser ejecutado en el tiempo pactado, con los costos pactados y las caractersticas pactadas de antemano, entonces NO funcionar nunca, ya que por filosofa se aceptan los cambios propuestos por el cliente. Si en cambio se trata de establecer o mejorar una relacin de confianza con los desarrolladores y el cliente y dems 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 parmetros meritocrticos, la adopcin de agile procurar ms problemas que soluciones Como uno de los puntos primordiales del con metodologa 32. Son eficaces las metodologas giles ? Las metodologas giles son particularmente eficaces en aquellas realidades donde los requisitos cambian con frecuencia. Tambin son ptimas para realidades donde se requiere mucha creatividad. No menos importante, son eficaces donde los miembros del equipo y el cliente estn 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 caractersticas mencionadas: Agile security, Agile marketing, Agile Start-Up, Agile analytics, Agile 33. Algunos peligros al adoptar metodologas giles Las metodologas giles imponen un cambio de paradigma no solo en el modo de programar, sino tambin en el modo de entender la supervisin de los equipos Realizar implementaciones superficiales confundiendo metodologas y procesos giles con herramientas, certificaciones, etc Agile es bsicamente un paradigma mental y comportamental. Suponer que por la simple adopcin de una metodologa gil, las personas involucradas en los equipos cambiarn el propio modo de actuar, o que lo harn en modo ms profesional Intentar adoptar agile solo en pequeos 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 ms sobre Scrum Est programado un curso de Scrum, con ejemplos de potenciamiento con Kanban, XP y Lean El curso es terico con ejercitaciones prcticas Dividido en 8 mdulos: Introduccin al proceso de scrum El equipo y sus roles Cultura del grupo Historias de usuario El proceso de scrum visto ms en detalle Rituales de Scrum Mejora continua 38. Muchas gracias Pablo Gil [email protected] http://www.eldba.com