![](https://i.imgur.com/jnmauPu.png) # Project Management ## Objetivos - Entender las diferencias entre las distintas metodologías de Gestión de Proyectos - Identificar los beneficios de las metodologías ágiles - Comprender que son SCRUM y Kanban - Aprender a utilizar Trello para gestionar la metodología Kanban ## Introducción Durante el curso, iremos trabajando en algunos proyectos, ya sea de forma individual o grupal. En esta lección, veremos los diferentes métodos de gestión de proyectos. **Agile** es una filosofía para la gestión de equipos y proyectos. **Scrum** y **Kaban** son implementaciones prácticas que siguen los principios ágiles de diferentes maneras. Siempre es recomendable entender cada una y elegir lo que se adapte a vos y tu equipo. Después de comprender las ideas y los principios detrás de cada metodología, tenemos que tener en cuenta que pueden pasar años de práctica antes de dominar la Gestión de Proyectos. Siempre es recomendable empezar cuánto antes gestionando proyectos propios e intentar convertirlo en un hábito continuo. Lo importante es intentar entender como hacernos más eficientes. ### El triángulo de la Gestión de Proyectos El principio básico de la gestión de proyectos es el [Triángo de la Gestión de Proyectos](https://en.wikipedia.org/wiki/Project_management_triangle), que explica que: 1. La calidad del trabajo está limitada por el **presupuesto** (costo), **fechas límite** (tiempo) y **alcance** (características) del proyecto. 2. El director del proyecto puede negociar entre estas limitaciones. 3. Los cambios en una restricción requieren cambios en otras para compensar o la calidad se verá afectada. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_d23e8f76110fbe46ac078927b2b585b9.png =250x) Por ejemplo, un proyecto se puede completar más rápido aumentando el presupuesto o reduciendo el alcance. De manera similar, aumentar el alcance puede requerir aumentos equivalentes en el presupuesto y el cronograma. Reducir el presupuesto sin ajustar el cronograma o el alcance conducirá a una menor calidad. En la práctica, el intercambio entre restricciones no siempre es posible. Por ejemplo, invertir dinero (o personas) en un proyecto con personal completo puede ralentizarlo. En proyectos mal ejecutados, a menudo es posible mejorar el presupuesto, el cronograma o el alcance sin afectar negativamente la calidad. Otra [representación](http://smarterwebsiteowner.com/the-project-management-triangle/) del triángulo de gestión de proyectos que se adapta mejor a los equipos de diseño incluye *calidad* como una restricción implícita en el triángulo y elimina el alcance: ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_62ca549b52d6cb50b8dfec435151bd31.png =400x) Cada lado corresponde a la idea de que no puede tener estos tres resultados (velocidad, costo, calidad); solo puede elegir dos y, al hacerlo, la tercera opción se verá afectada: | A | B | Result |:----------:|:----------:|:--------: | Barato | Rápido | **Baja calidad** | Barato | Calidad | **Mucho tiempo** | Rápido | Calidad | **Caro** ## Métodos de Gestión de Proyectos ### 1. Modelo tipo cascada Después de la revolución industrial, la gestión de proyectos se basó principalmente en el [modelo de cascada](https://en.wikipedia.org/wiki/Waterfall_model). El modelo de cascada es un enfoque de diseño secuencial relativamente lineal para la gestión de proyectos que proviene del diseño de ingeniería. En el desarrollo y diseño de software, tiende a estar entre los enfoques menos iterativos y flexibles. El progreso fluye en una dirección ("hacia abajo" como una cascada) a través de las diferentes fases. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_01f056372a4402e14631d952ab6760e2.png =600x) Ha habido una gran cantidad de [críticas](https://en.wikipedia.org/wiki/Waterfall_model#Criticism) hacia este modelo porque: - Es posible que los clientes no sepan exactamente cuáles son sus requisitos antes de ver el entregable. - Los cambios en sus requisitos conducen a rediseño, remodelación y reevaluación y, por lo tanto, aumento de costos. - Es posible que los diseñadores no estén al tanto de las dificultades futuras al diseñar un nuevo producto/servición o función. Este método todavía se utiliza en algunas organizaciones y funciona muy bien cuando todos los requisitos se pueden identificar clara e inequívocamente en una etapa temprana. --- ### 2. Agile Los métodos tradicionales de diseño y producción (por ejemplo, el método cascada) no funcionaban de forma demasiado eficientes en industrias modernas como el desarrollo de software. En esta industria, los proyectos solían retrasarse, excedían las estimaciones de costos, no cumplían las expectativas o incluso, simplemente se cancelaban. Un [famoso estudio](https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf), publicado en 1994, reveló que solo el 9% de los proyectos de software en las grandes empresas tuvieron éxito. Para abordar estos problemas, profesionales de todo el mundo y de todo el espectro funcional (gerentes de proyectos, arquitectos, diseñadores, desarrolladores, probadores, ...) comenzaron a experimentar con nuevos enfoques para la Gestión, Diseño y Desarrollo de Proyectos, como [UP](https : //en.wikipedia.org/wiki/Unified_Process), [XP](https://en.wikipedia.org/wiki/Extreme_programming), [Agile Modeling](https://en.wikipedia.org/wiki/Agile_modeling) y [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)). En 2001, dieciocho de las mentes brillantes detrás de algunas de estas iniciativas se reunieron para compartir sus ideas y acordar un conjunto común de **Valores** y **Principios**. El resultado de esta reunión fue el [Manifiesto Ágil](http://agilemanifesto.org/), que dice: A través de este trabajo hemos llegado a valorar cuatro pilares principales: - *Individuos e interacciones* sobre procesos y herramientas - *Un producto funcionando* mejor que documentación e informes extensivos - *Colaboración con el cliente* durante todo el flujo de trabajo - *Respuesta ante el cambio* antes de seguir un plan ## Agile Agile es un *framework* alternativo al modelo tipo cascada o al desarrollo secuencial tradicional. Ayuda a los equipos a responder a la imprevisibilidad a través de ciclos de trabajo incrementales e iterativos, conocidos como *sprints*. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_cd0067a7794c0e13fc571ffd9b4e8837.png) Agile crea un producto de forma incremental desde el inicio del proyecto, en lugar de intentar entregarlo todo de una vez al final. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_4021b1de0e0b667a2b9dd2a4bbcc9d0e.png) Funciona dividiendo los proyectos en pequeños fragmentos de funcionalidad de usuario llamados **historias de usuario**, priorizándolos y luego entregándolos continuamente en ciclos cortos de una semana (puede ser más o menos tiempo) llamados iteraciones. [Fuente](https://medium.com/@StaceyDyer/design-thinking-how-and-when-should-i-use-it-91ba567b831d) ## ¿Qué hace al Agile diferente? ### 1. El desarrollo es **iterativo** El análisis, diseño, desarrollo o testeo nunca terminan cuando se utiliza la metodología Agile. Siempre que haya funciones para construir y los medios para implementarlas, estas actividades continúan durante la duración del proyecto. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_a6634d43f67a0dbaab93d503db56075e.png =400x) El desarrollo iterativo significa comenzar con algo realmente simple y agregarlo gradualmente con el tiempo. Significa evolucionar la arquitectura, aceptar que sus requisitos van a cambiar y **perfeccionar y ajustar continuamente su producto sobre la marcha**. ### 2. El plan es **Adaptable** ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_51ddef04c290cdcefd8f6587048693dc.png =400x) Cuando la realidad no se ajusta a los planes, los *agilistas* encuentran más fácil cambiar sus planes que la realidad. A esto lo llaman planificación adaptable. ### 3. Roles *difuminados* ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_1eac0a725f9f062de322ff724310fff7.png =300x) Los roles realmente se difuminan en los proyectos ágiles. Cuando se hace bien, unirse a un equipo ágil es muy parecido a trabajar en una mini-startup. La gente colabora y hace lo que sea necesario para que el proyecto sea un éxito, independientemente del título o función. :::warning :bulb: Las personas tienen habilidades específicas y, por lo general, se apegan a lo mejor hacen. En un proyecto ágil, los roles estrictamente definidos como analista, programador y evaluador no existen realmente, al menos no en el sentido tradicional. ::: ### 4. El alcance puede variar ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_20923640076f672a2eca8c39d0e8556c.png =300x) Poniendo en común el tiempo, presupuesto y calidad, además de ser flexible con el alcance (que tanto realmente se puede hacer considerando las restricciones), los equipos Agile mantienen la integridad de su planificación, trabajando dentro de sus posibilidades y evitando el agotamiento la disfunción tradicionalmente asociados con proyectos grandes. ### 5. Los requerimientos pueden cambiar Tradicionalmente, se ha evitado el cambio en los proyectos debido a su alto costo percibido al finalizar el mismo. Agile desafía esta noción y cree que el costo del cambio puede ser relativamente bajo. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_f0d6c05e62783a18a0001e4f220d4ece.png) Mediante una combinación de prácticas modernas de ingeniería de software y una planificación abierta y honesta, los usuarios Agile aceptan y adoptan los cambios incluso al final del proceso de entrega. ### 6. El producto que funciona es la principal medida del éxito ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_1cf8f517988c55cb10754912b61eac19.png =400x) La velocidad a la que los equipos pueden convertir los requerimientos de sus clientes en un producto funcional es la forma en que los agilistas miden la productividad. Los planes de proyecto, los planes de prueba y los estudios de análisis son insumos relevantes, pero los agilistas entienden que en sí mismos no tienen ningún valor para el cliente final. -- Fuente: **[Agile Nutshell](http://www.agilenutshell.com/what_is_agile)** #### Agile | 12 prinicipios Con el manifesto Agile, acordaron [12 principios](http://agilemanifesto.org/principles.html) para ayudar a los equipos a responder a la imprevisibilidad mediante flujos de trabajo incrementales e iterativos y retroalimentación constante. Los agilistas proponen alternativas a otras metodologías como [Cascada](https://en.wikipedia.org/wiki/Waterfall_model), o [el desarrollo secuencial tradicional](https://en.wikipedia.org/wiki/Traditional_engineering). La metodología agile sigue los siguientes [principios](http://agilemanifesto.org/principles.html) *- un poco adaptados a equipos de UI*: 1. Satisfacción del cliente. Es la base de todo. Se alcanza a través de la entrega de productos de valor que cubran una necesidad. 2. Bienvenidos los nuevos requisitos. Cambiar sobre la marcha no es dar un paso atrás. Cualquier sugerencia o solución es bienvenida si se trata de mejorar el producto. 3. Entregas por semanas. La división del trabajo en fases productivas es la base de la metodología. En lo posible, ejecutar una cada semana. 4. Es posible medir el progreso. La evolución de los procesos no es un elemento subjetivo. Se puede medir con indicadores concretos. 5. Desarrollo sostenible. La forma de ejecutar los proyectos debe garantizar en sí misma su continuidad. No es una cuestión de hacer por hacer. 6. Trabajo cercano. Los líderes de los proyectos deben ejercer su labor en el mismo terreno donde tienen lugar las tareas y no desde los despachos. 7. Conversación cara a cara. El gestor responsable debe comunicar de forma eficaz sus mensajes, mejor si se hace de forma presencial. Se recomiendan reuniones periódicas tanto con el cliente como con sus colaboradores. 8. Motivación y confianza. Los procesos sólo tendrán éxito si quienes los llevan a cabo son personas motivadas y que interactúan en climas de confianza y solidaridad. 9. Excelencia técnica y buen diseño. Las formas nunca deben perderse, así como tampoco la calidad del trabajo. Todo es un conjunto. 10. Simplicidad. Las tareas han de ser lo más sencillas posible. Si alguna no puede ser ejecutada en esos términos, debe ser dividida en iteraciones hasta que se reduzca su nivel de complejidad. 11. Autogestión de los equipos. Si bien debe existir una figura que monitorice los equipos de trabajo , éstos deben ser capaces de organizarse por sí mismos. El exceso de jerarquías crea dependencia entre los colaboradores. 12. Adaptación circunstancias cambiantes. Los proyectos no suelen terminar de la misma forma en que empezaron. Es indispensable que quienes los ejecutan puedan adaptarse a las distintas circunstacias que puedan surgir. Agile busca alternativas a la gestión de proyectos tradicional. Los enfoques ágiles ayudan a los equipos a responder a la imprevisibilidad a través de cadencias de trabajo iterativas e incrementales y retroalimentación empírica. #### Agile vs. Lean Las implicaciones de los principios ágiles son enormes y han provocado una revolución en la gestión de proyectos que conduce a una nueva mentalidad. Inicialmente Agile se creó para gestionar con proyectos de desarrollo de software. Poco después, se aplicó a una variedad de industrias (Marketing y UX) y finalmente incluso a la gestión empresarial. Hay algunos principios clave en el núcleo de [Lean Thinking](https://en.wikipedia.org/wiki/Lean_thinking), y se manifiestan de manera diferente en diferentes contextos. El objetivo de los principios fundamentales de Lean son: 1. Minimizar el desperdicio 2. Crear una cultura de mejora continua 3. Medir el panorama general Estos apoyaron las innovaciones de Toyota ([Toyota Production System](https://en.wikipedia.org/wiki/Toyota_Production_System)) y resuenan en todo el mundo Lean Startup de diferentes maneras. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_1abf7b5347df31f87e28d1de15de2ab3.png =200x) ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_0f6581e5cc612eed5779616d9b27af92.png =200x) ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_d609fe5cd03630c647255702c832ea1f.png =200x) --- ## Metodologías que implementan Lean y Agile Hay muchas metodologías que han evolucionado a partir del Manifiesto Ágil, las más populares son Scrum y Kanban. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_0646ec4af5e9565b5e02c58f5f653182.png =500x) > Lean y Agile son filosofías, mientras que Scrum y Kanban son metodologías que implementan Lean y Agile. ### 3. SCRUM [SCRUM](https://en.wikipedia.org/wiki/Scrum_(software_development)) es un marco o metología para la gestión del trabajo, alineado con los valores y principios Agile, con énfasis en el desarrollo de productos/servicios. Es la metodología más utilizada en la industria y es probable que trabajes en un equipo Scrum en algún momento de tu carrera. #### Estructura Scrum está diseñado para equipos de 3 a 9 miembros que dividen su trabajo en acciones (*historias*) que se pueden completar dentro de iteraciones de intervalos de tiempo, llamadas **sprints**. La primera reunión que Scrum propone para todos los proyectos se llama **reunión inicial**. Aquí es donde definimos todas las características que podemos incluir en el Producto y agruparlas en la **Lista de Producto** o **Backlog de Producto**. Al comienzo de cada Sprint, el equipo llevará a cabo una reunión de **Planificación de Sprint**, donde seleccionan del Backlog de Producto el subconjunto de características que se comprometen a terminar y las mueven al **Sprint Backlog**. Los miembros realizan un seguimiento del progreso y vuelven a planificar en reuniones de 15 minutos, llamadas **Scrums diarios** *(o reuniones diarias)*. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_0a12db480278c3bceb9cb46fe5e58646.png) Después de cada Sprint, el objetivo es tener **una versión nueva del producto** y entregar cada función como si fuera a ser entregada a un cliente, completamente probada y revisada. Si una función no es **utilizable**, el equipo continuará trabajando en ella en el próximo Sprint. Antes de que comience un nuevo Sprint, los equipos suelen tener una reunión **Retrospectiva**, donde analizan el último Sprint y encuentran formas de mejorar su desempeño como equipo en un entorno colaborativo y de mente abierta. #### Valores Menos conocidos que el proceso de Scrum son los valores centrales de Scrum en los que se basa el marco. Estos valores permiten al equipo tomar decisiones y ajustes a sus comportamientos individuales y colectivos, para trabajar mejor en equipo. - Compromiso - comprometerse a colaborar, trabajar con calidad, aprender y mejorar constantemente - *este valor se trata de la dedicación y el esfuerzo, no del resultado final* - Enfoque: concentrarse en el trabajo en cuestión frente a los planes para un futuro incierto y concéntrese en lo que realmente importa para entregar el trabajo terminado en lugar de los accesorios y los detalles - Apertura: abierto a colaborar, a la crítica, a probar diferentes ideas y enfoques, especialmente cuando desafían nuestra forma de pensar. - Respeto: hacia los demás, sus opiniones, su contexto, habilidades y antecedentes, así como hacia las partes interesadas y los usuarios. - Coraje: ser abiertos y transparentes sobre nuestro trabajo y nuestro progreso, aceptar cambios de dirección o formas de trabajar, terminar lo que comenzamos, compartir riesgos y beneficios, desafiar a los demás y decir la verdad con respeto. Este es un muy buen video sobre el SCRUM: {%youtube XU0llRltyFM %} --- ### 4.Kanban El método [Kanban](https://en.wikipedia.org/wiki/Kanban) es un enfoque del cambio de proceso evolutivo para las organizaciones. A diferencia de **Scrum**, no prescribe herramientas y prácticas específicas, como reuniones específicas diarias o semanales. En cambio, se centra en principios que ayudan a los equipos a mejorar continuamente. En otras palabras, Kanban no impone reglas, reuniones o herramientas; cada cambio en la forma en que trabaja un equipo debe probarse de manera colaborativa y, luego, el equipo en su conjunto debe incorporarlo, modificarlo o eliminarlo. Los orígenes de Kanban se remontan a un sistema inventado por Toyota a fines de la década de 1950 para solucionar problemas en sus procesos de cadena de suministro. El objetivo era bastante simple, pero bastante difícil de poner en práctica: "Alinear los niveles de inventario con el consumo real". Operacionalmente, esto significa que para optimizar nuestra producción como diseñadores, debemos *"alinear nuestro trabajo actual con la demanda real"*. En otras palabras, **Termina la tarea más importante primero**, luego enfócate en la **segunda tarea más importante** y repite. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_6d6b4d456f29b674ab7f5469af3b75a7.png =300x) Un término en español que captura el significado de la palabra japonesa, Kanban (看板), es *priorizador de trabajo*; y el resultado beneficioso es **priorización de trabajo**. En otras palabras, deberíamos limitar el número de tareas que podemos tener en la lista "En curso". Si se alcanza el número máximo de tareas, ¡debemos trabajar para terminar esas tareas antes de comenzar cualquier otra tarea! :::success :bulb: Para maximizar la productividad y reducir el desperdicio, debemos **limitar el número de tareas en curso**. ::: Esta técnica aparentemente básica puede percibirse como contraria a la intuición, especialmente si se tiene experiencia trabajando en un entorno donde la cultura dominante está haciendo lo contrario. Pero los beneficios están respaldados por la ciencia, es decir, por la Teoría de las Restricciones (el estudio de los cuellos de botella), el Sistema de Conocimiento Profundo (estudio de la variación y cómo afecta a los procesos) y el Modelo Económico Lean (basado en el concepto de medir y minimizar el “desperdicio ”). Estos son los principios básicos de Kanban: - Empezar con lo que esta haciendo ahora - Buscar un cambio evolutivo incremental - Respetar el proceso actual, roles, responsabilidades y títulos. - Fomentar actos de liderazgo en todos los niveles Y algunas de las prácticas empleadas habitualmente: - Visualizar el flujo de trabajo - Limitar el trabajo en curso - Gestionar el flujo - Hacer explícitas las políticas del proceso - Mejorar colaborativamente (usando modelos y el método científico) #### El tablero Kanban Kanban sugiere que los equipos visualicen su flujo de trabajo y progreso a través de un tablero de elementos de trabajo. El tablero Kanban le permite tener una gran comprensión tanto del trabajo como del flujo de trabajo. ![](https://i.imgur.com/N92i6QA.jpg) Como puede ver en la imagen, el tablero Kanban tiene tres estados diferentes: - **To Do**: Trabajo que tienes que hacer. - **Doing**: Trabajo que está en progreso. - **Hecho**: Trabajo que ya está hecho. Hay enfoques más complejos para equipos / proyectos más grandes que incluyen otros estados, como: - **Backlog**: una lista completa de tareas por realizar, sin filtrar. - **Prioridades**: Separación de tareas en diferentes prioridades (P1, P2). - **Test**: Validación de tareas antes de considerarlas realizadas. - **Icebox**: una lista de deseos con ideas para hacer en el futuro. ![](https://s3-eu-west-1.amazonaws.com/ih-materials/uploads/upload_452c1446a174c1b7adefe33ee3b38f6b.png =350x) #### Ejemplo de un proceso simple A continuación, se muestra un ejemplo de un proceso simple, siguiendo los principios Kanban: 1. El cliente solicita una nueva característica para un producto 2. Tienes que agregar la nueva solicitud a tu tablero Kanban, en la lista "Tareas pendientes". 3. Antes de comenzar a trabajar en una nueva función, debe mover la tarjeta a la lista "Haciendo" 4. Una vez que se implemente la nueva función y haya comprobado que funciona, debe mover la tarjeta a la lista "Listo". El nombre de las listas puede ser diferente según el equipo. Puede encontrar el estado "Haciendo" renombrado como "En curso", por ejemplo. Lo más importante es comprender el flujo de trabajo que debe seguir para implementar Kanban. Hay muchas empresas que utilizan pizarras para ver el estado actual de un proyecto. Si trabaja en un equipo que trabaja a distancia, esta no es la mejor solución. Los miembros que no estén en la oficina no podrán mover sus tarjetas. Es por eso que necesita algún tipo de herramienta para manejar el tablero Kanban. En nuestro caso, vamos a utilizar [Trello](http://www.trello.com). #### Definición de Terminado o DoD por sus siglas en inglés (Definition of Done) La Definición de Terminado es una lista simple de actividades adjunta a cada tarea en el Tablero Kanban que agregan valor verificable / demostrable al producto. La DoD asegura que todos en el equipo sepan exactamente qué se espera de todo lo que el equipo entrega. Asegura la transparencia y la calidad que se ajustan al propósito del producto y la organización. Centrarse en los pasos de valor agregado permite que el equipo se concentre en lo que se debe completar para crear productos y, al mismo tiempo, eliminar las actividades inútiles que solo complican los esfuerzos del equipo. La definición de Terminado (DoD) es crucial para un equipo ágil altamente funcional ya que garantizará que esté brindando funciones que están realmente hechas, no solo en términos de funcionalidad sino también en términos de calidad. Las siguientes son características que debe buscar en el DoD de sus tareas: 1. DoD es una lista de verificación de actividades valiosas necesarias para producir productos/servicios 1. El DoD es el principal mecanismo de presentación de informes para los miembros del equipo. 1. El DoD se basa en la realidad y hechos reales 1. El DoD no es estático, puede y debe evolucionar 1. DoD es una lista de verificación auditable #### Scrum Vs Kanban Las diferencias entre Scrum y Kanban pueden resultar confusas para los principiantes. Aquí hay una tabla que describe las principales diferencias: Scrum | Kanban ------- | -------- El trabajo se realiza dentro de Sprints en intervalos de tiempo definidos. El objetivo es producir un producto potencialmente enviable después de cada Sprint. | No hay sprints de duración fija. Los equipos extraen tareas de una lista priorizada de cosas que deben hacerse El Producto se lanza con una cadencia particular, que está determinada por la duración del Sprint | Las liberaciones ocurren continuamente o siempre que se crea un producto para envío Hay un gran enfoque en la funcionalidad cruzada. Los equipos no tienen roles específicos, todos son un [cerdo](https://www.mountaingoatsoftware.com/agile/scrum/roles/the-chicken-and-the-pig). | Los miembros del equipo pueden especializarse y realizar tareas relacionadas con su área de especialización. Sprint kickoffs, standups diarios, revisiones de sprint, retrospectivas de sprint son rituales vitales dentro del proceso Scrum | Se hace hincapié en la mejora continua de los procesos, pero no hay reuniones periódicas estandarizadas. ## Resumen En resumen, hemos visto sobre la historia de algunas metodologías de Gestión de Proyectos. Ahora podemos entender por qué las metodologías ágiles son tan importantes hoy en día y qué problemas resuelven. Hemos visto que las metodologías ágiles más habituales son Scrum y Kanban, y hemos aprendido Kanban en profundidad. ## Recursos extra - [Metodología Agile](http://agilemethodology.org/) - [Agile Manifesto](http://agilemanifesto.org/) - [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) - [Trello](https://trello.com/) - [La historia de Lean Stratup](http://www.salimvirani.com/the-history-of-leanstartup-and-how-to-make-sense-of-it-all/)