Proceso unificado vs metodologías ágiles

Esta publicación es un trabajo universitario que realicé hace poco. Espero que lo disfruten tanto como lo hice yo al escribirlo. ¡Un saludo!

1.Objetivo del trabajo

El objetivo del trabajo presente es poder ilustrar las diferencias principales entre la metodología UP y una metodología ágil existente.

2. Introducción UP

UP es un proceso de desarrollo software. El principal objetivo de UP como proceso de desarrollo de programas informáticos, es proveer de formalización a actividades relacionadas con la creación de sistemas informáticos.

UP, al ser un proceso de desarrollo software, se encuentra entre los requisitos del usuario y el sistema software en sí.

Como lenguaje de modelado utiliza UML (Unified Modeling Language), que es el lenguaje de modelado más conocido y usado en la actualidad.

3. Introducción metodología ágil elegida

Antes de pasar a introducir la metodología ágil elegida, parece conveniente poner en manifiesto qué se entiende por dicho término.

“Una metodología ágil está centrada en una idea iterativo de desarrollo, donde los requisitos y las soluciones evolucionan mediante la colaboración entre equipos multifuncionales autoorganizados. Algunos ejemplos de metodología ágil podría ser Kanban o Scrum”.

La metodología ágil elegida para este trabajo va a ser Scrum. ¿Por qué? Según se afirma en ‘The state of agile’, que es uno de los informes más importantes sobre el desarrollo de software ágil, se reporta que el 56% de los equipos usan esta metodología [1]. Siendo la más popular. De hecho, existe a nivel mundial la organización sin ánimo de lucro Scrum Alliance, que cuenta con más de 400.000 miembros.

Dicho esto, ¿qué se entiende por scrum?

“Scrum es un marco ágil para el desarrollo, entrega y mantenimiento de productos complejos, con un énfasis inicial en el desarrollo de software. Está diseñado para equipos de nueve o menos miembros, que dividen su trabajo en objetivos que se pueden completar en tiempos determinados denominados sprints. El equipo realiza un seguimiento del progreso en reuniones diarias de 15 minutos denominadas scrums. Tras realizar un sprint se hace una revisión del sprint y una retrospectiva para mejorar continuamente”. [2]

4. Comparativas

4.1 Dominio de aplicación

Up

La experiencia ha demostrado que dominios de problemas diferentes, requieren diversos procesos.  Todos esos procesos pueden tener cabida bajo los términos de UP, ya que es un marco de trabajo capaz de adaptarse a las necesidades.

Por lo tanto, UP se puede aplicar a gran cantidad de problemas -independientemente de su dominio-, puesto que posee la capacidad de lidiar con los cambios de requisitos.  Dichos cambios pueden venir por parte del cliente o del propio proyecto.

Como conclusión, se puede afirmar que el dominio de aplicación de UP es cualquier tipo de problema

Scrum

El dominio de aplicación de Scrum son proyectos pequeños, pues el número de miembros ha de oscilar entre los tres y nueve, tal como se indica en la ‘Scrum guide’.

  • Características

Up

Las características principales de este proceso de desarrollo, es que está dirigido por casos de uso -incluye su captura, así como el análisis, diseño e implementación-, centrado en la arquitectura y es iterativo e incremental.

Su última característica es muy relevante, puesto que reduce el coste de los riesgos, disminuye el riesgo a una mala planificación, acelera el ritmo de desarrollo…

UP se repite a lo largo de una serie de ciclos, conformando cada uno de ellos una versión del producto; que no deja de ser un producto ya preparado para ser entregado.

Un ciclo se divide en fases: inicio, elaboración, construcción y transición.

En la fase de inicio, se planifica el proyecto. Incluyendo el caso de negocio, estableciendo el alcance del proyecto, identificando los riesgos iniciales… Si esta fase resulta durar mucho, es un indicador que la visión y objetivos del proyecto no son del todo claros para lo stakeholders.

 En la fase de elaboración se establece una arquitectura adecuada y un plan. Se realiza un análisis de riesgos y se hace un plan para reducir su impacto en la planificación final del producto.

 En la fase de construcción, se desarrolla el sistema. La fase de construcción es dividida en múltiples iteraciones, resultando para cada una de ellas una versión ejecutable del sistema. La última iteración da lugar al sistema totalmente completado que se implementará en la fase de transición.

Y, por último, en la transición, se proporciona el sistema a los usuarios finales.

Como conceptos importantes de UP, merecen destacar los siguientes:

Actividad: unidad tangible de trabajo realizada por un trabajador, de forma que queda implícita su responsabilidad, y sus límites quedan bien definidos.

Artefacto: pieza de información tangible que es creada, utilizada y modificada por trabajadores. Dos tipos posibles: de ingeniería y de gestión.

Modelo: abstracción del sistema desde un punto de vista concreto y con cierto nivel de abstracción. Identifica al sistema que se está modelando.

Trabajador: rol que desempeña un trabajador en un instante dado. Tiene responsabilidades: o bien de realizar actividades o ser responsable de artefactos.

UP se basa en gran medida, en sus flujos de trabajo. Destacan como flujos de trabajo fundamentales: análisis, diseño, implementación y pruebas.

A grandes rasgos, UP cuenta con las 6 mejores estrategias para el desarrollo de software.

  1. Desarrollo iterativo de software.
  2. Gestión de los requisitos
  3. Utilización de arquitectura basada en componentes
  4. Modelado visual de software.
  5. Verificación de calidad del software.
  6. Gestión de la configuración.

Scrum

Scrum se basa en equipos multifuncionales de máximo 9 miembros, con el fin de entregar servicios y productos en cortos ciclos; permitiendo mejora continua, feedback, adaptación rápida a los cambios y naturalmente, una entrega veloz del producto.

Para entender un poco más sobre este método, se ha de hacer hincapié en el hecho de dividir grandes productos/servicios en pequeñas partes que pueden ser abordadas por un equipo en un corto periodo de tiempo –sprints-.

Los sprints pueden durar desde una semana, hasta un máximo de un mes. Tras un sprint, viene otro. En cada uno, se realiza un incremento sobre el producto/proyecto; que será notificado a los strakeholders, con el fin de conocer si se han satisfecho sus expectativas.

Además, algo muy importante que ha de resaltarse, es que Scrum sigue los principios siguientes, definidos en el ‘Agile Manifesto (2001)’:

  1. Individuos e interacciones sobre* procesos y herramientas.
  2. Productos funcionales sobre* documentación entendible.
  3. Colaboración del cliente sobre* la lo estipulado en el contrato.
  4. Responder a los cambios sobre* seguir a un plan.

*Sobre: denota preferencia respecto a la otra actividad

Con el objetivo de asegurar un correcto flujo de trabajo, Scrum usa tres pilares fundamentales para controlar todo lo realizado:

  1. Transparencia:  Se han de realizar constantes reviews para informar a los miembros del equipo sobre lo realizado y proveer de una visión clara del proyecto a los stakeholders.
  2. Inspección:Se inspecciona lo que se está siendo creado de manera regular para asegurar que no existan desviaciones respecto al objetivo final.
  3. Adaptación: al cabo de cada iteración, se ha de ajustar el producto en caso de que haya ocurrido una desviación del objetivo.

Aparte de los tres pilares mencionados con anterioridad, Scrum es también iterativo e incremental; y, según lo estipulado en ‘The Scrum Guide’, todo equipo que siga una metodología Scrum ha de compartir los 5 siguientes valores: compromiso, concentración, respeto, franqueza y coraje.

Y es que, con respecto a los equipos, Scrum define tres roles: el ScrumMaster -ayuda al equipo a llegar a sus objetivos-, el ProductOwner -representa al cliente- y el equipo de desarrollo -decide cómo llevar a cabo el trabajo establecido por el ProductOwner-. 

Scrum, además de lo mencionado, define 3 artefactos: Product Backlog -que es una lista de lo conocido y de lo que necesita el producto-, Sprint Backlog -es una lista de las cosas que ha realizado el equipo para terminar el sprint-, e incremento de producto potencialmente listo para salir al mercado – completamente probado y aprobado-.

Y para concluir con las características, se tienen los 4 eventos que define Scrum:Sprint Planning -el equipo colabora y discute sobre los objetivos del sprint-, Daily Scrum – reuniones diarias de 15 minutos o menos , para exponer los avances del Sprint- , Sprint review  – el equipo invita a los stakeholders  para comentar y debatir lo completado en el sprint- y  Sprint retrospective  -reunión donde el equipo hace balance sobre lo que fue bien en el sprint, y se hace hincapié en lo que se puede mejorar.

4.3 Resto de elementos diferenciadores y similitudes

Similitudes: ambas metodologías son iterativas e incrementales, son capaces de abordar problemas más allá del sector tecnológico, se les da importancia a los cambios y al cliente.

Diferencias:  dominio de aplicación distinto marcado por el número de miembros de los equipos, distinto tiempo necesario para llevar a cabo el proyecto, y a priori más reuniones en Scrum.

4.4 Ejemplo de aplicación de metodologías

UP

Algunos ejemplos de aplicación de UP podrían ser: aplicaciones independientes, aplicaciones web o aplicaciones cliente/servidor.  

Scrum

 Scrum no se centra solo en desarrollo de software, o aspectos relacionados exclusivamente con la industria tecnológica. De acuerdo con el artículo ‘Evolution of Scrum Transcending Business Domains and the future of agile Project management’, Scrum también tiene cabida en ámbitos como las ventas, educación, comunicación, manufacturación o recursos humanos, y tiene mucho potencial de cara a campos que aún no han sido explorados.

5.Bibliografía

https://www.sciencedirect.com/topics/computer-science/unified-process.

Janis Osis, Uldis Donins

The Latest Reports and Stats About Agile [2019] | Adeva (adevait.com)  [1]

Scrum (software development) – Wikipedia : [2]

Evolution of Scrum Transcending Business Domains and the Future of Agile Project Management | SpringerLink

Scrum Dev Team Size | Scrum.org

Scrum Theory and Principles (scrumalliance.org)

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s