3

Apunte 3

Conceptos Fundamentales del

Desarrollo Ágil de Software

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
51
1. Introducción

En la actualidad, muchas organizaciones operan en entornos altamente dinámicos que

experimentan cambios constantes. Para mantenerse competitivas, estas organizaciones deben ser
flexibles y capaces de adaptarse rápidamente a nuevos desafíos y oportunidades. Esto implica que
tanto los procesos de producción de bienes y servicios como la estrategia de comercialización deben
evolucionar y mejorarse de manera frecuente. En este contexto, resulta claro que el desarrollo de
software también debe estar en sintonía con estos procesos cambiantes.

En situaciones como estas, es una ilusión pensar en una planificación inicial que se mantenga
estable durante largos periodos de tiempo, ya sea meses o incluso años, que pueden abarcar un
proceso de desarrollo. Surge entonces la necesidad de explorar nuevos modelos que permitan llevar
a cabo proyectos de software exitosos en este tipo de escenarios.

En lugar de seguir un enfoque rígido y predecible, es necesario adoptar metodologías ágiles que
fomenten la flexibilidad, la adaptabilidad y la entrega temprana de valor. Los métodos ágiles
permiten responder de manera rápida a los cambios y ajustar el enfoque a medida que se van
adquiriendo nuevos conocimientos y se comprenden mejor las necesidades del cliente.

Asimismo, es fundamental adoptar una mentalidad de mejora continua y aprendizaje. A través

de ciclos iterativos y feedback constante, se puede adaptar el desarrollo de software a medida que
se avanza y se obtienen nuevos aprendizajes. Esto permite maximizar el valor entregado al cliente
y mantenerse en sintonía con los cambios del entorno.

Los modelos de desarrollo ágil se han desarrollado como una respuesta a los desafíos
mencionados, permitiendo la producción rápida de software útil y de calidad en períodos de tiempo
más cortos. Estos modelos se basan en la idea de que el software no se desarrolla como una única
entidad completa, sino como una serie de incrementos que agregan gradualmente nuevas
funcionalidades a una aplicación que ya está en funcionamiento, pero también en constante
evolución.

El desarrollo ágil se lleva a cabo mediante equipos reducidos de profesionales altamente

capacitados, que comparten inicialmente la visión general del producto o servicio que se pretende
implementar. A partir de esta visión, se van realizando pequeños incrementos de acuerdo con las
prioridades establecidas por el cliente. Estos incrementos se ejecutan en ciclos breves de desarrollo
conocidos como iteraciones o sprints.

Cada iteración del ciclo de vida del desarrollo ágil incluye una serie de etapas, tales como
planificación, análisis de requerimientos, diseño, codificación, revisión, implementación y
documentación. Sin embargo, es importante destacar que estas tareas no se llevan a cabo con la
misma formalidad que se requiere en los modelos tradicionales.

En lugar de seguir rigurosamente una secuencia lineal y rígida, los equipos ágiles adoptan un
enfoque más flexible y adaptable. Las tareas se llevan a cabo de manera colaborativa y se prioriza
la comunicación y la entrega temprana de valor. Las iteraciones permiten obtener rápidamente
resultados tangibles y retroalimentación del cliente, lo que facilita la adaptación y mejora continua
del producto.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
52
 Los requerimientos del cliente se recopilan y se les asignan prioridades, quedando en espera.
En cada iteración, no es necesario que se agregue una gran cantidad de funcionalidades para
justificar lo que en los enfoques tradicionales de desarrollo evolutivo podría considerarse una nueva
versión. En cambio, se seleccionan las funcionalidades que pueden ser programadas e
implementadas dentro de los cortos plazos del sprint. El objetivo es tener un producto
constantemente operativo y en continua mejora.

Al concluir cada iteración, el equipo revisa nuevamente los requerimientos pendientes y

toma decisiones sobre qué funcionalidades se incluirán en el siguiente sprint. Este ciclo iterativo se
repite hasta que se determine que el producto no necesita más evolución. Durante esta evaluación
periódica de los requerimientos, se tienen en cuenta factores como la prioridad de los elementos
pendientes, la retroalimentación del cliente y otros criterios relevantes. El equipo busca maximizar
el valor entregado en cada sprint y asegurarse de que el producto siga evolucionando de manera
efectiva.

2. Modelos Tradicionales versus Ágiles

Es frecuente escuchar que los modelos tradicionales son considerados lentos, pesados y
burocráticos, mientras que los modelos ágiles son percibidos como rápidos y livianos. Esta
afirmación es válida en cierta medida, ya que los modelos tradicionales pueden resultar ineficientes
en entornos que experimentan cambios constantes. Sin embargo, es importante señalar que no
todas las organizaciones operan en escenarios dinámicos y que no todas las empresas tienen
procesos internos que se orienten hacia la flexibilidad.

Existen situaciones en las que los desarrollos de software requieren un análisis exhaustivo del
sistema y la entrega de un producto completo. Por ejemplo, los sistemas críticos que gestionan
maquinaria o vehículos autónomos, así como los sistemas bancarios17 que necesitan garantizar altos
niveles de seguridad. En estos casos, es necesario realizar un análisis detallado y meticuloso del
sistema, teniendo en cuenta los riesgos y las regulaciones aplicables.

Si bien los modelos ágiles son altamente efectivos en contextos cambiantes y permiten una
entrega rápida y continua de software, no son la solución ideal en todos los escenarios. Cada
enfoque tiene sus ventajas y desventajas, y es importante seleccionar el modelo más adecuado
según las necesidades y características específicas de cada proyecto.

Podríamos entonces afirmar que ambos modelos tienen diferente utilidad y aplicación conforme
el tipo de organización, el tipo de sistema y el escenario en los que se aplique. En todo caso los
problemas pueden aparecer si se trata de usar metodologías tradicionales en escenarios cambiantes

17
Actualmente, los bancos utilizan prioritariamente modelos ágiles para el desarrollo de sus aplicaciones. Sin embargo,
estos modelos ágiles son reservados para sus Apps y sistemas de banca on-line, que justamente enfrentan escenarios
cambiantes. A la hora de modificar sus sistemas centrales o “core”, que gestionan operaciones críticas y sensibles, como
el procesamiento de transacciones, la seguridad y el cumplimiento normativo, los bancos suelen adoptar prácticas de
desarrollo más tradicionales y rigurosas, que incluyen análisis exhaustivos, pruebas rigurosas y una mayor planificación.
Esto se debe a la necesidad de garantizar la estabilidad y la seguridad de los sistemas centrales, así como el cumplimiento
de regulaciones y estándares exigentes.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
53
o intentar un desarrollo ágil en una empresa con procesos formales18.A modo de resumen
podríamos analizar el siguiente cuadro:

Modelos Tradicionales Modelos Ágiles

Útiles para organizaciones que operan en Útiles para organizaciones que operan en
entornos estables y con normas y procesos entornos cambiantes, con procesos flexibles
definidos. También para software con y donde se privilegia tener un software
funcionalidades críticas o alta seguridad. siempre listo y con posibilidad de cambios.
Requisitos definidos al inicio. No existe una especificación inicial detallada
del sistema.
Sin posibilidad de cambios. Los cambios son frecuentes conforme se
avanza con el desarrollo.
El sistema se entrega en forma completa (o, El sistema está en siempre en desarrollo. Se
en modelos incrementales, en sucesivas incorporan permanentemente nuevas
versiones completas). funcionalidades al que ya está funcionando.
El usuario no forma parte del equipo de El usuario participa activamente durante
desarrollo. Solo toma contacto con el sistema todo el proceso de desarrollo y puede ser
cuando lo recibe para las pruebas finales. parte del equipo de desarrollo.
El usuario de adapta al sistema El sistema de adapta al contexto

3. El “Manifiesto Ágil”

El "Manifiesto Ágil"19. es un documento fundamental que aborda técnicas y procesos para el

desarrollo de software. Fue redactado en febrero de 2001 en la ciudad de Utah, Estados Unidos, por
Kent Beck y otros 16 desarrolladores expertos en programación, quienes eran críticos de los
enfoques tradicionales. En este manifiesto se establecen cuatro valores y doce principios que
conforman la filosofía de los métodos ágiles. A partir de estos valores y principios, se han
desarrollado diversos modelos de desarrollo ágil de software

Valores del manifiesto Ágil

Los autores del manifiesto destacan que “Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo
hemos aprendido a valorar:”

• Individuos e interacciones sobre procesos y herramientas

18
Puede ampliarse esta comparación en el apunte “Conceptos Fundamentales del Desarrollo de Software Dirigido por
un Plan”. También el capítulo 3 del libro “Ingeniería de Software” 9na Ed. de Ian Sommerville tratan estos puntos con
mayor profundidad.

19
https://agilemanifesto.org/iso/es/manifesto.html

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
54
 Se valora el recurso humano como el principal factor de éxito. Contar con un equipo de
trabajo capacitado da mayor garantía de éxito por sobre priorizar herramientas y procesos
rigurosos. Se buscan recursos humanos que provean:

▪ Alta capacidad técnica.

▪ Compromiso con los objetivos comunes.
▪ Habilidades para el trabajo en equipo.
▪ Capacidad para tomar decisiones.
▪ Capacidad de resolver problemas.
▪ Confianza y respeto mutuo.
▪ Autogestión y organización personal.

• Software funcionando sobre documentación extensiva

Se respeta la importancia de la documentación como parte del proceso. Sin embargo, las
metodologías ágiles hacen énfasis en que se deben producir los documentos estrictamente
necesarios. Los mismos deben ser cortos y limitarse a lo fundamental.

• Colaboración con el cliente sobre negociación contractual

El cliente es parte del equipo de trabajo. Es un ingrediente más en el camino al éxito en un
proyecto de desarrollo de software. La participación del cliente debe ser constante, desde el
comienzo hasta la culminación del proyecto, y su interacción con el equipo de desarrollo, de
excelente calidad.

• Respuesta ante el cambio sobre seguir un plan

En entornos cambiantes y por la dinámica de la tecnología, un proyecto de desarrollo de
software se enfrenta a frecuentes modificaciones durante su ejecución. La planificación no
debe ser estricta, puesto que hay muchas variables en juego, sino que debe ser flexible para
poder adaptarse a las nuevas necesidades que puedan surgir.

Principios que rigen el desarrollo ágil

1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua

de software de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos
ágiles se doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un
par de meses, con preferencia en los períodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana en
el proyecto.

5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el

respaldo que necesitan, y procurándoles confianza para que realicen la tarea.

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un

equipo de desarrollo es mediante la conversación cara a cara.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
55
 7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores

y usuarios deben mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica enaltece la agilidad.

10. Es esencial la simplicidad como arte de maximizar la cantidad de trabajo que se hace.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su
conducta en consecuencia.

4. Programación Extrema

La programación extrema (Extreme Programming, XP) es un método ágil ampliamente

adoptado que engloba un conjunto de prácticas de programación efectivas. Esta metodología se
destaca por su enfoque en las liberaciones frecuentes del software, la mejora continua y la
participación activa del cliente en el equipo de desarrollo. XP se centra en potenciar las relaciones
interpersonales como un factor clave para el éxito en el desarrollo de software, promoviendo el
trabajo en equipo, fomentando el aprendizaje de los desarrolladores y creando un ambiente de
trabajo positivo. El término "Extreme Programming" fue acuñado por Kent Beck en el año 2000.

Valores de XP

Los valores en los cuales se afianza la programación extrema son:

• Simplicidad: La simplicidad es la base de XP. Se simplifica el diseño para agilizar el desarrollo

y facilitar el entendimiento. Un diseño complejo del código, junto a sucesivas modificaciones
por parte de diferentes desarrolladores, hace que la complejidad aumente. En ciertas
ocasiones, incluso, se puede tornar necesaria la refactorización del código para hacerlo más
simple.

• Comunicación: La comunicación es fundamental, dentro del equipo de trabajo y con el

cliente. Crea un ambiente de cooperación y unidad, que ayuda a poder aplicar los demás
valores. Al estar el cliente integrado, su opinión sobre el estado del proyecto se conoce en
tiempo real.

• Retroalimentación: Realimentación concreta y frecuente del cliente, del equipo y de los

usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.

• Corajey valentía: Muchas de las prácticas implican coraje valentía. Una de ellas es programar
para hoy y no para mañana. La valentía permite a los programadores sentirse cómodos con
reconstruir su código cuando sea necesario. Otro ejemplo es saber cuándo desechar código

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
56
 obsoleto, sin importar cuanto costo y esfuerzo llevó hacerlo. Valentía significa persistencia,
un programador puede encontrarse estancado en un problema complejo por mucho tiempo
y luego lo resolverá rápidamente solo si es persistente.

• Respeto: Si no hay respeto y aprecio entre el equipo, XP no se puede aplicar efectivamente

el modelo.

Prácticas de XP

La programación extrema incluye una serie de prácticas las cuales reflejan los principios de
los métodos ágiles:

• Planeación del incremento: Los requerimientos se registran en tarjetas de historia (story

cards). Las historias que se van a incluir en la próxima liberación se determinan por el tiempo
disponible y la prioridad relativa.

• Liberaciones pequeñas: Al principio, se desarrolla el conjunto mínimo de funcionalidad útil

que ofrece valor para el negocio. Las liberaciones del sistema son frecuentes y agregan
incrementalmente funcionalidad a la primera liberación.

• Diseño simple: Se realiza un diseño solo suficiente para cubrir aquellos requerimientos
actuales.

• Desarrollo de la primera prueba: Las pruebas de unidad (para probar el funcionamiento del
módulo de modo aislado del resto) son frecuentes y continuas. Se aconseja escribir el código
de la prueba antes de la codificación de modo que sirva como un marco de referencia de
prueba de unidad automatizada.

• Refactorización: Se espera que todos los desarrolladores refactoricen de manera continua

el código, tan pronto como sea posible y se encuentren mejoras de éste. Lo anterior conserva
el código simple y mantenible.

• Programación en pares: Los desarrolladores trabajan en pares, y cada uno comprueba el

trabajo del otro; además, ofrecen apoyo para que se realice siempre un buen trabajo.

• Propiedad colectiva: Los desarrolladores en pares laboran en todas las áreas del sistema.
Todos los programadores se responsabilizan por el código, de modo que no se generen “islas
de experiencia”. Cualquiera puede cambiar cualquier función.

• Integración continua: Tan pronto como esté completa una tarea, se integra en todo el
sistema. Después de tal integración, deben probarse todas las pruebas de unidad y de
integración en el sistema.

• Ritmo sustentable: Grandes cantidades de tiempo extra no se consideran aceptables, pues

el efecto neto de este tiempo libre con frecuencia es reducir la calidad del código y la
productividad de término medio.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
57
 • Cliente en sitio: Un representante del usuario final del sistema (el cliente) tiene que disponer
de tiempo completo para formar parte del equipo XP. En un proceso de programación
extrema, el cliente es miembro del equipo de desarrollo y responsable de llevar los
requerimientos del sistema al grupo para su implementación.

Roles en XP

• Entrenador (Coach). Es la persona que conoce a fondo el proceso XP y el responsable

del proceso global. Debe proveer guía a todos los miembros del equipo para que el
proceso sea satisfactorio.

• Programador: Es quien escribe las pruebas unitarias y produce el código del sistema.
Debe existir una comunicación y coordinación adecuada entre los programadores y
otros miembros del equipo.

• Cliente: Encargado de escribir las historias de usuario y las pruebas funcionales para
validar su implementación. Además, es quien asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en aportar
mayor valor al negocio. El cliente es solo uno dentro del proyecto, pero puede
corresponder a un interlocutor que está representando a varias personas que se verán
afectadas por el sistema.

• Encargado de pruebas (Tester): Ayuda al cliente a diseñar las pruebas funcionales, de

ejecutarlas y de brindar los resultados al resto del equipo.

• Encargado de seguimiento (Tracker). Es el responsable de que se cumplan las

estimaciones realizadas y de ver si los objetivos trazados en cada iteración fueron
alcanzados.

• Consultor. Es un miembro externo del equipo con un conocimiento específico en algún

tema necesario para el proyecto. Guía al equipo para resolver un problema específico.

• Gestor (Big Boss). Es quien coordina el vínculo entre clientes y programadores, el que
ayuda a que las condiciones de trabajo sean las adecuadas.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
58
Ciclo de desarrollo de la programación extrema

Los requerimientos de software se expresan en forma de escenarios, conocidos como

historias de usuario. Los clientes colaboran estrechamente con el equipo de desarrollo para definir
y priorizar estos requerimientos. Cada historia de usuario es clara y concreta y limitada, lo que
permite a los programadores implementarla en un período corto de tiempo, generalmente unas
pocas semanas.

Una vez definidas las historias de usuario, el equipo de desarrollo las desglosa en tareas y estima
los recursos y esfuerzos necesarios para llevar a cabo cada una de ellas. Los programadores trabajan
en parejas y crean pruebas para cada tarea antes de comenzar a escribir el código. Todas las pruebas
deben ejecutarse satisfactoriamente al integrar el nuevo código en el sistema.

El cliente desempeña un papel activo en el desarrollo y es responsable de definir las pruebas

necesarias para la aceptación final del software. El software se considera aceptado cuando todas las
pruebas se ejecutan exitosamente. Este punto se convierte en la base para la siguiente iteración del
sistema, dando continuidad al proceso de desarrollo.

Las historias de usuario

Queda fuera de alcance de este trabajo analizar en profundidad como es el relevamiento

basado en historias de usuario, pero si se describirá en qué consisten estas historias a modo de
poder comprender de modo general su funcionamiento.

Básicamente, una historia de usuario es un requerimiento que tiene un determinado usuario

y que lo expresa, de modo simple, desde su perspectiva. Suelen tener el siguiente formato:

COMO <rol>
QUIERO <descripción de eventos que queremos que ocurra>
PARA <descripción de funcionalidad>

Ejemplo en un banco

COMO Oficial de atención al cliente

QUIERO Presionar una tecla y acceder a los productos que el cliente tiene contratados
PARA Ofrecerle nuevos productos

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
59
 Si se decide que la historia es pertinente, se la estima en cuanto al esfuerzo que demandará
realizarla y se priorizan para su realización. Cada vez que se termina un sprint se comienza a realizar
que tenga mayor prioridad de las pendientes.

Las historias pueden completarse con alguna descripción mayor de la funcionalidad y

también los criterios de aceptación. Por ejemplo: Primero deben mostrarse las tarjetas de débito,
luego las de crédito y por ultimo los seguros.

Ocasionalmente, alguna historia debe ser particionada en tareas más sencillas. Por ejemplo,
en el ejemplo, primero podría considerarse una historia para obtener el detalle de los productos
que posee el cliente y, en una segunda historia, ordenar estos productos y mostrarlos en pantalla.

Pruebas en XP

Una fortaleza particular de la programación extrema, antes de crear una característica del
programa, es el desarrollo de pruebas automatizadas.

Las características clave de poner a prueba en XP son:

• Desarrollo de la primera prueba: En lugar de escribir algún código y luego las pruebas para
dicho código, las pruebas se elaboran antes de escribir el código. La prueba se corre a medida
que se escribe el código, con el objetivo de descubrir errores durante el desarrollo.20

• Desarrollo de pruebas incrementales a partir de escenarios: El papel del cliente en este

proceso es ayudar a desarrollar pruebas de aceptación para las historias, que deban
implementarse en la siguiente liberación del sistema. En XP, la prueba de aceptación, como
el desarrollo, es incremental.

• Involucramiento del usuario en el desarrollo y la validación de pruebas: El cliente que

forma parte del equipo escribe pruebas conforme avanza el desarrollo. Por lo tanto, todo
código nuevo se válida para garantizar que eso sea lo que necesita. Contar con el cliente para
apoyar el desarrollo de pruebas de aceptación en ocasiones es una gran dificultad en el
proceso de pruebas XP.

• El uso de marcos de pruebas automatizadas: La automatización de las pruebas es esencial

para el desarrollo de la primera prueba. Estas se escriben como componentes ejecutables
antes de implementar la tarea. Dichos componentes de pruebas deben ser independientes,
simular el envío de la entrada a probar y verificar que el resultado cumple con la
especificación de salida. Un marco de pruebas automatizadas es un sistema que facilita la
escritura de pruebas realizables y envía una serie de pruebas para su ejecución.

Conforme se automatizan, siempre hay una serie de pruebas que se ejecutan rápida y
fácilmente. Cada vez que se agregue cualquier funcionalidad al sistema, pueden correrse las pruebas
y conocerse de inmediato los problemas que introduce el nuevo código.

20
Puede consultarse el capítulo 3 del libro “ingeniería de Software” de Ian Sommerville para ver como más detalle y
ejemplos sobre la primera prueba.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
60
Programación en pares

Otra práctica innovadora que se introdujo en XP es que los programadores trabajan en pares
para desarrollar el software. Se requiere de dos programadores que participen en un esfuerzo
combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no
está haciendo actualmente, por ejemplo, mientras uno codifica, el otro se encarga de analizarlo para
mejorarlo.

Los roles en esta técnica son el Conductor y el Acompañante. El conductor es el que

implementa el código y el acompañante tiene como tarea observar y corregir en todo momento los
errores cometidos por el conductor, considerar soluciones alternativas y sugerir nuevos casos de
prueba. Esta constante inspección produce código y un diseño de mayor calidad.

El uso de la programación en parejas tiene algunas ventajas:

• Apoya la idea de la propiedad y responsabilidad colectivas para el sistema. El software

es propiedad del equipo como un todo y los individuos no son responsables por los
problemas con el código. El equipo tiene responsabilidad colectiva para resolver dichos
problemas.

• Actúa como un proceso de revisión informal, porque al menos dos personas observan
cada línea de código. Las inspecciones y revisiones son muy eficientes para detectar un
alto porcentaje de errores de software.

• Ayuda a la refactorización, que es un proceso de mejoramiento del software.

• Enseñanza. La programación por parejas realmente mejora la distribución de

conocimiento entre el equipo de un modo sorprendentemente rápido.

• Múltiples desarrolladores contribuyen al diseño. Esto ayuda a crear mejores soluciones,

especialmente cuando una pareja no puede resolver un problema difícil.

• Mayor disciplina. Se concentran en lo que tienen que hacer en lugar de tomar largos
descansos.

Ventajas y desventajas de XP

Ventajas:

• Se adapta al desarrollo de sistemas pequeños y grandes.

• Optimiza el tiempo de desarrollo.

• Permite realizar el desarrollo del sistema en parejas para complementar los

conocimientos.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
61
 • El código es sencillo y entendible, a pesar de la poca documentación a elaborar para el
desarrollo del sistema.

Desventajas:

• No se tiene la definición del costo y el tiempo de desarrollo, nadie puede decir que el
cliente no querrá una función más.

• Se necesita de la presencia constante del usuario, lo cual, en la realidad, es muy difícil de

lograr dado que los usuarios tienen no pueden desatender sus propias tareas dentro de
la organización.
• Algunos desarrolladores son celosos del código que escriben y no les es grato que alguien
más modifique las funciones que realizó o que su código sea desechado por no cumplir
con el estándar.

• Requieren mayor cantidad de programadores entrenados, que suelen ser costosos y

difíciles de conseguir.

Para tener en cuenta

En la práctica, muchas compañías que adoptan XP pueden adaptar y personalizar las

prácticas de programación extrema según sus necesidades y preferencias. Por ejemplo, algunas
compañías encuentran beneficioso el enfoque de programación en pares, mientras que otras
prefieren utilizar programación y revisiones individuales. Para adaptarse a diferentes niveles de
habilidad, algunos programadores pueden optar por no realizar refactorizaciones en partes del
sistema que no desarrollaron, y en lugar de historias de usuario, pueden utilizar requerimientos
convencionales. Sin embargo, la mayoría de las compañías que adoptan una variante de XP siguen
principios como liberaciones pequeñas, desarrollo basado en pruebas y la práctica de integración
continua.

5. Scrum

El modelo Scrum es, quizá, el modelo más aplicado entre las organizaciones que utilizan
desarrollo ágil. A diferencia de otros modelos, este no refiere solamente a un modelo de
construcción de software, sino a metodología ágil enfocada en la gestión general de proyectos.

El proceso Scrum

El proceso de Scrum se compone de tres fases bien definidas. La primera fase es el

planeamiento del sprint (“sprint planning”, en inglés), en la cual se establecen los objetivos
generales del proyecto y se diseña la arquitectura de software. Esta etapa sienta las bases para el
desarrollo posterior del sistema.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
62
 La segunda fase es conocida como los Sprints, que consisten en una serie de ciclos de trabajo.
En cada sprint, el equipo se enfoca en desarrollar un incremento del sistema. Durante la
planificación del sprint, se seleccionan las características o funcionalidades específicas a desarrollar
y se realiza la implementación del software correspondiente. Al finalizar cada sprint, se entrega la
funcionalidad completa a los participantes.

La tercera y última fase es la Revisión del Sprint, donde el equipo realiza una evaluación
exhaustiva del sprint finalizado. Se identifican áreas de mejora y se definen acciones para el próximo
ciclo. Este proceso de revisión y mejora continua asegura que el equipo se adapte y aprenda de cada
iteración, optimizando así su desempeño.

Una vez concluida la revisión del sprint, el equipo reinicia el proceso, comenzando un
nuevo ciclo con una nueva planificación del bosquejo. De esta manera, Scrum permite un enfoque
iterativo e incremental en el desarrollo de software, promoviendo la entrega continua de valor y la
mejora constante del equipo

Las características clave de este proceso son las siguientes:

1. Los sprints tienen longitud fija, por lo general de dos a cuatro semanas. Una vez definida la
duración ideal del sprint, en función de las características del desarrollo, la misma no debe
cambiarse ya que, en cierto modo, pasan a conformar la medida del ritmo de trabajo.

2. El punto de partida para la planeación es el Product Backlog, que es la lista de trabajo

pendiente de realizar en el proyecto. Los nuevos requerimientos se van incorporando a esta
lista. Al comenzar un sprint se revisan las tareas pendientes, se priorizan y se deciden cuál o
cuáles de ellas serán desarrolladas en ese sprint.

3. La fase de selección de tareas incluye a todo el equipo del proyecto que trabaja con el cliente,
con la finalidad de priorizar y elegir las características y la funcionalidad a desarrollar.

4. Una vez seleccionadas las tareas, el equipo se organiza para desarrollar el software. Con el
objetivo de revisar el progreso y, si es necesario, volver a asignar prioridades al trabajo, se
realizan reuniones diarias breves con todos los miembros del equipo. Estas reuniones diarias
habitualmente se realizan sin sillas para que sean cortas y efectivas. Durante esta etapa, el
equipo se aísla del cliente y la organización, y todas las comunicaciones se canalizan a través
del llamado “Scrum Master”. El papel de este último es proteger al equipo de desarrollo de
distracciones externas y atender las necesidades que los miembros plantean en la reunión
diaria.

5. La forma exacta en que el trabajo se realiza puede variar y depende del problema y del
equipo.

6. Al final del sprint, el trabajo hecho se revisa y se presenta a los diferentes interesados,
continuándose con el siguiente sprint.

Roles en Scrum

Los roles de Scrum se dividen en dos categorías:

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
63
 1. Roles comprometidos directamente con el proyecto: Estos roles son los que
obligatoriamente se requieren para producir el producto o del proyecto. Dichos roles son
los responsables del éxito de cada sprint y del proyecto en sí:

• Product Owner es la persona responsable de lograr el máximo valor empresarial para

el proyecto. También es responsable de la articulación de requisitos del cliente. El
Product Owner representa la voz del cliente dentro del proyecto.

• Equipo Scrum es el grupo o equipo de personas responsables de la comprensión de

los requisitos especificados por el Product Owner, y de la creación de los entregables
del proyecto.

• Scrum Master es un facilitador que asegura que el equipo Scrum esté dotado de un
ambiente propicio para completar el proyecto con éxito. El Scrum Master guía, facilita
y les enseña las prácticas de Scrum a todos los involucrados en el proyecto; elimina
los impedimentos que encuentra el equipo; y asegura que se estén siguiendo los
procesos de Scrum.

2. Otros Roles involucrados con el proyecto: Son aquellos roles que, si bien son importantes,
no participan directamente del proceso Scrum. No siempre están presentes y no son
obligatorios, aunque en muchos proyectos desempeñan un papel muy importante y deben
ser tenidos en especialmente en cuenta. Como ejemplo, podemos nombrar a los
Stakeholder(s) (cliente, usuarios, accionistas).

Las ceremonias del Scrum

En base a lo anteriormente descripto cada Sprint estaría compuesto de 5 ceremonias o eventos:

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
64
 1. Sprint Planning o planificación inicial, con la participación de todo el equipo de desarrollo,
es donde el Product Owner presenta la versión actualizada y priorizada del Backlog, para que
el equipo pueda estimar que tareas podrán ser incluidas en el próximo sprint. Se define
entonces que se va a hacer y cómo se realizará.

2. Daily Meeting o reuniones rápidas diarias, son encuentros breves para que cada miembro
del equipo informe que tarea realizará ese día. También informará al Scrum Master si tiene
algún impedimento para que éste pueda tratar de solucionarlo.

3. Sprint Review, es la reunión final al terminar el sprint, donde el product owner y el equipo
de desarrollo presentan a los stakeholders el incremento terminado, para que lo
inspeccionen y realicen las observaciones pertinentes. No se trata de una demo, sino que se
presenta el software funcionando en producción. De esta reunión pueden surgir nuevas
necesidades que pasan a actualizar el Product Backlog.

4. Sprint Retrospective. Esta reunión, que puede realizarse en conjunto con lo anterior,
consiste en reflexionar sobre el sprint que ha finalizado, identificando posibles cosas que
puedan mejorarse. Es común analizar que salió bien, que ha fallado y que cosas podrían
hacerse de un modo más eficiente.

5. Refinamiento del Product Backlog. Esta reunión adicional permite depurar el listado de
pendiente y completar, refinar o aclarar ciertas historias de usuario que pudieron quedar
pendientes durante el Sprint Planning.

El tablero Scrum

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
65
 El tablero Scrum21 es una herramienta muy útil en la metodología Scrum, ya que permite
visualizar y gestionar el flujo de trabajo de manera efectiva. Cada columna del tablero representa
una etapa del proceso, y las tarjetas representan las historias de usuario o tareas a realizar.

En un tablero Scrum, las tarjetas se mueven a través de diferentes columnas que representan
las etapas del flujo de trabajo. Comúnmente, se utilizan las siguientes columnas: "Por hacer", "En
progreso", "Testeo" y "Terminadas". Estas columnas reflejan el ciclo típico de trabajo en Scrum.

En la columna "Por hacer", se encuentran las tareas que aún no han sido iniciadas. A medida
que un miembro del equipo comienza a trabajar en una tarea, esta se mueve a la columna "En
progreso". Una vez que la tarea está completa, se traslada a la columna "Testeo" para realizar las
pruebas necesarias. Finalmente, cuando la tarea ha pasado exitosamente las pruebas, se coloca en
la columna "Terminadas".

Es importante destacar que el tablero Scrum puede adaptarse a las necesidades específicas
del equipo y el proyecto. Se pueden agregar columnas adicionales según las etapas o actividades
que sean relevantes para el flujo de trabajo en particular. Por ejemplo, se pueden incluir columnas
como "En revisión", "En espera" o "Bloqueadas" para identificar y abordar posibles cuellos de botella
o problemas que requieren atención adicional.

La personalización del tablero Scrum permite que el equipo tenga una representación visual
clara y específica de su flujo de trabajo, lo que facilita la identificación de áreas de mejora, la gestión
de tareas y la resolución de problemas de manera más efectiva.

El tablero Scrum es una herramienta fundamental que proporciona una visualización clara
del progreso de cada tarea y facilita la sincronización diaria en las reuniones del equipo Scrum.
Permite identificar de manera rápida y sencilla las tareas que están en curso, las que están
pendientes y las que ya han sido completadas. Esto ayuda a mantener a todos los miembros del
equipo informados y al tanto del estado del proyecto. Esto facilita la colaboración y la toma de
decisiones conjuntas, ya que todos tienen acceso a la misma información actualizada.

Además, el tablero Scrum ayuda a distribuir el trabajo de manera equitativa entre los
miembros del equipo. Cuando una persona completa una tarea, puede pasar a ocuparse de la
siguiente tarea pendiente, lo que ayuda a mantener un flujo constante y evita la acumulación de
trabajo en una sola persona. Esto fomenta la colaboración y la capacidad del equipo para responder
de manera ágil a los cambios y desafíos que puedan surgir durante el proyecto.

Es importante destacar que existen herramientas informáticas que permiten crear y

gestionar tableros Scrum en línea22, lo que facilita la colaboración y el seguimiento del progreso del
proyecto por parte de todos los miembros del equipo, incluso si están trabajando de forma remota.

21
Los tableros Scrum guardan similitud con los tablero Kanban, desarrollados por Toyota para administrar su
producción en la década del 1940. Si bien fueron desarrollados en contextos diferentes (Scrum en el ámbito del
desarrollo de software y Kanban en el ámbito de la producción), ambos enfoques se centran en la gestión ágil y
promueven la transparencia, la colaboración y la adaptación.

22
En las tiendas de aplicaciones, encontrar soluciones, para generar tableros Scrum/Kanban es muy sencillo. Existen
diversas herramientas multiplataforma que permiten visualizar estos tableros tanto en la PC como en los celulares de

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
66
 Ejemplo de un tablero Scrum:

¿Por qué utilizar Scrum?

Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto son:

1. Adaptabilidad: las entregas iterativas hacen que los proyectos sean adaptables y abiertos a
la incorporación de cambios.

2. Transparencia: por medio del Tablero de Scrum se visualiza el avance de cada Sprint y, al ser
compartido, lleva a un ambiente de trabajo abierto.

3. Retroalimentación continua: se proporciona a través de las reuniones diarias y revisiones al

finalizar cada sprint.

4. Mejora continua: los entregables se mejoran progresivamente sprint por sprint a través del
proceso de priorización del Product Backlog.

5. Entrega continua de valor: los procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el cliente lo requiera.

6. Ritmo sostenible: los procesos scrum están diseñados de tal manera que las personas
involucradas pueden trabajar a un paso cómodo (ritmo sostenible) que, en teoría, se puede
continuar indefinidamente.

los miembros del equipo, muchas de ellas gratuitas Una de las herramientas más reconocidas en este ámbito es Trello
(disponible en https://trello.com/).

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
67
 7. Motivación: los procesos de reuniones diarias y retrospectivas del Sprint conducen a
mayores niveles de motivación entre los empleados.

8. Resolución rápida de problemas: la colaboración de equipos multifuncionales lleva a la

resolución de problemas con mayor rapidez.

9. Entregables efectivos: los procesos de crear la lista de Product Backlog y revisiones

periódicas después de la creación de entregables, asegura entregas efectivas para el Cliente.

Críticas a la metodología Scrum

• Complejidad de implementación: Scrum puede parecer simple en teoría, pero su

implementación efectiva puede resultar desafiante. Requiere un cambio cultural y una
adopción completa por parte del equipo y la organización, lo que puede llevar tiempo y
esfuerzo significativos.

• El equipo puede sufrir estrés pues siempre estará de sprint en sprint, inmerso en un ritmo
muy intenso de trabajo. Es saludable introducir, cada tanto, sprint que impliquen una tarea
más relajada.

• Scrum se basa en equipos autoorganizados que toman decisiones colaborativas. Esto puede
ser un desafío en entornos donde los miembros del equipo no tienen experiencia en
autogestión o no tienen la capacidad de tomar decisiones conjuntas. Ocasionalmente, el
equipo puede estar tentando a tomar el camino más corto para sumar los puntos del sprint,
sacrificando calidad o seguridad.

• Esta metodología funciona bien en proyectos más simples y menos estructurados, pero
puede tener dificultades para abordar proyectos complejos o con requisitos altamente
detallados. En tales casos, otros marcos de trabajo pueden resultar más efectivos.

• Scrum se basa en la flexibilidad y la adaptabilidad, pero puede tener dificultades para

gestionar proyectos con plazos fijos o fechas de entrega estrictas. Esto puede generar
conflictos entre las expectativas del cliente y la capacidad de respuesta del equipo Scrum. Lo
mismo ocurre con proyectos de precios cerrados por contrato. (ej. Licitaciones)

• Scrum se centra en la entrega de incrementos de trabajo en lugar de resultados finales. Esto

puede dificultar la medición precisa del progreso y la evaluación del éxito del proyecto para
las partes interesadas externas. Se requiere de un experto en la metodología que monitorice
su cumplimiento.

• Si bien Scrum presupone un alto nivel de involucramiento y participación del cliente en el

desarrollo, sus propias responsabilidades y obligaciones pueden dificultar mantener este
nivel constante de involucramiento a lo largo del tiempo.

• Muchas reuniones, por cortas que sean, pueden ocasionar pérdidas de productividad.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
68
Scrum, no solo para desarrollo de Software

Si bien es cierto que esta metodología nació para resolver problemas en el desarrollo de
software, es importante destacar que no es exclusiva de ese ámbito. En la actualidad, los modelos
ágiles de trabajo han trascendido el ámbito del software y las organizaciones los utilizan en diversos
procesos. Si bien no se aplican todas las ceremonias, artefactos y roles, las adaptaciones que se
realizan siguen la filosofía del modelo. Podemos mencionar los siguientes ejemplos:

• Marketing: Los equipos de marketing pueden aplicar metodologías ágiles para gestionar
campañas publicitarias, lanzamientos de productos o estrategias de contenido. Pueden
utilizar tableros Kanban para visualizar las tareas, asignar prioridades y hacer un seguimiento
de los plazos. También pueden realizar iteraciones rápidas y adaptar sus estrategias en
función de los resultados y la retroalimentación obtenida.

• Gestión de proyectos: Las metodologías ágiles, son ampliamente utilizadas en la gestión de

proyectos en diferentes industrias. Los equipos pueden dividir los proyectos en tareas más
pequeñas, establecer plazos realistas y realizar entregas incrementales. Esto permite una
mayor flexibilidad y adaptación a medida que se avanza en el proyecto.

• Investigación y desarrollo: Los equipos de investigación y desarrollo pueden beneficiarse de

los modelos ágiles al abordar proyectos complejos. Pueden aplicar principios como la
colaboración multidisciplinaria, la experimentación y la retroalimentación continua para
agilizar el proceso de innovación y adaptarse rápidamente a los cambios en el entorno.

• Planificación de eventos: Los equipos encargados de organizar eventos, como conferencias

o festivales, pueden utilizar una metodología ágil para gestionar las tareas, asignar
responsabilidades y hacer un seguimiento del progreso. Pueden utilizar tableros Kanban
para visualizar las etapas de planificación, asignar tarjetas a miembros del equipo y realizar
un seguimiento de las tareas pendientes, en progreso y completadas.

• Enseñanza: Los educadores pueden aplicar los principios ágiles para organizar y llevar a cabo
sus clases. Pueden utilizar metodologías como Scrum para planificar el contenido del curso,
establecer objetivos y asignar actividades a los estudiantes. También pueden utilizar tableros
visuales para gestionar el progreso de los estudiantes y adaptar el enfoque de enseñanza
según las necesidades individuales.

• Tareas del hogar: En un entorno doméstico, las metodologías ágiles se pueden aplicar para
organizar y distribuir las tareas del hogar de manera efectiva. Puedes utilizar tableros Kanban
o aplicaciones de gestión de tareas para asignar responsabilidades a los miembros de la
familia, establecer fechas límite y hacer un seguimiento del progreso de cada tarea.

Estos ejemplos demuestran que los modelos ágiles no se limitan al desarrollo de software,
sino que pueden aplicarse de manera efectiva en una amplia variedad de contextos. La clave está
en comprender los principios fundamentales de agilidad y adaptarlos de manera adecuada a cada
situación específica, aprovechando las herramientas y técnicas ágiles disponibles, como los tableros
Scrum y Kanban.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
69
6. Otras metodologías ágiles

Si bien Scrum y XP son las metodologías más utilizadas y difundidas, desde luego no son las
únicas. En todas estas metodologías los subyacen los principios del manifiesto ágil, tendiendo todas
ellas una estructura similar. Queda fuera del alcance de este apunte ahondar sobre las mismas, pero
si vale la pena al menos mencionar algunas de ellas

Metodología Crystal

Creada por Alistair Cockburn, uno de los firmantes del manifiesto ágil, se trata en verdad de
un conjunto de metodologías que proponen alternativas para diferentes tamaños de equipos de
trabajo y dificultad del proyecto, categorizándolos mediante una codificación de colores. Esta
centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la
reducción al máximo del número de artefactos producidos. El equipo de desarrollo es un factor
clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener
políticas de trabajo en equipo definidas. Dada la vital importancia a las personas que componen el
equipo de un proyecto, sus puntos de estudio son:

• Aspecto humano del equipo

• Tamaño de un equipo (número de componentes)
• Comunicación entre los componentes
• Espacio físico de trabajo adecuado
• Políticas claras para todo el equipo.

Los valores propuestos son concordantes con los principios ágiles:

• Entrega frecuente y constante de software operativo a intervalos que pueden ser diarios,
semanales o mensuales.
• Comunicación permanente de todo el equipo de trabajo, preferentemente estando en el
mismo espacio (comunicación osmótica)
• Reflexión y mejora continua. Es beneficioso dedicar un tiempo regular (ya sea unas pocas
horas cada semana o una vez al mes) para reflexionar sobre el trabajo realizado, revisar
notas, analizar el progreso y discutir posibles mejoras..
• Hablar con los compañeros cuando algo molesta dentro del grupo.
• Focalizarse en lo que se está haciendo, teniendo claro el objetivo y contando con el tiempo
necesario para hacerlo.
• Tener fácil acceso a los usuarios y contar con desarrolladores expertos para consultas
puntuales.

Método de Desarrollo de Sistemas Dinámicos

(en inglés Dynamic Systems Development Method o DSDM)

Este método de desarrollo surge en Inglaterra, en los años 90, y busca hacer frente a la
problemática de desarrollar software en entornos con agendas y presupuestos apretados. Puede

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
70
considerarse como una adaptación del modelo RAD a los principios ágiles y, de hecho, promueve la
utilización de herramientas RAD.

Este framework de trabajo destaca 5 etapas, 3 de ellas previas a la construcción propiamente

dicha:

1. Estudio de viabilidad y de negocio de los proyectos. Solo aquellos que puedan

desarrollarse con un enfoque RAD pueden llevarse a cabo con esta metodología.
2. Estudio comercial o de la empresa. Se verifica que el sistema planificado pueda cumplir
con los requisitos solicitados por la organización.
3. Iteración del modelo funcional, que implica construir un prototipo del sistema
4. Diseño e iteración de la estructura, donde se construye y prueba la solución definitiva.
5. Implementación.

Los principios de esta metodología, una vez más, están en línea con aquellos enumerados en
el manifiesto ágil:

• Involucrar al cliente es la clave para llevar un proyecto eficiente y efectivo.

• El equipo del proyecto debe tener el poder para tomar decisiones que son importantes.
• DSDM se centra en la entrega frecuente de productos.
• El desarrollo es iterativo e incremental.
• Todos los cambios durante el desarrollo son reversibles.
• Las pruebas son realizadas durante todo el ciclo vital del proyecto.
• La comunicación y cooperación entre todas las partes interesadas.

7. Ventajas, dificultades y limitaciones de las metodologías ágiles

Las metodologías ágiles presentan ventajas a la hora de su utilización como también

desventajas. A continuación, enumeramos algunas:

Ventajas

• Las metodologías ágiles ofrecen una rápida respuesta a cambios de requisitos a lo largo
del desarrollo del proyecto, gracias a su proceso iterativo y a que el software está en un
proceso de cambio permanente.

• El cliente puede observar cómo va avanzando el proyecto, y por supuesto, opinar sobre
su evolución.

• El poder ofrecer entregables parciales permite ir atacando los objetivos más sencillos,
ganado tiempo y experiencia tiempo para atacar luego los objetivos más complejos.

• Uniendo las dos anteriores se puede deducir que, al utilizar estas metodologías, los
cambios que quiera realizar el cliente van a tener un menor impacto. Las entregas,
intervalos cortos de tiempo contienen solo una porción del producto deseado. Si el

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
71
 cliente quiere cambiarlo nuevamente, solo se habrá perdido unas semanas de trabajo.
Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización
de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando
meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la
pérdida de todo ese trabajo.

• Se reducen los tiempos y costos de capacitación (el cliente participa del diseño y conoce
el producto desde su desarrollo) e implementación.

• Se involucra desde un principio y se da un rol a todos los stakeholders.

Dificultades en la aplicación de los principios

• Aunque es atractiva la idea del involucramiento del cliente en el proceso de desarrollo,

los representantes que asigna el cliente a menudo deben también seguir realizando sus
tareas dentro de la organización. Tienen sus propios tiempos y presiones y no siempre
pueden estar disposición de las necesidades del equipo de scrum.

• Quizás algunos miembros del equipo no cuenten con la personalidad adecuada para la
participación intensa característica de los métodos ágiles y, en consecuencia, no podrán
interactuar adecuadamente con los otros integrantes del equipo. Muchos
desarrolladores desarrollan hábitos de trabajo en solitario y no siempre se consigue
integrarlos eficazmente.

• Ocasionalmente, priorizar los cambios se torna muy difícil, sobre todo en sistemas donde
existen muchos participantes. Cada uno puede tener diversas prioridades a diferentes
cambios. Deben consensuarse, además, las necesidades operativas con las políticas.

• Mantener la simplicidad requiere trabajo adicional. Bajo la presión de fechas de entrega,

es posible que los miembros del equipo carezcan de tiempo para realizar las
simplificaciones deseables al sistema.

• Muchas organizaciones, especialmente las grandes compañías, pasan años cambiando

su cultura, de tal modo que los procesos se definan y continúen. Para ellas, resulta difícil
moverse hacia un modelo de trabajo donde los procesos sean informales y estén
definidos por equipos de desarrollo.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
72
 Limitaciones

• Falta de documentación del diseño. Por lo general la única documentación con la que se
cuenta son unos pocos comentarios en el código. Pueden producirse complicaciones con
la reusabilidad de componentes a partir de esta falta.

• También la falta de procesos rigurosos y documentación escrita puede producir

problemas si el software requiere ser certificado o auditado por equipos de contralor, los
que seguramente exigirán constancias de las tareas realizadas en el proceso de
desarrollo.

• Problemas derivados de la comunicación oral. No hace falta decir que algo que está
escrito “no se puede borrar”, en cambio, algo dicho es muy fácil de olvidar o de tener
ambigüedad. No siempre existe un entendimiento entre el usuario, que no entiende
cuestiones técnicas, y los desarrolladores que carecen de conocimiento sobre cuestiones
de negocios.

• El desarrollo no siempre tiene la misma secuencialidad ni necesidades que las prioridades

fijadas. Puede ocurrir que para poder implementar alguna solicitud sea necesario que se
programen funcionalidades extras o sea necesario implementar cosas que estaban
previstas para más adelante.

• Restricciones en cuanto a tamaño de los proyectos, para el desarrollo de software de

seguridad crítica, o para implementaciones dispersas geográficamente.

• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no
hay documentación, o hay muy poca, para no volver a cometer los errores; lo mismo
ocurre con el diseño. La comprensión del sistema se queda en las mentes de los
desarrolladores.

• Los contratos por lo general son por tiempo insumido y no siempre fáciles de administrar
ni de controlar.

• Son difíciles las subcontrataciones y la presupuestación.

8. Casos de estudio

En alguna de las actividades de la materia Ingeniería de Software se les solicita a los alumnos
que expongan casos reales basados en su propia experiencia laboral. Resulta interesante analizar
alguno de estos casos para ver cómo se aplican las metodologías ágiles en algunas empresas de
nuestro entorno, en especial para ver cómo el aplicar la metodología en forma relajada casi siempre
terminan en fracaso.

También queda reflejado como, en ocasiones, se aplica mal la metodología o directamente

no se aplica. En ocasiones simplemente de dice que se usan metodologías ágiles porque suena
“moderno”, o quizá a los solos efectos de evitar alguna de las formalidades de los desarrollos
basados en un plan. En estos casos los resultados suelen ser desalentadores.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
73
 Si bien se trata de relatos parciales y en muchos casos descontextualizados, sirven como base
para ejemplificar los conceptos desarrollados en este trabajo. Con el permiso de los alumnos,
aunque preservando su identidad y el nombre de la organización al que hacen referencia, estos son
algunos ejemplos son valiosos para tener en cuenta23:

Caso A: Éxito en metodología Scrum en un banco

“Debido a la creciente necesidad del equipo de analistas de datos del banco de contar con
una herramienta que cubra sus requerimientos de búsqueda de toda información contenida
en el Data Warehouse y que sea de fácil escalabilidad para la utilización en el resto de las
áreas, surge la idea de crear un equipo dedicado a la creación de un asistente virtual.

Para el desarrollo de este, se optó por una metodología ágil que permitiera la entrega de un
producto iterativo e incremental que, al disponibilizarse para su uso, aportará valor al
negocio de forma temprana. Se decidió realizar sprints con una duración de 2 semanas cada
uno y entregas productivas (releases) cada 2 sprints, poniendo a disposición el producto para
un grupo seleccionado de usuarios. Atravesando una profunda transformación, el banco
decide formar un equipo integrado por Scrum Masters, facilitando uno de ellos para este
proyecto. Además, se terminó de conformar el equipo con la contratación de un Product
Owner, un Technical Owner y un equipo de desarrollo.

Durante los primeros sprints, se desarrolló una UI sencilla conectada a los servicios
cognitivos. Esto permitió que el negocio pueda empezar a probar el asistente virtual y que se
puedan ir realizando mejoras incrementales tanto en la interfaz, así como también, en los
entrenamientos cognitivos. Además, cabe destacar que ayudó en el descubrimiento de
necesidades futuras. En los incrementales siguientes, el asistente se conectó con diferentes
servicios pasando a ser de esta manera un bot transaccional. Se agregó la analítica de datos
para poder realizar explotación de estos y, actualmente, se está trabajando con sprints de
seguridad y la incorporación de nuevas tecnologías.”

Caso B: Después de mucho tiempo y esfuerzo, se logró el objetivo.

“Este es un caso de uno de los principales banco privados de Argentina, el cual tuvo varios
problemas a la hora de hacer la transición desde el desarrollo de software con modelos
basados en un plan hacia el uso de metodologías ágiles, durante aproximadamente dos años
el banco tuvo inconvenientes con este cambio de paradigma de desarrollo, se utilizaron
muchos recursos para cambiar la estructura del departamento de sistemas, y aun así no se
consiguieron los resultados esperados, incluso pasaron varios scrum master por el sector sin
poder lograr cambios significativos.

23
Los alumnos tuvieron libertad para describir los casos según su criterio. Aunque se solicitaron casos reales, es
importante destacar que no se presentan de manera rigurosa y completa, ni se basan en un análisis exhaustivo de las
organizaciones mencionadas. Además, los alumnos tuvieron la posibilidad de agregar o omitir detalles para adaptar los
casos a la actividad planteada. El análisis realizado se basa exclusivamente en la información proporcionada por los
alumnos, y es importante tener en cuenta que podría variar si se contara con información adicional del contexto. Los
casos de trascriben tal y como fueron presentados.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
74
 Uno de los principales factores de porque se tardó mucho en cambiar el paradigma de
desarrollo de forme eficiente, fue que gran parte del sector seguía muy aferrado al viejo
modelo de desarrollo, es decir había un la falta de adaptabilidad por parte de los empleados
y de los jefes, se insistía en seguir con el modelo tradicional de cascada, el cual era utilizado
hasta ese momento, por otro lado, también influyó negativamente el no tener un plan de
proyecto para realizar este tipo de cambios, así como un plan de contingencia para evitar un
derroche de recursos innecesario, que fue lo que terminó ocurriendo.

Por último, en términos de ingeniería de software, queda en claro que, para llevar a cabo este
tipo de cambios de hacer las cosas, para imponer una nueva manera, no solo se requiere una
voluntad de adaptabilidad por parte de los individuos, sino que también se necesita un plan
que contenga al menos los principales riesgos posibles que puedan boicotear o ralentizar los
objetivos deseados.”

Caso C: Scrum en la industria automotriz.

“En este caso, hablamos de una empresa automotriz que subcontrata a empresas de IT para
los desarrollos de sistemas. Tiene en agenda muchos cambios de sistemas para optimizar los
procesos y hacer más dinámica la parte comercial. Si bien la mayoría de los sistemas antiguos
han sido desarrollados con el modelo tradicional ahora intenta hacer esos cambios usando
un desarrollo con metodologías agiles.

Esto dentro de un contexto de globalización donde la casa matriz francesa contrata, a través
de su filial argentina, a una empresa local de IT para el desarrollo ágil de un sistema usado
en Francia.
El software original utilizaba el lenguaje antiguo y era muy poco eficiente solo se conservaba
por el costo y el riesgo de cambiar el sistema, hasta que el mismo software se volvió
problemático y poco fiable. Dicho Sistema tenía como funcionalidad los pagos de primas a
concesionarios y era clave para la gerencia comercial de la empresa.

Durante la migración de COBOL/DB2 a Java/Oracle hubo cambios frecuentes y nuevos

pedidos por parte del usuario, cosa que no se hubieran podido procesar con el modelo
tradicional donde se establecen los requerimientos al inicio sin posibilidad de cambio. Se
incorporaron nuevas funcionalidades con las distintas liberaciones, se usó la metodología
SCRUM donde se establecieron la longitud de SPRINT en cuatro semanas con la lista de
trabajo (product backlog). Se hicieron pruebas en forma continua durante el desarrollo del
sistema por medio del sector de QA antes de la salida a producción y sus correspondientes
correcciones. El product owner de la empresa de IT fue clave para comunicar los
requerimientos al scrum master.

Este caso muestra el éxito de como la ingeniería de software a través del uso correcto de
metodologías ágiles, facilita los desarrollos y permite la migración de una plataforma vieja a
una plataforma nueva, brindando una herramienta para lograr un software más escalable,
funcional, eficiente, fiable y seguro.

A modo de conclusión, el desarrollo con metodologías ágiles del nuevo sistema de pago de
primas a concesionarios fue el puntapié que hizo que la empresa de IT ganara varias
licitaciones con esta multinacional francesa y logre afianzar su crecimiento dentro del
mercado de empresas de IT.”

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
75
 Caso D: Problemas en metodología Scrum en una institución pública.

“La institución realiza los desarrollos necesarios para poder llevar a cabo las comunicaciones
y las integraciones para obtener los datos de las demás áreas de gobierno y así alimentar la
base de datos logrando que las comunicaciones sean con datos actualizados. Actualmente
desarrollan una plataforma de comunicación que centralice las diversas herramientas que se
utilizan para la comunicación dentro de lo que es gobierno como Mailing, IVR (Respuesta de
voz interactiva), audios, SMSs con los distintos proveedores contratados.

En este caso se puede ver como por la incorrecta aplicación (desde el punto de vista
conceptual) de metodologías ágiles, no se logró ningún beneficio y derivo tanto en pérdida
de tiempo como en la falta de resolución de problemas. Utilizaron una especie de Scrum ya
que lo adaptaron como les pareció útil. Por un lado, no se hacían las reuniones diarias, estas
fueron intercambiadas por reuniones semanales. En las cuales capaz se planteaba el estatus
del proyecto, pero no eran de utilidad ya que no se hablaba de los impedimentos para
avanzar con el proyecto o lo que se iba a desarrollar la semana siguiente. Con los futuros
usuarios no se hacia el relevamiento correcto de requerimientos lo que deriva en nuevas
reuniones con los mismos para poder refinar las historias de usuario que en primera instancia
estaban mal relevadas o relevadas de forma incompleta. Por otro lado, los product backlog
que se manejaban estaban mal armados, no estaban las tareas divididas en sprints como
deberían.

La funcionalidad que se debía entregar en los releases presentaba anomalías debido a que
por intentar cumplir con los sprints no se hacían las pruebas necesarias y se realizaban las
entregas como estaban. No se llegaban con los tiempos por el retrabajo ocasionado por los
errores de relevamiento y la mala organización de los tiempos donde no se les dio mucha
importancia a las contingencias.

Caso E: Pérdida de tiempo y dinero en un banco.

“El proyecto constaba del desarrollo del Homebanking, plataforma donde se prestan los
servicios bancarios a los titulares que registran una cuenta, (usuarios del banco), donde se
puede acceder a través de internet por medio de computadoras, tablets o teléfonos celulares.
El proyecto estaba organizado basado en un plan, con una combinación de metodologías
Scrum. Todas las fechas ya se encontraban planificadas, determinadas, las cuales se tenían
que cumplir al pie de la letra, (Por ejemplo, las salidas a producción).

En desarrollo los Sprints duraban 3 semanas, donde se pretendía llegar como sea a cumplir
con las historias comprometidas en cada Prueba con los usuarios.

El problema fue que por mucho tiempo por falta de tiempo varios equipos dejaron de testear,
hacer pruebas de software, y las incidencias que levantaban las personas de Testing no se les
prestaba demasiada atención, nunca eran prioridad, esto se sostuvo durante varios meses.
Llegó un día donde el producto que se estaba desarrollando tenía que salir a producción,
cuando se empezó a llevar a cabo el proceso para poder realizar esto, todo exploto en los

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
76
 servidores, y afecto a otros módulos, debido a las fallas que se fueron acumulando y no se les
había dado la atención necesaria.

Solucionar esas incidencias, y realizar las pruebas que tendrían que haberse hecho en su
tiempo correspondiente produjo un enojo por parte de los PO, entre otras personas del banco.
Se tuvo que modificar toda planificación del proyecto el cual se atrasó bastante tiempo, lo
que a su vez hizo que se pierda una cantidad considerable de dinero.”

Como vemos en estos dos últimos casos, ninguno aplicó correctamente la metodología
Scrum, sino que hicieron adaptaciones y mezclas. Toda metodología puede ser adaptada conforme
la organización y el tipo de proyecto, pero no puede ser desvirtuada al punto tal de perder su
esencia.

En el “caso D” caso en lugar de aplicar correctamente Scrum hicieron una adaptación tan
particular, que hasta las ceremonias fueron eliminadas, o en el mejor de los casos, adecuadas a
como mejor le venía a quienes llevaron adelante el proyecto.

En el “caso E”, se intentó aplicar una metodología ágil, como Scrum, a un proyecto que
estaba rigurosamente planificado en términos de fechas y entregables. Es importante destacar que
Scrum se recomienda para proyectos en los que existe la posibilidad de cambios y donde las fechas
y entregables no pueden ser completamente definidos al inicio. En proyectos tan estrictamente
planificados como este, podría haber sido más adecuado utilizar un enfoque basado en un plan, que
permite establecer un proceso bien definido y ajustado para cumplir con los plazos establecidos.

9. Comentario final

Como se ha visto, agilidad y desarrollo rápido no son sinónimo de un software construido a

la ligera, con errores y sin procesos que aseguren la calidad del producto entregado. Programar
software y entregarlo rápidamente, sin seguir ninguna regla ni metodología, no implica que se estén
siguiendo modelos ágiles. Por el contrario, implican enormes riesgos y altas chances de fracaso. Es
común que muchos desarrolladores afirmen utilizar metodologías ágiles por razones de moda o
eficiencia, sin darse cuenta de que, si no las aplican correctamente, el éxito del proyecto queda a
merced de la suerte.

Los modelos de desarrollo ágil tienden, como su nombre lo indica, a agilizar y acotar los
procesos tradicionales. Sin embargo, existen metodologías y procesos para seguir.
Lamentablemente, es frecuente encontrar organizaciones que dicen estar utilizando metodologías
ágiles cuando en realidad no están aplicando metodología alguna.

En estos casos debemos recordar que:

• Metodologías ágiles no implica ausencia total de documentación.

• Metodología ágil no implica suprimir etapas del ciclo de vida, en especial las pruebas.

Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software - 2° Edición - Lic. César Ariel Briano
77