Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Metodologías ágiles

670 views

Published on

Scrum, XP y Kanban desde un punto de vista práctico

Published in: Education
  • Be the first to comment

Metodologías ágiles

  1. 1. Metodologías Ágiles: Scrum y Kanban Óliver Centeno Álvarez [2012, Pronoide S.L.]
  2. 2. 2 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  3. 3. 3 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  4. 4. 4 ¿Por qué Métodos Ágiles?  Los Proyectos fallan  No se entregan a tiempo  No cumplen con los objetivos  Cuestan más de lo estimado  ¿De quién es la culpa?  Hay demasiada documentación  Hay muchos cambios  La tecnología no es adecuada  Los desarrolladores no son expertos  La metodología falla (carrera de relevos)  …
  5. 5. 5 Principio Básicos de los Proyectos  El Triángulo de Hierro  Coste  Tiempo  Alcance  Productividad  Calidad Coste TiempoAlcance Calidad y Productividad
  6. 6. 6 Principio Básicos de los Proyectos  El Software no son tuercas  El software es complejo  Siempre tendremos incertidumbre  Siempre tendremos cambios COMPLEJO inestables Req conocidos conocida Tecnología desc
  7. 7. 7 Principio Básicos de los Proyectos  La magia no existe  Productividad <> Más horas  Mejora continua (Ishikawa)  Mejora del proceso para ser más productivo  Luchar contra el cambio no es efectivo  Gestión del cambio  Burocracia  Burocracia  Insatisfacción  La incertidumbre disminuye con el tiempo  Decide en el último momento responsable
  8. 8. 8 Principio Básicos de los Proyectos  Realidad en los proyectos  31-24% se cancelan  53-44% son problemáticos  16-32% tienen éxito  Realidad en el software  64% funcionalidades no se utilizan  16% rara vez se utilizan  20% se utilizan  Gestión de proyecto inadecuada  Ignorar los principios
  9. 9. 9 ¿Por qué Métodos Ágiles?  Modelo de desarrollo en cascada (Métrica v3)  Realizar de manera exhaustiva: Análisis, Diseño, Implementación, Pruebas, Despliegue, Mantenimiento  ¿Qué valor aportan estos proyectos?  ¿En qué coste incurren?  Al 90% del proyecto el valor aportado puede ser casi nulo
  10. 10. 10 ¿Por qué Métodos Ágiles?  Modelo de desarrollo incremental (RUP)  Realizar entregas periódicas que aportan valor  Aportan valor desde la primera iteración  Y siguen aportándolo de manera periódica  Pero esto no es ágil…
  11. 11. 11 ¿Por qué Métodos Ágiles?  Modelo de desarrollo ágil  No solo realizar entregas periódicas  Sino priorizar las que aportan más valor  El valor aportado al principio es mayor  El valor aportado al final es menor
  12. 12. 12 ¿Por qué Métodos Ágiles?  Modelo de desarrollo ágil  Esto nos da la oportunidad de añadir más valor en subsiguientes iteraciones  Y así poder continuar con el proyecto
  13. 13. 13 ¿Cómo transmito esto a mi cliente?  Dilema del Prisionero (J. Forbes Nash)  Teoría de Juegos
  14. 14. 14 ¿Cómo transmito esto a mi cliente?  Cuadrante de la Estupidez (C.M. Cipolla) Proveedor Cliente
  15. 15. 15 ¿Cómo transmito esto a mi cliente?  Compromiso Ágil  Colaboración con el cliente, CONFIANZA  Entregas progresivas (iterativo e incremental)  Evitar el oportunismo  Riesgo y beneficio compartidos  Participación del cliente en el alcance  Min = Estimación + factor foco (reuniones, plan,…)  Target = Min + buffer (10%-30% según cliente)  Max = Target + beneficios esperado Target MaxMin Beneficio Compartido Coste Compartido
  16. 16. 17 ¿Cómo transmito esto a mi cliente?  ¿Y los cambios?  Los errores/bugs los asume el proveedor  Las aclaraciones dependen del cliente  Razonable: se puede asumir  Conflictivo: …  Los añadidos los asume el cliente  Reestimación  Mantenimiento <> Evolutivo
  17. 17. 18 En Resumen…  Los métodos ágiles buscan aportar el mayor valor posible lo antes posible  Dejando abierta la posibilidad de aumentar el valor  Como efecto colateral permiten adaptarse a los cambios  Y responder al feedback del cliente  La cancelación del proyecto sigue aportando valor  Es especialmente útil en proyectos con una duración y/o un coste fijos que buscan aportar el máximo valor  No funcionan tan bien cuando se quiere seguir un plan
  18. 18. 19 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  19. 19. 20 Manifiesto Ágil  2001, Kent Beck et. Al. “Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan ”
  20. 20. 21 Manifiesto Ágil  Valorar más:  Individuos y su interacción  Software que funciona  Colaborar con el cliente  Respuesta al cambio  Por encima de:  Procesos y herramientas  Documentación  Ceñirse a contratos  Seguir un plan
  21. 21. 22 Manifiesto Ágil  Individuos y su interacción  Los procesos ayudan al trabajo  Las herramientas mejoran la eficiencia  Pero sin personas con conocimientos y actitud adecuados no se consiguen resultados  Software que funciona  Es difícil tener un documento con todos los requisitos al inicio del proyecto  Los prototipos generan un feedback enriquecedor  El exceso de documentación genera mucho trabajo que no aporta valor directo al producto
  22. 22. 23 Manifiesto Ágil  Colaborar con el Cliente  Las necesidades del cliente cambian  Un contrato no aporta valor al producto  El cliente debe ser un miembro más del equipo que colabora en el equipo de trabajo  Respuesta al Cambio  Los proyectos tienen cambios  Asegurar un plan es difícil  Anticipación y adaptación al cambio
  23. 23. 24 ¿Qué son todos esos conceptos?  Desarrollo Lean y Ágil  Frameworks y principios que usamos como guías  Scrum  Cómo aplicar las prácticas ágiles  XP  Prácticas específicas de desarrollo y pruebas Lean Ágil Scrum XP
  24. 24. 25 Principios de Lean (Toyota)  Eliminar los desperdicios  Fomentar el aprendizaje  Decidir lo más tarde posible  Reaccionar lo más rápido posible  Potenciar el equipo  Conseguir la integridad  Ver todo como un conjunto
  25. 25. 26 Principios del Agilismo  Satisfacer al cliente mediante entregas tempranas y continuas de software de valor  Doblegarse a los requisitos cambiantes  Trabajo conjunto de personas de negocio y desarrolladores  Mantener la motivación de los individuos  Aportarles los entornos y apoyo que necesiten  Confiar en su capacidad
  26. 26. 27 Principios del Agilismo  Comunicar la información cara a cara  Utilizar el software que funciona como medida de progreso  Mantener un ritmo constante de trabajo  Simplicidad y excelencia técnica  Equipos auto-organizados  Auto-reflexión periódica del equipo para ser más efectivos
  27. 27. 28 Métodos Ágiles Metodología Acrónimo Creación Tipo de modelo Característica Adaptive Software Development ASD Highsmith 2000 Prácticas + Ciclo de vida Inspirado en sistemas adaptativos complejos Crystal Methods CM Cockburn 1998 “Familia de metodologías” MA con énfasis en modelo de ciclos Dynamic Solutions Delivery Model DSDM Stapleton 1997 Framework / Modelo de ciclo de vida Creado por 16 expertos en RAD Evolutionary Project Management Evo Gilb 1976 Framework adaptativo Primer método ágil existente Extreme Programming XP Beck 1999 “Disciplina en prácticas de ingeniería” Método ágil radical Feature-driven development FDD De Luca & Coad 1998 Palmer & Felsing 2002 “Metodología” Método ágil de diseño y construcción Lean Development LD Charette 2001, Mary y Tom Poppendieck “Forma de pensar” – Modelo logístico Metodología basada en procesos productivos Microsoft Solutions Framework MSF Microsoft 1994 Lineamientos, Disciplinas, Prácticas Framework de desarrollo de soluciones Scrum Scrum Takeuchi 1986 - Schwaber 1995 “Proceso” (framework de management) Complemento de otros métodos, ágiles o no
  28. 28. 29 Actividades y Fases de Proyecto  Todo proyecto incurre en una serie de actividades  Toma de requisitos  Diseño Arquitectónico  Construcción  Pruebas de Integración (internas)  Pruebas de Sistema (externas)  Estas actividades se realizan (o no) en fases  Modelo de Ciclo de Vida  Cómo se secuencian y particionan estas actividades  Es determinante para que una metodología funcione
  29. 29. 30 ¿Por qué ese interés?  ¿Qué es mejor?  Modelo puramente secuencial (Cascada)  Implica realizar todas las pruebas al final  Y éstas derivan en cambios y agujeros en los requisitos  Además, seguramente impliquen cambios de diseño  Modelo puramente iterativo (XP)  XP Implica centrarse en la construcción  Se pierden de vista los requisitos y el diseño  Al final se acumulan los requisitos cambiantes 100% Requisitos 100% Diseño 100% Construcción 100% Test
  30. 30. 31 ¿Por qué ese interés?  Las prácticas ágiles sólo son efectivas si el modelo de ciclo de vida es adecuado  El modelo de ciclo de vida es el atributo definitorio de un Método Ágil  Indica si un método es o no es Ágil  Se pueden hacer mucha o pocas iteraciones  Con mucha o poca dedicación a cada actividad
  31. 31. 32 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  32. 32. 33 Historias de Usuario  Característica escrita en una o dos frases utilizando el lenguaje común del usuario  Como {rol}  quiero {algo}  para obtener {valor de negocio}  Forma rápida de administrar los requisitos sin gran cantidad de documentos formales  Debe ser limitada, escribible sobre un post-it  Duración estimada: 10 horas - 2 semanas
  33. 33. 34 Historias de Usuario  Tiene asociada una prioridad  Tiene asociadas unas pruebas de validación  No es una especificación rigurosa sino un comienzo  No es una tarea  Cada historia es, en principio, independiente  Las historias SON negociables  Las historias son valiosas
  34. 34. 35 Historias de Usuario  Las historias son estimables  Días ideales  Puntos de historia  Triangulación  Deben ser pequeñas y fáciles de entender  Deben poder probarse para asegurar que han finalizado  Pruebas unitarias  Criterio de aceptación  Prototipos
  35. 35. 36 Historias de Usuario  Beneficios  Representan requisitos que pueden implementarse rápidamente (días o semanas)  Necesitan poco mantenimiento  Mantienen una relación cercana con el cliente  Permite dividir los proyectos en pequeñas entregas  Permite estimar fácilmente el esfuerzo de desarrollo  Ideal para proyectos con requerimientos no muy claros
  36. 36. 37 Historias de Usuario  Limitaciones  Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contrato  Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso  Podría resultar difícil escalar a proyectos grandes  Requiere desarrolladores muy competentes  Requieren saber cuando se puede considerar hecha
  37. 37. 38 Historias de Usuario  Ejercicio A  Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca. El sistema debe admitir el alta y la baja de socios y de libros. Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. Cuando llega a cero el socio se dé de baja automáticamente.
  38. 38. 39 Historias de Usuario  Ejercicio B  Se quiere desarrollar un simulador de Mus para jugar online.  Ejercicio C  Se quiere desarrollar un simulador del juego de cartas Bang! de Emiliano Sciarra.  Instrucciones
  39. 39. 40 Historias de Usuario  Ejercicio A  Alta libro  Baja libro  Alta socio  Baja socio  Préstamo de libro  Devolver libro  Penalizar socio  Baja automática de socio  Iniciar sesión en el sistema  Cerrar sesión  Alta usuario  Baja usuario
  40. 40. 41 Planning Poker  Estimación de tareas por consenso  Utilizando cartas con valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?,  No tiene unidades, el objetivo no es dar un valor  Se explica la característica a estimar y todos votan excepto un moderador  Los votos más extremos deben explicarse  Se repite la votación hasta el consenso  Evita el poder de alguien influyente  Incluye el punto de vista del cliente
  41. 41. 42 Planning Poker
  42. 42. 43 Planning Poker  Ejercicio A  Estimar cada una de las historias detectadas en el ejercicio anterior  Ejercicio B: Estimar  Como usuario quiero poder ver los productos disponibles para comprar ordenados por precio y/o tipo de artículo para encontrar lo que busco más rápido.  Como usuario quiero poder ver los detalles de mi pedido para saber en qué estado se encuentra y si todavía estoy a tiempo de modificarlo.
  43. 43. 44 Planning Poker  Ejercicio C: Estimar  Como usuario quiero poder pagar con tarjeta o mediante Pay-Pall para tener distintas alternativas en caso de no tener el número de tarjeta a mano.  Como usuario quiero poder acceder a la aplicación desde mi móvil para poder utilizarla en cualquier parte.  Como usuario quiero poder imprimir documentos para poder llevármelos conmigo.  Como usuario quiero poder ver la fecha y hora actuales para no tener que salir de la aplicación para ello.
  44. 44. 45 TDD  Test Driven Development  Desarrollo Dirigido por Ejemplos  Diseño e implementación de las pruebas antes de programar la funcionalidad  Pilares fundamentales:  Implementar justo lo que necesita el usuario  Y no más  Minimizar el número de defectos a producción  Crear SW muy modular y reutilizable
  45. 45. 46 TDD  Test Driven Development  No se trata de crear pruebas a granel  Sino diseñarlas en función de los requisitos  No implementar tareas  Pensar en ejemplos sin ambigüedad  La arquitectura emergerá de los ejemplos
  46. 46. 47 TDD  Un test NO se realiza para comprobar que un sistema no tiene errores, NI para demostrar que funciona  Un test se realiza para encontrar fallos (decisión fuerte)  Se pueden probar las distintas fases de desarrollo  Modelo en V
  47. 47. 48 TDD  Tipos de Test
  48. 48. 49 TDD  ¿Cómo es un Test?  Supongamos un sistema de gestión documental public class Test{ public void testDocument() { Document d = new Document("a", "t", "y"); assertEquals("a", d.getAuthor()); assertEquals("t", d.getTitle()); assertEquals("y", d.getYear()); } }
  49. 49. 50 TDD  Aserciones  Condiciones que deben darse para validar un test  assertTrue("mensaje", condición)  assertFalse("mensaje", condición)  assertSame(objeto, objeto)  assertNotSame(objeto, objeto)  assertNull(objeto)  assertNotNull(objeto)  assertEquals(variable, variable)
  50. 50. 51 TDD  Fases de un test (rojo, verde, refactorizar) 1. Escribir el test 2. Compilarlo 3. Implementar lo justo para que compile 4. Ejecutarlo y comprobar que falla 5. Implementar lo justo para que pase 6. Ejecutarlo y comprobar que no falla 7. Refactorizar para simplificar y eliminar duplicados 8. Repetir
  51. 51. 52 TDD  Ejemplo  Programar una función de búsqueda public void testResultadosVacios() { Buscador b = new Buscador(); Resultado r = b.buscar("algo"); assertEquals(0, r.getNumResultados(); }
  52. 52. 53 TDD  Test Driven Development  Para que compile creo un stub de búsqueda public class Buscador{ public Buscador() {} Resultado buscar(String q) {return null;} }  El test compila pero falla, cambiamos: Resultado buscar(String q) {return new Resultado();}
  53. 53. 54 TDD  Test Driven Development  ¿Qué haríamos ahora?  Probar que se encuentra 1 elemento  ¿Cómo lo haríamos?  Un nuevo test  Un aserto encontrando un elemento  Un aserto no encontrando el elemento  ¿Algo más?  Modificar el buscador para que el test pase
  54. 54. 55 TDD  Trucos y consejos  Programar como si las clases y los métodos ya existieran  Y refactorizar para que se generen automáticamente  Una vez implementado extraer las interfaces de programación public interface Buscador{ Resultado buscar(String q); } public interface Resultado{ public int getNumResultados(); }
  55. 55. 56 TDD  Spikes  Pequeño programa para explorar la funcionalidad de una librería desconocida  A partir de él podemos crear tests  Mock  Clase que sustituye una parte del sistema  Para centrar el test en lo que vamos a probar  Ej: Mock que simula una BD que no existe
  56. 56. 57 TDD  Frameworks de pruebas  JUnit  NUnit  DBUnit  Carga datos para un único test  Pero no permite restaurar  Hay que eliminar los datos anteriores  HttpUnit  Simula un navegador accediendo al servidor  Permite acceder a enlaces, tablas, formularios,…
  57. 57. 58 TDD  Frameworks de pruebas  Selenium IDE  Plugin de pruebas de sistema para Firefox  CubicTest para Eclipse  JMeter  Lanza pruebas de stress contra servidor  Simulando múltiples usuarios concurrentes  Genera informes y gráficos  Mockito  Librería Java para crear Mocks
  58. 58. 59 ATDD  Tests de Aceptación  Afirmaciones en leguaje humano (ejemplos)  ATDD es TDD enfocado a estos ejemplos  Conexión perfecta entre Scrum y XP  Se describen los ejemplos de cada historia con el cliente  Cada historia provoca preguntas  Las respuestas son ejemplos  Que se convierten en tests de aceptación
  59. 59. 60 ATDD  Tests de Aceptación  Pueden ser funcionales o no funcionales (tiempo de respuesta, capacidad de carga,…)  Los detecta el analista  Machacando al cliente hasta que dice “pero, ¿esto realmente importa?”  Así comienzan a involucrarse
  60. 60. 61 ATDD  Ejemplos  Cuando el libro X se añade al carrito, el sistema devuelve un mensaje que dice: ‘‘El libro X ha sido añadido al carrito’’  Al mostrar el contenido del carrito aparece el libro X  El libro X ya no aparece entre los libros a añadir al carrito  Al introducir la fecha y hacer click en el botón de añadir, se crea un nuevo registro vacío
  61. 61. 62 ATDD  Frameworks ATDD  Concordion  FitNesse  Robot  Cucumber
  62. 62. 63 ATDD  Ejercicio: Formular criterios de aceptación  Quiero lanzar al mercado un software educativo para enseñar matemáticas a niños.  Necesito que puedan jugar o practicar a través de una página Web pero también a través del teléfono móvil y quizás más adelante también en la consola Xbox.  El sistema debe recordar a cada niño, que tendrá un nombre de usuario y una clave de acceso.  El sistema registrará todos los ejercicios que han sido completados y la puntuación obtenida para permitirles subir de nivel si progresan.  Existirá un usuario tutor que se registra a la vez que el niño y que tiene la posibilidad de acceder al sistema y ver estadísticas de juego del niño.  El tema más importante ahora mismo es la aritmética básica con números enteros.
  63. 63. 64 ATDD  Ejercicio: Formular criterios de aceptación  "2 + 2", devuelve 4  "5 + 4 * 2 / 2", devuelve 9  "3 / 2", produce el mensaje ERROR  "* * 4 - 2": produce el mensaje ERROR  "* 4 5 - 2": produce el mensaje ERROR  "* 4 5 - 2 -": produce el mensaje ERROR  "*45-2-": produce el mensaje ERROR  ¿Puede ser negativo el resultado de una resta en nuestra calculadora?  ¿Cual es el número más grande que se permite?
  64. 64. 65 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  65. 65. 66 Scrum “El factor más importante en el desarrollo de software no son las técnicas y las herramientas que emplean los programadores, sino la calidad de los propios programadores” Robert L. Glass “Estimo que el 75% de las organizaciones que utilizan Scrum no van a obtener los beneficios que esperan” Ken Schwaber Scrum y XP desde las Trincheras Henrik Kniberg
  66. 66. 67 Scrum
  67. 67. 68 Scrum  No es un método independiente, sino complemento de otras metodologías (XP, MSF, RUP)  Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrollo  Equipos auto-dirigidos y auto-organizados  No hay un Jefe de Proyecto que decida, solo “miembros del equipo” o “cerdos”  Excepción: el Scrum Master que debe ser 50% programador y que resuelve problemas, pero no manda  Los observadores externos se llaman “gallinas”; pueden observar, pero no interferir ni opinar
  68. 68. 69 Categorías en Scrum  Primero una historia: Una gallina y un cerdo pasean por la carretera cuando la gallina le dice al cerdo: “¿Qué te parece si abrimos un restaurante?”, a lo que el cerdo le pregunta: “¿y cómo se llamaría?” La gallina le contesta: “Huevos con jamón” y el cerdo le replica: “No estoy de acuerdo, porque en este negocio yo estaría comprometido, mientras que tu sólo estarías implicada”
  69. 69. 70 Categorías en Scrum  ¿Qué queremos decir?  Quienes tienen la responsabilidad también tienen la autoridad necesaria para poder lograr el éxito  Para que quienes no la tienen no puedan producir interferencias innecesarias
  70. 70. 71 Roles en Scrum (Cerdos)  Dueño del Producto  Product Owner  Determina qué es importante para el proyecto  Determina la dirección en que evoluciona el producto  Equipo Scrum  Analista, Desarrollador, Tester,…  Proactivos, multifuncionales, autoorganizados, <10 por equipo
  71. 71. 72 Roles en Scrum (Cerdos)  Scrum Master  Debe asegurar que el proyecto progresa con suavidad  Y que el equipo tiene lo que necesita para tener éxito  Establece reuniones  Resuelve problemas  Monitoriza el progreso del proyecto
  72. 72. 73 Roles en Scrum (Gallinas)  Usuarios finales  Marketing  Áreas comerciales  Áreas contables  Administradores  Etc
  73. 73. 74 Ciclo de Scrum
  74. 74. 75 Sprint  Iteraciones de 15-30 días (~3 semanas)  Demostración a participantes externos al final de cada iteración en una fecha indicada  Al principio de cada iteración, plantear una Meta expresada en términos de negocio  Planificación del Sprint entre todos con una agenda acotada (no alargar reuniones!!)  Se selecciona una Pila de Sprint  Historias que se van a incluir en el Sprint
  75. 75. 76 Pila de Producto (Product Backlog)  Lista priorizada de requisitos/historias  Nombre, importancia, estimación, cómo probarlo,…  Puntos de historia: días/persona ideales para completar la historia
  76. 76. 77 Pila de Sprint (Sprint Backlog)  Historias ordenadas por importancia de la pila de producto que se van a implementar  Tener en cuenta la velocidad del equipo
  77. 77. 78 Ciclo de Scrum
  78. 78. 79 División de las historias  Al equipo le interesan tareas pequeñas  Una historia se descompone en tareas  No son entregables, el cliente no se preocupa  Pizarra/Tablón y post-its
  79. 79. 80 Scrum Diario (Daily Standup)
  80. 80. 81 Cambios durante el Sprint  Durante un Sprint no se puede modificar el contenidos de la pila  El cliente puede cambiar una historia en las reuniones mensuales (cambiando el alcance y/o prioridad de una historia, o dividiéndola)  Sólo el Scrum Master puede abortarlo  Si la tecnología seleccionada no funciona  Si las circunstancias del negocio han cambiado  Si el equipo ha tenido interferencias
  81. 81. 82 Alarmas  Tareas terminadas de baja prioridad  Exceso de tareas no planificadas
  82. 82. 83 Ciclo de Scrum
  83. 83. 84 Al final de un Sprint…  Hacer una demo para:  Obtener reconocimiento para el equipo  Que todos sepan lo que se está haciendo  Obtener un feedback de los interesados  Permite interactuar con otros equipos  Fuerza a que realmente se terminen las cosas  Auque haya poco y el resultado sea malo que enseñar se motiva al equipo para que la próxima demo sea mejor
  84. 84. 85 Al final de un Sprint…  En la demo, centrarse en:  Presentar claramente el objetivo del Sprint  No hacer florituras (PPT, detalles de implementación,…)  Mantener un ritmo rápido  Mantenerse a nivel de negocio, sin detalles técnicos  Hacer una retrospectiva para ver  Cosas bien hechas  Cosas mejorables  Ideas de mejora para el futuro
  85. 85. 86 Ejercicio 1: Doggy Day Care  Product Backlog:  Crear carátulas, la marca y/o logotipo  Definir las principales secciones de atención  Describir requisitos mínimos (vacunas, temperamento, etc)  Establecer la estructura de precios para los servicios  Proporcionar testimonios de clientes satisfechos  Crear perfiles de personal (antecedentes, formación, intereses)  Definir las ofertas de servicios  Completar una póliza de garantía  Definir un servicio "Ultra Perrito Spa"  Definir servicios con descuento para socios  Esquema el menú de la semana
  86. 86. 87 Ejercicio 2: Turismo Marciano  Product Backlog:  Crear carátulas, la marca y/o logotipo  Definir las claves más importantes para el turismo marciano  Describir un tour por el "Arte por Europa"  Describir un tour por los "Deportes Humanos"  Esquema de mensajes de advertencia (gravedad, oxígeno, bacterias, hongos, etc)  Explicar las opciones de viaje a/desde Marte  Establecer precios de los tours  Expedición a las "7 maravillas del mundo"  Proponer opciones de ropa
  87. 87. 88 Ejercicio 3: Wedding Planner  Product Backlog:  Crear carátulas, la marca y/o logotipo  Definir las principales ofertas de servicio  Determinar el formato para el diseño de un folleto  Incluir servicios para personas fuera de la ciudad  Proporcionar referencias de clientes satisfechos  Lista de recomendaciones para la recepción/localización  Reunir los nombres de posibles proveedores de servicios  Definir tratamientos especiales fiesta nupcial  Establecer la estructura de precios  Definir opciones de música  Lista de opciones de catering y precios  Definir los temas personalizados de la boda
  88. 88. 89 Ciclo de Scrum
  89. 89. 90 ¿Cómo funciona el equipo?  Las métricas y medidas proporcionan una indicación de dónde se puede mejorar  Hay medidas informativas y motivacionales  Las informativas pueden ayudar a mejorar los procesos y a ser más efectivo y coordinado  En los Métodos Ágiles interesan las informativas  ¿Cómo las tomamos? Preguntado al equipo  ¿Cuándo las tomamos?  En el Scrum diario  Medidas de coordinación  En la retrospectiva  Medidas de proceso
  90. 90. 91 Diagrama Burndown  Ver el progreso de tareas completadas en un Sprint  ¿Se van a conseguir los objetivos del Sprint?  Por encima de la diagonal  Exceso de historias  Por debajo de la diagonal  Pocas historias
  91. 91. 92 Diagrama Burndown  Inicializarlo en la planificación del Sprint  Marcando en eje X el Nº de días  Y en el eje Y el Nº de horas de trabajo estimadas  Marcar la tendencia ideal  Si el ritmo de trabajo fuera constante  Actualiza el valor diariamente  ¿Qué hiciste ayer? ¿Qué harás hoy? ¿Qué problemas tienes? 110- 100- 90- 80- 70- 60- 50- 40- 30- 20- 10- 0- ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ 1 2 3 4 5 6 7 8 9 10 11
  92. 92. 93 Diagrama Burndown  Diariamente se monitoriza  Mirando las tareas pendientes  Seleccionando las mejores tareas para no desviarnos del ideal  Cono de +/- 20%  Si nos salimos del cono por debajo  Añadir nuevas historias de la pila  Porque somos así de buenos!   Si ocurre a menudo hay que mejorar las predicciones  Si nos salimos del cono por encima  Eliminar impedimentos  Hacer las cosas de otro modo  Reducir el alcance 110- 100- 90- 80- 70- 60- 50- 40- 30- 20- 10- 0- ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ 1 2 3 4 5 6 7 8 9 10 11
  93. 93. 94 Diagrama Burndown  NO OCULTAR EL DIAGRAMA  Es una medida del progreso del proyecto y es importante que el equipo y cualquiera que le interese pueda verlo  ACTUALIZARLO A DIARIO  Si no se actualiza a diario surgen tendencias horizontales que nada tienen que ver con la realidad  NO TENER EXCESO DE ESPECIALIZACIÓN  El equipo podría elegir sólo las tareas que le interesa a cada individuo y dejar las “aburridas” sin hacer  UTILIZAR EL DIAGRAMA PARA CORREGIR  Si la tendencia no es buena tomar medidas cuanto antes
  94. 94. 95 Diagrama Burnup  Representa las historias de usuario completadas  Estimadas mediante puntos de historia  Para un Sprint concreto  Pero sólo cuentan las historias completas (hecho-hecho)  Hecho-Hecho  Se ha construido de manera adecuada  Se ha construido el módulo adecuado  Análisis, diseño, codificación, pruebas y aceptación  Criterio de Aceptación
  95. 95. 96 Diagrama Burnup  Inicializarlo en planificación del Sprint  Marcando en el eje X el Nº de días  Y en el eje Y el Nº de puntos de historia comprometidos  Diariamente  Marcar las historias hechas-hechas  Esto impone un énfasis en terminar las historias  Las historias sin completar no aportan valor  No importa el trabajo “en progreso”  Importa el feedback temprano 50- 45- 40- 35- 30- 25- 20- 15- 10- 5- 0- ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ 1 2 3 4 5 6 7 8 9 10 11
  96. 96. 97 Diagrama Burnup  NO DESESTIMAR EL DIAGRAMA BURNDOWN  El diagrama de Burndown refleja el progreso del equipo  El diagrama de Burnup refleja qué tal lo están haciendo  REALIZAR LAS PRUEBAS DE ACEPTACIÓN  Si no se acepta, una historia no está hecha-hecha y no se puede añadir al diagrama y pasará al siguiente Sprint  UTILIZARLO PARA OBTENER FEEDBACK  De manera continua y temprana  Centrándonos en aportar valor de negocio
  97. 97. 98 Velocidad del Equipo  Medida de la cantidad de trabajo que puede realizar el equipo en un Sprint  Medido en cada Sprint  Para mantener un histórico  Basado en el trabajo real que han completado  Importan los resultados, no el esfuerzo  Hecho-hecho
  98. 98. 99 Velocidad del Equipo  Es una base para la planificación de tiempos  Varía al cambiar miembros del equipo  … y cuando hay vacaciones  … y al aumentar la experiencia del equipo  … y cuando se presentan problemas o impedimentos  …  Permite estimar qué hará el equipo en sucesivos Sprints
  99. 99. 100 Velocidad del Equipo  Estimar la Pila de Producto  Extraer las historias a comprometernos para el Sprint  Ejecutar el Sprint y calcular la velocidad  No se consideran las historias no terminadas Velocidad real = 18
  100. 100. 101 Estimación de la Velocidad  Opción 1: El tiempo que hizo ayer  Nos comprometemos a realizar tanto trabajo como el que completamos en el/los último/s Sprint  Sólo sirve con equipos experimentados  No sirve cuando el equipo cambia o hay vacaciones  Opción 2: Cálculo de recursos  Calcular la disponibilidad del equipo los días de Sprint  Considerar el factor de dedicación del equipo pasado Velocidad = [d/h disponibles] * [Factor de dedicación]
  101. 101. 102 Seguimiento de la Velocidad  La velocidad debería ser constante  Si varía mucho algo están haciendo mal  En los Sprints 3 y 4 es posible que estén pasando por alto algunas pruebas y el sistema puede volverse inestable  Por eso en los Sprints 5 a 8 la velocidad ha bajado 0 5 10 15 20 25 30 35 1 2 3 4 5 6 7 8 Velocidad
  102. 102. 103 En Resumen…  Divide tu organización en equipo pequeños  Inter disciplinares y autoorganizados  Divide el trabajo en una lista de entregables  Pequeños y priorizados  Divide el tiempo en iteraciones cortas  Con entregables visibles y testados  Optimiza tus procesos
  103. 103. 104 En Resumen…  El gráfico de Burndown muestra el esfuerzo pendiente en el Sprint actual  El gráfico de Burnup muestra la cantidad de software completo que se puede entregar  La velocidad registra el histórico de software completado por el equipo
  104. 104. 105 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  105. 105. 106 Kanban Taiichi Ohno
  106. 106. 107 Kanban  ¿Por qué Kanban?  Scrum no sirve siempre  Hay entornos con demasiados cambios  El equipo no se puede comprometer a un Sprint  Problema de las tareas urgentes  Que surgen cada día  Y duran más de una jornada  No hay Sprint suficientemente pequeño  Eliminar los Sprints y aplicar Kanban
  107. 107. 108 Kanban “El principio de Kanban es que comienzas con lo que sea que estés haciendo, comprendes tu proceso … y acuerdas los límites de trabajo … a continuación comienzas a hacer fluir el trabajo … Kanban proporciona transparencia al proceso y su flujo” David Anderson Kanban y Scrum – Obteniendo lo Mejor de Ambos Henrik Kniberg http://virtualkanban.net/
  108. 108. 109 Kanban  "Tarjeta visual"  Fabricación de productos en la cantidad y tiempo necesarios (Toyota 1940's)  WIP  Work In Progress  Empezar algo nuevo sólo cuando el trabajo anterior haya finalizado  NO es Desarrollo de Software  NO es Gestión de Proyectos  Es Gestión Evolutiva del Cambio
  109. 109. 110 Kanban  ¿Qué es Kanban?  Aproximación a la gestión evolutiva e incremental de los cambios en procesos y sistemas  Limitando la cantidad de trabajo en curso (WIP)  Busca optimizar el proceso y terminar las tareas
  110. 110. 111 Kanban  ¿En qué se parece/diferencia de Scrum?  Ambos son herramientas de proceso  No son completas ni sirven para todo  Ambos debo adaptarlos a mi equipo  Scrum es más prescriptivo  Kanban es más adaptativo  Kanban tiene menos reglas (Haz lo que sea)
  111. 111. 112 Kanban  ¿En qué se parece/diferencia de Scrum?  Kanban no habla de roles  Kanban no habla de iteraciones  Se pueden mezclar planificaciones y entregas  Kanban limita el número de tareas WIP  Máximo 2 tareas en curso y 5 pendientes  Scrum limita las tareas por velocidad de equipo  Ambos practican el "menos es más"  Menos estados en las tareas  Simplicidad en las soluciones (KISS, YAGNI)
  112. 112. 113 Kanban  ¿En qué se parece/diferencia de Scrum?  En Scrum restringe cambios durante un Sprint  Kanban permite sustituir un cambio por otra tarea  En Kanban no hay restricciones del equipo  Kanban no tiene técnicas de estimación  Ambos admiten proyectos simultáneos  Ambos son sistemas de planificación tipo "pull"  Kanban no tiene Pila de Producto  El equipo decide qué tarea completar
  113. 113. 114 Kanban  ¿En qué se parece/diferencia de Scrum?  Ambos son empíricos  Hay que experimentar para optimizarlos  ¿Qué máximo de tareas en curso ponemos?  Ambos tienen ciclos de feedback  Retrospectivas Scrum  Cuellos de botella y lead time Kanban  Kanban tiene tiempos de respuesta menores  No hay que esperar al siguiente Sprint  Kanban admite interacción fuera del equipo
  114. 114. 115 Kanban  ¿En qué se parece/diferencia de Scrum?  Tablero Scrum
  115. 115. 116 Kanban  ¿En qué se parece/diferencia de Scrum?  Tablero Kanban
  116. 116. 117 Kanban  Principios Kanban 1. Empieza haciendo lo que haces ahora  NO es un proceso nuevo, no hay que cambiar 2. Acepta cambios incrementales y evolutivos  Es una buena forma de mejorar el sistema 3. Respeta roles, responsabilidades y procesos  Es importante que no se vea como una amenaza 4. Fomenta el liderazgo en todos los niveles  Es importante que la organización esté alineada
  117. 117. 118 Kanban  Cultura Kaizen  "Mejora continua"  El equipo tiene poder, se potencia al equipo  El individuo actúa, detecta problemas y propone e implementa soluciones  Elige sus tareas voluntariamente, se autoorganiza  La rama de gestión tolera los fallos  Si el objetivo era mejorar el proceso/rendimiento  Se respeta a los individuos y sus aportaciones  Reduce desperdicios y costes de coordinación
  118. 118. 119 Kanban  Cultura Kaizen  Adoptar una metodología ágil exige un cambio en la cultura de la organización  Se vuelve más flexible a los cambios  Kanban se centra en optimizar lo que ya existe  En lugar de cambiarlo todo  A largo plazo mejora la madurez, capacidad y cultura de la empresa
  119. 119. 120 Kanban  Prácticas Clave en Kanban 1. Visualizar el flujo de trabajo (real)  Para que sea más entendible  Generando el Tablón Kanban a partir del workflow 2. Limitar el WIP  Implementando un sistema pull  Que guía el proceso de desarrollo 3. Gestiona el proceso (flow)  Monitorizar los estados del trabajo  Evaluar el efecto de los cambios en el sistema
  120. 120. 121 Kanban  Prácticas Clave en Kanban 4. Explicitar las políticas de proceso  Para evaluar los posibles problemas  De manera objetiva y consensuable 5. Implementar ciclos de feedback  Revisar el flujo de trabajo y distintas métricas  Buscando cambios evolutivos 6. Usar modelos para detectar oportunidades  Mejorar en colaboración  Evolucionar por experimentación
  121. 121. 122 Kanban Taiichi Ohno
  122. 122. 123 Kanban  ¿Cómo implementar Kanban?  Modelar el flujo de trabajo  Buffers entre los procesos
  123. 123. 124 Kanban  ¿Cómo implementar Kanban?  Tablón Kanban (card wall)
  124. 124. 125 Kanban  ¿Cómo implementar Kanban?  Límites WIP
  125. 125. 126 Kanban  ¿Cómo implementar Kanban?  Límites de capacidad de servicio
  126. 126. 127 Kanban  ¿Cómo implementar Kanban?  Relación entre equipos
  127. 127. 128 Kanban  ¿Cómo implementar Kanban?  Cadencias: Forma en la que organizamos nuestros ciclos de trabajo
  128. 128. 129 Kanban  Un ejemplo  Visualizar el Workflow
  129. 129. 130 Kanban  Un ejemplo  Detectar problemas
  130. 130. 131 Kanban  Un ejemplo  Limitar el WIP
  131. 131. 132 Kanban  Un ejemplo  Mejorar el proceso
  132. 132. 133 Kanban  Un ejemplo  Mejorar el proceso
  133. 133. 134 Kanban  Un día cualquiera en Kanban
  134. 134. 135 Kanban  Un día cualquiera en Kanban
  135. 135. 136 Kanban  Un día cualquiera en Kanban
  136. 136. 137 Kanban  Un día cualquiera en Kanban
  137. 137. 138 Kanban  Un día cualquiera en Kanban
  138. 138. 139 Kanban  Un día cualquiera en Kanban
  139. 139. 140 Kanban  Un día cualquiera en Kanban
  140. 140. 141 Kanban  Un día cualquiera en Kanban
  141. 141. 142 Kanban  Un día cualquiera en Kanban
  142. 142. 143 Kanban  Un día cualquiera en Kanban
  143. 143. 144 Kanban  Un día cualquiera en Kanban
  144. 144. 145 Kanban  Un día cualquiera en Kanban
  145. 145. 146 Kanban  ¿Tiene que ser así?  No, tú adaptas el Kanban  Pero el flujo tiene que ser visual y suave  Para minimizar el tiempo de entrega  Adaptar las columnas y los límites WIP  Límite bajo  Gente ociosa, poco productiva  Límite alto  Tareas paradas, mala respuesta  Lo mejor es que refleje el flujo de trabajo  Si se alcanza el límite y estás parado busca cuellos de botella
  146. 146. 147 Kanban Taiichi Ohno
  147. 147. 148 Kanban  Implantar Kanban con Éxito  Centrarse en la calidad  Herramientas, inspecciones, patrones, TDD,…  Reducir el trabajo en curso  Entregas frecuentes  Mejora las relaciones con equipos externos  Balancear demanda y rendimiento  Permite detectar cuellos de botella reales  Priorizar  Atacar las causas de variabilidad  Mejora la predecibilidad (Teoría de Colas)
  148. 148. 149 Kanban  Implantar Kanban con Éxito  Implantarlas de arriba abajo en orden  Las primeras son más funcionales  Las últimas pueden tener rechazo  Cambiar el comportamiento es difícil  Requiere diplomacia, tacto, inteligencia emocional, psicología,… la confianza del equipo  Abordar el último paso primero sobre las causas que no requieran cambios en el comportamiento
  149. 149. 150 Kanban  Proporcionar Niveles de Servicio  Establecer tipos y políticas de servicio  Se pueden distinguir por colores en el tablón  Establecer niveles SLA (criterio porcentual)  Es un target controlable estadísticamente  Tipos estándar:  Bala de plata (operación crítica)  Fecha fija de entrega  Intangible (sin coste asociado al retraso)  Normal
  150. 150. 151 Kanban  Métricas  En Kanban no es relevante si un proyecto llega a tiempo o si se está siguiendo un plan  Lo importante es saber si es predecible  Si el proceso fluye según lo esperado  Si se busca la mejora continua  Interesa la tendencia en el tiempo de indicadores  Para detectar las posibles variaciones
  151. 151. 152 Kanban  Diagrama de Flujo Acumulado  Gráfico que relaciona las tareas en curso (tablero) con su estado concreto  Muestra lo que tarda una tarea en pasar de la pila a producción (lead time)  Muestra a qué se está dedicando más tiempo  Muestra el número de tareas en curso (WIP)  Muestra algunos cuellos de botella  Las bandas deberían ser estables
  152. 152. 153 Kanban  Diagrama de Flujo Acumulado
  153. 153. 154 Kanban  Lead Time  Tiempo de ciclo  Mide lo predecible que son las entregas  Comparable con nuestra promesa SLA  Reportar la distribución y el tiempo medio
  154. 154. 155 Kanban  Medidas de Rendimiento y Productividad  Due Date Performance  Rendimiento "en fecha"  Porcentaje de items entregados a tiempo  Analizar la causa raíz de las desviaciones  Throughput  Número de items entregados en un período  Similar a la velocidad del equipo  Indica si el sistema mejora continuamente
  155. 155. 156 Kanban  Flow Efficiency  Medida del desperdicio en tiempo  Relaciona el tiempo dedicado a una tarea respecto al tiempo que pasa en el sistema (lead)
  156. 156. 157 Kanban  Medidas de Calidad  Initial Quality  Tasa de bugs por item  Número de defectos que se han escapado  En porcentaje respecto al WIP  Failure Load  Carga de trabajo por fallos  Detectados por los usuarios  Que han generado nuevas tareas
  157. 157. 158 Kanban  Valor Aportado  Una tarjeta Kanban representa una tarea  Derivada de una historia de usuario  Se sabe que la historia aporta valor  ¿Cuándo completo ese valor? ¿Cuánto valor es?  ¿Qué valor tiene un flujo trasversal?  Importa la característica (historia) no la tarea  Minimum Marketable Feature (MMF)  Minimum Marketable Release (MMR)
  158. 158. 159 Kanban  MMF  Requisito de negocio "liberable al mercado"  Caso de uso, Historia de Usuario, Backlog,…  Compuesto de muchos items de trabajo  Permiten disparar una entrega  Manteniendo bajo coste y alta satisfacción  Deben dividirse en items/tareas del flujo  Tablón Kanban "en 2 niveles"
  159. 159. 160 Kanban  MMF
  160. 160. 161 Contenidos I. ¿Por qué Métodos Ágiles? II. ¿Qué son Métodos Ágiles? III. Algunas Técnicas Ágiles IV. Scrum V. Kanban VI. Claves del Éxito
  161. 161. 162 Cultura y Estructura  Agile no se implanta en un mes…  Requiere cambios…  En las Personas  Es necesario tener un equipo de desarrolladores expertos  Es necesaria una cultura de formación constante  En los Procesos  Los procesos pesados interfieren en los Métodos Ágiles  Los equipos ágiles se autogestionan  En las Herramientas  Las herramientas ayudan a realizar el trabajo  Pero no cambian la cultura de la empresa por sí solas
  162. 162. 163 Cultura y Estructura  Los cambios requieren tiempo  Debemos alinear a clientes y gerentes 1. Utilizar buffers normalizados (midiendo!!!) 2. Hacer entregas frecuentes 3. Ser flexible en los cambios 4. Realizar pagos incrementales 5. Compartir los beneficios 6. Hablar con el cliente 7. Formar al cliente
  163. 163. 164 7 Rasgos de un Gestor Efectivo 1. Habilidad para gestionar y manejar riesgos 2. Orientación a los resultados 3. Mucha energía 4. Sentirse parte del equipo 5. Ser capaz de dedicarse a múltiples tareas 6. Orientación a la mejora 7. Primero escuchar, después hablar
  164. 164. 165 Efectividad del equipo  El equipo tiene autoridad para tomar decisiones  El equipo tiene acceso al dueño del producto  El equipo tiene un gran Scrum Master  El equipo se reúne diariamente y está al tanto de los proyectos actuales y futuros  Todos los implicados asisten a reuniones regulares
  165. 165. 166 Efectividad del equipo  El equipo utiliza la retrospectiva para mejorar  El equipo sabe lo que significa hecho-hecho  El equipo es responsable de las tareas que se compromete y lo hace de manera seria  El equipo es eficiente, productivo, responsable, está motivado, organizado, dedicado, bien gestionado
  166. 166. 167 Cosas que “huelen mal”  Falta de energía en el equipo  No respetar los compromisos  Equipo preocupado por el tiempo y no por la productividad  El equipo no quiere hacer demos  El equipo no quiere hacer reuniones diarias
  167. 167. 168 Cosas que “huelen mal”  El equipo tiende a sobrestimar  El equipo está desanimado  Las reuniones diarias no son para el equipo  Los roles son muy especializados  El Scrum Master asigna las tareas
  168. 168. 169 Sugerencias  No buscar culpables, la culpa es del equipo  Trabajar en conjunto como una unidad  Mantener al equipo centrado y motivado  Medir el nivel de agilismo de la empresa  Personal  % Cambios  Cultura corporativa  Impacto del producto  Tamaño del equipo  Dispersión del equipo
  169. 169. 170 Diagrama de Radar  Permite ver varias variables en un vistazo
  170. 170. 171 Diagrama de Radar  Peor cuanto más disperso
  171. 171. 172 Diagrama de Radar  Mejor cuanto más centrado
  172. 172. 173 Más Claves [Antes de nada]  Verificar que el proyectos necesita agilismo  Si el tiempo o el presupuesto son críticos SÍ  Si la funcionalidad/características es fija NO  Estaríamos buscando un problema que no existe  El enfoque incremental siempre es beneficioso  Aplicar iteraciones en el momento adecuado  Se puede iterar en cualquier momento (1-2 actividades)  Cada iteración debe ser lo más compacta posible  Iterar más rápido donde haya mayor riesgo  Las release  Planificarlas de manera interactiva y en ciclos cortos  En ocasiones son puramente internas
  173. 173. 174 Más Claves [Equipo]  Realizar Sprints pequeños  El progreso del proyecto es más visible  Mantiene alta la moral  Minimiza los cambios de rumbo  Equipo = Desarrollador + QA + Gestor + Cliente  Mejora la toma de decisiones  Y esto mejora la ejecución  Es importante un equipo disciplinado (Teoría Y)  Utilizar estándares de codificación y buenas prácticas
  174. 174. 175 Más Claves [Pruebas]  Realizar integraciones y compilados diarios  Utilizar Frameworks de pruebas unitarias  Automatizar las pruebas (TDD)  Aprender de las retrospectivas  Permite “afilar el hacha” de manera frecuente  Permite añadir más valor al proyecto  Evitar las reuniones “por reunirse”  Realizar reuniones más cortas
  175. 175. 176 Algunas herramientas  http://www.agilebuddy.com  http://www.agilezen.com  http://atlassian.com/software/jira  http://virtualkanban.net  http://www.versionone.com  http://www.tuneupprocess.com  Silver Catalyst  Greenhopper/Jira  …
  176. 176. 177 Epílogo  Be Agile my friend
  177. 177. 178 Epílogo  No existen comidas gratuitas
  178. 178. Muchas gracias Óliver Centeno Álvarez [2012, Pronoide S.L.]

×