SCRUM Concepto

De acuerdo con La Guía de Scrum 2017 de Ken Schwaber y Jeff Sutherland “Scrum es un marco de trabajo para desarrollar, entregar y mantener productos complejos. Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el trabajo en productos complejos desde principios de los años 90. Scrum no es un proceso, una técnica o método definitivo. En lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas.” (p. 3).

También consideran SCRUM como el paradigma para el desarrollo ágil, definiendo la forma de abordar un proceso de desarrollo de software de forma ágil y liviana, a través de la descripción de un conjunto de roles, componentes y organización de la actividad diaria. La base fundamental de este marco consiste en la división del trabajo completo (Product Backlog) en distintos apartados o bloques que pueden ser abordados en periodos cortos de tiempo (1-4 semanas) que se denominan Sprints.

Esta organización del proceso de creación de software permite potenciar los siguientes aspectos:

● Ágil: La división del trabajo en pequeñas unidades funcionales (Sprints) permite mantener una política de entregas frecuentes de software que ofrecen una visión clara del estado del proceso y permite la introducción de modificaciones.

● Simple: Se centra especialmente en facilitar el desarrollo rápido, por lo que su complejidad (por ejemplo desde el punto de vista de la documentación a generar o de la organización de equipos) se ha tratado de reducir al máximo.

● Flexible: Todo el desarrollo se contempla como un ciclo de iteraciones continuas de desarrollo, lo que facilita la introducción de modificaciones “sobre la marcha”, mejorando continuamente el proceso.

● Colaborativa: El planteamiento, desde el punto de vista de la organización del equipo, resulta bastante horizontal (en contraposición a una organización jerárquica férrea),

otorgando a los miembros del equipo de desarrollo una elevado grado de autonomía y auto-organización de su trabajo.

Equipos Scrum

Según La Guía Scrum (2016) Scrum prescribe tres roles: El Product Owner, el Scrum Master y el Equipo de desarrollo. Un equipo Scrum está compuesto idealmente de 6 a 10 miembros. Cada uno de estos roles en scrum tiene sus responsabilidades y tiene que rendir cuentas de distinta manera, entre ellos y para el resto de la organización. La suma de todos los roles de Scrum es el Equipo Scrum.

Figura 10: Roles de Scrum

Fuente: Essential Scrum Guide

Product Owner: La labor del Product Owner es optimizar el valor del producto dentro de los roles Scrum. Gestiona el todo el flujo de valor del producto, a través del Product Backlog, así como todo lo relacionado con informes, presupuestos y relación con las partes interesadas en el producto (Stakeholders). En Scrum existe solamente un Product Owner por cada producto, así como un solo Product Backlog.

Scrum Master: Se encarga de gestionar y asegurar el proceso Scrum, que este se lleve a cabo correctamente y de facilitar la ejecución del proceso y sus mecánicas, siempre atendiendo a los tres pilares del control empírico de procesos. Además, se encarga de eliminar impedimentos que puedan afectar a la entrega de producto. También se encarga de

hacer coaching al resto del equipo Scrum cuando lo necesitan, además de facilitar reuniones y eventos si es necesario. El Scrum Master puede ser compartido entre varios equipos, aunque su disponibilidad afectara al resultado final del proceso Scrum.

Según La Guía Scrum (2016) El Scrum Master tiene dos funciones dentro del marco de trabajo Scrum:

● Gestionar el proceso Scrum: El Scrum Master es el encargado de mantener Scrum al día, de proporcionar coaching, mentoring y formación a la organización en caso se necesite y de velar porque Scrum favorezca la entrega de valor en lugar de ser una herramienta de microgestión.

● Ayudar a limpiar impedimentos: Esta función del Scrum Master indica la necesidad de ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo en la organización y que afectan tanto a la integridad de Scrum. Hay que remarcar que estos impedimentos no son del equipo, sino de la organización.

Equipo de Desarrollo: El Equipo de desarrollo está formado por 3 a 9 profesionales que se encargan de desarrollar el producto, se auto organizan y deciden cual es la mejor manera de conseguir entregar un incremento de software al final del ciclo de desarrollo. En Scrum no importa el número de individuos sino el rol, independientemente de cuantos miembros tenga el equipo de desarrollo y cuales sean sus roles internos. Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tiene que rendir cuentas por ello; se tiene que evitar intervenir en sus dinámicas.

Roles del Marco de Trabajo Scrum . Según La Guía Scrum (2016) los roles son los siguientes:

 Product Owner: Es la persona responsable de transmitir al equipo de desarrollo la visión del producto que se desea crear, aportando la perspectiva de negocio. Representa al resto de interesados (Stakeholders, clientes, directivos etc) en el desarrollo del producto. Sobre el Product Owner recae la responsabilidad de definir el conjunto de requerimientos (Product Backlog), de priorizarlos, y de finalmente

 Stakeholders: Conjunto de personas que no forman parte directa del proceso de desarrollo pero que deben de ser tomados en cuenta, por ser personas interesadas en el mismo, tales como directores, gerentes, comerciales etc. El Product Owner será el encargado de recoger sus opiniones y sugerencias y decidir si las aplica a la definición del proyecto (Product Backlog), así como decidir si invita a alguna de estas personas al proceso de revisión de entregables.

 Usuarios: Al igual que los Stakeholders no forman parte del proceso de creación directamente (podrían estar en la fase de revisión de entregables si se considera necesario) Son los destinatarios finales de la aplicación a desarrollar, el público objetivo del mismo. Una vez que la aplicación esté completada serán los que accedan a ella con mayor frecuencia.

Según La Guía Scrum (2016) los componentes de SCRUM son :

● Definición del proyecto (Product Backlog): Consiste en un documento que recoge el conjunto de requerimientos que se asocian al proyecto. Es responsabilidad del Product Owner realizar esta definición y establecer las prioridades de cada requerimiento. Es un documento de alto nivel, que contiene descripciones genéricas (no detalladas), y que está sujeto a modificaciones a lo largo del desarrollo.

● Definición del Sprint : Un sprint debe entenderse como un subconjunto de requerimientos, extraídas del product backlog, para ser ejecutadas durante un periodo entre 1 y 4 semanas de trabajo. El sprint backlog sería el documento que describa las tareas que son necesarias realizar para abordar los dichos subconjuntos de requerimientos.

● Ejecución del Sprint: Sería el periodo de entre 1 y 4 semanas (periodo definido previamente sobre la base de las tareas recogidas en el sprint backlog) durante el cual el equipo de trabajo abordaría las tareas de desarrollo correspondientes. Una vez iniciada la ejecución de un Sprint definido, este no podrá ser modificado, y en caso de ser necesario introducir cambios estos se harán una vez concluido el periodo a través de la definición de otro Sprint Backlog.

● Entrega: Una vez concluida la ejecución del Sprint, se dispondrá de una porción de la aplicación potencialmente definitiva.

● Evolución del proyecto (Burn down): Es un documento que refleja el estado del proyecto, indicando el volumen de requerimientos que en ese momento se encuentran pendientes de ser abordados (en el Product Backlog), los requerimientos que en ese momento se están desarrollando (Sprint Backlog) y los requerimientos cuyo desarrollo ya se ha completado en su totalidad.

Según La Guía Scrum (2016) los beneficios de usar el marco de trabajo SCRUM:

● Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.

● Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. El marco está diseñado para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

● Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.

● Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

● Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.

● Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.

● Predicciones de tiempos: Para conocer la velocidad media del equipo por Sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.

● Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

BIGDATA

Según Adell & Guersenzvaig (2013). “El termino Big Data es una expresión usada para hacer referencia a grandes conjuntos de datos digitales que requieren de sistemas informáticos para su captura, almacenamiento, búsqueda, manipulación y visualización”. Este crecimiento está asociado al aumento en la capacidad de los equipos de cómputo, la instalación de sensores de diferente índole y las interacciones de los usuarios con sistemas de información e incluso con la web y las redes sociales.

La expresión big data también se emplea con relación a la disciplina que dentro del sector TIC, se ocupa de las actividades de tratamiento de estos datos masivos. Bien es cierto que antes ya había ingentes cantidades de datos o que ya se empleara la “minería” de datos sobre los mismos, sin embargo, con la nueva expresión se quiere transmitir la novedad y oportunidad del geométrico crecimiento de los datos y sobre todo de las posibilidades de tratarlos, a modo de nuevo impulso en la materia. Elliott, Timo. (2013). 7 Definiciones de los grandes datos que debe saber sobre Big Data. Business Analytics.

Según George et al (2014), Big Data se puede ver como un contenedor de diferentes tipos de datos, y los agrupan en cinco fuentes principales, las cuales se esquematizan en la figura 11.

Figura 11: Big Data

Fuente: Principales fuentes de datos para Big Data (George et al., 2014)

Dimensión de Big Data

Según Talburt & Zhou (2015), Cuando se habla de Big Data, el término se suele asociar al tratamiento de grandes volúmenes de datos, sin embargo, Biga Data es un enfoque que abarca otras dimensiones. A continuación se nombran y describen brevemente. Para algunos autores, Big Data ha pasado a ser el enfoque de las 4Vs.

 Volumen: acumulación y constante aumento de datos

 Velocidad: necesaria para generar, obtener y procesar los datos  Variedad: de origen, fuente y formato de los datos

 Veracidad: fiabilidad de los datos