Estudio de metodologías ágiles en la gestión de proyectos industriales.

UNIVERSIDAD DE VALLADOLID ESCUELA DE INGENIERÍAS INDUSTRIALES Grado en Ingeniería en Organización Industrial Estudio de metodologías ágiles en la gestión de proyectos industriales. Autor: Fernández Hernández, Tania Tutor: Gonzalo Tasis, Margarita Departamento de Informática Valladolid, mayo 2021. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 1 RESUMEN En el presente trabajo se han estudiado las metodologías de gestión ágil de proyectos y más en concreto el marco de trabajo Scrum, una de las prácticas más comunes dentro de esta gestión ágil. Tras este estudio se procederá a sintetizar toda la información detallando en el documento todas las partes intervinientes en el marco de trabajo seleccionado. La finalidad del trabajo es demostrar que el marco de trabajo Scrum se puede aplicar a la gestión de proyectos industriales. Para ello se incluyen una serie de cambios en la práctica Scrum. Se aplicará dicha metodología ágil a un caso práctico, en el que se simulará como sería la gestión de un proyecto industrial utilizando el marco de trabajo Scrum. Obteniendo un resultado que compararemos con el modelo de gestión real que se utilizó en el proyecto. El documento se concluirá con una serie de aprendizajes sobre la materia estudiada, en los que se detallarán las ventajas y los inconvenientes de utilizar este tipo de metodologías ágiles en proyectos industriales, así como en qué casos sería conveniente utilizar esta metodología y de qué manera. PALABRAS CLAVE Scrum, Sprint, Scrum Master, Metodología, Ágil Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 2 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 3 ABSTRACT In this paper we have studied the agile project management methodologies and more specifically the Scrum framework, one of the most common practices within this agile management. After this study, we will proceed to synthesise all the information, detailing in the document all the parties involved in the selected framework. The purpose of the work is to demonstrate that the Scrum framework can be applied to industrial project management. To this end, a number of changes to Scrum practice are included. This agile methodology will be applied to a practical case, in which the management of an industrial project will be simulated using the Scrum framework. The result will be compared with the real management model used in the project. The document will conclude with a series of lessons on the subject studied, in which the advantages and disadvantages of using this type of agile methodologies in industrial projects will be detailed, as well as in which cases it would be convenient to use this methodology and in what way. KEYWORDS Scrum, Sprint, Scrum Master, Methodology, Agile Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 4 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 5 “It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.” Theodore Roosevelt, 1910 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 6 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 7 ÍNDICE DE CONTENIDO ÍNDICE DE FIGURAS ..........................................................................................................9 Capítulo I: Introducción ...........................................................................................13 1.1. OBJETIVOS Y ALCANCE ....................................................................................... 13 1.2. ESTRUCTURA DEL DOCUMENTO ......................................................................... 14 Capítulo II: Metodología ágil...................................................................................15 2.1. Manifiesto ágil................................................................................................... 15 2.2. Valores del manifiesto ágil ................................................................................. 16 2.3. Principios del manifiesto ágil.............................................................................. 17 Capítulo III: Marco de trabajo Scrum .......................................................................19 3.1. La solución del FBI, Scrum .................................................................................. 19 3.2. Definición de Scrum ........................................................................................... 21 3.2.1. Pilares de Scrum ............................................................................................ 22 3.2.2. Valores de Scrum ........................................................................................... 23 3.2.3. Usos de Scrum ............................................................................................... 24 3.3. El Equipo Scrum (Scrum Team) ........................................................................... 25 3.3.1. Propietario del Producto (Product Owner) ..................................................... 26 3.3.2. Equipo de Desarrollo (Development Team) .................................................... 27 3.3.3. Scrum Master ................................................................................................ 29 3.4. Eventos Scrum (Scrum Events) ........................................................................... 30 3.4.1. Sprint ............................................................................................................ 31 3.4.2. Planificación del Sprint (Sprint Planning) ........................................................ 32 3.4.3. Objetivo del Sprint (Sprint Goal) .................................................................... 34 3.4.4. Scrum Diario (Daily Scrum)............................................................................. 34 3.4.5. Revisión del Sprint (Sprint Review) ................................................................. 35 3.4.6. Retrospectiva del Sprint (Sprint Retrospective) ............................................... 36 3.4.7. Reunión de Propietarios del Producto ............................................................ 37 3.5. Artefactos Scrum (Scrum Artifacts) ..................................................................... 38 3.5.1. Pila del Producto (Product Backlog) ................................................................ 38 3.5.1.1. Seguimiento del progreso hacia los objetivos ................................................. 39 3.5.2. Pila del Sprint (Sprint Backlog) ....................................................................... 42 3.5.3. Definición de “Terminado” (Definition of Done “DoD”) ................................... 43 3.5.4. Incremento (Increment) ................................................................................. 43 3.5.5. Definición de “Listo” (Definition of Ready “DoR”) ........................................... 44 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 14 1.2. ESTRUCTURA DEL DOCUMENTO Con motivo de alcanzar la resolución de los objetivos propuestos para este trabajo de fin de grado, se dividirá el documento de la siguiente manera: En primer lugar, los capítulos II y III, presentarán los estudios correspondientes a la metodología ágil y una de sus prácticas, el marco de trabajo Scrum, el cual se utilizará durante el desarrollo de todo el trabajo y en el que se centrará la atención de este. Aquí se explicará en que consiste, cuáles son sus objetivos, sus componentes y, sus diferentes usos y aplicaciones. Esto dará lugar, en el capítulo IV, a una comparativa entre las distintas metodologías, en la que se enumerarán sus principales diferencias, ventajas e inconvenientes. Acto seguido, en el capítulo V, se encontrará la presentación del caso práctico que se va a utilizar para la aplicación del marco de trabajo Scrum, detallándose el proyecto seleccionado, explicando en qué consistió, quién lo realizó y cómo se gestionó. Tras la realización de la presentación, se pasará a la selección de la herramienta de trabajo que se utilizará en el caso práctico, realizando, una comparativa entre las dos opciones más famosas del mercado para estas prácticas, y una vez seleccionada la herramienta con la que se va a trabajar, se redactará una guía práctica para su correcta utilización, siendo el siguiente paso la resolución del caso práctico propuesto. En último lugar, una vez finalizada la práctica, en el capítulo VI, podremos observar un listado de las conclusiones y los aprendizajes, que se habrán obtenido durante la realización del presente trabajo de fin de grado. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 15 Capítulo II: Metodología ágil La metodología nace en febrero de 2001, de la mano de distintos desarrolladores cuyo fin era promover metodologías de desarrollo ligero. Para estos desarrolladores, era esencial conseguir crear un modelo en el que cada iteración del ciclo de desarrollo “aprendiera” y “mejorara”, a partir de la iteración anterior, logrando así una mejora continua en todo el proceso. Obteniendo como resultado una metodología eficiente, flexible y orientada al equipo. Existen diferentes métodos ágiles, pero todos y cada uno de ellos se basan en el manifiesto ágil y en sus 12 principios básicos. 2.1. Manifiesto ágil El manifiesto ágil se crea en Utah, en el año 2001, de la mano de los CEOs de las principales empresas de desarrollo de software del momento. Este manifiesto es un documento que define la mejora continua mediante la planificación, la creación y la comprobación de resultados, de una forma más rápida, que busca ante todo reducir los plazos de entrega, para evitar así la dispersión del trabajo y centrar la atención del equipo en la tarea que se está realizando en cada momento. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 16 2.2. Valores del manifiesto ágil Los valores sobre los que se establece el manifiesto ágil son los siguientes: o Valorar más a los individuos y sus interacciones que a los procesos y las herramientas. Al reconocer que el software lo hacen las personas, no los procesos, ni las herramientas, se les otorgará una importancia mayor a las personas, que trabajarán juntas y de manera efectiva. Los procesos y las herramientas serán una ayuda o un medio para realizar una tarea, pero nunca podrán reemplazar a las personas, por ello prima su importancia. o Valorar más un software que funciona, que la documentación exhaustiva. Esta es una clara oposición a la tradicional metodología ‘en cascada’. La metodología ágil nos dice, que un documento lleno de especificaciones y detalles, preciso y completo, no tiene ningún tipo de valor si no nos da como resultado, un software que funcione de la manera correcta que esperan los usuarios. o Valorar más la colaboración directa con el cliente, que la negociación contractual. La metodología ágil tiene en cuenta la realidad de los contratos, pero cree que una colaboración activa y directa con el cliente, durante todo el proceso de desarrollo del software, es una mejor manera de ofrecer valor, que mediante la redacción de un contrato muy detallado. Un contrato no puede ser un sustituto de comunicación, cuando se está desarrollando un proyecto. o Valorar más la respuesta ante el cambio, que seguir con el plan establecido. A excepción de los desarrollos más simples, es una ardua tarea pensar en todas aquellas funciones, datos y posibles casos de uso del software. Esto implicará, un proceso de colaboración con el cliente durante todo su desarrollo. Las necesidades y prioridades del proyecto no son algo fijo, por lo que podrán cambiar según vaya pasando el tiempo. Y este es uno de los motivos, por los que la metodología ágil valora tanto la capacidad de adaptación al cambio. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 17 2.3. Principios del manifiesto ágil Éstos son los 12 principios que refuerzan el manifiesto ágil, dando más luz a los valores ágiles del desarrollo del software. 1. La prioridad principal es satisfacer al cliente a través de la entrega temprana y continua de ´software’ con valor. 2. Se aceptará que los requisitos cambien en cualquier etapa del desarrollo del proyecto, incluso en las más tardías. Los procesos ágiles aprovecharán estos cambios para proporcionar una ventaja competitiva a los clientes. 3. Se entregará un software funcional con frecuencia. Estas frecuencias variarán, de 2 semanas hasta 2 meses, siendo siempre preferibles los plazos de entrega más tempranos. 4. Los responsables del proyecto, así como del negocio, trabajarán de forma coordinada con los desarrolladores, durante todo el proyecto. 5. Los proyectos han de desarrollarse en torno a personas motivadas. Hemos de proporcionarles el entorno y el apoyo que necesiten, así como confiarles la ejecución del trabajo. 6. La conversación cara a cara es el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros. 7. Un software que funciona es la mejor medida de progreso. 8. Los procesos ágiles promueven un desarrollo sostenido, es decir, tanto promotores, desarrolladores, como usuarios, han de mantener un ritmo constante de forma indefinida. 9. La continua atención a la excelencia técnica y al buen diseño, mejoran 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, nacen de equipos auto organizados. 12. Con intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 18 El modelo que propone Ahmed Sidky (Project Management Institute, Inc, 2017), señala a ágil como una mentalidad que se define por los valores del manifiesto ágil, que se guía por los 12 principios de éste y que se habilita por diversas prácticas. En los últimos años, esta metodología de gestión ágil ha ganado popularidad y su uso se ha extendido a múltiples organizaciones. Utilizándose de esta forma en una variedad muy amplia de proyectos de diferentes índoles y complejidades. Una de las aplicaciones de esta metodología, se lleva a cabo en proyectos industriales y en concreto con una de sus prácticas más conocidas, el marco de trabajo Scrum, el cual será el principal objeto de estudio de este trabajo. Figura 1. Ejemplificación del pensamiento ágil. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 19 Capítulo III: Marco de trabajo Scrum 3.1. La solución del FBI, Scrum Durante los años 2000, el FBI contaba con un grave problema de gestión de la información. Dicha información (expedientes, informes, pruebas…), se almacenaba impresa con un número de identificación. De hecho, se tiene la certeza de que este sistema tan arcaico fue uno de los principales culpables del atentado terrorista del 11 de septiembre. Diferentes investigaciones concluyeron que se tenía suficiente información, como para haber podido prever el atentado. El problema fue que la información estaba demasiado dispersa dentro del FBI y nadie fue capaz de ponerla en común. La solución al problema habría sido la existencia de un software para la gestión de la información de la agencia. Estos acontecimientos darían lugar al desarrollo de diferentes proyectos de software para el FBI. El primero de estos proyectos se llamó Virtual Case File (VCF) y se llevó a cabo entre los años 2000 y 2005. En él se invertirían 170.000.000$, pero nunca se llegó a poner en marcha, cancelándose sin ningún resultado. En 2005 se encargó un nuevo proyecto, de nombre SENTINEL, el cual estaría listo en 2009 y necesitaría una inversión de 451.000.000$. La empresa encargada de su realización fue Lockheed Martin. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 20 Pero SENTINEL no siguió en absoluto sus directrices y ante la imposibilidad de llegar a la meta en tiempo y coste, su director, Chad Fulgham pidió ayuda a Jeff Johnson, creador del marco de trabajo Scrum. Jeff Johnson logró dar con la solución para SENTINEL en marzo de 2010. En ese momento se habían gastado 405.000.000$ y se llevaba un año de retraso, habiéndose completado únicamente la mitad del trabajo del proyecto. Johnson determinó que el fallo no estaba en los profesionales, ni en la tecnología utilizada, si no en la forma de trabajar de la gran mayoría. Se había perdido una cantidad enorme de tiempo en planificar cómo sería el trabajo, sin contemplar que sería imposible seguir dicha planificación, en cuanto apareciese el primer problema que no se hubiera contemplado, nada de lo planificado serviría de ese momento en adelante. SENTINEL cambiaría de rumbo, solo podría llevarse a cabo si el FBI asumía su desarrollo y se disminuía a la mitad el número de desarrolladores. De esta forma, se entregaría la parte restante del proyecto en menos de una quinta parte del tiempo y en menos de una décima parte del presupuesto. El FBI aceptó la propuesta, pero con gran escepticismo. La clave del proyecto sería su realización utilizando el marco de trabajo Scrum, el cual lograría una productividad mucho mayor, gracias a sus métodos de inspección y adaptación. Una de las primeras acciones que se realizaron fue la priorización de requerimientos. En lo que al desarrollo del software se refiere, impera una regla que dice lo siguiente: “El 80% del valor de un componente de software, reside en el 20% de sus funciones”. Por ello, lo primero que tuvieron que hacer los equipos de Johnson, fue buscar ese 20% de las funciones. El FBI le pidió una fecha aproximada de entrega a Johnson, quien no estaba a favor de dar fechas en etapas tempranas del desarrollo. Esto se debía a que, para dar una fecha correcta, Johnson necesitaba ver cómo se desarrollaban sus equipos, cómo se aceleraban, cómo aumentaban su productividad de una semana a otra… etc. Durante el tercer mes de desarrollo pudo por fin dar una fecha correcta. La principal tarea de Johnson era eliminar todos aquellos impedimentos que dificultaran el trabajo de los equipos. El término “impedimento”, tal y como lo entendemos dentro del marco de trabajo Scrum, procede de una compañía que ha forjado muchas de sus ideas principales, TOYOTA. TOYOTA basa su trabajo en la idea de flujo, la producción tiene que fluir veloz e ininterrumpidamente a lo largo de todo el proceso y todo lo que hace que esto no pueda ser así, se consideraría impedimento. Establecieron periodos de trabajo de dos semanas, a los que llamaron sprints, de los que se obtenía retroalimentación de todas las partes interesadas a su finalización, lo cual les permitió mejorar periodo a periodo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 21 Finalmente tardaron 18 meses en codificar la base de datos para el FBI y dos meses más para configurarla y ponerla en marcha. De tal forma que, en ese tiempo y con tan sólo un 5% del presupuesto total, se consiguió realizar lo que no se pudo en 10 años y con el 90% del presupuesto. En Julio del 2012 comenzó a andar SENTINEL y hoy en día continúa haciéndolo. Con este ejemplo se busca señalar la importancia de este marco de trabajo y de esta nueva forma de gestión ágil de proyectos, la cual permite hacer más trabajo en menos tiempo y de una forma mucho más flexible y adaptativa. 3.2. Definición de Scrum Scrum, es un marco de trabajo a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor. Scrum cuenta con las siguientes características: o Ligero y simple de entender, lo cual se debe a su estructura perfectamente definida. o Difícil de dominar, ya que su práctica requiere de mucho esfuerzo y constancia en todas las etapas del desarrollo. Este marco de trabajo se implementa desde principios de los años 90. Sus técnicas y procesos se pueden utilizar indistintamente para alcanzar los objetivos del proyecto. Con Scrum se logrará una mejora continua tanto en procesos, cómo en el equipo y su trabajo. Los componentes del marco de trabajo Scrum son: o El equipo Scrum y sus respectivos roles. o Eventos. o Artefactos. o Reglas asociadas. Estos componentes son una serie de personas con uno roles asignados, que utilizan unas herramientas en diferentes periodos de tiempo o eventos y que se guían por unas reglas específicas de actuación, para lograr completar un proyecto, es decir, que cada componente ha de cumplir con su función y debe relacionarse de la forma correcta con el resto, para conseguir el éxito del marco de trabajo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 22 3.2.1. Pilares de Scrum El marco de trabajo Scrum se basa en la teoría de control de procesos, empírica o empirismo, lo que quiere decir, que se basa en el conocimiento procedente de la experiencia y en base a dichos conocimientos adquiridos, toma las decisiones pertinentes. Existen 3 pilares que soportan todo el peso de la implementación del control de procesos empíricos: o Transparencia: Los aspectos significativos del proceso han de ser visibles para todo aquel que sea responsable del resultado. Estos aspectos se han de definir siempre entorno a un mismo estándar, para que todas las personas implicadas entiendan exactamente lo mismo. Tanto las personas encargadas de realizar el trabajo, como las personas encargadas de inspeccionar el incremento también deberán compartir una definición común de “Terminado” (“Done”). (Dicho término se definirá más adelante). o Inspección: El fin es detectar anomalías en el proceso, por ello los usuarios que utilizan Scrum, deberán realizar inspecciones sobre los artefactos y el progreso hacia el objetivo, frecuentemente. Estas inspecciones no deben interferir en el trabajo del equipo, por lo que es recomendable que las realicen profesionales dentro del entorno de trabajo. o Adaptación: El proceso de adaptación tendrá lugar cuando los inspectores determinen que uno o más aspectos del proceso no cumplen con las tolerancias aceptadas. Por ello, el material o el proceso que se está llevando a cabo, tendrá que ajustarse/adaptarse para conseguir el objetivo final. Estos pilares serán visibles, durante todo el proceso de desarrollo de un proyecto que se realice utilizando el marco de trabajo Scrum. Se podrán encontrar en los eventos y artefactos que utiliza el equipo en todo momento, siendo esencial su correcta aplicación para lograr el éxito del trabajo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 23 3.2.2. Valores de Scrum Figura 2. Valores de Scrum. Estos cinco valores, que terminan de definir el marco de trabajo Scrum serán la base de los procesos e interacciones del equipo Scrum. o Foco: Todos los miembros del equipo se centran en el trabajo del sprint y en alcanzar su objetivo. o Apertura: El equipo y los interesados acuerdan realizar un ejercicio de transparencia durante todo el desarrollo, así como estar abiertos a cambios y desafíos en el trabajo. o Respeto: La relación de los miembros del equipo, se basará siempre en el respeto mutuo, lo que les permitirá ser personas capaces e independientes. o Valor: Los miembros del equipo tendrán coraje para hacer bien su trabajo y valor para enfrentarse a los problemas más difíciles que les surjan. o Compromiso: Los miembros del equipo han de comprometerse a alcanzar los objetivos que se les marcan. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 30 3.4. Eventos Scrum (Scrum Events) Un evento Scrum es un periodo de tiempo limitado o time-box, con una duración máxima. Los diferentes eventos con los que cuenta el marco de trabajo Scrum son: o Sprint. o Reunión de propietarios del producto. o Reunión de Scrum Masters. o Planificación del sprint (Sprint Planning). o Scrum diario (Daily Scrum). o Revisión del sprint (Sprint Review). o Retrospectiva del sprint (Sprint Retrospective). De todos estos eventos, el sprint es el único que cuenta con una duración fija que se establece al inicio del proyecto. El resto de los eventos se podrían terminar antes de tiempo, siempre que se hubiera alcanzado el objetivo fijado para ellos. El Sprint es un evento que engloba al resto de eventos mencionados, a excepción de la reunión de propietarios del producto, que solo se llevaría a cabo una vez antes del sprint 0, y cada uno de estos eventos de Scrum, es una nueva oportunidad para la inspección y la adaptación de alguno de los aspectos. Se diseñaron con el fin de habilitar los pilares vitales de la transparencia, la inspección y la adaptación. Para el desarrollo de proyectos industriales, añadiríamos un par de eventos a mayores, una reunión de propietarios del producto anterior al sprint 0 del proyecto, y una reunión de Scrum Masters antes de cada reunión de planificación del sprint, se explicarán a continuación con más detalle. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 31 3.4.1. Sprint El sprint es un evento con una duración máxima de 1 mes, en el que se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Contiene al resto de eventos Scrum, a excepción de la reunión de propietarios del producto y cada nuevo sprint comienza tras la finalización del sprint anterior. Durante el Sprint: • No se realizará ningún cambio que afecte al objetivo del sprint (Sprint Goal). • Los objetivos de calidad nunca pueden disminuir. • El propietario del producto y el equipo de desarrollo pueden renegociar el alcance del sprint, a medida que éste se va desarrollando y ambos aprenden más sobre el objeto de su trabajo. • Se considerará cada sprint, como un “Subproyecto” de una duración establecida, no mayor de 1 mes. Éste “Subproyecto” tendrá un objetivo, a partir del cual se construirá un plan, que guiará todo el trabajo del equipo para obtener el incremento del producto “Terminado”. • Se tratará de establecer un horizonte para el sprint asumible, ya que, si el horizonte es muy amplio, la definición de éste podría cambiar con facilidad y la complejidad del sprint incrementarse de la mano del riesgo. Por ello, se afirma que la utilización del sprint es beneficiosa para el trabajo, ya que habilita la predictibilidad, al asegurar la inspección y adaptación del progreso del trabajo, en intervalos de tiempo muy pequeños, con lo que se estaría limitando el riesgo de coste a 1 mes o menos. Cancelación del Sprint o Se podrá cancelar, antes de que el “time-box” llegue a su fin. o El único que puede cancelar un sprint, es el propietario del producto. o Los motivos por los que se podría cancelar este evento de Scrum son: Si el objetivo del sprint (Sprint Goal) queda obsoleto. Si las condiciones del mercado para el proyecto en el que se está trabajando, cambian. Si pasa con la tecnología del proyecto lo mismo que con el mercado. Si la empresa para la que se trabaja cambiara su dirección y esto implicara que el proyecto ya no cumpliría con los requisitos. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 32 o Cuando se cancela un sprint, se revisan los elementos de la pila del producto que se han completado y “Terminado” durante el tiempo que ha estado activo. Si alguna parte del proyecto es potencialmente entregable y va a ser de uso para el proyecto final, el propietario del producto podría aceptarla. o Se revisarán todos los elementos de la pila del producto que no han sido completados y se volverán a estimar, metiéndolos de nuevo a la pila del producto. o Las cancelaciones de este tipo consumen recursos, lo que implicaría costes adicionales Figura 4. Ciclo de vida de un Sprint. 3.4.2. Planificación del Sprint (Sprint Planning) Es el primer evento que transcurre dentro del sprint, en esta reunión se planificará el trabajo que debe realizar el equipo Scrum para lograr el objetivo fijado. Para sprints de 1 mes tendrá una duración de 8 horas. Si la duración del sprint fuera menor, la de la reunión también deberá serlo. En proyectos industriales, esta reunión constará de 2 partes. La primera, correspondería a la reunión de Scrum Masters, en la que los Scrum Master de los equipos que trabajan en paralelo, se repartirían los recursos disponibles, de cara a la realización del nuevo sprint. Aquí es donde se forman los equipos de desarrollo para cada sprint, siempre en función a lo establecido en la reunión de revisión del sprint anterior. Una vez se finaliza esta reunión, el equipo Scrum formado para este sprint, procede con la segunda parte de la reunión de planificación. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 33 La segunda parte es donde se planifica qué y cómo hay que realizar el trabajo para conseguir el incremento de producto “Terminado”, para ello el equipo Scrum debe responder a 2 preguntas: o ¿Qué se puede entregar en el incremento resultante del Sprint? o ¿Cómo conseguiremos realizar todo el trabajo necesario para entregar el incremento “Terminado”? A la primera de las preguntas, el equipo Scrum respondería de la siguiente manera: o El equipo de desarrollo trabaja con el fin de definir que funcionalidad o parte del proyecto se desarrollará durante el sprint. o El propietario del producto establece el objetivo que se debe alcanzar en el sprint y qué elementos de la pila del producto se deben completar para lograr el objetivo. o El Scrum Master se encargará de que todo el equipo Scrum logre entender la finalidad del trabajo y que se trabaje de manera ágil. La entrada a este evento Scrum se constituye por: Pila del producto El último incremento de producto La capacidad proyectada del equipo de desarrollo para el sprint El rendimiento del sprint anterior del equipo de desarrollo El número de elementos de la pila del producto seleccionados para el sprint normalmente dependía del equipo de desarrollo. Esto se debía a que el tamaño del equipo era invariable en el tiempo, entonces eran ellos los encargados de determinar cuánta cantidad de trabajo podían realizar en el tiempo estimado del sprint. Pero en proyectos industriales, al ser los equipos de desarrollo diferentes en cada sprint, el encargado de seleccionar los elementos de la pila del producto será, el propietario del producto. A la segunda de las preguntas, el equipo Scrum respondería de la siguiente manera: o Con el objetivo claramente definido y los elementos de la pila del producto que se van a completar, seleccionados, el equipo de desarrollo decidirá cómo va a construir la funcionalidad, para formar un incremento “Terminado”, de ese producto/parte de proyecto. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 34 En este evento, se crea otro de los artefactos que se utilizarán en Scrum, la pila del sprint. De ella se puede adelantar que es el conjunto de elementos de la pila del producto seleccionados para completar en el sprint, más el plan de cómo hacerlo. 3.4.3. Objetivo del Sprint (Sprint Goal) o El objetivo del sprint (Sprint Goal) es la meta que se pretende lograr mediante la implementación de la pila del producto. o Es una guía del “porqué” se realiza cada paso, para el equipo de desarrollo. o Se crea durante la planificación del sprint. o Este objetivo, común a todos, consigue que los integrantes del equipo de desarrollo hagan punto de unión y trabajen en conjunto y no con iniciativas individuales que normalmente alejan el resultado del objetivo marcado. o Con el fin de satisfacer el objetivo, se implementa la funcionalidad y la tecnología. 3.4.4. Scrum Diario (Daily Scrum) Este evento, es una reunión diaria que cuenta con una duración aproximada de 15 minutos, siempre tiene lugar a la misma hora y se realiza única y exclusivamente para el equipo de desarrollo. Aquí se plantea el trabajo que se va a llevar a cabo en las próximas 24 horas. La reunión consigue optimizar la colaboración y el desempeño del equipo de desarrollo con la inspección del trabajo avanzado desde el último día y con la proyección del trabajo que se realizará a continuación, utilizándose para evaluar el progreso del equipo hacia el objetivo y la tendencia que sigue hacia la finalización del trabajo de la pila del sprint. Existen 2 tipos de estructura para esta reunión: o Basada en preguntas. o Basada en discusiones. Alguna de las preguntas tipo que se utilizan son: o ¿Qué he hecho para ayudar al equipo de desarrollo a lograr el objetivo del sprint? o ¿Qué voy a hacer para ayudar al equipo de desarrollo a lograr el objetivo del sprint? Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 35 o ¿Cuáles son, si es que los hay, los impedimentos para que el equipo de desarrollo no logre alcanzar el objetivo del sprint? Es bastante común que, una vez finalizada la reunión, el equipo de desarrollo o incluso el equipo Scrum al completo, se vuelvan a reunir para discutir alguna de las cuestiones más detalladamente, para adaptar o replanificar el trabajo. Esta reunión mejora la comunicación del equipo de desarrollo, hace que se identifiquen impedimentos, promueve la toma rápida de decisiones (tan importante dentro de este marco de trabajo) y logra aumentar el nivel de conocimiento del equipo en todos sus aspectos. Por lo que esta reunión es clave para la: INSPECCIÓN Y ADAPTACIÓN 3.4.5. Revisión del Sprint (Sprint Review) En este evento Scrum, de 4 horas de duración, participa todo el equipo Scrum y los interesados. Aquí colaboran sobre todo lo que se realizó durante el sprint y determinan, basándose en el trabajo realizado durante el sprint, los siguientes pasos a seguir. Es decir, lo siguiente que se va a hacer para aportar valor al producto/proyecto, siendo su principal objetivo, fomentar la retroalimentación de información y la colaboración. La reunión se desarrolla de la siguiente manera: o Asisten el equipo Scrum y los invitados que el propietario del producto considera. o El propietario del producto explica qué elementos de la pila del producto se han completado y “Terminado” y cuáles no. o El equipo de desarrollo comenta los aspectos positivos del desarrollo, los problemas que se identificaron y cómo fueron resueltos. o El equipo de desarrollo realiza una demostración del trabajo “Terminado” y contesta a las preguntas del resto de asistentes de la reunión sobre el incremento realizado, con el fin de aclarar cualquier tipo de duda que exista sobre el producto/parte del proyecto “Terminado”. En los proyectos industriales, esto varía en función de la parte que se haya completado, por ejemplo, si se ha terminado de fabricar unas tuberías, no habría como “probar” eso, simplemente se inspeccionaría y se vería el resultado final. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 36 o El propietario del producto habla sobre la pila del producto y su estado actual. Proyecta los objetivos más probables y sus fechas de entrega, basándose siempre en el progreso obtenido hasta la fecha. o Todos los participantes de la reunión colaboran sobre qué hacer a continuación, consiguiendo de esta forma obtener información valiosa para la siguiente reunión de planificación del sprint. o Acto seguido, se revisa la cronología, el presupuesto, las capacidades potenciales y el estado del mercado para la próxima entrega prevista del producto. Se obtiene como resultado de esta reunión: Una Pila del Producto revisada, que defina los elementos para el próximo Sprint. Con un posible ajuste general para enfocarse en nuevas oportunidades. 3.4.6. Retrospectiva del Sprint (Sprint Retrospective) Este evento de 3 horas de duración es una oportunidad para el equipo Scrum, de inspeccionarse y crear un plan de mejoras para el siguiente sprint. Los propósitos de la retrospectiva son los siguientes: o Inspeccionar cómo fue el último sprint en cuanto a: • Personas. • Procesos. • Herramientas. o Identificar y ordenar los elementos más importantes que salieron bien en el sprint y las posibles mejoras a todos ellos. o La creación de un plan para implementar estas mejoras al trabajo de todo el equipo Scrum. El Scrum Master motiva a todo el equipo para que mejore sus procesos de desarrollo y sus prácticas, para hacerlos de esta forma más efectivos y amenos. De la misma manera, ayudará a planificar nuevas formas para la mejora de la calidad, mejorando la calidad de los procesos. Se obtiene como resultado de la retrospectiva del sprint: Plan de Mejoras Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 37 Aquí se muestra la implicación de los participantes del marco de trabajo en cada evento de este: Figura 5. Resumen del funcionamiento del marco de trabajo Scrum. Figura 6. Tabla implicaciones Rol-Evento. 3.4.7. Reunión de Propietarios del Producto Esta reunión, tendrá lugar en proyectos industriales. Será el primer evento que se lleve a cabo de todo el proyecto, en ella se reunirán todos los propietarios del producto para dividir el proyecto en “proyectos” más pequeños y manejables. Priorizarán esa lista de partes del proyecto y se las repartirán entre ellos, de esta forma, cada propietario del producto junto con su equipo Scrum, llevará a cabo su parte del proyecto siguiendo con la metodología ágil tal y como la conocemos. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 38 3.5. Artefactos Scrum (Scrum Artifacts) Los artefactos, son las herramientas con las que cuenta el equipo Scrum para llevar a cabo su trabajo, proporcionan la transparencia tan buscada en este marco de trabajo y, además, aportan oportunidades para la inspección y la adaptación de los procesos y el equipo. Existen 3 artefactos dentro del marco de trabajo Scrum: o Pila del producto (Product Backlog). o Pila del sprint (Sprint Backlog). o Incremento (Increment). 3.5.1. Pila del Producto (Product Backlog) La pila del producto es: Una lista ordenada, que contiene todos los elementos que el propietario del producto considera que son necesarios para llevar a cabo el proyecto, siendo así, la única fuente de requisitos de este. El único responsable de la pila del producto es el propietario del producto, esto incluye: • El contenido. • La ordenación. • La priorización. Este artefacto es dinámico, ya que evoluciona con el propio proyecto, esto quiere decir, que la pila del producto se puede ir completando a medida que pasa el tiempo y van cambiando las necesidades del proyecto. No desaparecerá una vez se haya concluido el proyecto, ya que cuando el producto/proyecto está en el mercado, se obtiene una gran retroalimentación que servirá para implementar nuevas funcionalidades en el futuro. La pila del producto solo desaparecería si el producto/proyecto lo hiciera también. En los proyectos industriales, existirá una pila genérica que contendrá todos los requisitos del proyecto. Al ser esta pila de un tamaño mucho mayor al deseado, se dividirá en partes, similares a proyectos más pequeños dentro del proyecto. Por cada una de estas nuevas pilas, se tendrá un propietario del producto y un equipo de desarrollo trabajando en ella. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 39 Refinamiento de la pila del producto (Product Backlog Refinement) Refinamiento (Refinement): Es el acto de añadir detalle, estimaciones y orden a los elementos de la pila del producto. Es un proceso continuo donde colaboran: • Propietario del producto. • Equipo de desarrollo. Durante el refinamiento de la pila del producto, se examinan y revisan todos sus elementos. Siendo el equipo Scrum, quién decide cuando se realiza y no consumiendo más del 10% de la capacidad del equipo de desarrollo. 3.5.1.1. Seguimiento del progreso hacia los objetivos Gracias al estado de la pila del producto, el propietario del producto realiza un seguimiento del trabajo restante total, por lo menos en cada revisión del sprint. Se compara de esta manera, la cantidad de trabajo restante total, con la cantidad de trabajo restante que se obtuvo en la anterior revisión del sprint, para evaluar de esta forma el progreso que se lleva hacia la finalización del producto en el tiempo deseado. Esta información es totalmente transparente y se muestra a todos los miembros del equipo Scrum. Estas son algunas de las prácticas de proyección de tendencia que han resultado ser de gran utilidad: o Gráfica del trabajo pendiente (Burn-Down Chart). o Gráfica del trabajo completado (Burn Up Chart). o Diagrama del flujo de trabajo acumulado (Cumulative Flow Diagram). Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 46 3.7. Ventajas y desventajas de Scrum Las principales ventajas de este marco de trabajo serían: o El cliente podrá comenzar a utilizar su producto: Debido a esto, el equipo obtendrá periódicamente feedback sobre el producto que se está desarrollando, lo que le permitirá adaptarse a las necesidades del cliente, implementando nuevas funcionalidades. En el caso de un proyecto industrial, esto variará. Después de cada entrega se obtendrá feedback de nuestro cliente, nuestro Product Owner o nuestros trabajadores, pero hasta la finalización del proyecto, la utilización de alguna de las partes “Terminadas” no tendría sentido. o Poder decidir la dirección del proyecto: Gracias a las entregas periódicas y a la capacidad de adaptación frente a los cambios del equipo, éste podrá decidir la dirección del proyecto en todo momento. o Divide y vencerás: Dividir el proyecto en “subproyectos” más pequeños y abordables, ayuda al equipo en su desarrollo. Las entregas periódicas aportarán ritmo de trabajo al equipo que, de esta manera, podrá medir su progreso hacia la meta de una forma clara. o Disminuir las sorpresas: Dicha metodología ágil, permite al equipo Scrum seguir una evolución de su trabajo muy detallada. La revisión del trabajo después de cada sprint permitirá ver que errores se han cometido, lo que es una gran ventaja, puesto que, de haber fallos, tan solo estarían perdiendo el tiempo de un sprint, algo perfectamente asumible para el equipo. Por lo contrario, las desventajas con las que cuenta el marco de trabajo serían: o El equipo Scrum estará tentado de tomar el camino más corto: En cada sprint, se tienen que completar una serie de elementos de la pila del producto, en un tiempo determinado. Esto implica que, cuando quedan elementos por completar y se echa el tiempo encima, se decida “completar a medias” alguno de estos elementos. Esto es un error puesto que podría implicar futuras consecuencias. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 47 o Necesitar fechas de entrega con mucha antelación: Es muy difícil establecer cuando se va a terminar algo que ni siquiera se ha empezado. Dar una fecha de entrega correcta, con demasiada antelación, será imposible con este marco de trabajo, pues es necesario ver cómo trabajan los equipos para estimar el tiempo de desarrollo, correctamente. o Estrés: Este tipo de metodología requiere mucho esfuerzo, ya que es un trabajo de fondo. Esto puede provocar mucho estrés en el equipo, ya que mantener el ritmo de trabajo durante mucho tiempo puede ser complicado. Por ello precisamos de un equipo entrenado, que responda bien ante el cambio y que sea capaz de no bajar el ritmo de trabajo. o La realidad de los equipos auto organizados: Ningún equipo se va a dedicar a tareas concretas, en este marco de trabajo se pretende que los equipos trabajen en conjunto. El problema aquí nace, cuando el equipo no cuenta con un miembro que sea experto en algún ámbito necesario de su trabajo y se queda “cojo”. La clave estaría en formar un equipo completo, que pudiera atender a todas las necesidades del proyecto. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 48 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 49 Capítulo IV: Comparación entre metodologías de gestión de proyectos 4.1. Metodología tradicional de gestión de proyectos en cascada Esta metodología de gestión de proyectos en cascada se corresponde, con un proceso secuencial que sigue un orden concreto. El contenido del proyecto se estructurará de una forma determinada desde un principio, para lograr que el resultado material del mismo satisfaga las expectativas, así como, las necesidades de todas las partes interesadas. La metodología nace en los años 50, en proyectos de construcción y fabricación, pero no encontramos una descripción formal de la misma hasta los años 70. El encargado de su realización fue Wiston W. Royce. Uno de los puntos más significativos de este tipo de gestión, es la rigidez de su estructura, esto se debe a la intensa búsqueda de requisitos en la etapa más temprana del desarrollo. El fin de establecer estos requisitos desde el momento inicial, es poder definir el alcance completo del proyecto, con ello se pretende anticipar cualquiera de los problemas que pudieran surgir. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 50 Para la búsqueda de requisitos y el establecimiento del alcance, existe una fase llamada, fase de requerimientos o fase de especificaciones. La especificación de un proyecto consistirá en la recopilación de los requisitos, con sus correspondientes documentos en los que se describirán con detalle y todos los pasos que habrán de seguirse durante el desarrollo del proyecto. Estos requisitos deberán ser medibles, alcanzables y realistas. La gran mayoría de las veces los clientes no son capaces de definirlos con total claridad, por ello, el trabajo del equipo de proyectos será esencial en esta cuestión, determinar y definir correctamente los requisitos. En la viñeta superior se puede observar el problema que podría suponer una mala definición de los requisitos. La fase de requerimientos ayudará al equipo de dirección de proyectos a definir el llamado plan de proyecto, que será la guía que toda persona implicada en el proyecto deberá seguir. Esta guía tendrá que responder a las siguientes cuestiones: o ¿Qué hay que hacer? o ¿Cómo hay que hacerlo? o ¿Cuándo tiene que estar terminado? o ¿Cuánto dinero costará hacerlo? o ¿Quién será el responsable de la realización de las diferentes tareas? Figura 12. Viñeta sobre los requerimientos. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 51 Con relación a la última de las preguntas, dentro de la metodología tradicional de proyectos, existe un rol dentro del equipo que destaca sobre los demás. Esta persona es el jefe de proyectos, será el responsable del trabajo de todo el equipo. Su posición estará por encima de la del resto de miembros del equipo, lo que se debe a que es el máximo responsable del proyecto. Una de las herramientas que más se utilizan en este tipo de gestión son los diagramas de Gantt. En ellos se definirán todas las actividades que componen las diferentes fases del proyecto, se asignarán a estas actividades duraciones, recursos, relaciones de precedencia… etc. El diagrama permitirá establecer el camino crítico de actividades, que estará formado por todas aquellas actividades que de sufrir cambios o retrasos comprometerían la fecha estimada de entrega del proyecto. Figura 13. Ejemplo diagrama de Gantt. Con esta herramienta altamente visual, se podrá apreciar el estado del proyecto en cualquier momento, pero contará con una serie de problemas: El tiempo que se tarda en confeccionar es demasiado alto y acertar de pleno con su predicción será una tarea complicada. Esto se debe a que no es posible prever con total exactitud todos los problemas que podrían aparecer. Una vez aparece uno de estos problemas se ha de replantear todo el diagrama, lo que conlleva de nuevo una gran cantidad de tiempo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 52 4.2. Principales diferencias entre metodologías Figura 14. Comparación desarrollo de proyectos con metodología tradicional y ágil. DIFERENCIAS PRINCIPALES ENTRE AMBAS METODOLOGÍAS CASCADA SCRUM Se realizará al comienzo una lista completa y definitiva de requisitos para el proyecto. Difícilmente se realizará una toma de requisitos al comienzo del proyecto que se encuentre inalterable durante su desarrollo. Con este método, realizar al comienzo del proyecto una estimación realista en coste y esfuerzo es relativamente sencillo. Con Scrum, realizar una estimación en coste y esfuerzo al principio es imposible. Para poder realizar sin fallos la estimación, serán necesarias unas sesiones de investigación, en las que se observará cuánto se “aceleran” los equipos. Lo cual permitirá saber cuánto tiempo van a necesitar para finalizar sus trabajos. Se identifican, definen y ordenan detalladamente todas las actividades de las que se compone el proyecto. Normalmente utilizando herramientas como los gráficos de Gantt. A medida que se van sucediendo las distintas iteraciones, van surgiendo actividades y modificaciones de éstas, gracias al feedback de los usuarios, adaptándose el proyecto a sus necesidades en todo momento. Los imprevistos no son excesivamente habituales y la posibilidad de adaptación a los cambios es muy baja y problemática, debido a su complejidad. El uso de la creatividad para adaptarse a los imprevistos que aparecen es lo habitual. Por ello, la adaptabilidad a los cambios, los cuales son siempre bien recibidos, es alta. Figura 15. Tabla resumen sobre las principales diferencias entre ambas metodologías. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 53 Cada una de estas metodologías se centrará en unas u otras partes del proyecto en lo que al enfoque se refiere: ENFOQUE CASCADA SCRUM El énfasis está en Procesos Personas Estilo de procesos Incremental Iterativo Documentación Exhaustiva Mínima requerida Planificación por adelantado Alta Baja Priorización de los requisitos Fijos en el Plan de Proyecto Según su valor para el negocio asociado y sujetos a una actualización regular Organización Gestionado Equipos auto organizados Estilo de Gestión Centralizado Descentralizado Calidad Centrada en el proceso Centrada en el cliente Gestión de los cambios Según el sistema formal de gestión de los cambios Según las actualizaciones de la pila del producto priorizada Estilo de liderazgo Mando y control Colaborativo Medición del rendimiento Según el plan de conformidad Según el valor del negocio Retorno de la Inversión (ROI) Al finalizar el proyecto Al comienzo y a lo largo de las distintas etapas del proyecto Participación del Cliente Varía en función del ciclo de vida del proyecto Participación alta durante todo el proyecto Figura 16. Tabla resumen sobre las principales diferencias entre metodologías según el enfoque. Tras la comparación de ambas metodologías, cabe decir que no hay una que sea mejor que otra, si no que siempre habrá una metodología que se adapte mejor al tipo de proyecto que se desea desarrollar. Elegir la metodología correcta para el proyecto conllevará un estudio previo del entorno en el que se va a trabajar, de los requerimientos del proyecto y de los recursos necesarios para su desarrollo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 54 Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 55 Capítulo V: Caso práctico 5.1. Proyecto Pointe Jarry Figura 17. Vista aérea proyecto Pointe Jarry. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 62 • Visión general de la planta Figura 30. Vista general de la planta. • Celdas de motores Figura 31. Vista de las celdas de Motores. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 63 • Anexos mecánicos Figura 32. Vista de los anexos Mecánicos. • Edificio de tratamiento de combustible Figura 33. Vista del edificio de tratamiento del combustible. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 64 • Edificio de compresores Figura 34. Vista del edificio de Compresores. • Edificio de tratamiento de aguas Figura 35. Vista del edificio de tratamiento de aguas. • Edificio prevención de incendios Figura 36. Vista del edificio de prevención de incendios. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 65 • Sistema de chimeneas y escape Figura 37. Vista del Sistema de Chimeneas 1. Figura 38. Vista del Sistema de Chimeneas 2. • Zona de tanques Figura 39. Vista de la zona de Tanques. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 66 • Almacenamiento de urea Figura 40. Vista de los tanques de almacenamiento de urea. • Estantes y caminos de tuberías Figura 41. Vista de los estantes y caminos de tuberías 1. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 67 Figura 42. Vista de los estantes y caminos de tuberías 2. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 68 5.2. Selección y guía práctica de uso de la herramienta de trabajo 5.2.1. Selección de la herramienta de trabajo Para el caso práctico de este trabajo de fin de grado, en el que se hará un supuesto del desarrollo del proyecto Pointe Jarry mediante el uso del marco de trabajo Scrum, será necesaria la utilización de un software para la gestión de proyectos ágiles. Existe una amplia variedad de herramientas, pero se seleccionará una de las 2 más utilizadas, Jira Software o Azure DevOps Services. A continuación, se realizará un breve estudio de ambas herramientas para justificar la selección de una frente a otra. Jira Software, de Atlassian, es un potente software para la gestión de proyectos de cualquier tipo y tamaño desde cualquier lugar del mundo. Está diseñado para que los equipos puedan comunicarse plenamente, compartiendo la planificación, el seguimiento y la supervisión del proyecto. Como alternativa a Jira se encuentra Azure DevOps Services, un software creado por Microsoft con el que se puede crear, administrar e implementar diferentes aplicaciones desde cualquier parte del mundo, para la gestión de proyectos. Su nombre, DevOps es un término que nace de la mezcla entre desarrollo (development) y operaciones (operations). Ambas herramientas nos permiten gestionar proyectos de manera ágil, pero existen una serie de diferencias que se tratarán a continuación: Figura 43. Comparación de Herramientas para la gestión ágil de proyectos. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 69 Como se veía en el apartado 5.1. el proyecto Pointe Jarry contó con las siguientes características: Figura 44. Características generales del proyecto Pointe Jarry. En la imagen superior se ve que el pico de personal de oficina cuenta con 55 trabajadores. Por lo tanto, se buscará presupuesto de ambas herramientas para un total de 55 personas. Figura 45. Precios herramienta Jira Software. Figura 46. Precios herramienta Microsoft Azure. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 70 La diferencia es muy alta, siendo el precio mensual de Jira para su plan PREMIUM 770$ mensuales y para el plan básico + Test Plans de Azure DevOps de 2860$. Según las valoraciones de los usuarios se encuentran prácticamente a la par. Figura 47. Valoraciones de las herramientas según los usuarios. En cuanto a funcionalidades, se observa una gran diferencia en favor de Jira, pues cuenta con un número muy superior a Azure DevOps. Esta diferencia se debe a que Jira es un software completo y Azure DevOps son un conjunto de aplicaciones, lo que quiere decir que si se añadieran las aplicaciones correspondientes a las funcionalidades con las que no cuenta Azure DevOps, obtendríamos un software igualmente preparado, pero menos funcional y a un mayor coste, pues cada aplicación extra que se añade tiene un precio por usuario y mes. Figura 48. Funcionalidades de las herramientas. Plataformas en las que se pueden instalar los softwares: Figura 49. Plataformas para las que se encuentran disponibles las herramientas. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 71 En cuanto al servicio de asistencia, Jira cuenta con asistencia 24 horas por un representante de Atlassian, así como asistencia en línea. Al contrario que Azure DevOps que no cuenta con tales servicios. Tras el análisis de los datos de la comparación se procederá a la selección del software. Precio 770$ 2860$ Valoración de los usuarios 4,4/5 4,3/5 Funcionalidades 10/10 4/10 Plataforma Nube, Microsoft, Appel, Android Nube Asistencia 24 horas / en línea No cuenta con ella Figura 51. Tabla resumen sobre las características de ambas herramientas. El software seleccionado para la realización del caso práctico será Jira Software de Atlassian. Principalmente se debe a su precio, mucho menor y a que incluye todas las funcionalidades sin necesidad de utilizar más aplicaciones. Otro aspecto decisivo ha sido la cantidad de plataformas en las que se puede instalar dicho software. Es sabido, que con la nube realmente podemos acceder al programa desde cualquier dispositivo, pero siendo usuario habitual de este tipo de softwares es más práctico poder tener la aplicación descargada en el dispositivo, de la otra forma siempre dependeremos de una conexión a internet (que en ocasiones podría fallar). Y de la misma manera, la asistencia por profesionales del software es un factor que tener muy en cuenta ya que siempre puede surgir alguna duda o problema y solucionarlo en tiempo real es la mejor opción. Figura 50. Servicio de asistencia de las diferentes herramientas. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 78 ¿Cómo se añaden las incidencias al epic? Arrastramos las incidencias desde el backlog a la pestaña izquierda del epic, quedando de esta forma las incidencias añadidas al epic correspondiente. Otra forma de añadir las incidencias al epic es desde la ventana de detalle de las incidencias. Figura 66. Cómo agregar Incidencias a un Epic. Una vez están asignadas las incidencias al epic, aparece el nombre del epic en la incidencia como vemos en la imagen superior. Figura 67. Epic en detalle. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 79 Si abrimos el detalle del epic, como en la imagen superior, podemos ver el estado en el que se encuentra en todo momento. En la parte superior de la lista de incidencias, vemos el porcentaje de trabajo terminado, el cual se irá actualizando automaticamente según se vayan completando los sprints y las correspondientes actividades. PASO 3: Cómo crear versiones Las versiones representan determinados momentos o fases del proyecto, nos ayudan a organizar el trabajo y nos proporcionan diferentes hitos que queremos alcanzar. Esta división, nos permite realizar seguimientos especializados por fases de proyecto. Para crear una versión seguiremos el siguiente recorrido: Nos situamos en el backlog y en el lateral izquierdo observamos de nuevo las pestañas “Epics y “Versiones”, esta vez clicamos sobre “Versiones”. Nos aparece en ese mismo lateral una nueva pestaña en la que vemos un botón que dice: “Crear versión”, pulsamos y acto seguido aparecerá un desplegable con unos campos por rellenar, que son el nombre de la versión, una breve descripción de ésta y unas fechas de inicio y fin. Figura 68. Cómo crear una Versión 1. Completamos los campos del desplegable y pulsamos sobre el botón “Crear”. De esta forma, la versión ya estaría creada. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 80 Figura 69. Cómo crear una Versión 2. Ahora desde el backlog, con la ventana de “Versiones” abierta, podemos observar el estado en el que se encuentra dicha versión. Pero ¿cómo añadimos las incidencias a las versiones?, es muy sencillo, simplemente hay que pinchar sobre la incidencia que queremos añadir y arrastrarla con el ratón hacia la izquierda, a la zona de versiones. Figura 70. Cómo agregar Incidencias a la Versión. Una vez están las incidencias añadidas a la versión, en el backlog vemos cómo se le ha añadido una etiqueta en color gris con el nombre de la versión. En la zona de versiones podemos observar en qué estado están las incidencias. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 81 Pero ese estado también se puede comprobar en otro lugar: Figura 71. Vista del estado en el que se encuentran las Incidencias. En el lateral izquierdo, debajo de la pestaña de backlog, encontramos una pestaña con el nombre de “Versiones”, si clicamos nos aparece una vista detallada de las versiones existentes. Figura 72. Vista del detalle del estado de la Versión. Si clicamos sobre la versión nos lleva a otra vista en la que aparecen las incidencias que la forman y el estado en el que se encuentran. Una vez todas las incidencias de la versión se encuentran finalizadas podemos proceder a la entrega de la versión, esto se consigue pulsando sobre el botón “Release”, acto seguido nos pedirá la fecha de la publicación y Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 82 volver a pulsar sobre “Release”. Una vez hecho esto, el estado de la versión cambia de “Sin entregar” a “Entregada”. PASO 4: Cómo crear un Sprint Nos situamos en el backlog para comenzar con la creación del sprint. Clicaremos en la pestaña de “Crear Sprint” y obtendremos la siguiente ventana: Figura 73. Cómo crear un Sprint 1. Tras la realización de la reunión de planificación del sprint, el equipo habrá seleccionado las diferentes incidencias que se van a completar durante ese sprint. Para añadir las incidencias al sprint tenemos que arrastrarlas con el ratón hasta la caja superior, donde pone “Planifica tu Sprint”, como vemos en la imagen superior. Figura 74. Cómo crear un Sprint 2. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 83 Una vez están las incidencias en la casilla del sprint, en la parte superior observamos 2 pestañas, “Iniciar Sprint” y “Planificar Sprint”, clicamos sobre la segunda pestaña y nos aparece el desplegable que vemos en la parte superior. Aquí tenemos la opción de añadir diferentes elementos al sprint, como notas de importancia hechas en la reunión o requerimientos del producto. Al clicar en la pestaña de “Iniciar Sprint” nos aparece la siguiente ventana: Figura 75. Cómo crear un Sprint 3. Aquí tendremos que seleccionar, tanto la duración del sprint como sus fechas de inicio y fin, se añadirá también el objetivo principal del sprint en la casilla “Meta del Sprint” y una vez completos todos los campos, clicaremos en “Comenzar”. Una vez terminada la creación del sprint, Jira nos dirige automáticamente a la pestaña de “Sprints Activos”, que se encuentra en el lateral izquierdo de la pantalla: Figura 76. Vista Sprint activo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 84 En este lugar trabaja el equipo Scrum, seleccionando los elementos de la columna “Por hacer” y moviéndolos según se vayan empezando a la columna “En curso” y una vez finalizados a la columna de la derecha “Listo”. La forma de hacerlo es arrastrando el elemento con el ratón de una columna a otra o clicando en la tarea y: Figura 77. Cambio del estado de las Incidencias dentro de un Sprint. Así pues, a lo largo del sprint vemos como el tablero va cambiando de forma. Figura 78. Vista tablero Sprint activo. ¿Cómo concluir el Sprint? Una vez todas las incidencias del sprint están en la columna de “Listo”, clicamos sobre la pestaña superior “Terminar Sprint” y una vez abierta la pestaña de confirmación, clicamos sobre “Terminar”. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 85 Figura 79. Cómo concluir un Sprint. De no estar completas todas las incidencias del sprint, actuamos de la siguiente forma: • Movemos las incidencias de nuevo al backlog. • Movemos las incidencias a un sprint futuro. • Movemos las incidencias a un sprint que Jira creará por nosotros. PASO 5: Cómo establecer los puntos de historia o story points Los puntos de historia reflejan la dificultad de la historia de usuario. El avance o velocidad de un equipo se mide por la cantidad de puntos de historia que es capaz de completar en un sprint. A medida que el equipo se acelera va aumentando el número de story points que es capaz de completar. Éstos story points también son necesarios para completar informes del proyecto como la gráfica de trabajo pendiente. Para establecer los story points, lo primero que se necesita es una historia de usuario, de dificultad media, que todo el equipo sepa cómo llevar a cabo para tomarla como pivote o referencia. A esta historia se le da una puntuación en función de su dificultad, por ejemplo 6, entonces al resto de historias de usuario se les puntúa comparándolas con esta historia que hemos tomado como pivote. Si la historia requiere el doble de dificultad, su puntuación en story points será entonces 12 y si la dificultad de la historia es la mitad de la del pivote su puntuación será 3. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 86 Figura 80. Cómo añadir Story Points 1. Para añadir los story points a una historia de usuario, nos situaremos sobre ésta en el backlog, pincharemos sobre ella y a la derecha aparecerá un desplegable. Debajo de “Etiquetas” encontraremos la pestaña de “Story Points”, la rellenamos con la puntuación correspondiente y pinchamos sobre enter. Figura 81. Cómo añadir Story Points 2. Puntuaremos así, todas las historias de usuario que aparezcan en el backlog. Después comenzamos a crear un sprint. En la parte inferior vemos un sumatorio de todos los story points que conforman la pila del sprint, (ocurre de igual manera en las ventanas de “Epics” y “Versiones”, en la parte inferior aparece un sumatorio de los story points que los conforman). Iniciamos el sprint y vamos completando las incidencias que lo conforman. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 87 Figura 82. Ejemplo Sprint (Duración ficticia). Para poder ver el ejemplo le pondremos una duración de 3 minutos al sprint. Figura 83. Tablero del Sprint de ejemplo. Una vez todas las incidencias estén en la columna de “Listo”, clicaremos sobre “Terminar Sprint” y con el sprint ya terminado nos dirigiremos a la columna de la izquierda donde clicaremos sobre la pestaña de informes. Figura 84. Informes Jira Software. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 94 Figura 90. Orden de acontecimientos dentro de Scrum. A partir de la reunión de propietarios del producto, los equipos existentes trabajarán en paralelo en las diferentes partes del proyecto, siguiendo exactamente el mismo esquema de trabajo. Es aquí donde comenzamos a utilizar el marco de trabajo Scrum. Como se comentó anteriormente, nos centraremos en el Sistema de Lubricación de la planta. 5.3.2. El Sprint 0 Para comenzar se hablará del Sprint 0. Este Sprint no se considera un evento de Scrum, sino una práctica que emplean algunas empresas. Hay opiniones a favor y opiniones en contra de utilizar este sprint previo, pero hablando desde una perspectiva objetiva, creo que el sprint 0 es muy favorable en proyectos de índole industrial como el que nos atañe. Este sprint 0 no aportará ningún valor de negocio al proyecto, su principal objetivo será construir una parte de la arquitectura ágil básica que se utilizará durante el desarrollo del proyecto, para que en los incrementos de los futuros sprints, se consiga añadir el valor que se busca para el proyecto. Es decir, que es el paso previo necesario, para poder trabajar en el proyecto de forma ágil. Cabe destacar que en un proyecto de software este sprint 0 podría no tener sentido, por lo tanto, prescindiríamos de él. La duración del sprint 0 será mayor que la del resto de sprints y la velocidad con la que se trabajará en él, al ser el primero que realizamos, menor. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 95 En el siguiente listado se detallan todas las acciones que se deben realizar en el sprint 0: Estudio de la parte del proyecto encargado Establecimiento de Épicas Establecimiento de Versiones Creación del plan de trabajo (Release Plan) Creación de un listado de prioridades del cliente Establecimiento de Stakeholders Establecimiento de las expectativas de calidad del proyecto Creación de la primera versión del Backlog priorizada Detección de dependencias, restricciones y limitaciones Creación de un Backlog de Riesgos Establecimiento de la definición de “Terminado” Selección de métricas para el proyecto Figura 91. Tabla resumen de las Incidencias pertenecientes al Sprint 0. 5.3.3. ¿Cómo implementamos esto en Jira Software? El primer evento que tendrá lugar dentro del sprint 0, será la reunión de planificación del sprint. Dentro de la misma, será la reunión de Scrum Masters la primera parte en realizarse. Aquí los Scrum Masters se reunirán y se repartirán los recursos disponibles, teniendo en cuenta las necesidades de cada subproyecto. Después, en la segunda parte de la reunión, con el equipo ya formado se establecerá qué es lo que se va a llevar a cabo en el sprint, que no es otra cosa que la lista de actividades que vimos en el apartado anterior. ¿Cómo se conseguirá esto? El primer paso será crear un proyecto en la plataforma Jira como ya vimos en el paso 1 del apartado 5.2.2. Una vez esté creado el proyecto, se añadirán al backlog todas las actividades de la lista anterior. Figura 92. Tablero del Sprint 0. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 96 Se creará el sprint 0 y se añadirán las incidencias al mismo. Acto seguido se empezarán a completar todas las actividades que aparecen en la pila del sprint. Se realizaría el estudio de la parte del proyecto que se nos ha asignado, el Sistema de Lubricación. Con este estudio, se podrán definir las especificaciones que requiere el subproyecto, dividiéndolas así, en las historias de usuario pertinentes. Se podrán establecer de igual manera los epics en los que se dividirán estas historias de usuario, así como las versiones o fases en las que estará fragmentado el proyecto del Sistema de Lubricación. Lo primero que se haría es crear los epics, que como veíamos anteriormente son funcionalidades del proyecto lo suficientemente grandes como para no poder completarse en un solo sprint, por lo que estarán formados por una serie grande de incidencias. Se diferenciarán los siguientes epics: Figura 93. Epics en los que se divide el subproyecto. Como ya vimos, los epics se crean desde la pestaña del backlog, pero se pueden observar también en la pestaña de incidencias utilizando los filtros correspondientes como se puede apreciar en la imagen superior. El siguiente paso será establecer las fases o versiones en las que se segmentará el proyecto. Situándonos en la pestaña del backlog, en el lateral izquierdo aparecerá en vertical una pestaña que dice “Versiones”, clicamos y crearemos las versiones correspondientes al proyecto. Figura 94. Versiones en las que se divide el subproyecto. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 97 En la pestaña de la sección izquierda, encontramos una opción que dice “Versiones” (la señalada en rojo en la imagen), pulsamos y aparecerán las versiones del proyecto, con su estado, el progreso y una breve descripción. Establecidos ya los epics y las versiones, pasaremos a definir las especificaciones del Sistema de Lubricación, las cuales se dividirán en historias de usuario, pruebas y tareas. Se obtiene el siguiente listado tras haberlas implementado en el backlog del proyecto: P2-7 Estudio de la integridad de la ingeniería de Detalle Recibida P2-8 Determinación de las Especificaciones Técnicas de Equipos y Materiales P2-9 Cuantificación de Equipos y Materiales integrantes del Sistema de Lubricación P2-10 Petición de Cotizaciones a Proveedores de Equipos y Materiales P2-11 Tabulación Técnica y Económica de los diferentes Equipos y Materiales del Sistema de Lubricación P2-12 Elaboración de las diferentes mesas de Contratación para pedir autorización y proceder a la Compra P2-13 Activación de los diferentes Equipos P2-14 Realización de los controles de Calidad de los Equipos con pruebas en Fábrica P2-15 Recepción de los Equipos y Materiales en Almacén de obra P2-16 Verificación de Funcionamiento de Equipos y perfecto estado de Materiales P2-17 Verificación de las cimentaciones y bancadas de los Equipos de Bombeo P2-18 Desembalaje de los Equipos del Sistema de Lubricación P2-19 Completación del Dossier de Calidad P2-20 Análisis del procedimiento de Montaje P2-21 Instalación de Equipos sobre bancadas P2-22 Verificación de cotas de Instalación y posterior Grouteado P2-23 Preparación de Estructura auxiliar para el tendido de ductería auxiliar Eléctrica, de Instrumentación y Neumática P2-24 Trameado del Isométrico P2-25 Recepción y Revisión de los Isométricos de Tubería P2-26 Selección y Preparación de Material para expedición al taller de Prefabricación P2-27 Prefabricación en el Taller de Tubería mayor a 2 “ Parte 1 P2-30 Instalación y Montaje de Soportes de Tubería P2-31 Montaje de Figuras de Tubería Prefabricadas P2-32 Montaje del resto de tubería (No prefabricable) y Tubería Menor a 2” Parte 1 P2-35 Conexionado final de Tubería P2-39 Pintado de Tuberías P2-40 Aislamiento de los Circuitos de Alta Temperatura excepto costura hasta finalización de las pruebas Hidrostáticas P2-41 Instalación y Montaje de Bandejas y Conduit P2-42 Tendido de cableado de Alimentación sobre Bandeja P2-43 Conexionado a Cuadros de Fuerza, Control y Equipos P2-44 Timbrado e Identificación de Circuitos de Alimentación P2-45 Tendido de Cableado de Instrumentación bajo Conduit y Conexionado a Instrumentos de Control P2-46 Timbrado e Identificación de Circuitos de Control P2-47 Tendido de Circuito de Aire Comprimido de Instrumento P2-48 Realización de las Pruebas Hidrostáticas de los diferentes Circuitos P2-49 Conclusión de los trabajos de Aislamiento tras el Éxito de la Pruebas Hidrostáticas Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 98 P2-50 Verificación de los Sentidos de Giro de los Equipos rotativos y Ejecución de Pruebas On site P2-51 Verificación de Pruebas On site de los Equipos Estáticos P2-52 Integración de los diferentes Lazos de Control en el Sistema SCADA y pruebas de funcionamiento P2-53 Limpieza del Sistema de Lubricación con aceite (oil flushing) P2-54 Arranque del Sistema de Lubricación P2-59 Prefabricación en el Taller de Tubería mayor a 2 “ Parte 2 P2-60 Prefabricación en el Taller de Tubería mayor a 2 “ Parte 3 P2-61 Montaje del resto de tubería (No prefabricable) y Tubería Menor a 2” Parte 2 Figura 95. Listado de Incidencias de nuestro subproyecto. Los códigos de cada incidencia se van añadiendo en automático, en el orden en el que se van creando. Los saltos que encontramos entre incidencias se deben a que hay alguna que se subdivide en otras incidencias llamadas subtareas, las cuales cuentan con los códigos que faltan. Los colores se corresponden con los colores de las etiquetas de los epics, para que sea más visual. Una vez tenemos definidas tanto las especificaciones, como los epics y las versiones, pasaremos a crear el plan de trabajo o “Release Plan”, en el cual asignamos a cada epic las iteraciones que lo conforman (parte superior horizontal) y de igual manera a las versiones (parte derecha vertical), obteniendo lo siguiente: Figura 96. Release Plan. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 99 Una vez completado el “Release Plan”, volvemos a Jira Software para completar el backlog del sistema de lubricación, añadiendo cada iteración a su epic y versión correspondiente. Se obteniene lo siguiente: Figura 97. Vista del Backlog completo 1. Figura 98. Vista del Backlog completo 2. En estas imágenes apreciamos el backlog del proyecto con los epics y las versiones adjudicadas a sus correspondientes incidencias. Si desplegamos las pestañas izquierdas de “Epics” y “Versiones” observamos lo siguiente: Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 100 Los resúmenes de ambas siguen el mismo esquema, un título, una breve descripción, el número de incidencias que los conforman, el estado en el que se encuentran y su estimación en Puntos de Historia. Como veíamos en el apartado anterior, a las historias de usuario se les asigna una puntuación, todas en base a la historia de usuario que tomamos como pivote, la cual nos sirve para medir la “dificultad” de estas, para después poder calcular la velocidad con la que se está trabajando, cuanto se aceleran los equipos… etc. En el caso del Sistema de Lubricación utilizamos como pivote la historia de usuario P27, correspondiente con el estudio de la integridad de la ingeniería de detalle recibida. Figura 101. Detalle Historia de Usuario P2-7. La puntuación en story points que se le da a dicha historia de usuario es 6. Por ello, actividades de montaje, mucho más complicadas y duraderas tendrán alrededor de 20 puntos de historia y actividades como la recepción de materiales o equipos tendrán alrededor de 2 puntos de historia. A continuación, en la descripción del resto de sprints aparecerán todas las incidencias con sus correspondientes puntuaciones. Figura 99. Ventana de Versiones. Figura 100. Ventana de Epics. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 101 Páginas de proyectos en Jira Software Dentro de la aplicación que se está utilizando, encontramos una pestaña en la barra lateral izquierda que dice “Páginas de Proyecto”, clicando sobre la pestaña encontramos una serie de documentos que el equipo Scrum habrá ido creando durante el desarrollo del proyecto. Estos documentos pueden ser de tipos muy variados, pero entre ellos se pueden encontrar plantillas para planificación de sprints, documentos de requisitos del proyecto, documentos que detallan la retrospectiva de los sprints…etc. Figura 102. Vista páginas del proyecto. Como podemos observar en la imagen superior, se concentran en esta pestaña todos los documentos con relación al proyecto que el equipo Scrum ha ido creando y que estarán a disposición de cualquier miembro de este. La aplicación Jira, nos ofrece una gran variedad de plantillas para crear estos documentos, de entre las que destacaremos éstas para el tipo de proyecto que se está estudiando: ¿Cómo creamos estos documentos? Lo primero que haremos es situarnos en el backlog. Con el sprint 0 ya detallado, en la zona derecha encontraremos una pestaña que dice “Páginas vinculadas”, situamos el ratón sobre ella y aparecerá un desplegable en el que nos ofrecerán 2 opciones: Vincular página (una ya existente) o crear página. Le daremos a crear página y la aplicación nos llevará hasta el siguiente desplegable, una ventana en Figura 104. Plantillas de páginas para el proyecto 1. Figura 103. Plantillas de páginas para el proyecto 2. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 102 la que podremos elegir una plantilla para el documento de entre las que vimos en la imagen anterior. Una vez seleccionada la plantilla, pulsamos sobre “Crear” y aparecerá el documento que hemos seleccionado, en blanco, para que nosotros lo completemos como queramos: Figura 105. Cómo crear una página del subproyecto. Una vez tengamos el documento completo, clicamos sobre la pestaña “Publicar” y la página pasará a aparecer en nuestra aplicación de Jira Software, en la ventana de “Páginas de Proyecto”, que ya vimos anteriormente. Dentro del sprint 0, crearemos una serie de documentos para completar así las incidencias que lo conformaban. El equipo Scrum, tras realizar todo el trabajo planificado para el sprint, se junta en la revisión del sprint, la cual será un poco distinta al resto de revisiones. En esta reunión los miembros del equipo comprueban que todo lo necesario para comenzar a trabajar de forma ágil esta “Terminado”. Una vez hecho esto, deciden cual va a ser el punto de partida del siguiente sprint, que en este caso será el estudio de la ingeniería de detalle del sistema de lubricación con todo lo que esto conlleva. La retrospectiva de este sprint inicial o sprint 0, nos sirve para hacer una “prueba” del equipo, para ver cómo trabaja y observar futuras posibilidades, pero poco tendrá que ver con las retrospectivas de los siguientes sprints que veremos a continuación. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 103 Cronología de un Sprint Figura 106. Ilustración sobre la cronología de un Sprint. Como vemos en la imagen superior, un sprint se divide en varios eventos que ya se explicaron en el capítulo III. La reunión de Scrum Masters y la planificación del sprint son los primeros eventos que se llevan a cabo y sólo tienen lugar el primer día del sprint. En la Reunión de Scrum Masters, se juntan los Scrum Master de los diferentes equipos y con el “pre-objetivo” que se fijó en la reunión de revisión del sprint anterior, deciden qué número de personas harán falta para alcanzar dicho objetivo en este nuevo sprint, así como qué recursos materiales les serán necesarios. Acto seguido, tiene lugar la planificación del sprint, reunión en la que ya tenemos al equipo técnico formado. En esta reunión el propietario del producto clarifica ese “pre-objetivo” que se estableció en el sprint anterior y fija el llamado “Sprint Goal”, la meta del equipo Scrum para este sprint. Otra de las cuestiones que se han de tener en cuenta en esta reunión, es el plan de mejoras que se ha de implementar, (nacido en la reunión de retrospectiva del sprint anterior), lo cual será responsabilidad del Scrum Master. Una vez finalizada la reunión de planificación del sprint, aparece el Scrum diario, que es una reunión muy breve, de unos 15 minutos de duración en la que el equipo técnico plantea el trabajo que se va a llevar a cabo en las próximas 24 horas. Esto permite al equipo realizar inspecciones del trabajo ya realizado durante el sprint y del que queda por realizar, para evaluar tanto su progreso hacia el objetivo como la tendencia de trabajo del equipo. De esta forma es fácil ver si hay problemas y cuanto antes se identifiquen antes podrán solucionarse. Para este tipo de inspecciones, utilizamos Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 110 P2-12 Elaboración de las diferentes mesas de Contratación para pedir autorización y proceder a la Compra Figura 115. Detalle Historia de Usuario P2-12. P2-13 Verificación de las cimentaciones y bancadas de los Equipos de Bombeo Figura 116. Detalle Historia de Usuario P2-13. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 111 En esta historia de usuario encontramos otro detalle, un documento para las verificaciones, en el que quedará constancia del trabajo realizado. En estos detalles es donde el equipo técnico encuentra o da las explicaciones del trabajo que va a realizar. Se iniciará el sprint 1 para poder ver cómo se desarrollaría con la herramienta, por esta razón le pondremos una duración de 5 minutos al sprint, (que no es la real, pero es necesaria para poder obtener los diferentes informes que nos proporciona Jira). Después de establecer esos 5 minutos de prueba, pinchamos sobre “Comenzar” y acto seguido aparece la siguiente ventana: Figura 118. Vista Tablero del Sprint 1, 1. Como se puede ver, ésta es la pila del sprint 1. En el momento de su creación, todas las incidencias se encuentran en la zona de “Por hacer”. Figura 117. Cómo iniciar el Sprint 1. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 112 Todo lo anterior a este punto, es lo que se realizará durante la reunión de planificación del sprint 1. A continuación, tendrá lugar el Scrum diario, esa reunión en la que se decide que es lo que se va a hacer durante las próximas 24 horas y en la que se van a ir realizando diferentes inspecciones del trabajo del equipo Scrum. Después de esta reunión comienza el trabajo de desarrollo del proyecto. Este proceso, como se veía antes, se repite diariamente a lo largo del sprint. Durante los Scrum diarios, se verá cómo va actualizándose la pila del sprint 1: Figura 119. Vista Tablero del Sprint 1, 2. Según se van comenzando y completando las diferentes incidencias, se cambian de lugar en el tablero del sprint, hasta que se completan todas las incidencias el último día del sprint: Figura 120. Vista Tablero del Sprint 1, 3. Una vez llegados a este punto, el próximo evento que tendrá lugar es la revisión del sprint, en la que todo el equipo Scrum colabora. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 113 Como el principal objetivo de esta reunión es la retroalimentación de toda la información posible, se recurrirá a los diferentes informes que la herramienta Jira va creando durante el desarrollo del sprint. Figura 121. Gráfica del Trabajo Pendiente Sprint 1. Este es el gráfico del trabajo pendiente, con él podemos apreciar la tendencia del trabajo del equipo, determinando así, si el equipo puede realizar más o menos trabajo del que se ha completado en el sprint. En esta reunión, el propietario del producto establecerá el “pre-objetivo” del sprint 2, explicará los elementos de la pila del producto que se han “Terminado” y comentará el estado en el que se encuentra dicha pila actualmente. Los miembros del equipo técnico detallarán los aspectos positivos y los problemas con los que se han encontrado, así como la forma en que se resolvieron. Y todo ello quedará escrito en un documento llamado “Revisión del Sprint 1”: Figura 122. Documentos creados en la reunión de Revisión del Sprint 1. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 114 Una vez se concluye esta reunión, tiene lugar la retrospectiva del sprint 1, evento en el que el equipo Scrum se inspecciona y crea un plan de mejoras que incluye, tanto mejoras para personas, cómo para procesos y herramientas. Se planifica de esta forma cómo mejorar la calidad de nuestro producto/proyecto, mejorando la calidad de los procesos. Se crearán varias páginas en este evento, la propia página en la que se detalla el contenido de la retrospectiva y una en la que se detalla el plan de mejoras para el próximo sprint. Figura 123. Documentos creados en la Retrospectiva del Sprint 1. Así, una vez finalizado el sprint 1 daríamos comienzo al sprint 2, siguiendo exactamente el esquema anterior. Lo que se hará a continuación, será explicar cada sprint, para entender por qué seleccionamos para cada uno, unas u otras incidencias del backlog. Tras finalizarse el primer sprint, el equipo hará una pausa de 4 semanas en los trabajos del Sistema de Lubricación. Este será el tiempo correspondiente a la recepción de los equipos y los materiales necesarios para poder proseguir con el trabajo. Durante estas semanas tanto los técnicos, como el propietario del producto y el Scrum Master estarán trabajando con otros de los equipos Scrum que participan en el proyecto. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 115 Sprint 2 Figura 124. Vista Tablero Sprint 2. En este sprint trabajarán un total de 9 personas, el propietario del producto, el Scrum Master y 7 técnicos dentro del equipo técnico. En este periodo, se continúa con la fase de ingeniería. Tras recibir el material y los equipos, éstos se prueban para comprobar que se encuentran en perfecto estado y que funcionan. De la misma forma, se revisan los isométricos de tuberías y su trameado, incidencias que forman parte de la fase de fabricación y montaje pero que se pueden ir adelantando en estos primeros sprints. Sprint 3 Figura 125. Vista Tablero Sprint 3. Este sprint cuenta con 4 personas, el propietario del producto, el Scrum Master y 2 técnicos dentro del Equipo Técnico. Aquí comienza la fase de montaje del Sistema de Lubricación, con la instalación de equipos en el edificio de bombeo, lo que requiere la confección de una serie de dossieres de calidad y documentos en los que se analizan los diferentes procedimientos que se van a seguir durante el montaje del sistema. Se instalan los Equipos sobre las bancadas y se verifican sus cotas de instalación. Una vez hecho esto, se comienza la fabricación y montaje de tuberías, aunque en este Sprint solo seleccionaremos y prepararemos el material que se va a necesitar y lo enviaremos al taller de prefabricación. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 116 Sprint 4 Figura 126. Vista Tablero Sprint 4. El cuarto sprint, es el primero de los sprints que va a necesitar un número de personas en su equipo mucho mayor al normal. El equipo Scrum estará formado por 17 personas, de las cuales 15 formarán parte del equipo técnico. Esto se debe a que el trabajo que aquí comienza y que se extenderá durante los siguientes 5 sprints, es trabajo de fabricación y montaje a gran escala, lo que implicará la necesidad de mucha mano de obra para poder completarlo. Lo primero que se hará en el sprint, es preparar la estructura auxiliar para el tendido de ductería auxiliar eléctrica, de instrumentación y mecánica. Se dividirá la prefabricación de la tubería mayor en 3 partes y en este sprint se completará la primera de ellas. Esta división es necesaria, ya que la realización de esta incidencia en un único sprint sería imposible. Sprint 5 Figura 127. Vista Tablero Sprint 5. En este sprint, conformado por una única incidencia, trabajará un equipo Scrum de 16 profesionales y se dedicará completamente a la prefabricación de la segunda parte de la tubería mayor. Sprint 6 Figura 128. Vista Tablero Sprint 6. Para este sprint se contará con un equipo Scrum de 16 miembros, aquí completarán la última parte de la prefabricación de la tubería mayor e instalarán y montarán los soportes para las tuberías. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 117 Sprint 7 Figura 129. Vista Tablero Sprint 7. Se continuará con la fase de montaje, con un equipo Scrum de 21 personas, en este caso con el montaje de figuras de tubería prefabricadas. Así como con el montaje del resto de tuberías NO prefabricables y la primera parte del montaje de la tubería menor. Sprint 8 Figura 130. Vista Tablero Sprint 8. En este sprint, en el que trabajan 18 profesionales, se finalizará el montaje de la tubería menor y se procederá con el conexionado de todas las tuberías del Sistema de Lubricación, dando de esta forma casi por finalizado el montaje de las tuberías del Sistema de Lubricación. Sprint 9 Figura 131. Vista Tablero Sprint 9. En el noveno sprint, se dará por finalizada la fabricación y el montaje de las tuberías del Sistema de Lubricación, con la pintura de las tuberías, contando para ello con un equipo Scrum de 10 miembros. Continuando dentro de este mismo sprint, con los trabajos eléctricos y de instrumentación y con la instalación y el montaje de Bandejas y Conduit. Como podemos observar, en este sprint se ha reducido notablemente el número de miembros del equipo, ya que las actividades que faltan por completar son menos “aparatosas” que las de la propia fabricación de tuberías. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 118 Sprint 10 Figura 132. Vista Tablero Sprint 10. En esta última parte de la fase de montaje, se compondrá un equipo técnico formado en su mayoría por técnicos eléctricos, ya que todo el trabajo de este sprint está relacionado con esta materia, consistiendo los trabajos en los tendidos del cableado de alimentación, su conexión a los cuadros de fuerza, control y equipos, así como los timbrados y la identificación de los circuitos de alimentación. Para ello el equipo Scrum contará con 10 miembros, al igual que en el sprint anterior. Sprint 11 Figura 133. Vista Tablero Sprint 11. En este sprint se continua con las labores eléctricas y de instrumentación, contando con un equipo Scrum de 6 profesionales. Las labores del equipo consistirán en el tendido del cableado de instrumentación, el tendido del circuito de aire comprimido, junto con el timbrado y la identificación del circuito de control. Una vez se hayan concluido estas tareas, se comenzaría dentro de este sprint 11, la fase de precomisionado, con una serie de pruebas y verificaciones de los equipos rotativos. Sprint 12 Figura 134. Vista Tablero Sprint 12. En este sprint número 12, se completaría la fase de montaje con los aislamientos de los circuitos de alta temperatura y se proseguiría con la fase de precomisionado, realizando para ello las pruebas hidrostáticas de los diferentes circuitos. Siendo tan solo necesarias 10 personas para formar todo el equipo Scrum. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 119 Sprint 13 Figura 135. Vista Tablero Sprint 13. Este será el último sprint para la construcción del Sistema de Lubricación al completo. Aquí se concluirá la fase de precomisionado, integrando los lazos de control con el sistema SCADA y realizando todas las pruebas de funcionamiento requeridas antes de la puesta en marcha. Una vez se verifique el correcto funcionamiento del Sistema de Lubricación, se iniciará la limpieza de éste, con aceite y una vez terminada la limpieza, se procedería a la puesta en marcha del sistema. En la aplicación real de Scrum, los sprints tendrían que ir organizándose sobre la marcha, es decir, no se dividiría la pila del producto al inicio, si no que en cada sprint seleccionaríamos las diferentes incidencias que se fueran a completar. Se realiza de esta forma en el presente trabajo, para poder mostrar cómo sería el desarrollo de un proyecto utilizando este marco de trabajo. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 126 Los roles, aparentemente son los mismos, pero sus funciones y características varían ligeramente: • El propietario del producto y el Scrum Master podrán formar parte del equipo de desarrollo de ser necesario. • El Scrum Master, es quien se encarga de formar el equipo de desarrollo en la reunión de Scrum Masters, antes de comenzar el trabajo de desarrollo de cada sprint. • El tamaño del equipo de desarrollo no será fijo durante el desarrollo de todo el “subproyecto”, sino que variará en función a las necesidades del sprint correspondiente. • Tanto el Scrum Master, como el propietario del producto, deberán tener formación técnica superior. • El perfil del técnico, que formará parte del equipo de desarrollo, tendrá que ser especial. Con esto nos referimos a que su formación no deberá ser especializada, si no más general, de esta forma estará capacitado para completar más de un trabajo. • Otra opción, con respecto a lo anterior, sería la formación de nuestros propios técnicos dentro de la empresa, así su perfil se adaptaría perfectamente, al trabajo de los sprints. • El propietario del producto hace el papel de cliente “interno” en las revisiones de los sprints, aunque esto, solo sería necesario en los proyectos que impliquen construcciones a gran escala, ya que al cliente no se le podría entregar un incremento de producto terminado, al finalizar el sprint, si no una parte del proyecto, completada. Uno de los puntos fuertes de esta aplicación, es la utilización del llamado Sprint 0. Como hablamos de proyectos de índole industrial, nos referimos a proyectos que tienen una duración en tiempo, normalmente, mayor a la de un proyecto de software. A su vez, en este tipo de proyectos, hay partes que tienen que seguir un orden concreto e inalterable, por lo tanto, deberá estar planificado, y todo lo conseguimos con el sprint 0. No aportará valor al proyecto, pero es la llave que abrirá la puerta de la agilidad. En él, se construirá esa arquitectura básica de la agilidad, lo que va a permitir trabajar de forma ágil en el resto de sprints. Por ello, no podemos considerar ágil este sprint, sino una planificación previa necesaria del proyecto. Su duración será mayor que la del resto de sprints y la velocidad con la que se trabajará en él, menor. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 127 El Sprint 0, cuenta con una serie de pasos, que habrá que seguir para poder comenzar a trabajar: Estudio de la parte del proyecto encargado Establecimiento de Épicas Establecimiento de Versiones Creación del plan de trabajo (Release Plan) Creación de un listado de prioridades del cliente Establecimiento de Stakeholders Establecimiento de las expectativas de calidad del proyecto Creación de la primera versión del Backlog priorizada Detección de dependencias, restricciones y limitaciones Creación de un Backlog de Riesgos Establecimiento de la definición de “Terminado” Selección de métricas para el proyecto Los puntos fuertes de este marco de trabajo son, la transparencia, la inspección y la adaptación. A diferencia de las metodologías más tradicionales, utilizando estos sprints, con sus eventos y artefactos, se consigue, una flexibilidad y una capacidad de adaptación a los cambios, que, de otra forma, sería imposible. Esto nos lleva a considerar, pérdidas de tiempo y dinero mucho menores, ya que se trabaja, con cajas de tiempo con duración máxima de 1 mes, al contrario que en cascada, donde se planifica el trabajo de los próximos 3 años, intentando tener en cuenta todos los posibles problemas, lo que suele ser inasumible, y finalmente, enfrentándonos a situaciones de mayor dificultad resolutiva. Otra de las cuestiones clave de utilizar metodologías ágiles, es la capacidad de aceleración de los equipos, que a medida que van completando sprints, aprenden cual es la mejor forma de trabajar, pudiendo aceptar cantidades de trabajo, cada vez mayores. Las reuniones diarias, ayudan en el correcto desarrollo del trabajo, ya que, al prever diariamente los posibles impedimentos, es muchísimo más fácil deshacerse de ellos y completar la jornada con éxito, ayudando también a la toma rápida de decisiones, esencial en proyectos de este calibre. Los diagramas para medir el progreso serán de gran ayuda a la hora de estudiar qué cambiar de la forma de trabajar, qué mejoras incluir y qué malos hábitos eliminar, es decir, son indispensables para la realización de los planes de mejoras que se implementan en cada nuevo sprint, ayudando también en el cálculo de las incidencias que se incluirán en el próximo sprint o en el número de personas que serán necesarias. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 128 Unos de los mayores inconvenientes de este marco de trabajo, son la imposibilidad de marcar una fecha para la finalización del proyecto, en una de las etapas más tempranas del mismo, así como, la estimación de la cantidad de dinero, que tendrá que invertirse en el proyecto. Estos dos inconvenientes, marcarán la decisión de utilizar un tipo de metodología u otro, puesto que, para proyectos en los que se invertirá una gran cantidad de dinero, presentar un presupuesto al inicio, suele ser una cuestión básica. Utilizar, o no, estas metodologías ágiles, dependerá del tipo de proyecto industrial al que nos enfrentemos. Una vez estudiada la metodología con detalle, aceptamos que, en proyectos de empresas manufactureras, como puede ser la creación de un nuevo producto o la mejora de una versión ya existente, o en proyectos propios, sería lo más acertado utilizar estas metodologías ágiles, en cualquiera de sus versiones, ya fuera utilizando el marco de trabajo Scrum o incluso Kanban. Pero existen otro tipo de proyectos industriales, como el que se ha utilizado en el caso práctico, en el que seguir la metodología ágil al pie de la letra, en algunas fases del proyecto, puede complicarse. Por ello, concluiremos este trabajo, proponiendo un uso mixto de metodologías, en el que nos quedaremos con las partes mas positivas de cada una. 6.2. Solución propuesta USO MIXTO DE METODOLOGÍAS El cual seguirá el siguiente esquema: 1. Realizar un estudio del proyecto propuesto, en el que se tendrían en cuenta, proyectos similares, ya realizados con anterioridad dentro de la empresa. Con este estudio previo a la oferta que se realizaría, estimaríamos el tiempo aproximado que se tardaría en concluirlo, siempre con un margen de error correspondiente a 1 o 2 Sprints. Una vez estimado el tiempo, pasaríamos a estimar los recursos necesarios, tanto materiales, como personales, cerrando así, un presupuesto para poder lanzar una oferta. 2. Una vez nos adjudicaran el proyecto, comenzaríamos a trabajar en el. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 129 3. Como el estudio previo ya está realizado, se empezaría por el Sprint 0, en el que organizaríamos, como llevar a cabo todo el trabajo que tenemos por delante. Dividiendo el proyecto en fases, partes o “subproyectos”, que pudieran realizarse de forma independiente como un todo. Se establecería qué fases, y qué “subproyectos” , se podrían realizar con el marco de trabajo Scrum, y cuales se deberían llevar a cabo con una metodología más tradicional. Las fases de ingeniería y precomisionado, así como los “subproyectos”, que pudieran llevarse a cabo como un todo, se realizarían con Scrum. Pero la fase de montaje y fabricación, de las estructuras comunes al resto de partes, se realizaría de la forma habitual, pero añadiendo costumbres de la agilidad. 4. Dentro del proyecto, sea una fase realizada con agilidad o no, siempre se llevarán a cabo los eventos del marco de trabajo Scrum, ya sea para los equipos Scrum, o para los operarios que trabajan de la forma en cascada. Ya que estas reuniones, ofrecen grandes beneficios al proyecto, cómo son los planes de mejora o los aumentos de productividad, no podemos arriesgarnos a perderlas. De la misma forma, estos eventos se documentarán siempre. Y esos documentos se utilizarán para seguir mejorando y aprendiendo de un proyecto a otro. 5. Utilizaremos la herramienta de trabajo Jira, puesto que, a este software, se le pueden añadir diferentes aplicaciones, como “BigGantt”, para realizar diagramas de Gantt o “Excel for Confluence”, con el que podremos exportar y trabajar con diferentes hojas de calculo dentro de la misma aplicación. 6. El proyecto tendrá, una pila del producto general, en la que aparecerán las fases y las partes del proyecto, pero, a grandes rasgos. Esta pila del producto tendrá asociado, un diagrama de Gantt, que se irá completando según se vayan sucediendo las jornadas, en el que se podrá observar de manera muy visual, el avance completo del proyecto. Y será en las pilas de productos de las diferentes Partes y “Subproyectos”, donde se encontrará mayor detalle, dependiendo, cada una de éstas, de un equipo de trabajo, (como hemos visto en el ejemplo del Sistema de Lubricación del caso práctico). 7. Todas las personas que trabajen en el proyecto tendrán, acceso a la información que haya en Jira. Así, aseguraremos que todo el mundo pueda comunicarse fácilmente, a través de la aplicación, proponiendo eventos para tratar problemas, sugiriendo mejoras… etc. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 130 8. No nos olvidamos de una de las claves de la agilidad, que no es otra que, la comunicación constante con el cliente. Este, tendrá acceso a la página general del proyecto en Jira, en la que podrá acceder al estado del proyecto permanentemente, y donde podrá solicitar, al igual que los trabajadores, informes de cualquier tipo, reuniones con los responsables, visitas a la obra… etc. 9. Esta dinámica de trabajo es la que se seguiría durante todo el proyecto, hasta su finalización. Teniendo en cuenta la aceleración de los equipos, si se sigue la metodología de la forma correcta, el tiempo estimado al principio, será mayor, que el tiempo real en el que se finalizaría el proyecto, repercutiendo muy positivamente sobre los beneficios para la empresa. Así pues, esta sería la propuesta que realizamos para la gestión de este tipo de proyectos. Adaptamos al proyecto las partes más beneficiosas de cada metodología de gestión, para obtener el resultado buscado. 6.3. Conclusiones I. Se realiza el estudio correspondiente, a las metodologías de gestión ágil, detallando sus aspectos más significativos. II. Se realiza el estudio de la práctica seleccionada, dentro de las metodologías ágiles, el marco de trabajo Scrum, adaptándolo a un uso industrial. III. Se hace una comparativa entre metodologías, tras los estudios previos. IV. Se selecciona y estudia la herramienta de trabajo, Jira, para la que se realiza una guía práctica de uso, en la que se muestran sus detalles y ventajas. V. Se completa con éxito el caso práctico, en el que se demuestra, la posible aplicación del marco de trabajo Scrum, al proyecto Pointe Jarry, pasando de una gestión tradicional, a una gestión ágil. Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 131 BIBLIOGRAFÍA Agile for Industry. (n.d.). Retrieved from Agile for all industries - not just Software: https://www.agile.how/ Ambler, S. W., & Holitza, M. (2012). AGILE for DUMMIES. John Wiley & Sons, Inc. Araujo, D. S. (2019, Marzo 28). The softtek blog. Retrieved from Waterfall vs Agile: https://blog.softtek.com/es/waterfall-vs-agile Drumond, C. (n.d.). ATLASSIAN Agile Coach. Retrieved from Scrum: https://www.atlassian.com/es/agile/scrum Llorens, S. (2018). Akademus. Retrieved from Agile Management: Como aplicarlo en proyectos industriales: https://www.akademus.es/learning/miscursos/introduccion-gestion-agil-proyectos-scrum-open-iebs/5698/ Martel, A. (2016). Gestión práctica de proyectos con Scrum, desarrollo del software ágil para el Scrum Master. Menzinsky, A. (2015, Marzo 23). Blog de un apóstol de Scrum y Kanban. Retrieved from ¿Que es el Sprint 0?: https://scrum.menzinsky.com/2015/03/que-es-el-sprint0-actualmente-hay.html Petit, A. (2017). Paradigma. Retrieved from Sprint 0, clave en la gestión de proyectos ágiles: https://www.paradigmadigital.com/techbiz/sprint-0-clave-la-gestionproyectosagiles/#:~:text=El%20Sprint%200%20es%20un,de%20forma%20incremental%2 0e%20iterativa. Project Management Institute, Inc. (2017). AGILE PRACTICE GUIDE. Pennsylvania : Project Management Institute, Inc. RAE. (n.d.). Roche, J. (n.d.). Deloitte España. Retrieved from ¿Qué es Scrum?: https://www2.deloitte.com/es/es/pages/technology/articles/que-esscrum.html Schwaber, K., & Sutherland, J. (2017). La guía definitiva de Scrum: Las Reglas del Juego. Sutherland, J. (2014). SCRUM. The Art of Doing Twice the Workin Half the Time. Oceano. Sutherland, K. S. (2017). La guía de Scrum. Tirado, J. M. (2020, Diciembre 21). Mamá... ¿Qué es Scrum? Retrieved from Tu Sprint 0 es un waterfall vitaminado: https://mamaqueesscrum.com/2020/12/21/sprint0-es-waterfall-vitaminado/ Vázquez, P. (2013, Abril 7). GestióndeProyectosIT. Retrieved from Sprint cero: ¿que necesitamos?: http://www.gestiondeproyectosit.es/blogit/2013/04/sprintcero-%C2%BFque-necesitamos/ Estudio de metodologías ágiles en la gestión de proyectos industriales pág. 132