Aplicación de metodologías ágiles a desarrollo de proyectos

Equation Chapter 1 Section 1 Trabajo Fin de Máster Máster Universitario en Ingeniería Industrial Aplicación de Metodologías Ágiles a Desarrollo de Proyectos Dpto. Organización Industrial y Gestión de Empresas II Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Jesús Santiago Rial Huerta Tutor: Guillermo Montero Fernández-Vivancos Sevilla, 2019 Proyecto Fin de Máster Máster en Ingeniería Industrial Aplicación de Metodologías Ágiles a Desarrollo de Proyectos Autor: Jesús Rial Huerta Tutor: Guillermo Montero Fernández-Vivancos Profesor titular Dpto. Organización Industrial y Gestión de Empresas II Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 Proyecto Fin de Carrera: Aplicación de Metodologías Ágiles a Desarrollo de Proyectos Autor: Jesús Rial Huerta Tutor: Guillermo Montero Fernández-Vivancos El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 El Secretario del Tribunal Llegar aquí fue un sueño, hasta hoy... Agradecimientos Es difícil, acordarse de tanta gente cuando uno emprende un camino muy largo. Un camino, que comencé en septiembre de 2006, cuando decidí cruzar “el charco” (como solía llamar a la distancia que separa Ceuta de la península) para venir a Sevilla. Una Sevilla, de la que me tuve que despedir: aceptar que no estaba preparado para afrontar todo lo que se requería para realizar esta carrera fue lo más difícil, y durante varios años (siete) me costó entenderlo, los mismos siete que pasé en Córdoba aceptando lo que para mí era una derrota, pero no la partida.Creo que cada una de las personas que han vivido, que han convivido conmigo, o con las que he coincidido en todo este tiempo, han dejado una huella en mí, y me es inevitable no recordar a todas aquellas personas que se han ido yendo durante todos estos años. A todos ellos: gracias. Quiero darle las gracias también a mi tutor Guillermo Montero, por su tiempo, dedicación y buenos consejos para la realización de este Trabajo Fín de Máster. También quiero darle las gracias a mi familia, ese pilar fundamental sin el cual nada de esto tendría sentido, y que siempre han guiado mi camino: Miguel, Sonsoles, Diego, gracias por estar siempre ahí. También quiero agradecer a mi segunda familia, ese otro apoyo que ha hecho de este viaje un camino más llevadero: Leonor, Alfonso, Alfonsito, gracias por todo lo que habéis hecho en todo este tiempo. Alfonso, va por ti allá donde estés. Por último, quiero acordarme de la hija de esta segunda familia, que sacó de mí el hombre que soy hoy, la que me motivó a terminar aquelló que empecé y por la que hoy estoy aquí defendiendo este trabajo: Cristina, te quiero y gracias por estar siempre ahí. Jesús Rial Huerta Sevilla, 2019 ÍNDICE DE TABLAS Tabla 1: Comparación entre Metodologías Tradicionales y Ágiles 25 Tabla 2. Ejemplo de Product Backlog. 40 Tabla 3. Ejemplo de Sprint Backlog. 42 ÍNDICE DE FIGURAS Figura 1. Fases del modelo de desarrollo con la metodología Waterfall. 15 Figura 2. Modelo en Espiral. 16 Figura 3. Sistema 360 de IBM. 17 Figura 4. Esquema de etapas presentado por W. Royce. 19 Figura 5. Impacto de riesgos vs Evolución de un proyecto Waterfall. 24 Figura 6. Impacto de riesgos vs Evolución de un proyecto Ágil. 24 Figura 7. Fases del modelo APM. 27 Figura 8. Marco de trabajo de la Metodología XP. 28 Figura 9. Esquema del proceso TDD. 28 Figura 10. Diagrama de criticidad Crystal. 29 Figura 11. Diagrama del proceso DSDM. 30 Figura 12. Fases Proceso ASD. 31 Figura 13. Fases de la Metodología FDD. 31 Figura 14. Principios de Lean aplicados al desarrollo Sotware. 32 Figura 15. Evolución del flujo de valor en el desarrollo de un proyecto. 34 Figura 16. Tablero Kanban. 35 Figura 17. Pilares de la Metodología Scrum. 38 Figura 18. Viñeta humorística relacionada con los roles en Scrum. 38 Figura 19. Ejemplo de Historia de usuario. 41 Figura 20. Ciclo de vida de un proyecto Scrum. 43 Figura 21. Gráfico de Burndown de seguimiento. 46 Figura 22. Tablero Scrum Taskboard. 47 Figura 23. Baraja de cartas de Planning Póker. 48 Figura 24. Ejemplo 1 de diagrama de burndown. 49 Figura 25. Ejemplo 2 de diagrama de burndown. 49 Figura 26. Ejemplo 3 de diagrama de burndown. 49 Figura 27. Reunión de Scrum en oficinas de Endesa. 51 Figura 28. Planificación de las etapas de la aplicación de la Metodología Scrum. 52 Figura 29. Planificación de los distintos Sprints. 53 Figura 30. Planificación de los distintos Sprints. 53 Figura 31. Participantes de las agiles room. 54 Figura 32. Dedicación para cada etapa en función de los roles. 55 Figura 33. Diapositiva de Formación del proceso Agile, a través de la consultora Siag. 56 Figura 34. Baseline del proceso de Liquidaciones. 57 Figura 35. Lista de carencias detectadas en el proceso. 57 Figura 36. Estado Digital del proceso de Liquidaciones. 58 Figura 37. Baseline del proceso de cobros. 59 Figura 38. Baseline del Proceso de Facturación. 59 Figura 39. Lista de carencias detectadas en el proceso de Fact. y Cobros. 60 Figura 40. Estado Digital del proceso de Facturación y Cobros. 60 Figura 41. Explicación del proceso de Facturación en un tablero con post-its. 61 Figura 42. Equipo de trabajo en Room Agile. 61 Figura 43. Scrum Taskboard. 61 Figura 44. Pain Points con los KPI´S asociados para el año 2017. 62 Figura 45. Proceso de Liquidaciones con nuevos pain points detectados. 62 Figura 46. Proceso To be del proceso de Liquidaciones. 63 Figura 47. Listado del Product Backlog con la descripción de las iniciativas. 63 Figura 48 Pain Points con los KPI´S asociados para el año 2017. 64 Figura 49.Proceso de Facturación y Cobros con nuevos pain points detectados. 64 Figura 50. Listado de iniciativas del Product Backlog. 65 Figura 51. Proceso to be con las iniciativas agrupadas en varias soluciones. 65 Figura 52. Pain Points del proceso de liquidaciones reagrupados. 66 Figura 53. Nuenos kpi´s definidos y valorados. 66 Figura 54. Business Model Canvas para la iniciativa del DAR System. 67 Figura 55. Proceso de Facturación y cobros con pain-points agrupados. 67 Figura 56. Tabla con valores de los kpi´s redefinida. 68 Figura 57. Business Model Canvas de la Iniciativa Robot de Prefacturas. 68 Figura 58. Business Model Canvas de la Iniciativa Robot de Prefacturas. 69 Figura 59. Resumen de la iniciativa que se presentó. 69 Figura 60. Resumen de la iniciativa con costes, ahorros y estrategia de desarrollo. 70 Figura 61. Análisis del impacto de la herramienta en el estado digital del proceso. 70 Figura 62. Resumen de la iniciativa con costes, ahorros y estrategia de desarrollo. 70 Figura 63. Excel económico para calcular costes, ahorro y tasas de amortización para las iniciativas. 71 Figura 64. Resumen de iniciativas del proceso de Facturación y Cobros. 71 Figura 65. Mejoras en el proceso con la implantación de las iniciativas. 72 Figura 66. Análisis Coste-Beneficio, plazo, metodología, y estado digital de las iniactivas. 72 Figura 67. Proceso AS IS y TO BE, con la introducción de los nuevos sistemas. 72 Figura 68. Resumen de la agenda del evento. 73 Figura 69. Sala del evento en Barcelona. 73 Figura 70. Distintos participantes revisan un proceso de negocio. 74 Figura 71. Conclusiones extraídas de la retrospective. 74 Figura 72. Equipo analizando el producto backlog. 76 Figura 73. Equipo de trabajo trabajando sobre una historia de usuario. 76 Figura 74. Otro equipo Agile en fase de análisis de una historia de usuario. 77 Figura 75.Equipo agile, debatiendo sobre la priorización de las historias de usuario. 79 Glosario Agile Coach Burndow Chart Pain-Points Planning Poker Product Owner Product Backlog Retrospective Meeting Scrum Persona formada en metología Agile, cuyo objetivo es velar porque se desarrolle la metología. Gráfico de quemado, en el sentido de cuánto se lleva gastado o realizado en el proyecto, comparado con el ritmo teórico. Puntos del proceso que identifican aspectos de mejora. Proceso de identificación de la duración de las tareas mediante cartas. Representa la voz del cliente: conoce las necesidades como negocio, tiene la visión global del product, y es capaz de tomar decisiones. Lista de funcionalidades requerida por negocio. Se encuentra priorizada. Reunión tras la realización de un sprint, para encontrar fortalezas y mejoras. Marco de trabajo para gestionar proyectos dentro de la metodología Agile. Scrum Master Rol con capacidad de gestión. En Scrum, hace referencia a la persona que se encarga de que apliquen las metodologías seleccionadas, y resuelve cualquier problema acerca de las mismas durante todas las etapas del sprint. Sprint Sprint Backlog Sprint Daily Sprint Review Sprint Planning Time-Box Ciclo de trabajo. Proceso organizado en un período de tiempo (usualmente de una a cuatro semanas) que se repite. Es una forma de organización utilizada en Scrum. Conjunto listado de tareas que conforman un sprint. Reunión para revisar la planificación del día anterior, y el día en curso. Reunión de revisión de entregrables con el Product Owner. Reunión de planificación de las tareas del Product Backlog. Duración de un evento (reunión, sprint, etc.). Prólogo Durante estos 4 años en los que he realizado el Máster de Ingeniería Industrial, mi andadura profesional y académica han convivido juntas: antes de empezar el máster, trabajé en una de las cinco únicas fábricas del mundo donde se fabrican los dos principales tipos de transformadores (Columnas y Acorazados) en A.B.B. Posteriormente a esta experiencia, mi vida siguió ligada a ese elemento común como es la electricidad, pero vista desde otra perspectiva: la oportunidad venía de la mano de Endesa Generación y la Unidad de Producción Hidráulica de la Zona Sur de España. Por último, han sido estos últimos 4 años, de la mano de Endesa Medios y Sistemas, los que me han permitido, además de conocer en profundidad el sector eléctrico, colaborar y tratar de mejorar el proceso y los sistemas que soportan la Facturación y el Cobro de los servicios que presta Endesa Distribución. Además de realizar proyectos regulados por la legislación española mediante B.O.E., órdenes ministeriales, o bien acordados en la sede de la Comisión Nacional de los Mercados y la Competencia, la empresa ha apostado por el desarrollo de proyectos, utilizando las metodogías ágiles para la redefinición de los procesos que afectan a todas las áreas de la empresa. A través del presente documento pretendo ofrecer una visión del enfoque y del desarrollo del proyecto, mediante un caso de estudio concreto. Por motivos de confidencialidad con la empresa, el caso de estudio no será un caso real, sino uno ficticio. Dicho caso recoge y abarca, no obstante, datos muy similares al proyecto real. Introducción 12 12 1 INTRODUCCIÓN De un tiempo a esta parte, estamos viendo y viviendo, una serie de continuos cambios que afectan a todos lo sectores, tanto laborales, como no laborales. Todos estos cambios, comparten una misma palabra común: La Globalización. Pero ¿Qué es la globalización? Para definir el término “globalización” pueden utilizarse varias acepciones(Hirsch 2004): i. De forma técnica, globalización y desarrollo de nuevas tecnologías están vinculados. ii. Desde un punto de vista político, la globalización se entiende como un marco de consenso donde la igualdad y la justicia social forman parte de la convivencia mundial. iii. Desde un punto de vista cultural, la globalización se entiende como la aplicación de los derechos humanos de una forma generalizada en todas las comunidades del mundo. iv. Por último, desde un punto de vista capitalista, la globalización representa el libre comercio: la internacionalización y el acceso completo a cualquier recurso en cualquier parte del mundo. De este conjunto de significados, podemos decir que, para la industria (además de para cualquier otro sector), que participa en un mercado globalizado, cada vez es mayor la necesidad de adecuarse ágilmente y de forma estratégica, a las necesidades del mercado, para poder ser competitivo. Estas necesidades, han llevado a que los valores sobre los que se mantienen las industrias, y el negocio que acude a las mismas, se transforme: valores como la sapiencia, la comunicación, y la resiliencia a la alta variabilidad del mercado, han dejado en un segundo plano, otros que eran determinantes hasta ahora, como la preparación de personal y/o la gestión de los recursos. La entrada en el mercado de nuevos productos, con ciclos de vida extremadamente cortos en algunas circunstancias, obliga a incrementar la productividad para ofrecer una mejora contínua de los procesos, tratando de prever las demandas, y siendo capaces de readaptarse en un tiempo récord, para poder seguir compitiendo en un mercado global. Este hecho, afecta de forma directa, al desarrollo de sistemas informáticos, que aporta valor, cada vez en mayor medida, al resto de procesos industriales en los que la informática forma parte como eje necesario sobre el que desarrollar los productos. Ya en otros libros, como por ejemplo, en “Ingeniería de Software” (Addison-Wesley 2006) se defiende el desarrollo de la economía mundial como motivo principal para el desarrollo informático. También, entre otros factores, se defienden como fuentes de desarrollo, la descentralización empresarial, el reparto de tareas de forma automática, la volatibilidad de los requerimientos, la reducción del time-to-market 1 , las U.X. 2 , el avance tecnológico y la aparición de problemas de forma asíncrona como puntos clave en el desarrollo software en la actualidad. Ante esta situación, cabe preguntarse sobre el nivel de efectividad de las metodologías utilizadas en el desarrollo de sistemas software hasta ahora, también llamadas metodologías convencionales, frente a nuevas formas de desarrollo. ¿Se adaptan los métodos actuales de forma rápida a los cambios, y a los cambios de necesidades? ¿Cabría la opción de desarrollar un nuevo método adaptado a la situación actual? Según Kent Beck (miembro de la composición del manifiesto ágil), “cada cosa en software cambia: los requisitos cambian, el diseño cambia, el negocio cambia, la tecnología cambia, el equipo cambia y los miembros del equipo cambian. El problema no es el cambio, porque el cambio, inevitablemente, va a ocurrir. El problema, realmente, es nuestra incapacidad para hacer frente a los cambios”. 1 Tiempo desde que un producto es concebido, hasta que llega al mercado. 2 Experiencias de usuario (User Experience) Por todo ello, podemos concluir que una parte del mercado del software está sufriendo evoluciones contínuas, y que no existía una metodología que cubriera dicha casuística, ni en tiempo ni en forma. Ante estas situaciones, las metodologías ágiles se presentan como una alternativa asumible, debido a que otros métodos de desarrollo, basados en aspectos tradicionales como el control sobre la estricta calidad de la documentación, el control total de jerarquías, o el cumplimiento de hitos y fases de una manera secuencial, no son los más recomendados para proyectos donde las condiciones de desarrollo son muy variables, y donde priman los tiempos, y la calidad del software, frente a aspectos más procedimentales. Además, una gran parte del desarrollo de sistemas que se realiza hoy día, está más centrado en el desarrollo de productos ya creados, añadiendo nuevas funcionalidades, o modificando otras existentes, con el objetivo de rentabilizar la inversión inicial (un caso que da fe de esta situación, podría plasmarse en el actual sistema informático comercial de la compañía sobre la que se desarrolla este trabajo, cuya versión inicial de lanzamiento, data del año 2000, y sobre el que se han ido añadiendo nuevas características, manteniendo el mismo core). De hecho, algunos estudios (Addison-Wesley 2006) ponen de manifiesto que el presupuesto dedicado al mantenimiento del software y pequeñas mejoras pueden llegar a suponer un 80% del presupuesto, dedicando el 20% restante a nuevas funcionalidades. 1.1 Objetivos El objetivo de este proyecto es presentar el uso de las metodologías de desarrollo ágil en proyectos de software, para posteriormente, dar fe de su aplicación en un desarrollo realizado con la metodología SCRUM en la creación de un proyecto concreto: SMART, un sistema software capaz de monitorizar de facturación y cobros de una empresa, y notificando al área correspondiente los errores detectados, incluyendo el flujo de resolución de estos. Además, se explicarán de forma detallada todas las etapas, herramientas y terminologías que se usarán para el desarrollo de proyectos, mediante esta metodología, encontrándose al principio del documento, un glosario de toda la terminología a emplear, para que resulte más cómoda su lectura, debido a la cantidad de términos que se emplean para describirlas. Metodologías 20 20 En la era de las metodologías nacieron nuevos enfoques en respuesta a las limitaciones enumeradas anteriormente, que se pueden agrupar en dos vertientes: las que mejoraron el modelo waterfall y las que buscaron una nueva forma de gestionar proyectos. Además, a finales de los años 70 surgieron nuevas herramientas y técnicas sobre los que se basaron estas nuevas metodologías, como pudieron ser los diagramas de flujos, el modelo entidad-relación, la normalización, los diagramas de actividad, etc., y herramientas, como las de gestión de proyectos, bases de datos de código, repositorios de modelado, etc. Entre las metodologías que mejoraron el modelo waterfall, surgieron MERISE, Yourdon System Method, o Structured Systems Analysis and Design Method (SSADM), que integraban las novedades enumeradas en el párrafo anterior. Entre las metodologías alternativas de los años 80, Avison realizó una clasifición de las mismas en varios grupos de una forma sencilla de entender (Avison y Fitzgerald 1998): o Sistemáticas: emplean técnicas cualitativas a situaciones no sistemáticas. Un modelo que aplica esta medología podría ser Soft Systems Methodologies (SSM 6 ). o Estratégicas: enfocadas en la planificación previa al desarrollo de software, para cumplir los requisitos de negocio. Un modelo que aplica esta medología podría ser Business Systems Planning. o Participativas: basadas en la involucración de usuarios en el análisis, diseño e implementación. Como podría ser, ETHICS. o Prototipadas: utilizan prototipos para visualizar y validar el producto. Un modelo que aplica esta medología podría ser, Rapid Application Development (RAD 7 ). o Estructuradas: extienden la programación estructurada al análisis y diseño, con técnicas que permiten un análisis descendente y la representación compleja de procesos. o Análisis de datos: tratan de documentar y comprender los datos. Un modelo que aplica esta medología podría ser, Information Engineering. Posteriormente, en los primeros años de los 90 nacieron nuevas metodologías (Carvajal Riola 2008) como:  Orientadas a objetos. Enfocadas en objetos que representan entidades del mundo real.  Desarrollo incremental o evolutivo. Basadas en prototipos primitivos sobre los que desarrollar por etapas. Un modelo que aplica esta medología podría ser, Dynamic System Development Methods (DSDM).  Específicas. Llevadas a cabo para cierto tipo de proyectos, buscan un objetivo en concreto: o Welti, para desarrollar aplicaciones tipo ERP 8 . o CommonKADS, para aplicaciones de gestión de conocimientos. o Process Innovation, para aplicaciones de reingeniería de procesos. o Renaissance, para aplicar ingeniería inversa en sistemas heredados. o Web IS Development Methodology (WISDM), para aplicaciones Web. Sin embargo, gran parte de los usuarios de estas metodologías, no acabaron de estar satisfechos con las metodologías que emplearon, bien fuera waterfall o alguna de sus variantes. La mayoría, estaban destinadas para aplicarse en situaciones ideales, y en las situaciones reales, aparecían problemas, debido también a la singularidad de cada proyecto. Uno de los motivos principales de este descontento, fue que los usuarios de dichas metodologías esperaban encontrarse un guión paso a paso, y con un enfoque descendente (desde arriba hacia abajo) a lo largo del desarrollo (rara vez se da), pues lo normal, suele consistir en adaptar el guión, omitiendo fases y modificando el órden de ejecución de los pasos de éste. 6 Metodología Suave de sistemas. 7 Desarrollo rápido de aplicaciones. 8 Planificación de Recursos. El resultado fue la aplicación de metodologías más permisivas en las que el desarrollador elige la estructura, las herramientas, las técnicas, y las fases, en función de la necesidad del momento. (Un modelo que aplica esta medología podría ser Multiview). El éxito o fracaso en el desarrollo no dependió únicamente a la utilización de una metodología en concreto, pero a pesar de ello, nació una corriente, que replanteó los beneficios de las metodogías, que, juntamente con otros conceptos no metodológicos, darían paso a la era post-metodológica. Existen diversos motivos que explicarían este rechazo al uso de las metodologías, pero una de las principales fue la decepción por el no cumplir las expectativas iniciales: las metodologías no pudieron solucionar, todos aquellos problemas para los que supuestamente la metodología pondría fin. Algunas de las razones que Fitzgerald y Avison (Avison y Fitzgerald 1998) presentan como las causantes del debate metodológico fueron:  Productividad: no aumentaron la productividad prometida.  Complejidad: en ocasiones eran demasiado complejas.  Habilidades: eran necesarias habilidades específicas.  Herramientas: era difícil utilizarlas, caras y no eran rentables.  No contingente: no se adaptaban a las necesidades.  Enfoque unidimensional: basadas en una sola idea sobre cómo desarrollar.  Inflexible: imposibilidad de adaptarse a los cambios.  Supuestos no válidos: no se permite la modificación de requerimientos en ningún momento.  Desplazamiento del objetivo: el uso literal de las herramientas, dejando de lado la creatividad.  Poco orientadas: a personas y al entorno.  Dificultades: para ponerlas en práctica. Como hemos visto hasta ahora, cuando una metodología, o varias, no cubrían las necesidades, surgían nuevas variantes que trataban de dar solución. Mostramos ahora, los planteamientos que se llevaron a cabo en las empresas, y en los usuarios respecto a esta situación:  Desarrollo externo: las empresas optaron por no realizar de forma interna proyectos informáticos y externalizarlos.  Mejora continua: se apuesta por la mejora continua.  Desarrollo ad hoc 9 y contingencia: el desarrollo ad hoc supone la vuelta a la era premetodológica.  Desarrollo contingente o flexible: permitiendo, manteniendo una cierta estructura, posibilidades de elección de componentes a los desarrolladores.  Desarrollo ágil. Centrada en la participación de los usuarios y clientes más que en procesos y herramientas, trabajando más en el software y menos en la documentación, colaborando más con clientes en vez de negociar, y responder a los cambios por encima de la planificación de los tiempos del trabajo. 9 Ad hoc: Específico Metodologías 22 22 2.4 Requesitos para el Nacimiento de una Metodología. La enciclopedia de la ingeniería de software (Scacchi 2002) propone los siguientes aspectos a cumplir por toda metodología: 1. Visión del producto: todas las partes deben de conocer todos los detalles sobre el producto: plazos, tareas, cambios, etc. 2. Vinculación con el cliente: la metodología trata de ser la base para indicar las relaciones entre los distintos actores dentro de un proyecto: usuarios, programadores, soporte, etc. 3. Establecer un modelo de ciclo de vida: elegir un modelo: iterativo, waterfall, etc. Así se podrán conocer las fases, y gestionar los recursos. 4. Gestión de los requisitos: mínima calidad exigible a los requerimientos del producto. 5. Plan de desarrollo: plan lo suficientemente claro, y conciso, para que los programadores puedan llevar a cabo los desarrollos de una forma clara y precisa, sin equivocaciones, y sin dudas. También debe ser posible añadir modificaciones con posibilidad de recuperar el plan original. 6. Integración del proyecto: La metodología debe clarificar como el producto se relacionará con el resto de los productos actuales, en el presente, y a futuro. 7. Medidas de progreso del proyecto: deben ser accesibles, y lo suficientemente claras, para que todas las partes del proyecto sean capaces de ver, de una forma fácil, y rápido el estado actual de un proyecto, y del tiempo que resta para su terminación. 8. Métricas para evaluar la calidad: el equipo encargado de gestionar los despliegues del producto debe controlar y preservar la calidad del software que se está desarrollando, como un símbolo de estabilidad del producto. 9. Maneras de medir el riesgo: se deben tener controlados los riesgos: no solo en la gestión de estos, en las fases donde aparezcan, sino también en la medida en que puedan ser cuantificados y cualificados para dar una mejor respuesta a los pasos necesarios a dar, para afrontarlos. 10. Cómo gestionar los cambios: debe ser posible incluir la posibilidad de que aparezcan cambios, o bien en las necesidades del negocio, o bien en el propio desarrollo del software. 11. Establecer una línea de meta: se debe tener presente con qué funcionalidades probadas, se dará por bueno un producto. Es necesario que todas las partes que conforman el proyecto sepan de forma clara, cuando algo está “finalizado”. Viendo todos estos aspectos enumerados por la enciclopedia del software, parece que no hay ninguno de ellos que se aleje del uso del sentido común, y con los que todos podríamos estar de acuerdo en que son necesarios cumplir en cualquier metodología. 2.5 Metodologías Ágiles. 2.5.1 Necesidad de las metodologías Ágiles. En la industria del software, el desarrollo de procesos, y por tanto de productos, ha venido utilizando metodologías que lo encasillaban como algo rígido e inflexible, aspecto que se desmiente al analizar la variedad y la dinámica del mercado de software. Como indica Boehm (Boehm 1979) en su libro “Software Engineering as It Is” la tendencia del sector se dirige hacia desarrollo en menos tiempo, y a una vida más corta de los productos finales. Es en estas condiciones, donde la entrega de valor de producto en plazos de tiempos muy cortos para llegar al mercado, marcan la diferencia. Sin embargo, las metodologías tradicionales, presentan ciertos problemas a la hora de gestionar proyectos cambiantes, o con cierto dinamismo. Algunos de estos problemas son:  La toma de requerimientos como primera etapa ante de comenzar el desarrollo, debe cubrir todas las funcionalides y todos los aspectos de aquello que se desea implantar. Con esto, se busca evitar cambios a mitad de proyectos, que resulten inviables por costes y tiempo (también se conocen como metodologías predictivas). La realidad de este hecho es que difícilmente una toma de requerimientos completa justifica el tiempo y coste invertido en realizarla.  El cliente no tiene los conocimientos suficientes para definir con el nivel de detalle necesario, lo que necesita, cambiando sus necesidades a lo largo del desarrollo. Llevar un control de cambios, y distintas herramientas para controlar este tipo de situaciones, permiten proteger al proyecto en su desarrollo, pero desde el punto de vista del cliente, se entiende la gestión como algo que no se adapta a sus necesidades cambiantes, y que, en caso de necesidad de cambios, tengan costes adicionales.  El desarrollo del proyecto contiene documentación que no siempre se utiliza, ni tampoco se revisa. La entrega por hitos suele implicar la dedicación de recursos a elaborar mucha documentación con gran nivel de detalle que, en ocasiones, ni se utiliza, no la revisa el usuario, y por tanto no aporta valor sobre el producto final, teniendo que hacerse un esfuerzo exponencial en caso de que surjan cambios sobre el proyecto.  El ritmo para desarrollar un software es lento. A los programadores, les resulta difícil entender sistemas tan complejos e interconectados, lo que desencadena en ritmos más lentos. Por ende, los propios desarrollos se abordan por etapas en pequeños trozos para reducir la posibilidad de errores y de costes a la hora de desarrollar. Además, las funcionalidades se van agregando, de forma que se puedan ir liberando parcialmente en los distintos entornos para que puedan ser probadas. Sin embargo, el ritmo que marca competencia exige velocidad, calidad y ahorro de costes, desplegando de manera contínua funcionalidades, debido a que, si no, los productos en su totalidad puedan quedar obsoletos. Todos estos factores, hacen que sea dificil cumplir el Time to Market consiguiendo un malestar por parte de los usuarios:  Al no haber sabido responder a tiempo, a lo que demandaba el mercado.  A enfrentarse con los gestores de proyecto por no haberse involucrado lo suficiente para entregar el software a tiempo.  A tener una sensación de que los desarrollos siempre son muy lentos, y muy costosos, pensando que faltan más programadores para adelantar dichos procesos de desarrollo. Metodologías 24 24 A todo esto, se suma que en las metodologías tradicionales los riesgos se acumulan, siendo críticos si surgen en la etapa final, repercutiendo en retrasos, o incumpliendo la ejecución de las últimas fases del ciclo del proyecto. A diferencia de las metodologías clásicas, las metodologías ágiles surgen como una variante para dar respuesta a estos problemas.Como bien indica el artículo “Hallazgos empíricos en Métodos Ágiles” (Lindvall et al. 2002) las metodologías ágiles son adecuadas cuando los requisitos son emergentes, y cambian de forma rápida. De este modo, presentan varias ventajas: 1. Respuesta a los cambios durante el desarrollo puesto que durante toda la vida del desarrollo existe la posibilidad de mejorar el producto, y por tanto la percepción del cliente hacia el mismo, ya que es partícipe, y además, se integra la gestión de cambios como una característica del proceso. 2. Entrega continúa en plazos breves permitiendo al cliente saber en todo momento el estado de avance del proyecto, pudiendo probar las funcionalidades del producto incrementalmente y comprobar si cumplen sus necesidades, mejorando su satisfacción. Además, el trabajo y evaluación en periodos cortos de tiempo, disminuye el tamaño de los riesgos, las dificultades a dichos ciclos, y permite ir aprendiendo de los mismos. Figura 5. Impacto de riesgos vs Evolución de un proyecto Waterfall Figura 6. Impacto de riesgos vs Evolución de un proyecto Ágil 3. Trabajo codo con codo entre cliente y equipo de desarrollo con una comunicación directa y fluida eliminando malentendidos (principal origen de errores), y documentación que no aporta valor. 4. Importancia de la simplicidad eliminando trabajos innecesarios. 5. Gestión de cambios integrada en el propio proceso. 6. Mejora continua de los procesos y del equipo de desarrollo, dependientes del éxito técnico, del éxito personal y del éxito organizacional. En la siguiente tabla, podemos hacer una comparación entre las metodologías tradicionales y las metodologías ágiles: Tabla 1: Comparación entre Metodologías Tradicionales y Ágiles Metodologías Tradicionales Metodologías Ágiles Basadas en estándares. Basadas en buenas prácticas aprendidas y las experiencias. Inflexibles. Preparadas para cambios en el proyecto. Normas impuestas externamente. Normas impuestas internamente. Jerárquicas, donde se aplican políticas/normas. Proceso con menos principios. Hay un contrato previo. No hay contrato, o si hay, es flexible Diálogo cliente-desarrollador inexistente. Cliente integrado en el equipo. Grupos grandes y en distintas localizaciones. Pequeños grupos trabajando en el mismo sitio. Muchos roles en la organización Pocos roles. La arquitectura es esencial. Menos énfasis en la arquitectura. 2.5.2 Manifiesto Ágil: Origen, y principios. El origen de la metodología ágil se remonta a febrero de 2001, donde durante una reunión celebrada en Utah (Estados Unidos), nació el uso de la palabra “ágil”. En dicho evento, participaron 17 expertos de la industria del software, incluyendo a fundadores de algunas metodologías. El propósito de la reunión fue determinar los pasos a seguir por los grupos de desarrolladores para dar respuesta a la necesidad de crear un producto en el menor tiempo posible, admitiendo modificaciones durante su desarrollo. De esta forma, se buscaba una nueva forma de desarrollar software frente a los modelos tradicionales, más rígidos e inflexibles. Como resultado, se fundó “La Alianza Ágil”, una organización dedicada a promulgar estos principios, ayudando a las empresas a aplicar estos conceptos. La base sobre la que se construyó dicha alianza fue el Manifiesto Ágil, un documento que resume la filosofía “ágil” en 12 principios: los dos primeros sintetizan la idea de agilidad, y el resto, desarrollan las pautas de desarrollo para el equipo de programadores, su organización y cómo conseguir los objetivos (José, H., Canós, P. L., & Carmen 2003): De forma análoga, a lo ya comentado anteriormente en los requisitos para el nacimiento de una nueva metodología, en estos principios lo que se pretende es aplicar de nuevo un poco de sentido común, planteando cuestiones elementales, basadas en experiencias previas de fracasos que generalmente coinciden siempre en los mismos aspectos. Metodologías 26 26 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporten valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan, y confiar en ellos para conseguir finalizar el trabajo. 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. 7. El software que funciona es la medida principal de progreso. 8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. 9. La atención continua a la calidad técnica y al buen diseño, mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Estos 12 principios, se resumen en 4 aspectos que valoran las metodologías ágiles: I. Se valora al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. El éxito depende de las personas: es mejor tener un gran equipo, que un buen entorno de trabajo. En ocasiones se comienza preparando un entorno de desarrollo sobre el que se selecciona al equipo, esperando que éstos se adecúen a él, en lugar de dejar que sea el propio equipo el que defina sus condiciones de desarrollo. II. Desarrollar software en lugar de tener una detallada documentación. Se aboga por “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Los documentos han de ser de poca extensión y muy concretos. III. La colaboración con el cliente más que la negociación de un contrato. Se plantea la relación continua entre usuario/negocio y equipo de programación. Esto hará que el proyecto fluya hacia un entendimiento total, y por tanto al éxito. IV. Responder a los cambios más que seguir estrictamente un plan. Es necesario poder integrar las modificaciones que surjan a lo largo del desarrollo ( ya sea al principio, o durante el proyecto) para poder llevar a cabo con éxito el proyecto, siendo necesaria una gran flexibilidad en la planificación. 2.5.3 Tipos de Metodologías Ágiles. En este apartado, haremos un recorrido introductorio por las distintas metodologías Ágiles, para posteriormente, analizando los marcos de trabajo donde se mueven estas metodologías, realizar un análisis profundo de Scrum, que será la que se desarrolle con este proyecto, pero siendo necesarias citar al resto, para poder crear un contexto. 2.5.3.1 Agile Project Management (APM) Fue desarrollada por Jim Highsmith en 1999 a través de su libro “Adaptive Software Development: A Collaborative Approach to Managing Complex System”. En el libro, Jim defiende que el proceso de desarrollo debe estar en consonancia con los objetivos, de forma que, si los objetivos se repiten y se pueden definir de forma previa en su totalidad, un proceso prescriptivo sería idóneo, pero si los objetivos de negocio son cambiantes, y con cierto carácter innovador, entonces el marco de trabajo debiera ser ágil, con una gran flexibilidad y adaptabilidad. El modelo APM se basa en 5 fases: la previsión, la especulación, la exploración, la adaptación y el cierre. Previsión. En esta fase, se definen los objetivos del proyecto, componentes del equipo y las formas de trabajar de forma conjunta. Especulación. En esta fase, se hace una planificación de una serie de entregables con el conjunto de funcionalidades del producto (esta fase reemplaza a la planificación tradicional, porque planificar implica predecir en cierta forma el futuro, mientras que la especulación permite designar el futuro como algo incierto). Exploración. En esta fase, se obtienen las funcionalidades requeridas, para ser probadas y aceptadas por el usuario final. En esa fase se da mayor importancia a la integración del equipo para el desarrollo de las funcionalidades. Adaptación. En esta fase, se revisan las funcionalidades desplegadas, el estado y cómo ha trabajo el equipo, haciendo algunas modificaciones si fuera necesario. Cierre. Terminado el proyecto, se celebra aprendiendo de las experiencias vividas. 2.5.3.2 Extreme Programming (XP). La programación extrema fue desarrollada por Kent Beck en el año 2000, y propuesta en el libro “Extreme Programming Explained: Embrace Change” (Beck 2000). Esta metodología, se centra en desarrollar las relaciones entre personas como forma de llegar al éxito en cualquier desarrollo. Por ello esta metolodogía tiene un diseño muy acorde a lo que se demanda dentro del desarrollo ágil. En el Extreme Programming se busca la cooperación entre los distintos miembros del equipo, rodeados de un gran ambiente de trabajo. XP se basa en el feedback continuo entre usuarios y programadores, dando paso a una comunicación fluida entre los miembros, busca la simplicidad de las soluciones y la determinación ante los cambios. Su nombre tiene relación, a los principios que defiende, aplicando el sentido común, pero de una forma extrema. Esta metodología es muy útil en proyectos donde los requisitos puedan ser imprecisos, variables, y donde los riesgos sean altos (Ortiz 2010) Figura 7. Fases del modelo APM. (Carvajal Riola 2008) Metodologías 28 28 2.5.3.3 Test Driven Development (TDD) También conocida como “desarrollo orientado a pruebas”, sería como la forma de aplicar el Extrem Programming. Esta técnica, por decirlo de alguna forma, se da en el ciclo de vida de la metodología XP, durante las fases de iteración, producción y mantenimiento. Siendo una técnica orientada al desarrollo de proyectos a través de las pruebas, y debido a su importancia, ya se considera una metodología fuera del Extreme Programming. Como comenta Carvajal (Carvajal Riola 2008), se puede considerar esta forma de desarrollar proyectos una metodología, al presentar normas y formas de desarrollo, que condicionan el desarrollo del proyecto, aumentando su calidad. Es aplicable de forma independiente, o juntamente con otras metodologías como SCRUM, o FDD, o waterfall. El proceso consiste en iterar 3 procesos que se repiten dentro de esta metodología: 1. Detallar las pruebas para la funcionalidad que se quiere implementar. 2. Codificar dicha funcionalidad hasta que pase la prueba. 3. Recodificar ambos códigos, para estructurarlo. De esta forma, se itera en bucle, construyendo las funcionalidades del sistema a desarrollar. Figura 8. Marco de trabajo de la Metodología XP (Lopez.R.E. 2015) Figura 9. Esquema del proceso TDD. (Gimson 2012) 2.5.3.4 Crystal Methodologies Metodología basada en la clasificación de la complejidad de un proyecto, en función de una serie de colores, de forma que cuanto más oscuro más complejo será el proyecto. Este método, además propone utilizan un color por proyecto dependiendo del tamaño de este y de su criticidad. Debido a esto, no hay una norma estándar de Crystal, si no que hay una aplicación específica de la metodología para cada proyecto sobre el que se haya aplicado cada tipo de proyecto. Cada letra de la figura del ejemplo anterior hace referencia a los distintos tipos de riesgos:  C: Pérdida de confort por un fallo en el sistema.  D: Pérdida de dinero (dinero propio).  E: Pérdida de dinero (dinero por préstamos).  L: Pérdida de vidas humanas por un fallo en el sistema. Los números hacen referencia a las personas que forman el proyecto de la siguiente forma (Gimson 2012):  Clear, para menos de 8 personas.  Amarillo, entre 10 y 20 personas.  Naranja entre 20 y 50 personas.  Rojo entre 50 y 100 personas, siguiendo este patrón con otros colores. 2.5.3.5 Dynamic Systems Development Method (DSDM) Desarrollo de sistemas centrada exclusivamente en que se satisfagan las necesidades del usuario. Este sistema fue publicado en febrero de 1995, como un método genérico para personas, procesos y herramientas. DSDM Consortium es la propietaria y administradora del método DSDM y solo sus miembros pueden utilizarlo. Para el DSDM, el desarrollo se ve como algo iterativo e incremental, en el que el usuario debe estar siempre presente, y en el que hay estar preparado para los cambios, siendo la única metodología que cubre el ciclo de vida del proyecto en su totalidad, al incorporar técnicas de gestión de proyectos, y otras técnicas para garantizar la rentabilidad del proyecto, de acuerdo a la solución prevista. Figura 10. Diagrama de criticidad Crystal (Gimson 2012) Marco de las metodologías ágiles 36 36 En cada equipo o grupo de trabajo, las normas se definen dentro del mismo, pudiendo establecerse cuantos criterios necesite el equipo para poder trabajar, como por ej: • Cada columna representa un proceso, con la marca del límite de tareas máximas simultáneas. • Las tarjetas blancas representan productos en proceso para realizarse. • Las tarjetas amarillas representan tareas a realizar para terminar un producto o subproducto. • Los avatares (emoticos) representan a los responsables de cada tarea. No se suele nombrar al responsable de cada tarjeta porque puede ser tratada por diferentes personas en diferentes momentos. • Las tarjetas verdes representan tareas completadas. • Las tarjetas rojas representan tareas bloqueadas por otras, o limitaciones encontradas durante el proceso. • Existen también reglas de decisión que indican el procedimiento a la hora de modificar las tareas en el tablero, pero también pueden contener información relevante para el proceso, notas, feedback, que se suelen colocar en la parte inferior de cada proceso del tablero. Cada tarjeta puede tener los siguientes datos: 1. Fecha de la tarea y de entrada y salida de cada proceso. 2. Fecha comprometida (si aplica). 3. Descripción. 4. Prioridad. 5. Estimación de la duración. El sistema Kanban puede entremezclar varios proyectos y sus tareas asociadas. El propósito es mantener un continuo ritmo de trabajo constante, con las tareas encoladas para ser realizadas de forma que no se pierda el ritmo y se tenga un seguimiento continuo. Como ventaja, Kanban permite no solo llevar la gestión de uno o varios proyectos, sino también tener presente las incidencias que van sucediendo y tenerlas en cuenta en próximos pasos. 3.1.3.4 Indicadores. Kanban dispone de varios indicadores como pudiera ser el límite de trabajo, que permite decidir si se debe comenzar un nuevo trabajo. De esta forma, y teniendo presente cuándo se plantearon estos límites se pueden regular los problemas que surgen en los procesos, así como liberar parte de recursos asignados a otras tareas, si fuera necesario. Además, las colas de tareas por hacer, y en los propios procesos, no dan pie a malas interpretaciones, porque todo el mundo puede ver en qué tarea está trabajando cada miembro, y con qué prioridad. 3.1.3.5 Funcionamiento y problemas en Kanban Una vez que comienza el equipo a trabajar, se suele lograr un ritmo constante, equilibrado y sostenido en el tiempo conforme las tareas se van realizando, y cada miembro se habitua a esta nueva forma de trabajar. Una de las situaciones que se deben evitar es la generación de cuellos de botella, ya que además de parar el ritmo de trabajo, son origen de errores, fallos, y olvidos que se pueden, y deben evitar. Esto puede ser debido a una mala definición de límites, problema de limitación de recursos, o una oportunidad de mejora en otros procesos. En caso de producirse, lo mejor es usar recursos libres para desatascar las colas, y examinar el proceso a posteriori para buscar mejoras. Otra situación que puede darse es la falta de asignación de tareas, porque una persona haya completado todas sus tareas, pero no pueda proseguir porque la tarea con la que comenzar, todavía no la ha terminado la persona de la que depende en ese momento dicha tarea. De nuevo, puede deberser a un problema de definición de límites, recursos, y una oportunidad de mejora. Una situación adicional que se puede presentar se da cuando un recurso asignado a una tarea se libera y otro miembro aún no ha finalizado su tarea. En estos casos, la persona que no tengan tareas asignadas en ese momento podría asignarse otra tarea de la cola de tareas o ayudar al compañero a terminar la suya. La regla no escrita, dice que un recurso libre debería ayudar al compañero a terminar el trabajo siempre que sea posible. De esta forma cuando los dos finalizan dicha tarea, pueden asignarse dos tareas de la cola de tareas. 3.2 Scrum 3.2.1 Breve Historia sobre Scrum Scrum forma parte de una evolución del modelo Shashimi, que fue concebido en Japón como una variante a la metodología waterfall, que buscaba una mayor velocidad, flexibilidad, y un mayor feedback al final de cada etapa del modelo en cascada. La primera vez que apareció el término Scrum fue en el año 1986, de la mano de Hirotaka Takeuchi e Ikujiro Nonaka en The New New Product Development Game (Takeuchi y Nonaka 1986) donde se hizo una recopilación de nuevos métodos de desarrollo exitosos,utilizados en empresas de Japón y en Estados Unidos (como por ej. las cámaras fotográficas Canon, fotocopiadoras de Xerox, vehículos Honda, los ordenadores de Hp,etc…). Los equipos detrás de estos productos fueron capaces de lanzar al mercado, partiendo de requisitos muy generalistas, de funcionalidades, y, por tanto, productos muy novedosos, en mucho menos tiempo que la competencia, compartiendo ciertos patrones en el desarrollo de proyectos. En dicho estudio presentado por los autores anteriormente citados, se realizó una analogía entre la manera de trabajar entre los equipos de desarrolladores, y la colaboración entre los jugadores de un equipo de rugby. La palabra Scrum tiene el mismo origen que en el deporte del rugby, donde se utiliza en la jugada en la que se debe devolver el balón que ha salido del campo de forma colectiva (Scrum significa melé en castellano). Scrum no fue puesto en práctica hasta 1993, cuando Jeff Sutherland aplicó el modelo al desarrollo informático para la compañia Easel Corporation. En 1996, Jeff Sutherland, y Ken Schwaber presentaron las las normas que usaron para los desarrollos informáticos en OOPSLA 95 en Austin, Texas (Conferencia Internacional sobre programación, lenguajes y aplicaciones que es realizada cada año por la A.C.M. (Association for Computing Machinery)) Posteriormente, Schwaber y Mike Beedle presentaron SCRUM en 2001 mediante el libro Agile Software Development with Scrum. Actualmente se encuentra publicada la Guía de Scrum (The Scrum Guide), como la referencia oficial de normas de Scrum, escrita por Ken Schwaber y Jeff Sutherland. La última versión de esta guía fue publicada en noviembre de 2017. 3.2.2 Descripción general de Scrum. Según la Guía del Conocimiento de Scrum (Satpathy 2017) un proyecto Scrum consiste en “un esfuerzo de colaboración para crear un nuevo producto, servicio u otro resultado tal como se define en la declaración de la visión del proyecto” (Project Vision Statement). Los proyectos suelen estar perjudicados por motivos de tiempo, coste, alcance, calidad, recursos, y demás restricciones que dificultan la planificación, y ejecución de estos. No obstante, la finalización de un proyecto en tiempo y forma con éxito repercute de forma económica a la empresa. Por ello, es necesario que las empresas sean capaces de implantar una metodología capaz de gestionar todos estos aspectos de forma adecuada. Marco de las metodologías ágiles 38 38 Scrum es un framework 14 adaptable, rápido, iterativo, eficaz, y flexible concebido para dar valor a un proyecto de una manera ágil y rápida. Scrum permite mejorar la comunicación y crear un entorno de responsabilidad común entre los participantes del proyecto, y una tasa de avance de forma constante. Scrum, por cómo está definido, es compatible con todo tipo de productos y todo tipo de proyectos, independientemente de la complejidad. El desarrollo de Scrum, se fragmenta en pequeños periodos de tiempo de trabajo, en los que se trabaja de una forma concentrada, llamados Sprints 15 . Estos sprints, permiten un alto ritmo de trabajo, en parte debido a que los equipo son altamente cualificados, y con las autorizaciones suficientes como para tomar decisiones relativamente importante sobre la marcha, eliminando tiempos de espera que no aportan nada. Scrum se basa en tres pilares fundamentales: 3.2.3 Roles de Scrum. En Scrum, existen una serie de roles que se aglutinan en 2 conjuntos de personas: de una parte, estarían las personas que deben estar involucradas tanto en el proyecto como en Scrum, y de otra parte, están las personas que no siendo imprescidibles para el desarrollo del proyecto, o la aplicación de Scrum, su presencia en determinadas situaciones es necesaria. Estos 2 grupos, también son conocidos como el grupo de los cerdos y el de las gallinas, por una viñeta muy conocida en relación con un cerdo y una gallina, y la intención de montar un restaurante entre ambos: 14 Framework: Marco de Trabajo 15 Sprint: Con sprint, se hace referencia al conjunto de tareas y acciones que se hacen dentro del Sprint. Un proyecto se divide en n sprints. Transparencia Inspección Adaptación Figura 17. Pilares de la Metodología Scrum Figura 18. Viñeta humorística relacionada con los roles en Scrum Roles Comprometidos • Product Owner: Representa la voz del cliente, toma las decisiones, y es la que conoce realmente las necesidades del producto como usuario. Escribe las historias de usuario, y las prioriza en el Product Backlog. • Scrum Master: Es la persona encargada de garantizar que se aplica la metodología. Se encarga también de que el equipo no se desvíe de sus tareas, y trata de resolver aquellos problemas que impidan la consecución del sprint. Realizando tareas de coordinación, dirige los scrums diarios, y sigue el avance del proyecto. • Equipo: Está compuesto por menos de 8 personas (en caso de haber más, se dividiría en más equipos que trabajarían sobre el producto backlog del mismo). Son responsables de desarrollar y presentar el producto, tomando decisiones, pues tienen asumidas responsabilidades de decisión y de gestión. Son capaces de estimar el esfuerzo de las tareas del product backlog, y entregar un grupo de tareas del producto Backlog al final del Sprint. Roles Involucrados • Usuarios: personas para las que se diseña el producto. • Stakeholders o Interesados (Clientes, Proveedores): personas que, de forma indirecta, están relacionados con el proyecto porque de alguna forma les afecta (ya sea en positivo o en negativo). Participan durante la revisión de cada Sprint. • Managers: Son aquellas personas encargadas de preparar el marco de trabajo en el que se desarollará el producto. Además, participan en la toma de decisiones en situaciones bloqueantes o de atasco. 3.2.4 Elementos en Scrum. Los principales elementos de Scrum que son necesario conocer para entender el proceso, si bien se utilizarán otros que se irán describiendo más adelante, son (José, H., Canós, P. L., & Carmen 2003): 3.2.4.1 Product Backlog. El Product Backlog consiste en una lista de funcionalidades necesarias para negocio priorizada en función de las necesidades. Estas funcionalidades están basadas en descripciones a muy alto nivel de lo que se espera que realice el producto, en el que se detallan de una forma resumida, las características, funciones, mejoras que deberían tener el producto. Esta lista, supone el comienzo de la recopilación de los requisitos del producto, y de los nuevos que irá adquiriendo el producto en su evolución. El Product Backlog debe ser gestionado por el negocio, que, con la ayuda del Scrum Master, le dará una idea del coste estimado, y contendrá todo lo que aporte un valor final al producto. Las principales características son:  Debe incluir todas las necesidades del producto, expresados mediante historias de usuario.  Para cada necesidad, se incluirá el valor que aporta al negocio y un coste estimado, de forma que puedan ser priorizadas basándose en el ROI 16 .  Se tendrán que indicar el número de sprints o iteraciones, y los despliegues acordados.  Se han de incluir los riesgos que puedan contemplarse, y cómo se van a mitigar. Antes de comenzar a desarrollar deben definirse los objetivos, y las necesidades del producto. Sin tener que entrar en mucho detalle, basta con que tenga el contenido suficiente para poder empezar a trabajar. 16 ROI: Retorno de Inversión Marco de las metodologías ágiles 40 40 La aplicación de este conjunto de características hará que:  El proyecto no se detendrá ante necesidades poco claras, permitiendo obtener los resultados sobre los que se está trabajando desde el principio, antes.  El resto de las necesidades irán surgiendo a lo largo del avance del desarrollo, no perdiendo tiempo en analizar dichas necesidades al comienzo.  Estas necesidades secundarias, es posible que no sean necesarias al estar ya cubiertas, porque hayan surgido nuevas más interesantes, o que se descarten por su coste. Una vez definidos los requisitos se tendrá que acordar cuándo se tiene que entender un objetivo como terminado o completado. Un producto o entrega, se dará por finalizado si:  Se puede generar un documento que contenga una demostración con todas las necesidades que se pedían al comienzo, cubiertas y operativas.  Contiene todo aquello que se está realizando sobre el producto y que así ha sido solicitado por el cliente. Adicionalmente a la determinación de una funcionalidad completada, se deberían establecer una serie de criterios o condiciones que definan cuándo, o en qué momento se dará por buena la prueba, o la aceptación de las funcionalidades que se solicitaban al comienzo de la iteración. Todos estos aspectos, harán que el Product Backlog vaya evolucionando con el proyecto, dando por completadas funcionalidades, surgiendo nuevas, descartando otras existentes, o re-priorizando las necesidades que queden por desarrollar. A pesar de no haber una norma específica a la hora de hacer un Product Backlog, se recomienda que contengan por lo menos, información relacionada con:  Identificador de la funcionalidad.  Descripción de la funcionalidad.  Orden de prioridad de la funcionalidad.  Estimación de coste/esfuerzo de llevar a cabo la funcionalidad. ID Prioridad Historia de Usuario Estimación 1 Muy alta Motor de Cálculo 250 2 Alta Criterios de Intervención de Cálculo 210 4 Baja Registro de errores 130 5 Muy baja Consulta de facturas 90 Tabla 2. Ejemplo de Product Backlog. 3.2.4.2 Historias de Usuario. Las historias de usuario son el conjunto de funcionalidades necesarias para el negocio, que necesita que sean implementadas en el desarrollo software. Lo lógico es que sean diseñadas de forman común entre usuarios y resto del equipo, de forma que irán variando a lo largo del desarrollo. Cada historia de usuario cumple una serie de características, también conocidas como “Las 3 C”:  Card: breve descripción a modo de recordatorio de la historia.  Conversation: Pequeño resumen que garantiza que todos han entendido lo que se necesita y lo que quiere llevar a cabo.  Confirmation: casos de prueba que describirán si la funcionalidad cubre lo que se necesita En cuanto al modelo, existen varios tipos, pero podría ser uno parecido al siguiente:  ID: Identificador de la historia de usuario.  Título: breve descripción de la historia.  Estimación: Medida del esfuerzo (criterio establecido al comenzar el proyecto) para implantar la necesidad.  Prioridad: Rango de prioridad respecto al resto de historias, siendo más prioritario cuanto mayor sea dicho valor. Otra aproximación a la priorización se realiza mediante algún método de priorización, como el método Moscow: o Must: Es necesario terminar el requisito para finalizar el proyecto. o Should: Es necesario completar la funcionalidad como sea, pero el éxito del proyecto no depende de ella. o Could: Se podría completar esta funcionalidad, si la implementación de esta no afecta a la consecución de los objetivos principales. o Would: Se podría llevar a cabo la funcionalidad si sobrase tiempo.  Dependencias: Una historia de usuario debería ser independiente, pero no siempre es así. 3.2.4.3 Sprint Backlog. Está compuesto por el conjunto de tareas que componen un sprint. Mediante este, se identifican y definen todas las tareas necesarias para completar el sprint. Mientras que en el Sprint Backlog aparecen las distintas funcionalidades que se necesitan, por otro lado, también aparecen todas las tareas necesarias para completar dichas funcionalidades, de forma que el Sprint Backlog es una parte del Product Backlog (como un subconjunto). También al estar las historias de usuario ya priorizadas, las tareas asociadas a cada historia, ya vienen priorizadas por la propia historia de usuario que fue ordenada durante el product backlog. Figura 19. Ejemplo de Historia de usuario. Fuente: devnettips.blogspot.com. Marco de las metodologías ágiles 42 42 Sin embargo, el hecho de que puedan existir tareas que no se hayan terminado en un anterior sprint, harán que, en el comienzo del siguiente, se acumulen dichas tareas. Todo sprint backlog debe ser aceptado por el equipo del proyecto (sobretodo por los programadores), quedando a criterio del equipo la posibilidad de modificarlo. En caso de necesitar añadir nuevas funcionalidades de forma urgente, deberán ser incluidas en el producto backlog, y tenidas en cuenta para el siguiente sprint. Un ejemplo de Sprint Backlog, podría ser el siguiente: Entrada Historia de Usuario Estimación Prioridad Aceptada (Sí/No) Observaciones 1 Poder visualizar tendencia de consumo 250 1 Sí 2 Poder consultar histórico facturas 210 2 Sí 3 Poder consultar histórico de contratos 150 3 Sí 4 Poder descargar facturas 130 4 Sí 5 Poder reclamar una factura 90 5 No 6 Disponer de un buzón de correo 50 6 No 7 Hacer Login 40 7 No 8 Pagar una factura 30 8 Sí 9 Mandar un mensaje 10 9 Sí 10 Mostar notificación al usuario 5 10 Sí Tabla 3. Ejemplo de Sprint Backlog. Las características son: o Es un listado de necesidades para el usuario ordenado por prioridad. o Podrían existir dependencias entre ellas, y en ese caso habría que reflejarlo. o Las tareas deben tener un esfuerzo estimado entre 4 a 16 horas. El formato posible para hacer estas listas es variado: o Hojas de Cálculo. o Pizarras. o Herramientas Colaborativas (Trello, Microsoft Teams, …) Estas tareas se gestionan mediante un Scrum Taskboard, donde cada objetivo tiene asociadas las tareas necesarias para completarlo mediante post-its que van cambiando de columna en función del su estado de avance. Dicho tablero cumple las siguientes características: o Contiente las tareas a llevar cabo. o Incluye a la persona que lleva la tarea, estado de esta, y plazo para finalizarla. o Permite la consulta diaria por sus miembros. o Permite ver cada día lo que le resta a cada tarea. 3.2.4.4 Incremento. Un incremento se define como la suma de todos los ítems completados en el Sprint backlog. Si hubiera ítems incompletos, deben ser incluidos en el Product backlog para que sean realizados en el próximo sprint. Un ítem se dará por finalizado si este es funcional. El sumatorio de todos ellos debería de dar como resultado el producto final, preparado para ser puesto en producción o desplegado, tras la Revisión del Sprint con algunas tareas, aunque a veces se necesiten acciones adicionales ( pruebas o documentos) 3.2.5 El proceso de Scrum Scrum establece un marco para la gestión y desarrollo (entendiendo desarrollo como toma de requisitos, la fase de diseño funcional, y codificación posterior) de proyectos, en el que se definen una serie de iteraciones de una duración máxima de 4 semanas, conocidas como sprint. Cada sprint, estaría compuesto por 3 fases: 1. Pre-sprint: planificación de lo que se va a llevar a cabo en el sprint. 2. Sprint: periodo de trabajo. 3. Post-sprint: revisión y retrospectiva del sprint. El ciclo de Scrum se podría resumir en: 3.2.5.1 Planificación Pre-Sprint. También llamado sprint 0, es la primera fase en la que se escuchan las necesidades del usuario, con el objetivo de que las posteriores decisiones que se realicen en las siguientes etapas, agreguen siempre valor. Para este sprint, el product owner debería tener ya elaborado y priorizado un Product Backlog. En dicha reunión, en la que se encuentran el product owner, el equipo de programadores, y el scrum master, el dueño del producto define las funcionalidades que se deberían incluir en el sprint y se definen las tareas necesarias para llevar a cabo dichas funcionalidades. Generalmente, en esta etapa se producen errores en la estimación, ya que se hacen por encima, por lo que es aconsejable no parar mucho en esto, e invertir dicho tiempo en otros aspectos. Además, el equipo determina la lista de tareas y estima cuánto puede cumplirse para ese sprint. Las tareas que se realizan en este sprint 0 son:  Definir el objetivo: se indican los objetivos del proyecto a alto nivel de forma que los componentes del squad, puedan comprender las necesidades. El objetivo del sprint debe ser posible aunque haya tareas incompletas o abandonadas: “La razón del objetivo de un sprint es dar al equipo cierta flexibilidad respecto a la funcionalidad” tal como Ken Schwaber y Mike Beedle lo enuncian (Schwaber y Beedle 2001). El objetivo sirve para no perder el foco en las tareas que deben ser llevadas a cabo como principales. Además, el objetivo sirve para que el equipo se se encuentre animado y sean capaces de integrar cualquier circunstancia que pueda darse mientras dura el sprint. Figura 20. Ciclo de vida de un proyecto Scrum. Fuente: northware.mx Marco de las metodologías ágiles 44 44  Definir “terminado”: esto permitirá saber cuando se ha finalizado una tarea.  Definición del Backlog inicial: Esto permitirá que el sprint que se comience contenga una cantidad suficiente de tareas para llevar a cabo. Dicha lista, como ya comentamos anteriormente, debe ser priorizada por el product owner, de forma que conforme se vayan realizando sprints, se vayan añadiendo nuevas funcionalidades al producto de forma que se vayan cumpliendo las expectativas del usuario.  Definición de los entregables: Aunque anteriormente se haya comentado que la entrega de documentación pasa a un segundo plano con Scrum, sí que es cierto, que sería bueno para el proyecto, establecer cuándo se van a realizar estos documentos para añadir valor al producto, y poder tener un mayor feedback. Este plan de entregas puede variar por diversos motivos como:  Cambios en las necesidades, o nuevas necesidades para los usuarios.  Aparición de nuevas funcionalidades que añaden valor.  Cambios en el entregable. Este plan lo debe definir el usuario, que debe determinar las funcionalides y el coste asociado que asumirá. También, dicho entregable estará condicionado por el equipo de trabajo debido a:  El tiempo necesario para desarrollarlo.  La estimación de tiempo y coste.  Selección de tareas del Backlog del producto a asumir. Una vez planificado el sprint inicial, se realizará una reunión con todas las personas del equipo para:  Dimensionar el proyecto.  Revisar el product backlog.  Establecer el horario de trabajo, y las próximas reuniones. Tras esto, el equipo en su conjunto comenzará a trabajar hasta ajustar los recursos con la cantidad de trabajo planteada para el primer sprint, teniendo definido el Sprint Backlog. 3.2.5.2 Estimaciones del Sprint Backlog Para poder comenzar a planificar en la primera reunión de planificación, el equipo de programadores debe saber cuáles son sus capacidades de trabajo, y a qué ritmo puede ir realizando las distintas tareas. Para ello, primeramente, se han de decidir qué historias se incluirán en la pila de historias de usuario del primer sprint. La forma para decidir qué historias incluir, puede realizarse de dos formas: 1. Mediante tanteo. 2. Mediante estimaciones de velocidad de trabajo, basados en datos reales.  Mediante tanteo: En esta situación, los miembros analizan la cantidad historias de usuarios hasta alcanzar un consenso. Este método es útil en sprints cortos.  2.Mediante estimaciones de velocidad de trabajo: Este método se realiza en 2 fases: A. Elegir una velocidad estimada. B. Determinar la cantidad de historias realizables sin alcanzar la velocidad estimada. La forma óptima de estimar sería revisando el historial del equipo basándonos en sprints anteriores que pudieran dar una idea de la velocidad del equipo. Una de las formas para realizar esta técnica, sería utilizando un equipo que tenga un mismo historial, de forma que los sprints que se ejecuten sean similares a los ya realizados anteriormente por los miembros en equipos anteriores, y que en este compartan dimensionamiento y condiciones. Otra forma de realizar la técnica sería mediante el cálculo de recursos: 1º. Cálculo del número de días - hombre disponibles (aunque el dato sea poco significativo, porque influyen factores externos que pudieran alterar la dedicación). Nombre Días Usuario 1 15 Usuario 2 8 Usuario 3 9 Total 32 días-hombre 2º. La velocidad estimada se calcula como: 𝑽𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝑬𝒔𝒕𝒊𝒎𝒂𝒅𝒂 = (𝐷𝑖𝑎𝑠 − ℎ𝑜𝑚𝑏𝑟𝑒 𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒𝑠)∗ (𝑓𝑎𝑐𝑡𝑜𝑟 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖ó𝑛) 3º. El factor de dedicación se estima en función del estado del equipo, siendo razonable, estimarlo en función del estado de los últimos sprints. 𝑭𝒂𝒄𝒕𝒐𝒓 𝒅𝒆𝒅𝒊𝒄𝒂𝒄𝒊ó𝒏 = (𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝑅𝑒𝑎𝑙) (𝐷𝑖𝑎𝑠 − ℎ𝑜𝑚𝑏𝑟𝑒 𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒𝑠) La velocidad real sería el sumatorio de las estimaciones que se llevaron a cabo para el último sprint. Ejemplo: Supongamos que un equipo realizó 30 historias de usuario, con 4 personas, sumando 40 dias-hombre, para calcular la velocidad para el próximo sprint, con un total de 50 días-hombre, el resultado sería: 𝑭𝒂𝒄𝒕𝒐𝒓 𝒅𝒆𝒅𝒊𝒄𝒂𝒄𝒊ó𝒏 = 30 ℎ𝑖𝑠𝑡𝑜𝑟𝑖𝑎𝑠 40 𝑑í𝑎𝑠 − ℎ𝑜𝑚𝑏𝑟𝑒 ∗100 =75 % 𝑽𝒆𝒍𝒐𝒄𝒊𝒅𝒂𝒅 𝒆𝒔𝒕𝒊𝒎𝒂𝒅𝒂 = 50 𝑑í𝑎𝑠 − ℎ𝑜𝑚𝑏𝑟𝑒 ∗ 0,75 =37,5 𝑝𝑢𝑛𝑡𝑜𝑠 Para equipos nuevos, puede tratar de comporarse con equipos similares, o usar un valor inicial para el factor de dedicación. Se suele recomendar el 70%. Aplicación al caso práctico 52 52 4 APLICACIÓN AL CASO PRÁCTICO En esta sección veremos la aplicación de la metodología Agile, con el marco de SCRUM como referencia, aplicado a dos proyectos en la empresa. 4.1 Planificación de las etapas Para entender la introducción del desarrollo agile, dentro del mundo empresarial, es necesario mostrar las distintas etapas que se van a llevar a cabo dentro de este proyecto denominado DIG&IN y debemos de conocer la planificación de estas, así como los objetivos comunes de todas las etapas: Esta planificación, divide el proceso en 4 fases: Design, Sponsor & Prioritization, Inception y Execution.  Design: En esta fase, de una duración de unas 4 semanas, compuesta por los sprints 0, 1, 2 y 3, el objetivo es componer un equipo de trabajo (diferente al de desarrollo), revisar un proceso de negocio en concreto, identificar los pain points 19 , estableces distintos kpis medibles, plantear posibles mejoras (sin ninguna limitación), evaluar los impactos y necesidades de las distintas iniciativas, analizar los costes y beneficios, preparar un Business Model Canvas sobre cada iniciativa, y definir la mejor metodología para el desarrollo de dichas iniciativas.  Sponsor & Priorization: En esta segunda fase, de una duración de aproximadamente 2 semanas, el objetivo, es presentar las principales iniciativas detectadas como potenciales a un Sponsor 20 que hará las labores de aprobación presupuestaria de la/s iniciativa/s aprobada/s así como su priorización en función de la importancia y la urgencia.  Inception: En esta tercera fase, se definen las historias de usuario, las tareas, se comienza a elaborar y definir el producto Backlog, y se priorizan dichas tareas. 19 Pain Points: Puntos de dolor o ineficiencias detectadas dentro de un proceso. 20 Sponsor: Dentro de la empresa, esta figura está represantada por la dirección ejecutiva global. Figura 28. Planificación de las etapas de la aplicación de la Metodología Scrum Figura 29. Planificación de los distintos Sprints.  Execution: En esta cuarta fase, se ponen en marcha los desarrollos, trabajando por sprints, y realizando entregables al final de cada sprint. Para entender el desarrollo de las etapas, sus actividades, los recursos implicados, y los outputs que se esperan como salida de cada etapa se plantean los siguientes esquemas de planificación por etapas: Figura 30. Planificación de los distintos Sprints y ceremonias. Aplicación al caso práctico 54 54 4.2 Dedicación y roles de las personas designadas Para el desarrollo de las distintas sesiones de esta fase se planteó una organización de personas compuesta por: Como se puede ver en el cuadro anterior, existen nuevos roles, además de los ya comentados en la explicación de SCRUM, que se pasan a detallar a continuación:  Global Process Owner: Esta persona representa a la dirección global de los procesos, y cómo se relacionan con otros.  Tribe Leader: Representa la figura de negocio coordinadora de todas las rooms que se estén llevando a cabo. Coordina a los coordinadores de negocio.  Product Owner: Figura que representa la propiedad del proceso en cuestión, siendo una persona de máxima responsabilidad, y con capacidad de decisión.  Process Mentor: Esta figura representa a una persona dueña del proceso que se va a analizar, pero en otro país, donde se ya se ha realizado un análisis similar del proceso.  Process Experts: Equipo de 1 a n personas que forman parte activa del proceso, juntamente con el Product Owner, siendo este último el que las coordina.  Disruptor: Figura totalmente ajena al proceso, que proviene de otra área distinta, con el objetivo de dar un enfoque y una vision ajena al proceso.  Agile Coach and Scrum Master: Figuras que posibilitan el desarrollo de los sprints, explicando como se van a desarrollar las actividades, y resolviendo dudas que puedan surgir sobre la aplicación de las metodologías. Figura 31. Participantes de las agiles room.  Service Designer: Figura que representa el soporte de los sistemas (TIC 21 ) a nivel funcional.  Enterprise Architect: Figura que representa el soporte técnico de los sistemas.  Solution Architect: Figura encargada de analizar las viabilidades aportadas como soluciones a los procesos. Si bien es cierto que aquí se han definido todos estos roles, no será necesaria la presencia de todos, durante todo el proceso, variando su presencia, en función de la etapa en la que se esté, o solicitada su presencia, en el momento en que se estime oportuno. De esta forma se planteó el siguiente cuadro de asistencia: Viendo el cuadro anterior se observa que aparecen otros roles, a las que también se suman su presencia en la sala, como son las siguientes:  Methodology & Planning: Área de Metodología y Planificación.  Planning & Control: Área encargada de la planificación económica, y control económico.  Network Technology: Área encargada de las tecnologías de redes e infraestructuras.  HR: Área de Recursos Humanos  Regulation: Área de Regulación.  Legal: Área de Legal (cualquier aspecto legal).  Safety: Área de Seguridad y prevención.  Procurement: Área de Compras. Todas estas áreas, además de integrarse en su fase correspondiente (si aplica), están a disposición del product owner en todo momento, en caso de necesitar ayuda para resolver alguna cuestión, o necesidad de cualquier información. 21 TIC: Tecnologias de la Información y de la Comunicación Figura 32. Dedicación para cada etapa en función de los roles. Aplicación al caso práctico 56 56 4.3 Desarrollo de las distintas etapas. 4.3.1 Training, Design & Inception Set-up. En esta primera etapa, de una duración aproximada de 3 días, se formaron los grupos de trabajo, se habilitaron las salas preparadas para un entorno más dinámico, y se dio una formación inicial a todos los asistentes para conocer las distintas actividades que se fueran a desarrollar, mediante presentaciones y dinámicas, para reforzar los objetivos que buscan el Desarrollo ágil. Además, se estableció un consenso entre todos los participantes de la sala en cuanto a la organización de las reuniones (martes, miércoles y jueves en horario de 9:00 a 15:00). Por útimo, en esta primera etapa se presentó el análisis de la baseline 22 sobre el proceso, y los puntos de dolor identificados de forma inicial, como una tarea previa de los product owners con sus respectivos responsables. 4.3.1.1 Sala de Liquidaciones. El proceso de Liquidaciones está conformado por un equipo de unas 4 personas de negocio, un par de personas que dan soporte desde sistemas, y 4 personas más de Software Factory. La principal actividad de este área consiste en la elaboración de la declaración mensual y/o anual a la Comisión Nacional de Mercados y Competencia (CNMC) de la actividad regulada (consumos de energía y facturación liquidables), asegurando forma y plazo, incluyéndose en dicho proceso, las actividades de autodeclaración de Cuotas/Tasas y Liquidación. 22 Baseline: Línea base o directrices sobre las que enmarcaran los procesos Figura 33. Diapositiva de Formación del proceso Agile, a través de la consultora Siag. Figura 35. Lista de carencias detectadas en el proceso. Figura 34. Baseline del proceso de Liquidaciones Entre las tareas de dicha área, destacan: • Realización de las declaraciones mensuales según modalidad establecida por regulación (Informes SINCRO) a la Comisión Nacional de Mercados y Competencia (CNMC). • Declaración y liquidación de las cuotas y tasas a la CNMC, y tasas a la Agencia Estatal Administración Tributaria (AEAT). • Liquidación de costes de transporte, distribución y comercialización a tarifa, los costes permanentes del sistema, los costes de diversificación y seguridad de abastecimiento. • Gestión y atención de inspecciones de la CNMC. • Actualización de los sistemas y tarifas de acuerdo con la reglamentación vigentes. 4.3.1.1.1 Baseline de Liquidaciones. El modelo presentado como Baseline del proceso es el siguiente: El objetivo de presentar la baseline del proceso, es que todas las personas presentes en la sala puedan entender el proceso en su totalidad, de cara a entender los puntos de mejora encontrados, y/o plantear el mayor número de soluciones posibles. 4.3.1.1.2 Paint Points sobre la baseline. Sobre la Baseline, se detectaron las siguientes carencias, en un análisis previo a alto nivel: Aplicación al caso práctico 58 58 Viendo el análisis previo del product owner, en la elaboración de este as is, se puede observar que existe la necesidad de una gestión de los datos de forma automática, e informática, soportada por el área de sistemas informáticos de la compañía, ya que el soporte actual para la presentación de estos informes, está basado en herramientas ofimáticas, que no dejando de ser recursos de la empresa a nivel corporativo, no deja de ser una herramienta de trabajo propia ( BBDD Access propia) sin capacidad de procesamiento, ni soporte.Además, la gran variedad de fuentes de información de datos de la que se nutre esta base de datos, llevan a una falta de integridad y calidad, puesto que no deja de ser un proceso manual de carga, de interpretación y de generación de los informes finales a presentar a la CNMC. 4.3.1.1.3 Estado digital del proceso de Liquidaciones: El estado digital del proceso de liquidaciones, en su as is fue: El hecho de no utilizar herramientas de procesamiento masivo de datos (tipo Big Data), ni su tratamiento automático, hacen que el estado digital de este proceso no sea muy alto, siendo necesaria su actualización a un proceso automático, debido a la alta manualidad en la generación de los datos y su sensibilidad (60. MM € de sanción por errores graves en la presentación de los formularios). 4.3.1.2 Sala de Facturación y Cobros. El proceso de facturación y cobros, compuesto por 8 personas de negocio, 2 personas de sistemas, 6 personas de software factory, y un backoffice de 300 personas, realiza como principales actividades de generación, envío y conservación de la facturación tanto en el caso de ATR 23 (incluido el alquiler de contadores), como de otros servicios: nuevos suministros, conexiones, contratación, peajes de generación, enganches directos, fraudes, y las actividades de cobro y gestión de la deuda, tanto de clientes ATR directos como de comercializadoras. Este equipo está formado por unas 10 personas del área de negocio, que, a su vez, tienen contratada en una empresa de la matriz de Endesa (Cefaco), las principales actividades de la operativa diaria (este equipo lo pueden conformar más de 200 personas). Entre las tareas de dicha área, destacan: • Generación de facturas y refacturaciones (De energía, de no energía, altas, bajas, modificaciones, derechos, peajes de generación, fraudes, indemnización, trabajos en campo, calidad invidual del suministro, suplementos territoriales, etc…). 23 ATR: Acceso de Terceros a la Red. Figura 36. Estado Digital del proceso de Liquidaciones • Edición de facturas. • Envío y publicación de dichas facturas. • Gestión del cobro (Cobro/Dudoso Cobro/Impagos). • Análisis y evaluación de toma de acciones por vía judicial. • Reporting y control del proceso. • Atencion personalizada de comercializadoras. • Conciliación Contable • Soporte Fiscal. • Atención e información de facturación para áreas internas y organismos externos. • Seguimiento y atención a las modificaciones impulsadas por el regulador (CNMC). 4.3.1.3 Baseline de Facturación y Cobros. El modelo presentado como Baseline del proceso es: Figura 38. Baseline del Proceso de Facturación Figura 37. Baseline del proceso de cobros. Aplicación al caso práctico 60 60 4.3.1.3.1 Paint Points sobre la baseline. Sobre la Baseline, se detectaron las siguientes carencias: Viendo la lista de carencias elaborada con la baseline, vemos que se necesita una automatización en algunos pasos de los procesos (en la que los usuarios manifiestan las carencias del uso de un sistema a medida, creado con una tecnología de los años 2000 con una arquitectura MainFrame) así como utilizar nuevas tecnologías existentes en el mercado, como las vías de pago tipo pdp 24 , o automatizaciones de procesos actuales, que permitan un tracking completo y automático de los procesos de facturación y del cobro. 4.3.1.3.2 Estado digital del proceso de Liquidaciones: El estado digital del proceso de liquidaciones, en su as is es: 24 Pdp: Pasarela de Pago. Figura 39. Lista de carencias detectadas en el proceso de Fact. y Cobros. Figura 40. Estado Digital del proceso de Facturación y Cobros. Si bien este proceso es bastante automático, está basado en un sistema infórmatico que, como decíamos antes, se implantó en el año 2000 y que actualmente se encuentra en un proceso de sustitución mediante un proyecto que pretende sustituirlo por un sistema SAP, apoyado en la nube de S4 HANA que ofrece una mejora sustancial en el rendimiento de muchos procesos. 4.3.2 Design - Thinking En esta Segundo sprint, de una duración de una semana, los objetivos fueron analizar los pain-points, así como encontrar nuevos, para crear nuevas ideas innovadoras a través de brainstorming, buscar soluciones tecnológicas disponibles, y preparar el portfolio backlog con el listado de nuevas iniciativas. Para ello, se siguieron utilizando las room agile habilitadas, así como las herramientas de SCRUM, como las reuniones del Daily meeting, o las retrospective meeting diarias. Además, el uso de un Scrum Taskboard permitió ver las tareas pendientes en todo momento: Figura 41. Explicación del proceso de Facturación en un tablero con post-its Figura 43. Scrum Taskboard Figura 42. Equipo de trabajo en Room Agile. Aplicación al caso práctico 68 68 Con esta fase, se consigue una mayor definición de los procesos, al plantear cuestiones sobre los mismos, llevando a cabo de forma necesaria, una reflexión sobre los principales problemas, y las principales soluciones necesarias y prioritarias para un buen funcionamiento de los sistemas, y de la explotación de la gestión diaria (cabe mencionar, que este sistema en concreto (el SCE-MR 27 ) es utilizado por varios cientos de usuarios, y que una mejora en el funcionamiento del mismo, es una mejora en el cash Flow operativo de la empresa, y una reducción de costes de capex, asociada al ahorro en personal externo subcontratado para operar el sistema) 27 SCE-MR : Sistema Comercial de Endesa- Mercado Regulado. Figura 56. Tabla con valores de los kpi´s redefinida. Figura 57. Business Model Canvas de la Iniciativa Robot de Prefacturas. 4.3.4 Fase de Tuning En esta cuarta fase, también de una duración de una semana, el objetivo consistió en elaborar el entregable final de la fase de Diseño, incluyendo un porfolio backlog final, un análisis de beneficio – costes, y tiempos para cada cada iniciativa, el business model canvas para todas las iniciativas, y el análisis del futuro estado digital con la inclusión de todas las iniciativas implementadas. 4.3.4.1 Sala de Liquidaciones. En esta última entrega se definieron los pain-points definitivos, el valor de los kpi´s asociados, el proceso to be final, el listado de iniciativas con su coste y plazo asociado para su implementación. Además de esto, se terminaron de elaborar todos los business model canvas, así como el cálculo de los ahorros (FTE 28 ) y retornos de las posibles inversiones. 28 FTE: Equivalente a tiempo completo (full-time equivalent, en inglés). Es una forma de medir la cantidad de empleados a tiempo completo que se necesitarían para llevar a cabo el trabajo realizado en una empresa. Se obtiene dividiendo las horas de trabajo de varios trabajadores o empleados a tiempo parcial por la cantidad de horas de un período laboral Figura 58. Business Model Canvas de la Iniciativa Robot de Prefacturas. Figura 59. Resumen de la iniciativa que se presentó. Aplicación al caso práctico 70 70 Figura 61. Análisis del impacto de la herramienta en el estado digital del proceso. Figura 62. Resumen de la iniciativa con costes, ahorros y estrategia de desarrollo. Figura 60. Resumen de la iniciativa con costes, ahorros y estrategia de desarrollo. Estos ahorros, se basaron en varios aspectos:  Ahorro en coste de mantenimiento de los sistemas actuales.  Ahorro en coste de explotación de los sistemas actuales.  Ahorro en personal propio, como resultado de la automatización de los procesos.  Ahorro en personal externo, como resultado de las mejoras implementadas.  Se presupone un horizonte de amortización de 5 años. 4.3.4.2 Sala de Facturación y Cobros. De forma análoga a la otra sala, se terminaron de detallar los dossieres finales a presentar, terminando de definir los pain-points con sus kpi´s correspondientes, el proceso to be con las mejoras identificadas, la preestimación de tiempo, coste y beneficios para las distintas iniciativas, los business model canvas de cada una de las iniciativas, y la mejor metodología para desarrollar las distintas iniciativas. Figura 63. Excel económico para calcular costes, ahorro y tasas de amortización para las iniciativas. Figura 64. Resumen de iniciativas del proceso de Facturación y Cobros. Aplicación al caso práctico 72 72 Figura 67. Proceso AS IS y TO BE, con la introducción de los nuevos sistemas. Figura 65. Mejoras en el proceso con la implantación de las iniciativas. Figura 66. Análisis Coste-Beneficio, plazo, metodología, y estado digital de las iniactivas. 4.3.5 Fase de Priorization + Retrospective (Ceremony) En esta siguiente fase, celebrada mediante un evento en Barcelona, el objetivo, fue el de intercambiar ideas con personas de otros procesos de negocios, de cara a encontrar nuevas iniciativas, y hacer una reflexión conjunta de todo el proceso llevado a cabo. Durante el evento, pudimos aportar nuestro punto de vista en un proceso de negocio totalmente diferente a los ya trabajados, y junto a personas que trabajaban en áreas totalmente diferentes. Figura 68. Resumen de la agenda del evento. Figura 69. Sala del evento en Barcelona. Aplicación al caso práctico 74 74 Como resultado del encuentro pudimos compartir conclusiones, llegando entre todos los asistentes a encontrar conclusiones comunes tanto en beneficios aportados por el uso de la metología, como en carencias presentes a la hora de llevarlas a cabo. Todas estas conclusiones, fueron recogidas en unos cuadros de trabajo que fueron enviados por correo, y comentados a la dirección global del proyecto DIG&IN, para que sean tenidos en cuenta en el desarrollo de nuevas iniciativas, o análisis de procesos de negocio que no hayan sido revisados hasta ahora. Figura 70. Distintos participantes revisan un proceso de negocio. Figura 71. Conclusiones extraídas de la retrospective. De esta forma, podemos enumerar algunos de las conclusiones extraídas por todos los miembros:  Ventajas: o Mejora del trabajo en equipo. o Mayor conocimiento de procesos de negocio. o Nuevos contactos. o Mayor motivación. o Autoorganización.  Desventajas: o Dedicación exclusiva. o Carga de trabajo. o Falta de formación. o Necesidad de mayor planificación. o En ocasiones, alto stress. Como resultado de la presentación, de todas las iniciativas en los dossieres de todos los procesos de negocio, desde la dirección general, se priorizaron las iniciativas y se liberaron las partidas presupuestarias correspondientes a las distintas iniciativas que tuvieron el visto bueno. En lo referente a las dos salas que aquí se tratan (Liquidaciones, y Facturación y Cobros), salieron adelante las iniciativas de:  Sala de liquidaciones: DAR System, por un valor de 700.000 € y un plazo de ejecución de 18 meses, con una modalidad de implementación waterfall  Sala de Facturación y cobros: Smart+, por un valor de 1.280.000 € y un plazo de ejecución de 12 meses, con una modalidad de implementación híbrida waterfall/agile. 4.3.6 Fase de Inception. Para esta fase de inception, centrada ya en el desarrollo de los proyectos asociados, seguiremos con el ejemplo del modelo de facturación y cobros, ya que el de liquidaciones seguirá una metodología tradicional en su desarrollo, que no aporta nada adicional sobre este trabajo. En esta fase, de una duración aproximada de 2 a 3 semanas por cada sprint (como anteriormente comentábamos en el cuadro esquemático) pero iterativa hasta finalizar todas las historias de usuario, se definirán:  Las diferentes historias de usuario 29 de acuerdo con el product backlog priorizado por el product owner.  Las tareas asociadas a cada historia, así como posibles impactos.  Las pruebas que validaran las historias de usuario.  La velocidad o capacidad del equipo de trabajo sobre cada sprint en puntos de esfuerzo (valor que se irá ajustando en cada sprint).  Número de sprints necesarios para completer todas las historias de usuario.  Fecha de revisión del sprint realizado. Para llevar a cabo todas estas tareas, se utilizarán las herramientas comentadas como el Sprint Planning Poker, el diagrama de Burndown, o el daily meeting,entre otras. 29 Cada historia de usuario (user story) hace refencia a una parte/funcionalidad potencialmente entregable dentro del producto global Aplicación al caso práctico 76 76 Figura 72. Equipo de trabajo trabajando sobre una historia de usuario. Figura 73. Equipo analizando el producto backlog. 4.3.1 Fase de Execution. En esta última etapa de desarrollo, de una duración aproximada de 2 a 3 semanas por ejecución, el trabajo a desarrollar estará centrado en desarrollar las distintas tareas asociadas a cada historia de usuario sobre la que se esté trabajando, y su presentación al product owner al finalizar cada ciclo. De esta forma, en cada iteración, el usuario podrá ser partícipe directo del proyecto, pudiendo comprobar cómo el equipo en su conjunto va generando cada parte del proyecto, aportando nuevas funcionalidades en cada entrega, y, en definitiva, generando valor sobre el producto final. Todo esto, unido a la capacidad por parte del product owner, de modificar en todo momento, sus propias necesidades, y/o el orden de las nuevas funcionalidades a aportar, no hace sino entregar más valor añadido sobre el producto. En el momento de redacción y entrega de este trabajo, el desarrollo de los proyectos con metodología ágil aún no había llegado a la fase de liberación de versiones y puesta en producción, por lo que no se pueden plasmar en este documento, pero con el desarrollo expuesto a lo largo del documento quedaría cubierta la forma de desarrollar cada hito, y su explicación. Una similitud para explicar esta entrega de valor por hitos, podría presentarse por ejemplo, a la hora de hablar de cualquier aplicación para el móvil: en dichos entornos, se ha pasado en los últimos años, de una versión definitiva sin cambios en una app, a una aplicación, que cada 2-3 semanas, genera una nueva actualización que los usuarios descargan y utilizan, y en la que se le entrega un nuevo valor añadido al producto como mejora de la anterior versión, no existiendo nunca una versión final, porque hace tiempo que dejó de existir. Figura 74. Otro equipo Agile en fase de análisis de una historia de usuario.