Prácticas Ágiles de la Metodología Scrum

Las prácticas ágiles constituyen un conjunto de actividades y procesos que definen el desarrollo de un proyecto de desarrollo de software utilizando metodologías ágiles. Este artículo tiene el objetivo de revisar varias de las prácticas ágiles aplicadas en la actualidad, especialmente en la metodología ágil Scrum. Para este fin, una serie de prácticas ágiles serán mencionadas exponiendo la información encontrada sobre ellas en distintos artículos científicos disponibles en la base de datos científica de ScienceDirect.  

¿Qué son las prácticas ágiles?

El Desarrollo de Software es una disciplina que busca crear productos de Software siguiendo lineamientos bien definidos en cuanto a costos, tiempos de entrega y calidad, con el objeto de satisfacer necesidades y requerimientos de clientes. Como una disciplina volátil, el Desarrollo de Software ha experimentado una evolución significativa en años recientes, y cambia tan velozmente como la tecnología, en tanto que esta permite desarrollar nuevas herramientas y procesos que modifican la manera en que se Desarrollan Productos de Software.

Existe un ciclo de retroalimentación positiva que potencia al Desarrollo de Software y también a la Tecnología. Uno de los más importantes hitos en el ámbito de la Ingeniería de Software es el del establecimiento de las Metodologías Ágiles como el estándar para la producción de software. Estas se cimientan en equipos de trabajo capaces de auto-organización y con elevadas capacidades de colaboración y comunicación. Cada metodología ágil se define por un conjunto de Prácticas Ágiles.

Las Prácticas Ágiles constituyen una serie de actividades que se centran en la promoción y aplicación de distintos valores y principios consignados en el conocido Manifiesto Ágil, que establece la importancia de conceptos como la colaboración entre clientes y desarrolladores, medidas de progreso basadas en software funcional, velocidad de producción y entrega de productos como medio de satisfacción al cliente, entre otros.

Las Prácticas Ágiles son la respuesta de la Industria del Software a problemas recurrentes en proyectos de producción de software. Los sobrecostes, las entregas tardías y las deficiencias en la calidad son problemáticas comunes para las que las Prácticas Ágiles han sido respuesta. Han sido aceptadas y aplicadas en la mayoría de grandes, medianas y pequeñas industrias del software, lo que debe servir como muestra de su efectividad para responder al mercado.

Historias de usuario

Las User Stories, o historias de usuario, son artefactos utilizados en las prácticas ágiles para levantar los requerimientos que contempla el proceso de desarrollo de un producto de software. Por requerimiento debe entenderse una funcionalidad con la que el producto debe cumplir para dar satisfacción a una necesidad del Cliente. Comúnmente, los stakeholders deben reunirse para llevar a cabo el proceso de identificación de historias de usuario, pero es normal que sean los usuarios potenciales del producto de software quienes deban ser entrenados en esta actividad. Es una práctica que ha sido ampliamente aceptada e implementada en años recientes (Krisper, Mendling & Trkman, 2019).

Las historias de usuario se consignan normalmente en documentos cuya estructura puede ser definida de manera distinta en cada proyecto de desarrollo. Como representación de funcionalidades para tratar necesidades del Cliente, las historias de Usuario a menudo tienen información como:

• Un código o denominación que permita identificar fácilmente la historia de usuario
• Una descripción de requerimiento, es decir, a qué usuario va dirigida la funcionalidad, por qué la requiere y cuál es esta en concreto. Por ejemplo: Como administrador, deseo registrar clientes para agregarlos a la base de datos de mi organización
• Detalles en los que se incluyen las entradas que se necesitan para cumplir con la funcionalidad, como podría serlo la identificación de un nuevo usuario que se quiere registrar
• Detalles en los que se especifica la salida de una funcionalidad, como podría serlo el resultado de algún análisis matemático que el cliente requiere.
• Restricciones de carácter no funcional. Son aspectos con los que se limita la funcionalidad o se describe su comportamiento y que no cambian su identidad. Un ejemplo es el tiempo de respuesta que debe exponer un programa o la tecnología con la que debe implementarse.
• Pruebas de aceptación: criterios que determinan cuándo una historia de usuario puede darse por terminada. Un proyecto de desarrollo de software está definido, entonces, por un conjunto de historias de usuario que responden cada una a una necesidad concreta de los clientes.

La Estimación

La estimación es una práctica de capital importancia en la gestión de proyectos de desarrollo de software. Es también una de las prácticas más difíciles de abordar y es un campo de investigación activo en el que los investigadores proponen métodos nuevos con frecuencia (Brar, Kaur & Sehra, 2017). En el contexto del desarrollo de software, la práctica de estimar se refiere a plantear el esfuerzo que se requiere para llevar a término la implementación de una funcionalidad. Regresando a las historias de usuario, una práctica común es la de asignar a cada una de ellas un valor que resulta de un proceso de estimación.

Un método común de estimación es el Planning Poker (Mahnic & Hovelja, 2012). Es un proceso ampliamente utilizado en el marco de las metodologías ágiles de desarrollo de software, especialmente Scrum. Consiste en la estimación colaborativa de una historia de usuario por parte de los miembros del Equipo de Desarrollo. Normalmente se utilizan “puntos” para describir la dificultad que puede suponer implementar la historia de usuario.

Un punto puede significar varias cosas, como días u horas de trabajo por parte de un desarrollador. Los miembros del Equipo dan cada uno una estimación al mismo tiempo de lo que consideran es una cantidad prudente de puntos para la historia de usuario. Después, se conviene la estimación final que se la otorga a la historia.

La estimación es un proceso desafiante cuya complejidad aumenta mucho entre más envergadura tenga un proyecto. Su importancia reside en que, hecha de manera incorrecta o poco precisa, la estimación puede derivar en sobrecostos y demoras en los proyectos, pues al dimensionar mal las actividades a realizar se puede caer en fechas de entrega, tarifas y horarios poco realistas que presentan claramente un riesgo de negocios.

Algunos factores que la literatura sugiere son claves en el proceso de estimación son las habilidades y la experiencia del Equipo de Desarrollo (Borstler, Britto, Damm & Usman, 2018). Naturalmente, es más fácil estimar cuánto cuesta hacer algo si ya se ha hecho con anterioridad. Otro punto a notar es que la estimación es un proceso que va de la mano con la priorización, es decir, qué tan importante es realizar primero una historia de usuario u otra.

Product Backlog

El Product Backlog, o Lista del Producto, es una práctica ágil que se representa mediante una lista priorizada y estimada de todas las historias de usuario que componen el proyecto de desarrollo de software. En la metodología Scrum, la persona responsable de la lista del producto, de su contenido y de su disponibilidad es el Dueño del Producto.

Como explican Alshakhouri, Buchan y MacDonell (2018), la lista del producto es un artefacto volátil y dinámico que en un principio se constituye por los requerimientos inicialmente conocidos. El product backlog evoluciona conforme lo hace el proyecto, ya que a medida que este avanza es posible que se identifiquen requerimientos nuevos o se cambie la interpretación de los que ya se tenían. Es dinámica en tanto que debe cambiar repetidamente para acoplarse a las necesidades que exhibe el producto para ser competitivo, útil y tener valor. En un proyecto, siempre existe una lista del producto.

En la lista del producto se registran todas las mejoras, requerimientos, funciones y características del producto de software y los cambio que se espera aplicársele a futuro. Cuando se habla de un elemento de la lista del producto, se hace referencia a una de las historias de usuario.

Como se verá más adelante, el product backlog es también un registro del valor que va ganando el proyecto y tiene como una de sus materias primas la retroalimentación que se obtiene del mercado y de los clientes. Cambios en las condiciones del mercado, en los requerimientos de los clientes o en la tecnología son solo algunos de los factores que pueden ocasionar variaciones en la lista del producto.

Las historias de usuario contenidas en la lista del producto, como se explicó, tienen una serie de detalles que varían de proyecto a proyecto. Estos detalles pueden ser expandidos, reducidos o modificados, lo que implica un refinamiento del product backlog. El refinamiento es un trabajo del Dueño del Producto y del Equipo de Desarrollo. Aunque el refinamiento es un proceso que idealmente no debe ocupar más que una mínima cantidad de la capacidad del Equipo, es importante y puede realizarse en cualquier momento durante el desarrollo del proyecto.

Normalmente, los elementos de mayor orden de la lista del producto (aquellos que probablemente están más próximos a ser implementados) tienen un grado de detalle mayor que el resto. Esto es resultado del refinamiento, pues es de esperar que profundice en las actividades más próximas del proyecto.

Release Plan

El Release Planning, o Plan del Proyecto, es la práctica ágil utilizada para programar el horario que se seguirá para realizar las entregas funcionales frecuentes al Cliente.

Es un diseño de muy alto nivel en el que se agrupan una serie de sprints (práctica que se introducirá más adelante) en distintos lanzamientos, cada uno con fechas específicas. Un lanzamiento (o release) se define comúnmente por un objetivo o una funcionalidad más general al interior del proyecto, la cual requiere la compleción de múltiples requerimientos del cliente. Por ejemplo: el objetivo de un lanzamiento puede ser el de gestionar clientes. Gestionar clientes es una funcionalidad general que puede agrupar a las funcionalidades de registrar clientes, actualizar los datos de los clientes, eliminar clientes, entre otras.

El release plan es una guía que incluye las expectativas que se tienen de la evolución del proyecto de acuerdo a los lanzamientos. También es útil para inspeccionar el avance del proyecto conforme este es desarrollado.

Insumos necesarios para generar el plan del proyecto son:

• La lista priorizada y estimada de las historias de usuario, es decir, la lista del producto.
• La velocidad estimada del Equipo Scrum.
• Algunas condiciones que deben tenerse en cuenta como el presupuesto y el alcance del proyecto.

Con la velocidad del Equipo y las historias estimadas pueden determinarse los sprints que se agruparán en un lanzamiento. Como ocurre con el product backlog, el release plan es un artefacto volátil que puede modificarse si las necesidades del proyecto así lo exigen. Heikkila et al. (2015) exponen en su investigación el proceso de aplicación de un método para la realización del plan del proyecto, identificando también los beneficios que esta práctica puede aportar y posibles mejoras en el método estudiado.

Sprint

El Sprint es la práctica ágil que constituye el núcleo de la metodología Scrum. Comprende un espacio de tiempo de una o más semanas, pero no mayor a un mes. Durante este periodo, el equipo de desarrollo lleva a cabo la creación de una porción del proyecto de software que puede caracterizarse por distintos criterios. Así, la parte del proyecto realizada podrá responder a una cierta funcionalidad o a un cierto objetivo planteado al principio del sprint.

Por ejemplo, si un proyecto es la creación de una plataforma para el comercio virtual, un sprint puede estar determinado por la producción de la funcionalidad que permite realizar pagos y otro por la función de gestionar los envíos de los productos solicitados de los clientes.

Al producto del Sprint se le conoce como Incremento, en todo caso, el incremento producido debe ser completamente funcional, es decir, debe cumplir a cabalidad con las características que se esperan para la funcionalidad, bien sea en sentido de cómo se comporta, cuál es su alcance, sus lineamientos de calidad, o cualquier otro aspecto que se pueda atribuir a su completitud.

Los sprints tienen una duración constante a lo largo del proyecto de desarrollo y son consecutivos. Esto quiere decir que un sprint comienza tan pronto como el anterior termina. El sprint se comprende a su vez otros eventos que también son prácticas ágiles utilizadas en el marco de la metodología Scrum.

Durante un sprint no se realizan cambios que sean potencialmente nocivos para la meta que se estableció para el mismo. Tampoco se llegan a reducir los estándares de calidad definidos para el proyecto en sí. Además, el alcance del sprint puede ser objeto de aclaración o negociación como resultado de una negociación entre el dueño del producto y los miembros del equipo de desarrollo.

Cada sprint podría ser interpretado como un proyecto en sí mismo, y como proyectos, cada uno espera lograr algo específico. Cada sprint tiene una meta acerca de lo que generará, un diseño en aras de conseguirlo y un plan flexible que guía el proceso. La combinación de todos estos proyectos culmina en el producto final de software.

El sprint debe mantener firmeza en su configuración y en algunos aspectos. Es imperativo que un sprint no supere el límite de duración de cuatro semanas. Aunque no se realizan cambios al objetivo de un sprint en medio de éste, si su alcance es demasiado amplio sí es posible llegar a cambiar la definición de aquello que se está construyendo. Naturalmente, cambios así tienen implicaciones en cuanto a cambios en complejidad y aparición de nuevos riesgos. Los sprints, sin embargo, permiten tener capacidad de predicción mediante la inspección y la adaptación del progreso hacia el objetivo del sprint mientras se respete el límite de tiempo ya mencionado. Este límite también tiene la ventaja de delinear los riesgos que se toman.

Un sprint podría llegar a cancelarse antes de su culminación. La única persona con la facultad para cancelar un sprint es el Product owner (Dueño del Producto), soportado en potencia por los stakeholders, el equipo de desarrollo o el Scrum master. Esto puede ocurrir en caso de que la meta fijada para el sprint llegase a hacerse obsoleta, como resultado de eventos como un cambio en el interés de los clientes, una variación en el mercado o una modificación de las condiciones tecnológicas.

En síntesis, la cancelación de un sprint, aunque grave, es un evento plausible si el sprint deja de tener sentido en función de las circunstancias que atraviesa el proyecto de desarrollo de software. No obstante, la cancelación de un sprint es una ocurrencia muy poco frecuente dada la ya reducida duración que suele tener esta práctica ágil (Schwaber & Sutherland, 2017).

Sprint Planning

La planeación de sprints es una práctica ágil en la que se realiza un plan de lo que se construirá durante el sprint. El plan derivado es un resultado del trabajo conjunto de todo el Equipo Scrum.

La planeación de un sprint tiene una duración límite ocho horas para un sprint de cuatro semanas. Sprint menos longevos tienen planeaciones normalmente de menor duración. El Scrum master, como gestor de la metodología Scrum, debe asegurarse de la realización del evento y del entendimiento de su propósito por parte de los asistentes. También debe procurar que el evento se mantenga en la franja de tiempo definida.

La planeación de un sprint debe responder a las siguientes preguntas:

• ¿Qué puede entregársele al cliente en el incremento que resultará del sprint?
• ¿Cómo se conseguirá realizar el trabajo necesario para materializar el incremento?

El equipo de desarrollo genera un pronóstico de la funcionalidad que se producirá a través del sprint. El dueño del producto discute el objetivo que debería lograr el sprint y los elementos de la lista del producto que deberán completarse para que, una vez finalizado el sprint, se cumpla dicho objetivo. Todo el equipo debe colaborar para comprender el trabajo que representará el sprint.

La materia prima de un spring planning es la lista del producto, el más reciente incremento producido, la capacidad proyectada del equipo de desarrollo para el sprint e información de anteriores rendimientos del equipo. El equipo de desarrollo tiene la responsabilidad de definir qué elementos de la lista de producto serán seleccionados para ejecutarse durante el sprint, pues solo el equipo puede proponer qué puede lograr.

En la planeación del sprint es necesario, claramente, definir el objetivo del sprint. El objetivo establece la meta que se conseguirá al implementar parte de la lista del producto y también guía al equipo. Asimismo, provee justificación para las actividades que se llevan a cabo en el sprint.

Una vez establecido el objetivo del sprint y seleccionados los elementos apropiados de la lista de producto, el equipo de desarrollo debe decidir cómo construirá la funcionalidad pertinente para el incremento propuesto. Los elementos de la lista de producto seleccionados y el plan para entregarlos es también una práctica ágil y se conoce como Sprint Backlog.

El equipo de desarrollo normalmente comienza diseñando el sistema y definiendo el trabajo requerido para convertir la porción de la lista de producto seleccionada en un incremento funcional del producto de software. El trabajo definido depende del pronóstico hecho por el propio equipo de desarrollo, y usualmente se define en función de días. De este modo, lo común es dejar consignado qué trabajo o tareas se tienen programados para cada día cubierto por el sprint.

El Dueño del Producto debe aclarar los elementos de la lista del producto seleccionados y negociar con el equipo de desarrollo. Si el equipo de desarrollo llegase a considerar que tiene muy poco o demasiado trabajo, puede negociar los elementos de la lista seleccionados con el Dueño del Producto. Está dentro de las facultades del Equipo de Desarrollo invitar al evento a personas capacitadas para proveer evaluaciones técnicas sobre el trabajo a realizar.

Al finalizar la planeación del sprint, el Equipo de Desarrollo debe estar en capacidad de explicar al Dueño del Producto y al Scrum master cómo trabajará de manera auto-organizada para lograr completar el objetivo del sprint y el incremento considerado.

La planeación del sprint es un proceso crítico para asegurar el éxito de un sprint. En contraste con las metodologías tradicionales de desarrollo, la fase de planeación del sprint tiene una esencia no estructurada y gaseosa, puesto que responde al principio de necesidad de atender al cambio. La efectividad de una fase de planeación de sprints depende en gran medida de la precisión de las estimaciones realizadas por el Equipo, y en la capacidad de proyectar adecuadamente variables en el desarrollo del sprint.

Las estimaciones mejoran mientras mayor sea la experiencia del Equipo, pero el caso de las variables es un problema complejo que se hace más profundo entre más magnitud tenga el proyecto de desarrollo de software. Una planeación no óptima derivará en sobrecostos, demoras en las entregas periódicas del proyecto y deficiencias en calidad. Como es señalado por Golfarelli, Rizzi y Turicchia (2013), diferentes autores postulan distintas aproximaciones que, combinadas, son relevantes para procesos de planeación de sprints satisfactorios. Entre ellas:

• Satisfacción del cliente: los primeros sprints deben dar altas utilidades al cliente. Ello promueve confianza.
• Gestión de agrupamiento: tareas afines deben ser ejecutadas en el mismo sprint, así se incrementa la utilidad que se le entrega al cliente. Entre más tareas afines se desarrollen al sprint, mayor utilidad se entregará al culminarlo.
• Gestión de riesgo: tareas críticas deben programarse para sprints tempranos, en pos de evitar sorpresas tardías en el desarrollo. Tareas que supongan incertidumbre deben distribuirse en distintos sprints para balancear el riesgo de que las entregas deban retrasarse.

Daily Scrum

El Daily Scrum, Standup Meeting o Reunión Diaria, es una práctica ágil que inaugura cada día de trabajo durante el desarrollo de un sprint. Es un evento de 15 minutos en el que participan los miembros del Equipo de Desarrollo. Durante la reunión diaria se planean las próximas 24 horas de trabajo del Equipo. El fin de la reunión diaria es optimizar la colaboración y el rendimiento del Equipo de Desarrollo al inspeccionar el trabajo realizado desde la reunión diaria del día anterior. Sirve también para realizar un pronóstico del trabajo que se aproxima en el desarrollo del sprint. Lo normal es que la reunión diaria se realice en el mismo lugar y a la misma hora para reducir la complejidad del evento.

El Equipo de Desarrollo utiliza la reunión diaria para analizar el progreso hacia la meta del sprint y evidenciar cómo el trabajo confluye en la compleción del trabajo postulado en el Sprint Backlog. La reunión diaria es una forma de incrementar la probabilidad de que el Equipo de Desarrollo alcance el objetivo del sprint. Cada día, el Equipo debería llegar a entender cómo espera trabajar de manera auto-organizada para dar respuesta al objetivo y al incremento funcional esperado al culminar el sprint.

La estructura de una reunión diaria es configurada por el Equipo de Desarrollo. El evento puede desenvolverse de variadas formas. Lo importante, debe quedar claro, es que siempre tenga por foco considerar el avance hacia el objetivo del sprint. Algunos equipos realizan reuniones basadas en preguntas y otros las operan sobre discusiones. Algunas cuestiones comunes en una reunión diaria son:

• ¿Qué hice el día de ayer para que el Equipo de Desarrollo consiga completar el objetivo del sprint?
• ¿Qué haré hoy para que el Equipo de Desarrollo consiga completar el objetivo del sprint?
• ¿He identificado algún impedimento capaz de evitar que el Equipo de Desarrollo consiga completar el objetivo del sprint?

Como se sugirió, todo lo que se trate durante la reunión debe girar en torno al avance hacia el objetivo del sprint.

Con frecuencia, algunos miembros del Equipo de Desarrollo se juntan inmediatamente después de concluir la reunión diaria para sostener discusiones más técnicas o especializadas para adaptar el trabajo que aún hace falta al sprint. Debe notarse que la discusión que se mantiene en la reunión diaria no es detallada ni muy profunda, pues por ello podría dejar de ser un seguimiento del objetivo para convertirse en una charla técnica sobre algún problema específico que se le presentó a algún miembro del Equipo. Estas reuniones posteriores sirven a este propósito.

Como ocurre con la planeación del sprint, el Scrum master es la persona con la responsabilidad de asegurar que el Equipo de Desarrollo lleve a cabo la reunión diaria y que no rebase el tiempo de 15 minutos. Sin embargo, la responsabilidad de conducirla recae sobre el propio Equipo de Desarrollo.

Las reuniones diarias son la práctica ágil de mayor favorabilidad en las empresas dedicadas a la producción de software que siguen metodologías ágiles en general, no solo Scrum. Son eventos que fomentan la comunicación al interior de los equipos, eliminan la necesidad de otras reuniones, ayudan a identificar obstáculos, promueven la toma rápida de decisiones y mejoran el conocimiento que el Equipo tiene de sí mismo (Rola, Kuchta & Kopczyk, 2016).

Sprint Review

Según Sutherland (2012) El Sprint Review, o Revisión del Sprint, es la práctica ágil que tiene lugar justo con la finalización del sprint. Es una reunión durante la cual se inspecciona el incremento funcional producido en el sprint y se realizan ajustes pertinentes a la lista del producto en caso de ser necesario. Todos los stakeholders, tanto el Equipo Scrum como los Clientes o sus representantes, deben tomar parte de la revisión del sprint. Durante la revisión, los stakeholders colaboran para inspeccionar qué se realizó en el sprint.

De acuerdo a esta inspección y a los cambios en el product backlog que hayan podido ocurrir durante el sprint, los asistentes al evento trabajan en conjunto para deliberar acerca de los diferentes rumbos que puede tomar el proyecto, teniendo como punto clave la adición y optimización de valor. La revisión del sprint es una reunión de carácter informal y no de seguimiento del estado del proyecto. La intención de presentar el incremento funcional producido es que el Equipo obtenga retroalimentación y tenga la oportunidad de colaborar con los Clientes.

La duración de una revisión de sprint es de típicamente una hora por semana de duración del sprint. Así, un sprint de cuatro semanas culmina con una revisión de cuatro horas. El Scrum Master la organiza, se asegura de que se realice, de que se mantenga en el horario establecido y del entendimiento de su propósito por parte de quienes la asisten.

El curso normal de una revisión de sprint es el siguiente:

• El Dueño del Producto explica qué elementos de la lista del producto fueron culminados y cuáles aún no como resultado del sprint que concluye.
• El Equipo de Desarrollo explica qué ocurrió con éxito durante el sprint, en qué problemas incurrió y cómo puedo resolverlos.
• El Equipo de Desarrollo hace una demostración del incremento funcional a entregar y responde dudas de los participantes.
• Algunos clientes, quizá, requieran hacer un uso del incremento para estar en capacidad de proveer su retroalimentación y su parecer sobre el mismo.
• El Dueño del Producto exhibe el estado actual de la lista del producto. Después, realiza una proyección de posibles objetivos para el sprint que se ejecutará, con fechas de entregas tentativas.
• Todos los asistentes deliberan en conjunto acerca de qué hacer a continuación. Con esto, la revisión del sprint generará una entrada para la siguiente planeación de sprint.
• Se examina el estado actual del mercado potencial del producto que se está desarrollando podría haber cambiado para determinar, de entre los posibles cursos de acción, qué le agregaría más valor al producto.
• Se revisa la línea de tiempo del proyecto, el presupuesto, el mercado potencial y utilidades del producto.

En síntesis, podría decirse que la revisión del sprint es una práctica ágil que finaliza un sprint, involucra a los stakeholders y durante la cual el Equipo de Desarrollo demuestra el incremento del producto con el fin de obtener retroalimentación y promover la colaboración con los Clientes.

El resultado concreto de la revisión del sprint es una lista de producto modificada y la definición de elementos de la lista de producto que es deseable incluir en el sprint que se aproxima.

Sprint Retrospective

El Sprint Retrospective, o retrospectiva del sprint, es una práctica ágil constituida por un evento interno del Equipo Scrum mediante el cual se trata de hacer introspección sobre su funcionamiento en aras de diseñar un plan de mejoramiento para aplicar en el siguiente sprint.

La retrospectiva del sprint se lleva a cabo después de la revisión del último sprint y antes de la planeación del siguiente. Es una reunión de a lo sumo tres horas para sprints de cuatro semanas. Tiene menor duración para sprints menos extensos. De nuevo, el Scrum master la organiza, la mantiene en el espacio de tiempo descrito y se asegura de su entendimiento por parte del Equipo. Adicionalmente, debe velar porque sea una reunión productiva y positiva y participar en ella como un miembro más del Equipo en su calidad de responsable de la correcta aplicación de la metodología Scrum.

El objetivo de la retrospectiva del sprint puede dividirse en los siguientes tres puntos:

• Indagar cómo el sprint que concluyó se desenvolvió con respecto a los miembros del Equipo y las relaciones entre ellos, las herramientas utilizadas y los procesos.
• Establecer y ordenar los elementos de la lista de producto que se completaron más satisfactoriamente y determinar posibles mejoras.
• Crear el plan de mejoras que se espera aplicar al trabajo del Equipo Scrum.

En la retrospectiva del sprint, el Scrum master debe animar al Equipo Scrum a buscar y aplicar formas de mejorar su rendimiento, sus procesos de desarrollo, su manejo de la metodología Scrum y sus prácticas en general para el siguiente sprint.

Al completar la retrospectiva del sprint, el Equipo Scrum debería haber determinado qué mejoras aplicará para la ejecución del próximo sprint. Al implementar mejoras, el Equipo Scrum responde a la necesidad de adaptabilidad ante el cambio y las eventualidades durante la ejecución del proyecto. Cualquier momento es adecuado para implementar mejoras, pero la retrospectiva del sprint constituye una oportunidad formal y frecuente para que el Equipo Scrum atienda al principio de adaptabilidad mencionado (Eloranta, Koskimies & Mikkonen, 2016).

Refactoring

El Refactoring, o refactorización, es un proceso mediante el cual se optimiza el funcionamiento interno de un programa sin incidir en su comportamiento observable. Podría decirse que es una práctica ágil en la que se busca mejorar el cómo hace algo un programa, pero no el qué hace. A través de la evolución de la industria del software, la refactorización se ha convertido en una práctica clave del proceso de desarrollo de software, y múltiples ambientes de desarrollo integrado tienen acoplados métodos que ayudan a los programadores a realizarlo.

Un estudio realizado por Garcia et al. (2019) analiza la preferencia de una muestra de programadores en cuanto a distintos y comunes métodos para realizar refactorización actualmente. Algunos de ellos son:

• Refactorización de función definida en cuerpo: consiste en remover la definición de una función e introducir su código en el cuerpo de otras funciones que la invocan.
• Refactorización por Pull Up Fields: es la remoción de un campo en subclases para ponerlo en la superclase. En otras palabras, se quita un atributo común en dos clases hijas y se pone en la clase padre de ellas.
• Refactorización por Push Down Fields: es el inverso del método Pull Up. Un atributo de la clase padre se remueve de ella y se introduce en algunas de sus clases hijas.
• Refactorización por Renombramiento de Campos: es un método simple en el que sencillamente se cambia el nombre de un atributo o función de una clase.
• Refactorización por Encapsulamiento de Campos: consiste en encapsular un atributo público de una clase y proveer acceso a él por medio de métodos.

La refactorización no debe significar un cambio en la funcionalidad de un programa, como se ha indicado. Es básicamente un proceso de limpieza u optimización del código del programa que apunta a mejorar la mantenibilidad del código y a extender su escalabilidad y flexibilidad. La refactorización busca hacer esto mediante la reducción de super-clases y super-funciones a clases y funciones bien definidas y modulares, con funcionalidades únicas, y también con la introducción de patrones de diseño sencillos de reconocer. La utilización de la refactorización conlleva mejoras en métricas de código, en su capacidad de ser entendido, en su elegancia, en su calidad y en su limpieza (Bacchelli et al., 2019).

Kanban Boards

El Kanban Board, o Tablero Kanban, es una práctica ágil que emplea un tablero con tarjetas para organizar tareas y sus estados. Es una herramienta que describe el flujo de trabajo que sigue el Equipo en el proyecto.

El tablero con tarjetas Kanban es una herramienta de visualización del trabajo que se realiza. A menudo se combina con la práctica de reunión diaria para describir y encausar el flujo de trabajo del Equipo de Desarrollo. El tablero puede tener distintas presentaciones, y se divide a menudo en columnas que representan cada una el estado de una cierta tarea. Por ejemplo, se pueden tener las siguientes columnas: backlog, para agrupar las tareas o historias de usuario que se encuentran sin tratar en la lista del producto; to-do (para hacer), para agrupar las tareas que han sido seleccionadas para ser ejecutadas próximamente; Doing (ejecutando), para agrupar las tareas que se encuentran en proceso de implementación; Done (hecho), para agrupar las tareas que ya han sido completadas. Las tarjetas representan las tareas, y se mueven a las columnas correspondientes conforme avanza el proyecto.

Powell (2018), explica más a fondo el funcionamiento de la metodología Kanban. Según su investigación, el tablero Kanban y su combinación con las reuniones diarias son un factor de éxito en el campo del desarrollo de software con metodologías ágiles en la actualidad. Powell secunda la opinión de que los tableros son una herramienta sencilla y efectiva para la gestión y el control de tareas no solo en el desarrollo de software, sino también en otros entornos de producción.

Pair Programming

El Pair Programming, o Par Programador, es una práctica ágil en la que dos desarrolladores trabajan juntos en única estación.

Algunos beneficios posibles del Par Programador son:

• Previene la aparición de “Torres de conocimiento”, es decir, individuos que son casi eruditos cuando se trata del código que se está desarrollando. En principio esto no es malo, pero puede convertirse en un problema cuando el resto del equipo depende de unos cuantos miembros a los que todos se dirigen para solucionar problemas con rapidez. Esto tiene implicaciones en la confianza y en la moral conjunta del equipo.
• Facilita el entrenamiento de nuevos miembros en el Equipo de Desarrollo. Nuevos desarrolladores se asignan inmediatamente a un par, de manera que el proceso de adaptación al Equipo y familiarización con el proyecto es más rápido y ameno.
• Aumenta la posibilidad de obtener código más robusto. Si más de un individuo trabaja en un programa, las posibilidades de pasar errores por alto disminuyen. Además, es probable que determinados casos la combinación de conocimientos genere métodos de implementación más eficientes o acertados que el que generaría una única persona.

Balijepally, Mahapatra, Nerur y Price (2009) condujeron un estudio en el que se cuestiona la efectividad del par programador como estrategia para aumentar los niveles de rendimiento de los equipos de desarrollo. En su investigación, no se encontraron pruebas concretas de que pares de programadores produjeran más o mejor código que desarrolladores individuales, pero sí se encontraron patrones que sugerían niveles de satisfacción más altos en los pares de programadores. Además, son claros los beneficios de utilizar el par programador como método de entrenamiento de nuevos miembros en un equipo de desarrollo.

Continuous Development

El Continuous Development, o Desarrollo continuo, es un conjunto de prácticas ágiles que se encuentran entre las nuevas tendencias que parecen encausar el rumbo de la industria del desarrollo de software. Tradicionalmente, los proyectos de desarrollo mostraban resultados al momento de la entrega final al cliente. Con las metodologías ágiles, se migró hacia entregas frecuentes de pequeños incrementos funcionales del producto a los clientes. Las prácticas continuas, como el despliegue continuo, marcan el inicio de la era del software como una entidad en evolución continua. El producto de software se encuentra corriendo sin detenimiento en alguna plataforma, y cambia constantemente.

El desarrollo continuo puede dividirse en:

• Continuous integration (integración continua): cuando un desarrollador genera un cambio en alguna porción del código del producto, o agrega código nuevo, este se actualiza en el producto en tiempo real.
• Continuous testing (pruebas continuas): las pruebas que se le hacen al código ahora son automáticas y pre-programadas, y generan retroalimentación inmediata para los desarrolladores.
• Continuous delivery (entrega continua): el código producido y probado se transmite inmediatamente a una plataforma de prueba manual que simula la plataforma real en la que el producto está corriendo.
• Continuous deployment (despliegue continuo): similar a la entrega continua, pero en vez de integrarse a una plataforma de pruebas, el código nuevo se acopla automáticamente al servidor real.

La investigación de Eskeli et al. (2017) presenta un estudio sobre los posibles beneficios y retos que pueden enfrentar las empresas que adoptan el Desarrollo Continuo. En él, se muestra que este es un campo muy prometedor que se encuentra aún en una etapa temprana y aun así ofrece una amalgama de nuevas oportunidades tanto para investigadores como para la industria del software.

Conclusión

Se ha realizado una revisión del estado del arte respecto a varias de las prácticas ágiles que se aplican en la actualidad en el marco del desarrollo de productos de software utilizando metodologías ágiles, con énfasis en la metodología Scrum. Durante esta revisión, se ha evidenciado que las distintas prácticas ágiles constituyen un campo de estudio científico próspero y cuya base bibliográfica gana riqueza con rapidez. En prácticamente todas las fuentes consultadas se hicieron investigaciones sobre efectividad, pertinencia de aplicación, ventajas y desventajas de las prácticas ágiles en contextos industriales.

Finalmente, la revisión realizada sugiere que el ritmo con el cual se ejecutan estudios e investigaciones sobre la aplicación de distintas prácticas ágiles en la industria del desarrollo de software se irá acelerando en el futuro. Fue posible hallar estudios científicos numerosos y recientes en el tema.