Módulo 2. Enfoques y metodologías en la gestión de proyectos En el presente módulo abordaremos los enfoques y metodologías en la gestión de proyectos, buscaremos entenderlos en su complejidad y desde sus enfoques tradicionales. Una vez hecho este primer recorrido, podremos entender los nuevos requerimientos del mercado y abordar las metodologías ágiles en su complejidad. Video de inmersión 2.1 Complejidad y enfoques tradicionales 2.2 Metodologías ágiles Anexo: mani esto ágil GLOSARIO Video de habilidades Cierre Referencias Descargá la lectura Lección 1 de 9 Video de inmersión Verify to continue We detected a high number of errors from your connection. To continue, please confirm that you’re a human (and not a spambot). I'm not a robot reCAPTCHA Privacy - Terms Lección 2 de 9 2.1 Complejidad y enfoques tradicionales 2.1.1 Complejidad de los proyectos La complejidad de todo proyecto que debamos gestionar se encuentra condicionada por diversos factores que determinan que un proyecto sea más o menos complejo. Esos factores son los siguientes: 1 Nivel de conocimiento de las herramientas y medios necesarios para lograr el éxito del proyecto. Por ejemplo, el nivel de conocimiento sobre la industria en la que se debe desempeñar el proyecto o de las tecnologías inherentes a él. 2 Nivel de claridad o de detalle en el pedido del proyecto. Por ejemplo, requerimientos poco detallados o muy detallados, cambiantes o ambiguos por parte del cliente del proyecto. La Figura 1 muestra los diferentes grados de complejidad de los requisitos a cumplir y de las herramientas que necesitamos para trabajar según el nivel de conocimiento que tenemos. Figura 1. Complejidad de los proyectos Fuente: Elaboración propia. ¿Cómo gestionamos la complejidad de los proyectos? Básicamente, podemos agrupar en dos las maneras de manejar la complejidad de un proyecto: con metodología en cascada o con metodologías ágiles. Metodología tradicional o en cascada: es una metodología de gestión de proyectos que se aplica en proyectos simples, en los cuales los requerimientos a cumplir están lo suficientemente bien detallados al inicio del proyecto, de manera que no sea necesario hacer un segundo análisis más profundo durante la vida del proyecto. En estos casos, contamos con un conocimiento de las herramientas necesarias para gestionar el proyecto de manera de evitar reprocesos o complejidades. En otras palabras, aplicar este tipo de metodología implica tener un conocimiento total y detallado de lo que se pretende lograr al final del proyecto. Metodologías ágiles: es una metodología de gestión de proyectos que se aplica en proyectos complejos, en los cuales el nivel de conocimiento de los requerimientos no es total ni detallado al inicio y para los cuales no contamos con el nivel de conocimiento necesario sobre las herramientas para desarrollarlos con normalidad. Se incluyen múltiples revisiones llevadas a cabo de manera minuciosa y sistemática que permiten ir refinando el proyecto a medidas que avanza. Figura 2. Relación entre la complejidad de los proyectos y las metodologías de gestión de proyectos Fuente: Elaboración propia. 2.1.2 Metodologías tradicionales o en cascada Queda claro que los proyectos sencillos pueden llevarse a cabo con una metodología de gestión de proyectos simple en la que se sigue una sucesión de pasos y secuencias ordenadas para llegar a cumplir con el objetivo del proyecto. En la Figura 3, se puede ver esta metodología representada de forma gráfica. Figura 3. Metodologías tradicionales o en cascada Fuente: Elaboración propia. A continuación, se enumeran algunas particularidades a tener en cuenta sobre esta metodología de gestión de proyectos en cascada. La intervención del cliente se da dos veces: una al inicio (al definir las necesidades del proyecto) y otra al final (al recibir los resultados del proyecto). El proceso es totalmente desconocido para el cliente. El desarrollo es secuencial; es decir que se avanza en el proyecto a medida que se van concretando pasos de trabajo. Por este motivo, se la conoce como metodología en cascada. Los cambios no son bienvenidos, ya que requieren una gestión muy burocrática. ¿Qué complejidades puede tener esta modalidad de gestión de proyectos? El cliente del proyecto no tiene posibilidad de ver un adelanto de lo que será, sino que se encontrará con el producto terminado tal cual como lo describió varios meses atrás. ¿Y si al ver el producto no era lo que imaginaba o necesitaba? Reflexión ¿Cuántas veces alguien sabe todos los detalles de los requerimientos de un proyecto a su inicio? La respuesta depende del rubro, pero en general, esto sucede muy pocas veces. Retomando el tema de la complejidad, se puede decir que con esta metodología se debe comenzar el proyecto con todos los requerimientos muy claros y detallados, porque cualquier cambio implica un alto costo durante la vida del proyecto. De acuerdo con el rubro del proyecto, esta metodología puede o no ser apropiada. Hay campos de acción mucho más estables y menos dinámicos que otros. A continuación, se analizan algunos casos. Proyectos de construcción: hay pocas probabilidades de que, una vez hechos los cimientos, el dueño quiera achicar el living de la casa (pero puede pasar). Proyectos de software: hay muchas probabilidades de que, una vez hecho el análisis del sistema a construir, el dueño quiera agregar o cambiar funcionalidades. ¿Qué particularidades deben cumplir los interesados de un proyecto llevado adelante bajo esta metodología de gestión? Equipo de trabajo Generalmente, los equipos de trabajo en los proyectos ejecutados en cascada suelen ser especializados. Esto significa que hay un analista que entiende del rubro y conoce la problemática a resolver, hay un diseñador de soluciones experto en las herramientas necesarias para ejecutar las tareas, hay gente que sabe ejecutar las tareas en sí y hay gente que valida, verifica o prueba el producto antes de entregarlo. Son roles muy separados en los que cada uno hace lo que sabe hacer, con muy poco acople entre ellos. Intervención del cliente Como dijimos antes, el cliente prácticamente no participa durante la ejecución del proyecto. Solo forma parte del proceso al inicio y al final. Una vez comenzado el proyecto, el único objetivo es cumplir con el plan de proyecto pactado con el cliente. Control de cambios La metodología en cascada no es ágil frente a los cambios. Se invierte mucho esfuerzo y tiempo en la etapa de análisis para conseguir una foto completa y acabada de lo que el cliente necesita. El modelo en cascada prevé un comité de control de cambios (CCC) encargado de evaluar el impacto de los cambios que solicite el cliente una vez comenzado el proyecto. El CCC debe autorizar o no el cambio propuesto, evaluar los desvíos que provoque y volver a estimar las tareas restantes (o el retrabajo) que implique este imprevisto. 2.1.3 Aplicabilidad a cierto tipo de proyectos ¿Problemas? ¿Qué problemas tiene esta metodología? Los problemas no son de la metodología en sí, sino que son relativos al contexto en el que se utilice. Si miramos los resultados de los proyectos en los últimos diez años, nos encontramos con cifras alarmantes. Tomemos la industria del software para ejemplificar con números esta situación, aunque podría proyectarse a muchas otras disciplinas. Según un estudio de la Universidad del Caribe, las cifras que resultan del análisis de cientos de proyectos son las siguientes. El 31% de los proyectos se cancelarán antes de que finalicen. El 53% de los proyectos costarán 189% más de lo que se estimó originalmente. El 75% de los productos de software grandes tienen fallas. Esto hace que no se usen porque no cumplen con los requerimientos del cliente. Pero ¿cuáles son las causas de estos fracasos? Según la misma entidad, son las siguientes: 1 requerimientos incompletos; 2 deficiencia en el involucramiento del usuario; 3 deficiencia de recursos; 4 expectativas no realistas. ¿Dónde nacen estos errores? ¿En qué etapa del proyecto? el 56% nace en la etapa de análisis. el 10% nace en la etapa de diseño; el 7% nace en la etapa de construcción; el 27% nace en otros momentos del proceso. Los problemas reales surgen cuando se quiere utilizar una metodología de cascada en proyectos que no ofrecen las condiciones para que esta funcione correctamente. Esto ocurre en los siguientes casos: El cliente no tiene claro lo que quiere al inicio del proyecto, solo tiene las ideas principales. El cliente no participa de la evolución del proyecto, sino que solo espera el final del proyecto para ver su producto terminado. El conocimiento de las herramientas para ejecutar el proyecto es escaso (gráfico de la complejidad). 2.1.4 El mercado pide otra cosa El mundo y el mercado evolucionan tan rápidamente que así también lo hacen las necesidades de la gente. Esto hace que sea extremadamente difícil poder determinar el 100% del detalle de lo que se necesita antes de comenzar un proyecto. Los problemas aparecen al querer continuar utilizando la misma metodología en proyectos con necesidades dinámicas y cambiantes. La misma agilidad con la que comenzó a evolucionar el mercado es la que hizo que surgieran las llamadas metodologías ágiles. En la actualidad, los proyectos demandan uno de los siguientes tipos de gestión de proyectos. gestiones estáticas; metodologías ágiles; metodologías secuenciales; metodologías complejas. SUBMIT Lección 3 de 9 2.2 Metodologías ágiles 2.2.1 ¿Qué es SCRUM? Nos toca ahora profundizar sobre las metodologías ágiles para la gestión de proyectos y, el SCRUM es una de ellas. ¿Qué ocurre cuando no están del todo claros los requerimientos al inicio del proyecto, pero sí se tiene en claro el objetivo o necesidad final? Este no es un problema aislado, sino que ocurre en la mayoría de las industrias. El dinamismo con el que se mueven el mercado y el mundo hace que sean muy aisladas las situaciones en las que se tiene la posibilidad de tener un alcance detallado al iniciar los proyectos. Las metodologías ágiles han llegado para ayudar con esta situación. A diferencia de las metodologías tradicionales o en cascada, estos enfoques plantean n ciclos (y no solamente uno). Cada ciclo va construyendo parcialmente el producto. Siempre hay un resultado por cada ciclo y esto permite que el cliente tenga la posibilidad de ver la evolución de lo que se está construyendo. Con esto se evitan las grandes desviaciones que existen cuando no hay intervención de los clientes hasta la finalización del producto. En las metodologías ágiles, los cambios son bienvenidos y se plantea una respuesta rápida a esos cambios. Los integrantes del equipo no tienen conocimientos tan específicos, sino que van ocupando roles que pueden rotar. Es un ambiente colaborativo, donde todos colaboran con todos. SCRUM es el nombre que recibe un conjunto de buenas prácticas que buscan ayudar a gestionar de la mejor manera proyectos complejos. Es decir, escenarios en los cuales no tenemos total control de los requerimientos ni de las herramientas necesarios para construirlos. SCRUM se basa en los ciclos de vida iterativos y adaptativos y, además, agrega varias reglas de juego que se deben cumplir si se quiere sacar todo el provecho posible del uso de estas buenas prácticas y de lo que ellas nos pueden mostrar. Un SCRUM bien implementado logra llegar a un mejor producto y a un mejor proceso y ambos habrán madurado cuantitativamente al final del proyecto. Por otra parte, pone especial foco en la intervención del cliente durante todo el proyecto. Este proyecto es el resultado de una serie de iteraciones cortas cuya responsabilidad es agregar valor al producto en cada una de ellas. Figura 4. Ciclo de vida de SCRUM Fuente: [Imagen sin título sobre el método ágil SCRUM], s. f., https://bit.ly/3d0srrI En la Figura 4 se describe el proceso de trabajo que propone SCRUM. Vamos por partes. Recordemos que este enfoque se adapta muy bien a escenarios en donde el cliente sabe la estrategia, pero no tiene claridad sobre cómo avanzar en el proyecto. SCRUM es una metodología de gestión de proyectos que brinda: buenas prácticas; buenas prácticas, herramientas y roles de gestión; metodologías secuenciales; buenas prácticas y roles de trabajo. SUBMIT 2.2.2 Personas involucradas en un ciclo SCRUM ¿Quiénes participan de esta metodología? 1 Product Owner: es el representante del cliente en el proceso y tiene la responsabilidad de aclarar la necesidad que este tiene. 2 Scrum Master: es el líder del equipo de trabajo; es un facilitador de la gestión de trabajo. Asegura el foco de gestión del equipo y las prácticas de la metodología SCRUM. 3 Team: es el equipo de trabajo conformado por personas altamente capacitadas que ejecutarán las distintas tareas del proyecto. Figura 5. Roles presentes en la metodología SCRUM Fuente: Elaboración propia. El equipo debe ser estable durante el proyecto: debe cambiar lo mínimo posible. La autoorganización lleva tiempo, implica que ya las personas se conocen, que cada uno sabe lo que el otro puede dar, y que hay una base de confianza establecida e implícita que permite que los quehaceres del día a día fluyan con mayor naturalidad. El ciclo de vida de la metodología SCRUM Luego de haber presentado a los intervinientes, podemos detallar el proceso de trabajo de la siguiente manera. 1 El Product Owner elabora un documento denominado Product Backlog en el que se incluyen todas las necesidades, los requisitos y las ideas del cliente. 2 Luego, les presenta ese documento al Scrum Master y al Team en una reunión denominada Sprint Planning Meeting. 3 Allí se define una primera fase de trabajo que se detalla en un documento denominado Sprint Backlog y que deberá resolverse en un Sprint (un tiempo que dura entre una y cuatro semanas). 4 En el Sprint intervienen el Scrum Master y el Team para desarrollar ese producto según las necesidades del cliente. 5 A diario debe realizarse una reunión, denominada Daily Scrum (de menos de quince minutos y con la ayuda de un tablero estilo Kanban en el cual las actividades se clasifican en “por hacer”, “en proceso” y “finalizadas”). En esta reunión, cada miembro del equipo cuenta: qué hicieron el día anterior; qué harán el día de hoy; qué harán mañana; qué problemas han encontrado. 6 Al finalizar el Sprint, se lleva a cabo una reunión denominada Sprint Review en la cual participan todos los roles y revisan el cumplimento de los objetivos del Sprint para poder entregar el producto. 7 Luego de entregar el producto, se realiza una última reunión denominada Sprint Retrospective en la que se reúne todo el equipo para analizar: qué cosas estuvieron bien hechas; qué cosas podrían haber sido mejores con el fin de mejorar en la próxima iteración. 8 Por último, se vuelve al Producto Backlog y se inicia nuevamente el Sprint Backlog hasta contar con todo el producto finalizado. 2.2.3 Actividades y herramientas Figura 6. Las actividades del SCRUM Fuente: Elaboración propia. En SCRUM, cada iteración entrega valor parcial al producto final. Se dice que debe haber un incremento del producto al finalizar cada Sprint, ya que se intenta obtener un crecimiento orgánico del producto final. Resulta oportuno realizar un resumen sobre las herramientas que utiliza la metodología SCRUM. Figura 7. Las actividades del SCRUM Fuente: Elaboración propia. Figura 8. Tablero de metodología Kanban. Fuente: [Imagen sin título sobre Kanban], s. f., https://bit.ly/3f2wA00. También se pueden considerar algunas herramientas digitales para llevar a cabo el tablero de trabajo. Una de ellas puede ser Trello (Trello.com), una herramienta digital colaborativa con una dinámica de red social (con miembros, comentarios, notificaciones, etiquetas, etcétera) que permite organizar tareas en diferentes tableros, por lo que resulta oportuna para simular los tableros Kanban necesarios para las Daily Scrum. Figura 9. Trello (Trello.com) Fuente: Captura de pantalla de blog.trello.com. ¿En cuál de las buenas prácticas compartidas por SCRUM es útil tener presente un tablero que organice las tareas por hacer, las que están en proceso y las que resta por iniciar? Kanban. Daily Scrums. Sprint Review. Sprint Planning Meeting. SUBMIT Video 1: Resumen de metodología SCRUM #3. SCRUM en Ȳ 6 minutos ȱ | Metodologías Ágiles Fuente: Cristian Henao (2018). #3. Scrum en 6 minutos – Metodologías Ágiles [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=HhC75IonpOU 2.2.4 Aplicabilidad para cierto tipo de proyectos A modo de repaso, podemos mencionar las siguientes características del enfoque ágil de trabajo. No es un solo ciclo, sino que son n ciclos (sprints). Cada ciclo entrega un incremento del producto. El cliente está involucrado en todo el proceso y al final de cada ciclo puede ver los avances de esa iteración y dar feedback. Aplica para proyectos complejos, en los que no hay una claridad total de los requisitos al inicio del proyecto, sino que se van refinando a medida que este transcurre. Los interesados en el proyecto están dispuestos a participar activamente durante el transcurso del proyecto. Son proyectos donde es bueno, sirve, ayuda ir obteniendo versiones iniciales del producto final y así asegurar un final como el que todos esperan. Lección 4 de 9 Anexo: manifiesto ágil Como se indica en agilemanifesto.org (2011), los siguientes principios representan y resumen el espíritu de lo que se pretende lograr con el uso de las buenas prácticas de SCRUM: 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 cara a cara. 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 autoorganizados. 12 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su (agilemanifiesto.org, 2001, https://bit.ly/2WbuBhh). comportamiento en consecuencia. Lección 5 de 9 GLOSARIO 1 Metodología tradicional o en cascada: metodología de gestión de proyectos que se aplica en aquellos proyectos simples en los cuales los requerimientos están bien detallados al inicio del proyecto y para los que contamos con el conocimiento de las herramientas necesarias para llevar a cabo el proyecto. 2 Metodologías ágiles: metodología de gestión de proyectos que se aplica en proyectos complejos, en los que el nivel de conocimiento de los requerimientos no es total ni detallado al inicio de aquellos y para los que no contamos con el nivel de conocimiento necesario sobre las herramientas para desarrollar con normalidad el proyecto. 3 SCRUM: una de las metodologías ágiles que comparte un conjunto de buenas prácticas, roles y herramientas con las que se busca ayudar a gestionar de la mejor manera proyectos complejos. Se basa en los ciclos de vida iterativos y adaptativos en la ejecución de un proyecto. 4 Product Owner: representante del cliente en el proceso; tiene la responsabilidad de aclarar la necesidad de este. 5 Scrum Master: líder del equipo de trabajo, es un facilitador de la gestión de este. Asegura el foco de gestión del equipo y las prácticas de la metodología SCRUM. 6 Team: equipo de trabajo conformado por personas altamente capacitadas que ejecutarán las distintas tareas del proyecto. 7 Product Backlog: documento que detalla las necesidades del producto a producir o ejecutar. 8 Sprint Planning Meeting: reunión en la que el Product Owner les presenta el Product Backlog al Scrum Master y al Team para que puedan elaborar una definición de los alcances del próximo ciclo de trabajo (Sprint). 9 10 Sprint Backlog: documento que detalla lo que se abordará en el Sprint. Sprint: se trata de un ciclo de gestión a lo largo de la ejecución del proyecto y es la parte fundamental de la metodología SCRUM. Cada uno de estos ciclos de gestión deben durar, dependiendo de la complejidad de lo que deben desarrollar, entre una y cuatro semanas. 11 Daily Scrum: Se trata de una reunión diaria en la que cada miembro del equipo Team cuenta qué hizo el día anterior, qué hará el día de hoy, qué hará mañana y qué problemas ha encontrado. 12 Sprint Review: es una reunión en donde participan todos los roles y revisan el cumplimento de los objetivos del Sprint para poder entregar el producto. 13 Sprint Retrospective: una reunión en la que se reúne todo el equipo para analizar qué se hizo bien y qué podría haberse hecho mejor, con el fin de mejorar en la próxima iteración. Lección 6 de 9 Video de habilidades Verify to continue We detected a high number of errors from your connection. To continue, please confirm that you’re a human (and not a spambot). I'm not a robot reCAPTCHA Privacy - Terms Steve habla estrictamente de la metodología SCRUM. Verdadero. Falso. SUBMIT En este caso, la metodología de trabajo de Apple se asemeja con la SCRUM debido al sentido colaborativo de trabajo. Verdadero. Falso. SUBMIT En este caso, la metodología de trabajo de esta exitosa empresa se asemeja con la SCRUM debido a los siguientes 2 aspectos: La coordinación de reuniones de seguimiento. La intervención de su secretaria como Scrum Master. La concreción de Daily Scrums. La intervención de Steve como Product Owner. SUBMIT ¿Cuál es el rol de Steve Jobs en Apple? Team. Scrum Master. Product Owner. Product Backlog. SUBMIT El rol de Steve en su empresa se asimila al Scrum Master. Verdadero. Falso. SUBMIT Lección 7 de 9 Cierre Complejidad de los proyectos – La complejidad de todo proyecto que debamos gestionar se encuentra condicionada por diversos factores que determinan que un proyecto sea más o menos complejo ¿Cómo gestionamos la complejidad de los proyectos? Básicamente, podemos agrupar en dos las maneras de manejar la complejidad de un proyecto: con metodología en cascada o con metodologías ágiles. Metodologías tradicionales o en cascada – Queda claro que los proyectos sencillos pueden llevarse a cabo con una metodología de gestión de proyectos simple en la que se sigue una sucesión de pasos y secuencias ordenadas para llegar a cumplir con el objetivo del proyecto. ¿Qué complejidades puede tener esta modalidad de gestión de proyectos? El cliente del proyecto no tiene posibilidad de ver un adelanto de lo que será, sino que se encontrará con el producto terminado tal cual como lo describió varios meses atrás. El mercado pide otra cosa – El mundo y el mercado evolucionan tan rápidamente que así también lo hacen las necesidades de la gente. Esto hace que sea extremadamente difícil poder determinar el 100% del detalle de lo que se necesita antes de comenzar un proyecto. ¿Qué es SCRUM? – SCRUM es una metodología de gestión de proyectos que brinda: buenas prácticas, herramientas y roles de gestión; SCRUM es una de las metodologías ágiles que comparte un conjunto de buenas prácticas, roles y herramientas que buscan ayudar a gestionar de la mejor manera proyectos complejos. Se basa en los ciclos de vida iterativos y adaptativos en la ejecución de un proyecto. ¿Quiénes participan de un Scrum? – Product Owner: es el representante del cliente en el proceso y tiene la responsabilidad de aclarar la necesidad que este tiene. Scrum Master: es el líder del equipo de trabajo; es un facilitador de la gestión de trabajo. Asegura el foco de gestión del equipo y las prácticas de la metodología SCRUM. Team: es el equipo de trabajo conformado por personas altamente capacitadas que ejecutarán las distintas tareas del proyecto. Lección 8 de 9 Referencias agilemanifesto.org. (2001). Manifiesto por el Desarrollo Ágil de Software. Recuperado de https://agilemanifesto.org/iso/es/manifesto.html Figura 4. [Imagen sin título sobre el método ágil SCRUM]. (s. f.). Recuperada de https://programaenlinea.net/wp-content/uploads/2016/06/scrum-diagrama.png Figura 8 [Imagen sin título sobre https://wiki.kefir.red/farm/wiki.kefir.red/a/ad/Kanban.png Kanban]. (s. f.). Recuperada de Lección 9 de 9 Descargá la lectura Módulo 2. Enfoques y metodologías en la gestión de proyectos.pdf 7.7 MB Gestión de proyectos - Módulo 2.mp3 8.1 MB