Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tesis Master Manuel Puchades Rodriguez
Tesis Master Manuel Puchades Rodriguez
Autor
Manuel Puchades Rodríguez
Tutor
Luis Fernández Muñoz
febrero de 2020
Estado del arte de las metodologías de desarrollo ágil
[UPM] Máster en Ingeniería Web
Estado del arte de las metodologías de desarrollo ágil
AGRADECIMIENTOS
RESUMEN
Desde el año 2001, amparadas bajo el manifiesto ágil, cohabitan diferentes herramientas
y prácticas para la gestión y elaboración de proyectos de software. Estas son conocidas como
metodologías ágiles. El objetivo de sus creadores fue definir un conjunto de valores y
principios básicos para un mejor desarrollo de software.
Este nuevo enfoque se ha vuelto muy popular y ha sido ampliamente adoptado por las
organizaciones de desarrollo de software e, incluso, por compañías fuera del ámbito de las
tecnologías de la información. Los principios de la agilidad y sus diferentes implementaciones
han allanado el camino a formas innovadoras de desarrollo de software.
Sin embargo, el término ágil ha sufrido un gran desgaste en los últimos años, siendo tal
la situación que varios de los creadores y firmantes del manifiesto sostienen que los principios
y valores originales que llevaron a su redacción se han diluido con el tiempo y sus
implementaciones.
En el presente proyecto exploraremos la historia de los preceptos ágiles, estudiaremos
las metodologías más extendidas, y cómo ha evolucionado el concepto de agilidad a través de
estas hasta nuestros días.
P ALABRAS CLAVE
manifiesto ágil, metodologías ágiles, SCRUM, XP, Lean, Kanban.
[UPM] Máster en Ingeniería Web
Estado del arte de las metodologías de desarrollo ágil
ABSTRACT
Since 2001, united under the Agile Manifesto, different tools and practices for the
management and development of software projects cohabit. These are known as Agile
Methodologies. Its creators sought to define a set of values and basic principles for better
software development.
This new approach became very popular and has been widely adopted by software
development organizations, even by companies outside the field of information technology.
The Principles of Agility and its different implementations have paved the way for innovative
forms of software development.
However, the Agile term has suffered great wear in the recent years and several of
Manifesto’s creators and signatories argue the original Principles and Values have been
diluted over time during its implementations.
In this project, we will explore the history of Agile Precepts, study the most widespread
methodologies, and how the Concept of Agility has shifted over the last two decades.
K EYWORDS
Agile manifesto, Agile methodologies, SCRUM, XP, Lean, Kanban.
[UPM] Máster en Ingeniería Web
Estado del arte de las metodologías de desarrollo ágil
TABLA DE CONTENIDOS
Capítulo 1. INTRODUCCIÓN
1. Antecedentes
Probablemente el cambio más notable en el pensamiento del proceso de software en
los últimos años ha llegado con la aparición de la palabra “agile". Este término hace referencia
a métodos ágiles de producción de productos de software, de cómo introducir la agilidad en
un equipo de desarrollo de software.
Más en profundidad Larman y Basili [10] describen la historia del desarrollo de software
iterativo e incremental (IID). Esta comenzaría mucho antes en los años 70 y llegando a su
punto álgido con el manifiesto de 2001. Establecen el comienzo de la relación entre IID y los
métodos ágiles de la siguiente manera: "En febrero de 2001, un grupo de 17 expertos en
procesos [...] interesados en promover métodos y principios de IID modernos y simples se
reunieron en Utah para discutir un terreno común.”
En la publicación estructuran la historia ágil en décadas. Según su investigación la
mentalidad ágil comenzó en la década de 1930 con la idea de los ciclos de “planear-hacer-
estudiar-actuar”. Mencionan varios proyectos, como el proyecto de la NASA Mercury (el
primer programa de vuelo espacial humano de los Estados Unidos) o el desarrollo de software
para el sistema de armas de helicóptero a barco de la Armada de los Estados Unidos, en los
que fueron aplicadas todas las prácticas del IID. Señalan que los ejercicios de iteraciones cortas
y el desarrollo de primera prueba ya se utilizaron en el proyecto Mercury. Estas prácticas
En los años setenta, Royce [11] publicó un artículo considerado como la base para el
modelo de cascada. En su artículo, Royce describió sus opiniones sobre la gestión de grandes
desarrollos de software y lo que era “necesario para transformar un proceso de desarrollo
azaroso en uno que proporcione el producto deseado”. Su enfoque apunta a alcanzar la
condición de que el software de trabajo se entregue a tiempo y dentro de los costos.
Royce propone utilizar las fases del modelo de cascada con una relación iterativa entre
fases sucesivas. El proceso se beneficia al reducir el proceso de desarrollo a límites
manejables. Además, sugiere utilizar prototipos para obtener una simulación temprana del
producto final. En este documento se presentan las primeras reflexiones sobre el desarrollo
iterativo, la retroalimentación y la adaptación.
Inspirado en las ideas de Barry Boehm, James Martin creó durante la década de 1980 en
IBM el enfoque de desarrollo rápido de aplicaciones, formalizándolo finalmente al publicar el
libro Rapid Application Development en 1991, comúnmente conocido como RAD.
El enfoque RAD incluyó una entrega rápida e iterativa con un pequeño equipo de
desarrolladores altamente capacitados. Además, RAD estableció las bases para el Método de
Desarrollo de Sistemas Dinámicos (DSDM) que tuvo una amplia acogida en el noroeste de
Europa, Reino Unido, Países Bajos, Suecia y Dinamarca.
Página 2
Estado del arte de las metodologías de desarrollo ágil
La creación del término ágil se vio alimentado, además, como respuesta a la corriente de
pensamiento que no las consideraba formas de trabajo rigurosas. Hasta entonces eran
conocidas como metodologías ligeras, por lo que sus creadores decidieron contrarrestar esta
creencia de proceso irreflexivo tomando un nombre que representase sus ideales.
2. Motivación
La motivación para la realización del presente proyecto nace de cursar la asignatura de
Metodologías de Desarrollo de Software dentro del plan académico del Máster de Ingeniería
Web. Durante el desarrollo de esta se presentan dos metodologías de desarrollo
aparentemente opuestas: las metodologías tradicionales o pesadas, y las ligeras o ágiles.
Las primeras centran su atención en mantener una documentación exhaustiva del
proyecto, cumpliendo con precisión con el plan previsto y definido en la fase inicial del
desarrollo del proyecto. Estas metodologías, también llamadas predictivas, suelen enfatizar la
documentación, la planificación y seguimiento riguroso de múltiples actividades llevadas a
cabo por diferentes roles dentro del proyecto.
Las metodologías denominadas ágiles, en cambio, son métodos de desarrollo de
software en los que las necesidades y soluciones evolucionan a través de una colaboración
estrecha entre equipos multidisciplinarios. Y se caracterizan por enfatizar la comunicación
frente a la documentación, por el desarrollo evolutivo y por su flexibilidad.
El manifiesto para el desarrollo ágil de software parecía prometer una manera más
exitosa de desarrollar software "simplemente" siguiendo los valores y principios originales.
Esto a su vez hace que el manifiesto sea especial. Algunos desarrolladores creyeron y siguen
creyendo en el manifiesto como el "Santo Grial" para el desarrollo exitoso de software,
mientras que otros lo denominan un truco de marketing para vender el comportamiento de
desarrollo intuitivo dentro de una nueva fórmula.
Sin embargo, el éxito continuo de las ágiles tuvo varias consecuencias, entre las más
comunes: la creación de nuevas tendencias en cómo escalar ágilmente con Scrum of Scrums
(SoS) o Scaled Agile Framework (SAFe). Las ideas originales del manifiesto se han ido
comercializando cada vez más, muchos desarrolladores y administradores que ahora están
adoptando ágil no son conscientes de la diversidad inicial de los métodos ágiles y los principios
subyacentes y scrum es a menudo visto como la única práctica ágil.
La llamada transformación ágil de las organizaciones y compañías es un tema que se
discute con frecuencia, ya que las formas ágiles de trabajo prometen hacer que las empresas
estén preparadas para el futuro. No obstante, los desarrolladores a menudo se declaran
"ágiles" cuando solo usan scrum siguiendo sus preceptos de forma estricta. Por estas razones
el significado de ágil se interpreta erróneamente y de forma limitada, comercializándose así
un concepto incompleto.
Estas malas prácticas son denunciadas públicamente por varios de los autores del
manifiesto y constituyen el motivo principal por el que se realiza el presente trabajo
3. Objetivos
De lo anteriormente expuesto podemos extraer el propósito perseguido que servirá de
guía durante el desarrollo del estudio. El presente Proyecto de Fin de Máster envuelve dos
tipos de objetivos: principales y complementarios.
A partir de aquí descubriremos que, pese a esta gran expansión y reconocimiento de las
ágiles, varios de los firmantes del manifiesto han hecho público su descontento con el estado
actual de la agilidad y de cómo está afectando a la vida de los desarrolladores.
Los objetivos principales serán pues analizar cuál es el estado del arte de la agilidad en
la actualidad. Es decir, estudiar qué ha llevado a aquellos que iniciaron el desarrollo ágil a
manifestarse en contra de él, o al menos, en contra del uso que se le da hoy en día.
Para ello será necesario presentar y contrastar las diferentes opiniones de muchas de las
personalidades que en su momento contribuyeron a su creación y las de otros tantos expertos
en el mundo del desarrollo y gestión de equipos de software.
Página 4
Estado del arte de las metodologías de desarrollo ágil
4. Contenido
El estudio presentado en este proyecto se encuentra estructurado en tres ejes
principales con una serie de capítulos dedicados a cada uno de ellos, tal y como se indica a
continuación:
En la segunda parte se lleva a cabo la investigación que da pie al estudio. Comprende los
capítulos tercero y cuarto:
Página 6
Estado del arte de las metodologías de desarrollo ágil
El enfoque ágil engloba un conjunto de métodos iterativos y evolutivos [7] [8] que se
basan en la mejora de forma iterativa [10] y obtienen como consecuencia procesos de
desarrollo ventajosos [17]. Ágil es un término general que abarca varios enfoques de
desarrollo de software iterativo e incremental, dónde cada una de esas variaciones sería un
marco de trabajo ágil. Los enfoques ágiles más populares incluyen Scrum, Extreme
Programming, Crystal, entre otros.
proyecto. Se puede afirmar que el desarrollo es, por tanto, un proceso empírico y
protagonizado por el cambio continuo.
En palabras de Alistair Cockburn [19], la agilidad iría incluso más allá. Según sus palabras,
Agile es una mentalidad basada en los valores y principios contenidos en el Manifiesto Ágil.
Estos últimos proporcionan orientación sobre cómo responder al cambio y lidiar con la
incertidumbre. Este autor hace la diferencia entre una metodología y un marco de trabajo
(“framework”). Según Alistair una metodología es el conjunto de convenciones que un equipo
acepta seguir. Esto significa que cada equipo tendrá su propia metodología, que será diferente
en forma pequeña o grande de la metodología de cada otro equipo.
Entonces, las metodologías ágiles son las convenciones que un equipo elige seguir de
una manera que sigue los valores y principios ágiles.
Alistair aplica el término marco a los conceptos de Scrum o Extreme Programming.
Ciertamente, nacieron de la metodología de un solo equipo, pero se convirtieron en marcos
cuando se generalizaron para ser utilizados por otros equipos. Esos marcos ayudan a informar
dónde comienza un equipo con su metodología, pero no deberían ser la metodología del
equipo. El equipo siempre necesitará adaptar su uso de un marco para que encaje
adecuadamente en su contexto.
Los marcos de desarrollo que originalmente dieron forma a la Agile Alliance fueron:
Método de Desarrollo de Sistemas Dinámicos (DSDM)
Desarrollo de Software Adaptativo (ASD)
Crystal
Programación Extrema (XP)
Desarrollo Dirigido por Características (FDD)
Scrum
Página 8
Estado del arte de las metodologías de desarrollo ágil
Esta metodología se centra en la filosofía de que “cualquier proyecto debe estar alineado
con unos objetivos estratégicos claramente definidos y se enfoca en la entrega temprana de
beneficios reales para el negocio". Apoyar esta filosofía con los ocho principios permite a los
equipos mantener el enfoque y alcanzar los objetivos del proyecto [21].
Un ciclo de vida de ASD debe estar enfocado en la consecución de una misión y ser
tolerante al cambio. Una vez definida la misión, se procede a la planificación del proceso
donde se utiliza información de iniciación del proyecto para definir el conjunto de ciclos de
lanzamiento (incrementos de software) que serán requeridos para su ejecución. Esta fase se
denomina especulación. La especulación se basa en la creación de suposiciones que serán
iteradas en fases cortas y ajustadas paulatinamente.
Durante la fase de colaboración el equipo debe trabajar conjuntamente para compartir
conocimientos, tomar decisiones y finalmente producir resultados. En el contexto de la
gestión de proyectos, la colaboración representa un equilibrio entre seguir plan inicialmente
concebido con técnicas de gestión tradicionales y la adaptación teniendo en cuenta diversos
factores tales como las limitaciones tecnológicas, cambios de requerimientos, proveedores de
productos...
La parte de Aprendizaje del ciclo de vida es vital para el éxito del proyecto. El equipo
tiene que mejorar sus conocimientos constantemente, utilizando prácticas como: revisiones
técnicas, retrospectivas internas del desarrollo del proyecto, intercambios y demostraciones
con el cliente.
Las revisiones deben hacerse después de cada iteración. Tanto los desarrolladores como
los clientes examinan sus supuestos y usan los resultados de cada ciclo de desarrollo para
conocer la dirección del siguiente.
Las iteraciones deben ser cortas, para que el equipo pueda aprender de los errores
pequeños en lugar de los grandes. De esta manera se establece el proceso de aprendizaje
siendo, por tanto, un proceso colaborativo que se desarrolla según avanza el proyecto.
Página 10
Estado del arte de las metodologías de desarrollo ágil
3. Scrum
Scrum es un marco de proceso ágil altamente iterativo, creado a principios de la década
de 1990 y centrado en el desarrollo orientado a objeto. Sus desarrolladores más conocidos
son Ken Schwaber, Jeff Sutherland y Mike Beedle.
El embrión de este marco de desarrollo ágil es el análisis que Nonaka y Takeuchi realiza
a principio de los 80 sobre la forma de producción de las principales empresas tecnológicas
del momento [24]. En este análisis la nueva forma de trabajo es comparada con el avance en
formación de melé (scrum en inglés), una situación de juego de rugby. Este hecho provoca
que se acuñe finalmente el término ‘scrum’ para referirse a estas formas de trabajo.
Artefactos
Hay tres artefactos principales producidos por los equipos de scrum, todos estos son
abiertamente accesibles e intencionalmente visible para el equipo scrum:
Backlog del producto. Es una cola priorizada que describe las funcionalidades del
producto/proyecto, que evolucionará según las necesidades del cliente.
Sprint backlog. Es una lista de todas las características empresariales, tecnológicas,
mejoras y defectos que se han programado para la iteración actual, llamada sprint. El
sprint backlog también se mantiene en un formato similar a una hoja de cálculo. Los
requisitos se desglosan en tareas, cada tarea está descrita en la hoja de cálculo con
Proceso
Scrum fue diseñado para trabajar colaborativamente y su principal particularidad se
concentra en ser una estrategia de desarrollo incremental del trabajo a partir de equipos
autoorganizados. El equipo se compromete con un objetivo definido para una iteración y se
le otorga la autoridad, la autonomía y la responsabilidad para decidir la mejor manera de
cumplirlo, que comprometan una alta calidad durante todo recorrido.
Además, la división del desarrollo en sprints permite solapar diferentes fases del
desarrollo, a diferencia de los métodos en cascada.
Según este marco cada sprint incluye las siguientes cuatro actividades:
• Planificación. Establecer una descripción amplia del proyecto, objetivos generales:
aspectos como la funcionalidad, objetivos, riesgos del sprint, plazos de entrega, entre otros.
• Scrum diario. Esta reunión de equipo tiene como objetivo la actualización de status
del proyecto: toma de decisiones, mejoras, problemas. Estas reuniones están pensadas para
durar como máximo 15 minutos.
• Revisión de sprint.
• Feedback. En esta fase el equipo realiza una retrospectiva del trabajo para analizar y
mejorar los procesos realizados.
Página 12
Estado del arte de las metodologías de desarrollo ágil
Roles
Propietario del producto. Es la persona responsable de crear y priorizar la
acumulación de productos, elegir qué se incluirá en el próximo sprint y revisar el
sistema (con otras partes interesadas) al final de la iteración.
Scrum master. Conoce y refuerza la iteración, los objetivos del producto, los valores y
las prácticas de scrum. Es responsable de llevar a cabo la reunión diaria y la
demostración de la revisión escucha el progreso, elimina impedimentos (bloques) y
proporciona recursos. El scrum master también es un desarrollador y participa en el
desarrollo del proyecto.
Desarrollador, miembro del equipo scrum. El equipo scrum está comprometido a
lograr un objetivo de sprint y tiene plena autoridad para hacer lo que sea necesario
para lograr el objetivo. El tamaño de un equipo scrum es aproximadamente 7.
Scrum pone mucho menos énfasis en las prácticas de ingeniería, por lo que muchas áreas
y sectores combinan su enfoque de gestión de proyectos con las prácticas de ingeniería de
programación extrema.
4. Crystal
Alistair Cockburn ha sido durante mucho tiempo una de las principales voces de la
comunidad ágil. Desarrolló la familia Crystal de métodos de desarrollo de software como un
grupo de enfoques adaptados a equipos de diferentes tamaños. Crystal es visto como una
familia porque Alistair cree que se requieren diferentes enfoques a medida que los equipos
varían en tamaño y cambia la criticidad de los errores [28].
Crystal recibe el nombre de familia de métodos porque Cockburn cree que no hay un
proceso de desarrollo único e invariante. Se asignan a los diferentes métodos colores en una
escala de opacidad ascendente: la versión más ágil es Crystal Clear, seguida de Crystal Yellow,
Orange Crystal y Red Crystal.
El gráfico inferior se utiliza para ayudar a elegir un punto de inicio del método. El eje x
determina el tamaño del equipo de manera ascendente, lo que supone una gestión de la
comunicación cara a cara más y, por lo tanto, mayor es la necesidad de coordinación de
documentación, prácticas y herramientas. El eje y aborda el potencial del sistema para causar
daños, es decir, la criticidad. El menor impacto del daño es la pérdida de comodidad, la pérdida
de dinero discrecional, la pérdida de dinero esencial y, finalmente, la pérdida de vidas. Esta
escala se determina basándose en el equipo.
Página 14
Estado del arte de las metodologías de desarrollo ágil
humanos. Como resultado, considera que Crystal requiere menos disciplina que la
programación extrema, intercambiando menos eficiencia por una mayor habitabilidad y
menores posibilidades de fracaso.
A lo largo de los 90 Kent continuó desarrollando sus ideas en los contratos de consultoría,
destacando en particular el proyecto Chrysler C3 alrededor de 1997. A partir del desarrollo
del proyecto C3 es cuando se conoce que nace el concepto de programación extrema.
Herramientas formales
A pesar de que XP basa sus principios en la comunicación oral, hay determinados
conocimientos que deberán comunicarse a través de documentación escrita, así como el
propio código. Esta formalización de la comunicación a través de documentos también ocurre
cuando los equipos de desarrollo son sistemas grandes, son sistemas de alto riesgo o sistemas
que requieren capacidad de auditoría por razones legales o de ingeniería de confiabilidad de
software, ya que no es un procedimiento recomendado. Esta decisión permite volver a visitar
las herramientas periódicamente como parte de un proceso XP más rastreable.
Página 16
Estado del arte de las metodologías de desarrollo ágil
Ilustración 9: Detalle del Glosario y Actividad en del mapa de historia de usuarios [30]
Lista de tareas. Una lista de las tareas de uno a tres días de duración que se
construyen a partir de las historias de usuario y que se completará en cada
iteración.
Pruebas de aceptación del cliente. Son descripciones textuales y casos de prueba
automatizados desarrollados por el cliente. El equipo de desarrollo demuestra
la finalización de una historia de usuario y la validación de los requisitos del
cliente al pasar estos casos de prueba.
Tarjetas CRC [31] (opcionales). Son tarjetas de índice en papel en la que se
registran las responsabilidades y los colaboradores de las clases que pueden
servir como base para el diseño de software. Estos son identificados durante un
diseño sesión de lluvia de ideas / juegos de rol con múltiples desarrolladores.
CRC significa Clase-Responsabilidad-Colaboración.
Página 18
Estado del arte de las metodologías de desarrollo ágil
Ilustración 11: Ejemplos de gráficas de información útil: test de aceptación del cliente; gráfica de velocidad;
tipo de tareas realizadas por sprint; procesos del equipo [33]
Roles
Manager. Es responsable del equipo y sus problemas. Forma el equipo, obtiene
recursos, administra personas y problemas e interactúa con grupos externos.
Coach. Es la persona encargada de enseñar a los miembros del equipo el
funcionamiento del proceso de XP según sea necesario. Interviene en caso de
que surjan problemas; supervisa si se está siguiendo el proceso. Su perfil es
típicamente de programador y no de gerente.
Rastreador. Recopila regularmente la historia del usuario y el progreso del caso
de prueba de aceptación de los desarrolladores para crear los gráficos del muro
visible. El rastreador es un programador.
Programador. Escribe código, diseña y determina pruebas; identifica y estima
tareas e historias.
Evaluador. Ayuda a los clientes a escribir y desarrollar pruebas. Esta persona
también puede ser un programador.
Cliente. Escribe historias y pruebas de aceptación; recoge las historias para un
lanzamiento y para una iteración.
La producción Lean fue una inspiración para muchos de los primeros agilistas, siendo los
Poppendieck los más notables al describir cómo interactúan estas ideas, siendo, además,
quienes aplicaron el término lean al desarrollo de software y su asociación a los valores ágiles,
y lo popularizaron. [34]
Al igual que la metodología ‘Just in time’ (JIT) de Toyota, los Poppendieck también hacen
hincapié en la eliminación de desperdicios, eliminar la burocracia en el desarrollo de
productos, fomentar el aprendizaje por ciclos cortos y frecuentes, iteraciones rápidas, etc. El
principal resultado es la obtención de una retroalimentación que ‘tira’ del producto y no se
estanca en documentación y requisitos estrictos que lideren el desarrollo general.
En el libro, “Lean Software Development” Mary y Tom también destacan los siete
principios del desarrollo de software lean, así como un conjunto de 22 instrumentos y
herramientas y las comparaciones con otras prácticas ágiles
Optimizar el todo
Eliminar desperdicios
Calidad en la construcción
Aprender constantemente
Entregar rápido
Involucrar a todo el mundo
Seguir mejorando
Página 20
Estado del arte de las metodologías de desarrollo ágil
Kanban
Kanban es una palabra japonesa que tiene un significado parecido a ‘tarjetas visuales’ y
es también el nombre que recibe la técnica creada en Toyota para controlar el avance del
trabajo en el contexto de una línea de producción. Su objetivo es gestionar las tareas para
obtener una mejora garantizada. [35]
Esta herramienta JIT ha sido trasladada al desarrollo de software junto con la filosofía
Lean y sus principales reglas son:
Visualizar el trabajo y las fases del ciclo de producción/flujo de trabajo.
Determinar el límite de los trabajos en curso.
Medir el tiempo necesario para cumplimentar una tarea.
El inicio de esta herramienta comienza con la división del trabajo en partes, hecho que
también ocurre en la metodología Scrum, y la generación de una pizarra/tablero donde
visualizar de estas tareas. El tablero deberá tener tantas columnas como fases tenga el ciclo
de producción, mientras que las tarjetas de tareas deben contener cierta información como
descripción y duración de la tarea. Las tarjetas irán ‘pegándose’ y moviéndose a través de
estas columnas conforme avanza el proyecto y se completan las fases.
Ilustración 12: Ejemplo de tablero Kanban realizado con la herramienta kanbanize [36]
De esta forma la visualización del proyecto ayuda de forma clara a determinar el estado
de la producción.
7. El manifiesto ágil
Diecisiete críticos de desarrollo de software de procesos se reunieron el 12 de febrero
de 2001 en Snowbird, Utah, para la búsqueda de una mejora de las técnicas y procesos en
dichos procesos de desarrollo [15]. Este conjunto se considera como la alianza ágil.
Fue en aquel momento dicha alianza documentó su declaración de valor de la siguiente
manera:
‘Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando
a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
Es decir, mientras hay valor en los elementos de la derecha, valoramos los elementos de
la izquierda más.’
Valorar más a los individuos y sus interacciones que a los procesos y las herramientas
Para la filosofía ágil el conocimiento y la aportación que las personas dan al proceso de
desarrollo son primordiales. Los procesos, técnicas, herramientas son una guía que mejoran
la eficiencia, pero sin la contribución del equipo no se producen resultados.
Las técnicas y metodologías son las que han de adaptarse al equipo humano y sus
características, no viceversa.
Página 22
Estado del arte de las metodologías de desarrollo ágil
Página 24
Estado del arte de las metodologías de desarrollo ágil
Ilustración 14: Método de desarrollo primario utilizado en la organización de proyectos 2017. [38]
Ilustración 15: Experiencia y adopción de las metodologías Agiles en la empresa 2019. [40]
Página 26
Estado del arte de las metodologías de desarrollo ágil
Martin Fowler menciona específicamente Scrum porque desde su punto de vista es bajo
este marco de trabajo dónde más a menudo ha observado este fenómeno. Esta situación se
ve agravada por el hecho de que Scrum es un proceso que se centra en las técnicas de gestión
de proyectos y omite deliberadamente cualquier práctica técnica en contraste con Extreme
Programming, por ejemplo.
Recientes estudios [47] confirman que las tendencias en cuanto a metodologías
empleadas han cambiado en los últimos veinte años. En sus inicios, la década de 1999-2009,
las prácticas de Programación Extrema se encontraban entre las diez prácticas ágiles más
utilizadas. En los últimos años 2010-2016 Scrum se encuentra en el centro de las
implementaciones de desarrollo de software ágil y sus prácticas son las más extendidas en los
proyectos de software.
Como respuesta al “Flaccid Agile” surge en los últimos años el movimiento de software
Craftmanship o de artesanía del software [49], que ha llegado incluso a tener su propio
manifiesto [50]. Esta iniciativa enfatiza en las habilidades técnicas de generar código de
calidad por parte de los propios desarrolladores de software, además de promover un código
ético para programadores [51].
Para Robert Martin, defensor del movimiento de la artesanía del software, la agilidad tal
y como se conoce hoy no es el mismo concepto que se discutió en la famosa reunión en Utah.
Ha habido un cambio de enfoque hacia los negocios que se posiciona más lejos de la
tecnología, aspecto que se consideró fundamental en la reunión.
Página 28
Estado del arte de las metodologías de desarrollo ágil
Una variante especialmente llamativa es Scaled Agile Framework o SAFe. Este modelo
de gestión que se apoya en XP y Scrum como marco de trabajo a nivel del equipo de desarrollo,
añade una serie de capas de burocracia, en la cual el cliente está casi totalmente ausente.
Este modelo, que está cada día más extendido en las grandes empresas, ofrece a la
administración la potestad de llamarse ágil y seguir haciendo lo que siempre ha hecho.
Esencialmente, subordina a los equipos ágiles a la burocracia, en lugar de hacer lo necesario
para lograr la agilidad empresarial, es decir, transformar los grandes sistemas monolíticos
enfocados internamente en arreglos donde los presupuestos, recursos humanos, finanzas,
etc. sean flexibles y enfocados activamente en apoyo a los equipos ágiles.
Esta opinión está bastante extendida y es respaldada por un número cada vez mayor de líderes
de pensamiento ágil [37] [43].
Esta noción iría más allá con otro principio del manifiesto: "A intervalos regulares, el
equipo reflexiona sobre cómo volverse más efectivo, luego ajusta y ajusta su comportamiento
en consecuencia". No solo un equipo debe elegir su propio proceso, el equipo debe controlar
cómo evoluciona ese proceso.
Página 30
Estado del arte de las metodologías de desarrollo ágil
Actualmente, las tres entidades certificadoras más reconocidas a nivel profesional y, por
ende, más expandidas son Professional Scrum Master (PSM) de Scrum.org, Certified Scrum
Master (CSM) de Scrum Alliance y Agile Certified Professional (PMI-ACP) de PMI.
Las dos primeras tienen su origen en la misma persona, Ken Schwaber. Ken es uno de los
creadores de Scrum que, junto con Jeff Sutherland, definió las versiones iniciales de Scrum
presentadas por ambos formalmente en la OOPSLA del 95. Juntos crearon también la
organización Scrum Alliance en la que comenzaron a legitimar profesionales de Scrum con la
certificación CSM.
En 2010 Ken decide dejar la Scrum Alliance y fundar el instituto scrum.org para orientarlo
hacia el objetivo de divulgar Scrum. Desde este nuevo instituto (scrum.org) se comenzaron a
entregar las certificaciones PSM.
Desde 2012 surge un nuevo competidor en liza, la certificación PMI-ACP que, gracias al
prestigio histórico de otra de las certificaciones de la misma entidad: la certificación PMP-PMI,
está muy bien considerada en el mundo empresarial.
Kent Beck ha expresado públicamente su malestar con las certificaciones tal y como las
conocemos [56], dudando de los conocimientos o aptitudes que se puedan adquirir o
demostrar mediante este proceso. Kent alude además a la responsabilidad de la entidad
certificadora que, para mantener la credibilidad y reputación de la acreditación, debería
asegurarse de que cada candidato es apto y merece dicho certificado [29].
En opinión de Martin Fowler [57], para que una certificación resulte útil, necesita
necesariamente una correlación con la competencia en lo que certifica. Martin apunta que en
la mayoría de los casos él no ha visto esta relación, y lo que es peor, incluso ha encontrado
casos en los que la correlación sería negativa.
La situación actual es que los esquemas de certificación, incluso los útiles, son propensos
a la mercantilización. Si puede obtener reconocimiento por un diploma de certificación, existe
una buena oportunidad de lucrarse: cursos, evaluaciones, libros, etc. Lamentablemente, no
parece haber mucha correlación entre la capacidad de ganar dinero de una certificación y su
utilidad. Este es un problema común, no solo en la industria del software, que la certificación
se ha convertido en una industria en sí misma. Fomentando la proliferación de exámenes y
calificaciones que, cada vez más, están ahí para ayudar a los márgenes de ganancia de las
empresas de certificación y pruebas.
Surge entonces el debate ¿Es razonable que una persona competente obtenga una
certificación inútil? la realidad es que una certificación a menudo se usa como una puerta de
entrada en un proceso de selección, incluso si es deficiente. Como resultado, las personas
competentes a menudo necesitan una certificación inútil para obtener una entrevista. Se
podría argumentar que esto hace que la certificación sea interesante, al menos desde el punto
de vista económico, puesto que puede ofrecer oportunidades laborales, pero esto sería
completamente al margen la correlación de competencia.
Kent recomienda como modelo de certificación el utilizado por La Leche League [58],
similar al propuesto por Dave Snowden en Cynefin [59]. Según este modelo tanto el
acreditado como la entidad son responsables de su comportamiento. La acreditación sería
una forma de informar de que aquello se sostiene en el currículum es cierto y que la persona
en cuestión está alineada con los principios y prácticas de la organización certificadora.
Página 32
Estado del arte de las metodologías de desarrollo ágil
En este caso concreto, para formar parte de la organización deberías ser invitado por un
miembro en primer lugar. Tanto este anfitrión como una tercera persona evaluadora deben
asegurar que el candidato posee los conocimientos y habilidades necesarias.
El proceso de evaluación incluye:
Evaluación de los conocimientos técnicos, sociales y organizacionales del
candidato para desempeñar su labor.
Acompañamiento del candidato en su desempeño y critica de sus actuaciones.
Revisión de un documento
Interacción social con otros miembros.
Ser introducido públicamente al resto del grupo en una conferencia regional.
Acompañamiento y soporte.
Puede ser posible crear un programa de certificación que realmente se relacione con la
competencia, pero el ámbito de las certificaciones todavía tiene problemas particulares para
los métodos ágiles.
En un proceso impulsado por un plan, es decir, un desarrollo que ha sido previamente
planificado, el punto es que la conformidad con el proceso es esencial. Por lo tanto, un
esquema de certificación puede probar que un equipo o una organización hace un buen
trabajo de conformidad con un proceso definido. Sin embargo, en un mundo ágil, cada
proceso sigue la autoadaptación, es decir, se espera que el equipo modifique el proceso para
adaptarlo a sus condiciones locales conforme se desarrolla el software. Esto hace que
cualquier certificación sea mucho más difícil de diseñar [31].
Lo que denuncian los impulsores y firmantes del manifiesto es que la tendencia actual
es adoptar de forma estricta alguna de estas metodologías o un conjunto de ellas para
ajustarse perfectamente a aquello que predica o bien el manifiesto o lo que establece una
metodología concreta. Esta rigidez conlleva la contradicción de los fundamentos de la agilidad.
La constante iteración y adaptabilidad en los procesos y software ágiles son el
fundamento que el colectivo ha olvidado según Hunt. Esto se debe a que las personas que se
inician en el desarrollo tienden a seguir fielmente reglas libres de contexto y ciertos métodos
relacionados con la agilidad para intentar dominarla. En lugar de seguir la metodología ágil a
ciegas, debería analizarse las necesidades de cada uno en particular para ajustar
posteriormente el método [60].
Distintos firmantes han bautizado de diferente manera esta inquietud con respecto a la
adulteración de la agilidad que se está llevando a cabo hoy día: Martin Fowler lo llama “Dark
Agile”, “Faux Agile” según Ron Jeffries [16].
Andy Hunt cita a la Dra. Patricia Benner [43], autora de From Novice to Expert, como la
mejor definición que capta el espíritu ágil cuando habla sobre la naturaleza de cómo capacitar
a las personas en las diferentes prácticas existentes: “Las prácticas nunca pueden objetivarse
o formalizarse por completo, ya que siempre deben elaborarse de nuevo en relaciones
particulares y en situaciones reales.” [61].
El mensaje que Andy Hunt valora de Benner es el alejamiento de las formalizaciones, ya
que, tanto el desarrollo ágil como sus prácticas deben evolucionar para satisfacer necesidades
específicas en circunstancias específicas (contexto).
Para ilustrar este fenómeno P. Kruchten utiliza a modo de ejemplo una analogía de
definición de una carretera [63]. Según sus palabras podríamos tratar de definir una carretera
como algo compuesto de rocas trituradas y alquitrán. O como una superficie que es más negra
que blanca, más lisa que ondulada… O bien se podría definir una carretera como un
componente de un sistema de transporte que permite a los vehículos circular de un punto a
otro. Según sus palabas, las propiedades y los componentes de dicha carretera deberían
emanar de esta tercera definición, permitiendo así nuevas y novedosas soluciones en el diseño
y ejecución.
Página 34
Estado del arte de las metodologías de desarrollo ágil
reduzca la tendencia a alargar la duración de la reunión. Para James lo que suele suceder en
esta ceremonia es que, tras una breve introducción y algún anuncio por parte del responsable,
se realizan una serie de interacciones entre este y algún miembro del equipo, en la que se
abordan sistemáticamente tres preguntas: ¿Qué se ha hecho desde la última daily? ¿Qué hay
planeado hasta la próxima? ¿Qué impedimentos se han encontrado? El problema es que en
estas conversaciones solo estarían involucradas dos personas, el resto del equipo suele dejar
de escuchar esperando su turno o, en el peor de los casos, si tienen el ordenador, prestan
atención a otros asuntos.
Este ritual en el que los miembros del equipo reportan individualmente al responsable
del equipo el estado de las tareas estaría muy alejado del propósito del que pretende
satisfacer esta práctica. Lo que sucede además es que los responsables, que conducen la
reunión sin saber muy bien por qué la realizan, esperan que esto haga crecer la productividad
del equipo. Tom de Marco advierte en su libro Peopleware que este tipo de reuniones cortas,
ampliamente expandidas, pueden llegar a ser un obstáculo para la efectividad de la
organización si carecen de propósito y enfoque [64].
Página 36
Estado del arte de las metodologías de desarrollo ágil
Ilustración 19: Portada de la conferencia NATO sobre ingeniería del software [67]
La icónica representación que ilustra el modelo de cascada apareció por primera vez en
un artículo de Winston Royce en 1970 sobre problemas en la gestión de proyectos de TI de
grandes sistemas de software [11].
Esta ilustración de Winston Royce se hizo famosa como el modelo de cascada, sin
embargo, lo usó para mostrar cómo el proceso de desarrollo no está funcionando. Royce
escribe justo después de introducir el patrón: “Creo en este concepto, pero la implementación
descrita anteriormente es arriesgada e invita al fracaso”.
Además, Royce describe los efectos devastadores de este proceso que 30 años más tarde
recordaría la literatura Agile. Según sus palabras la fase de pruebas que se produce al final del
ciclo de desarrollo sería la primera ocasión en la que el producto es verificado. Si el
Página 38
Estado del arte de las metodologías de desarrollo ágil
comportamiento no encaja por cualquier circunstancia sería necesario llevar a cabo un gran
rediseño de la aplicación. En este punto el proceso de desarrollo prácticamente regresaría al
origen y se podría esperar que se duplicasen los costes y los tiempos de entrega.
Royce nunca utilizó el término “cascada”, ya que no existía un método con dicho nombre
en ese momento. El término no aparece hasta el artículo "Requisitos del software: ¿son
realmente un problema?" Por T.E. Bell y T.A. Thayer en 1976 [68].
Además, ya en 1970 Royce explicó que no se puede crear un buen software sin
iteraciones, realizar pruebas exhaustivas y recopilar comentarios de los usuarios lo antes
posible.
Página 40
Estado del arte de las metodologías de desarrollo ágil
Curiosamente, el mismo informe del Standish Group de 2015 expone una tasa de éxito
similar tanto a proyectos desarrollados con metodologías modernas, como a aquellos
desarrollados con métodos tradicionales. Teniendo los primeros un porcentaje de proyectos
fallidos sensiblemente mayor a las difamadas metodologías pesadas.
Ilustración 25: Estadísticas por tipo de proyecto – Standish Group 2015 [73]
Parafraseando a Dave Thomas [14], la práctica, por sí sola, no podría aportar agilidad,
porque la agilidad es una capacidad o característica propia de una entidad. En el caso del
desarrollo de software, un indicador del desempeño de un equipo en un proyecto.
Página 42
Estado del arte de las metodologías de desarrollo ágil
Ante estos hechos los firmantes del manifiesto aconsejan encarecidamente volver a él
como pilar fundamental. Incluso cuando paradójicamente el propio nombre del manifiesto se
ha tergiversado: actualmente se le conoce popularmente como el manifiesto ágil.
Página 44
Estado del arte de las metodologías de desarrollo ágil
CONCLUSIONES Y POSIBLES
AMPLIACIONES
1. Conclusiones
En el presente proyecto hemos visto como el movimiento ágil se ha extendido
enormemente. Sus prácticas han dejado de ser extravagantes y son ahora comunes, acogidas
o al menos adoptadas por la mayoría de los equipos de desarrollo.
Una serie de casos de éxito iniciales en las que algunos de los firmantes del manifiesto
fueron protagonistas contribuyeron a enardecer el movimiento. Este entusiasmo fue
amplificado por el “Complejo Industrial Agile”, que rápidamente convirtió en un negocio lo
que se inició como un movimiento que buscaba formas mejores de desarrollar de software.
El cambio hacia la agilidad cambió los caminos de la industria del software, marcando la
hoja de ruta de las empresas del sector. Modernizó la forma en que estamos haciendo nuestro
trabajo, pero las empresas acogen este cambio más impulsadas por la promesa de la mejora
en la eficiencia que por la creencia en los valores o en la mejora de las condiciones de los
desarrolladores. Irónicamente, como defienden sus creadores esta eficiencia no puede
lograrse en su punto más alto cuando los valores no se tienen en cuenta.
Parece que el enfoque inicial del desarrollo de software ágil se ha olvidado a lo largo del
tiempo, y el objetivo ha pasado de centrarse en convertirse en profesionales adaptables,
flexibles y ágiles a simplemente seguir un subconjunto de prácticas ágiles prescritas y
canónicas. Para muchos de los firmantes la gente ha olvidado por qué surgió este movimiento.
Los colaboradores originales enfatizan que los métodos ágiles deben ser seleccionados
cuidadosamente y que la agilidad y sus prácticas no deben verse como una bala de plata.
Subrayan la importancia de considerar la variedad de prácticas y métodos diferentes que
influyeron en el desarrollo del manifiesto. Además, mencionan que las personas deberían
cuestionar su comprensión actual de la agilidad y recomiendan reconsiderar las ideas
centrales del manifiesto.
Este estudio proporciona una introducción a la agilidad y cómo los problemas a los que
se enfrenta hoy en día la son muy diferentes a los de sus inicios. Revela la incomodidad de
algunos de los creadores y expertos con las tendencias actuales, como la certificación,
comercialización, o el dogmatismo. Destaca una mala comprensión por parte de los
practicantes, forzados a emplear la metodología o desconocedores de los valores que las
sustentan.
Por último, se exponen ciertas flaquezas en el discurso de la agilidad cómo la
generalización de la cascada, la trampa de la eficiencia, o la ausencia de definición de los
elementos que hacen que un equipo sea considerado ágil.
Con este trabajo, tratamos de retener este conocimiento para las personas que desean
aprender más sobre la opinión de los creadores del manifiesto para el desarrollo ágil de
software. La comprensión y el aprendizaje continuo es no solamente una herramienta que
aplicar al enfrentarse al desarrollo de software, sino el camino para dominar los conceptos
básicos de la agilidad.
2. Líneas futuras
El presente trabajo revela varias vías para futuras investigaciones. Entre las cuales
destacarían dos direcciones potenciales:
Por un lado, se podría investigar la influencia de la adopción de la mentalidad
ágil en el grado de éxito de los proyectos a nivel internacional. Esta dirección
viene motivada del hecho de que las encuestas y estudios encontrados
provienen en su mayoría de empresas de consultoría privadas.
No se ha encontrado ningún análisis realizado por una organización
independiente, que ratifique el grado de adopción de unas metodologías frente
a otras y que mida el impacto de estas en el éxito de los proyectos.
Sería necesario investigar, solicitando datos de empresas del sector, el grado de
adopción de las metodologías, la satisfacción de los clientes y de todos los
actores involucrados en el proceso de desarrollo.
Por otro lado, asumiendo los beneficios de las prácticas del desarrollo ágil, se
propone desarrollar un plan de estudios para acercar la enseñanza actual de
ingeniería del software a la filosofía de la agilidad. Este trabajo vendría motivado
por la constatación de varios de los firmantes del manifiesto de que la agilidad
se está aplicando de forma incorrecta.
Con la idea de subsanar en la medida de lo posible esta situación se pretendería
incorporar los preceptos de la agilidad desde el comienzo de la carrera del
programador, en este caso en los estudios de ingeniería informática.
Se buscaría que el estudiante pudiera interiorizar durante su periodo formativo
conceptos agiles en la forma en la se imparten y evalúan todas las asignaturas y
no como una única asignatura de metodologías de desarrollo del software.
El plan de estudios debería establecer los mecanismos para que la formación y
evaluación recibida fuese iterativa e incremental, revisable y adaptable y donde
el trabajo del alumno es realizado mediante la colaboración en equipos
autoorganizados, e inmersos en un proceso compartido de toma de decisiones.
Página 46
Estado del arte de las metodologías de desarrollo ágil
Referencias
[1] B. Boehm, «Get Ready for Agile Methods with Care,» IEEE Computer, vol. 35,
nº 1, pp. 64-69, 2002.
[2] J. Highsmith, Agile Software Development Ecosystems, Addison-Wesley,
2002.
[3] B. W. Boehm, «A Spiral Model of Software Development and
Enhancement,» IEEE, vol. 21, nº 5, pp. 61-72, 1988.
[4] B. Boehm, Software Engineering Economics, Prentice Hall, 1981, pp. 4-21.
[5] V. R. Basili y A. J. Turner, «Iterative Enhancement: A Practical Technique for
Software Development,» IEEE Transactions on Software Engineering, vol. 1, nº
4, pp. 266-270, 1975.
[6] R. Fairley, Software Engineering Concepts, McGraw-Hill, 1985.
[7] C. Larman, Agile and Iterative Development: A Manager's Guide, Addison
Wesley, 2004.
[8] C. Larman y V. Basili, «A History of Iterative and Incremental
Development,» IEEE Computer, vol. 36, nº 6, pp. 47-56, 2003.
[9] L. Williams y A. Cockburn, «Special Issue on Agile Methods,» IEEE
Computer, vol. 36, nº 3, 2003.
[10] C. Larman y V. Basili, «Iterative and incremental developments. a brief
history,» IEEE, vol. 36, nº 6, pp. 47-56, 2003.
[11] W. W. Royce, «Managing the development of large Software Systems,»
IEEE WESCON Proceedings, pp. 1-9, 1970.
[12] W. Swartout y R. Balzer, «On the inevitable intertwining of specification and
implementation,» Communications of the ACM, vol. 25, nº 7, pp. 438-440, 1982.
[13] G. Booch, Software Engineering with ADA, Addison Wesley Longman, 1983.
[14] D. Thomas, Agile is dead, long live agility,
https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html, 2014.
[15] K. Beck, M. Beedle, A. v. Bennekum, A. Cockburn, W. Cunningham, M.
Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C.
Martin, S. Mellor, K. Schwaber, J. Sutherland y D. Thomas, «Manifesto for Agile
Software Development,» 2001. [En línea]. Available: https://agilemanifesto.org/.
[16] R. Jeffries, Developers Should Abandon Agile,
https://ronjeffries.com/articles/018-01ff/abandon-1/, 2018.
[17] B. Curtis, «Three Problems Overcome with Behavioral Models of the
Software Development Process,» International Conference on Software
Engineering, Pittsburg, pp. 398-399, 1989.
[18] H. Kniberg, Agile @LEGO, Uppsala: https://blog.crisp.se/wp-
content/uploads/2016/03/[email protected], 2016.
Página 48
Estado del arte de las metodologías de desarrollo ágil
Página 50
Estado del arte de las metodologías de desarrollo ágil
Página 52