La Gestión en

Entornos Ágiles

Ingeniería de
Software

1
La gestión en entornos ágiles
Antes de comenzar con la gestión en entonos agiles mencionaremos la
diferencia que existe con el enfoque estándar de la administración de
proyectos, la que se basa en un plan y en los cuales el alcance del proyecto,
el tiempo y costo requeridos para lograr dicho alcance, se determinan lo
antes posible en el ciclo de vida del proyecto.
La responsabilidad principal de los administradores del proyecto es
asegurarse de entregar el proyecto de acuerdo al alcance, tiempo, costos
establecidos. Para que el software pueda ser entregado en tiempo y con el
presupuesto planeado, se deben supervisar el trabajo del equipo y
monitorizar el avance en el desarrollo del software.
Sin embargo, este enfoque no funciona bien con los métodos ágiles, donde
los requerimientos se desarrollan de manera incremental, el software se
entrega en periodos cortos y es normal que se realicen cambios.
El desarrollo ágil tiene que administrarse de modo tal que se alcance la
mayor eficiencia en el uso del tiempo y de los recursos disponibles para el
equipo. Para lograrlo, se requiere un enfoque diferente a la administración
del proyecto orientada al plan, que se tiene que adaptar al desarrollo
incremental y a las particularidades de los métodos ágiles.

Características del proceso Scrum

Planeación del bosquejo y diseño arquitectónico

Comenzaremos detallando la primera fase definida en scrum, en la que se

establecen los objetivos generales del proyecto y el diseño de la arquitectura
de software. En esta fase se propone responder a la pregunta ¿qué trabajo
será realizado? Se define lo que se necesita hacer y las hipótesis del cliente
que se van a desarrollar.
En esta fase se crean los ítems de product backlog y los criterios de
aceptación. Estos son generalmente definidos por el dueño del producto y
están diseñados para asegurar que las hipótesis de requisitos del cliente
estén claramente representadas y puedan ser comprendidas por todos los
stakeholders y los desarrolladores del equipo.
Esta es una reunión que sirve para establecer las prioridades y necesidades
de negocio del cliente, y se determinan cuáles y cómo van a ser las
funcionalidades que se van incorporar al producto en el proximo sprint.
La reunión sera llevada a cabo por el Scrum Master y a la que debe asistir
el dueño del producto junto con el equipo completo, como asi tambien
interesados del proyecto que lo desee. (ver figura 1).

2
Figura 1: (El proceso de Scrum)

Fuente: Sommerville, 2005, p. 73.

Planificacion Sprint

La reunión de planificacion de Sprint pueden durar una jornada de trabajo

completa, cuando se debe planificar un sprint largo de aproximadamente
un mes de duración.
Esta reunión debe dar respuesta a dos cuestiones:

 Qué se deberá entregar al terminar el sprint.

 Cuál es el trabajo que va ser necesario para realizar el incremento
previsto, y cómo el equipo va hacer para llevarlo a cabo.

La reunión se divide en dos partes con la misma duración, para poder dar
respuesta a cada una de estas cuestiones.
Los sprint son el nucleo mas importante de scrum, ya que por cada uno de
estos se desarrolla un incremento del sistema, lo que significa que hay una
entrega de valor para el cliente.
Scrum es una metodología que está basada en planeación, en la que se da
valor está dado por el trabajo que se va a realizar, donde se seleccionan las
funcionalidades por desarrollar y se implementa el software.
Lo más recomendable en los sprints es que sean de un tiempo fija, por lo
general, de dos a cuatro semanas, lo que va permitir obtener métricas de
velocidad del equipo, incluso para ayudar a mejorar las estimaciones de
proximas entregas.
El punto de partida para la planeación es el product backlog, el cual
conforma la lista de trabajo por realizar en el proyecto. Este se debe revisar
durante la fase de valoración del sprint, debe ser revisado y priorizado junto
con su correspondiente análisis de riesgos. El cliente es quien siempre
interviene en este proceso. Al inicio de cada sprint, puede introducir nuevos
requerimientos o tareas.

3
La fase de seleccionar las características y la funcionalidad a desarrollar
durante el sprint debe incluir a todo el equipo del proyecto que trabaja con
el cliente.
Una vez que el equipo acuerda con el cliente las características y la
funcionalidad que va tener el producto, se organiza para desarrollar el
software.

La daily

El equipo revisa el progreso a través de breves reuniones diarias con todos

los miembros. Durante esta etapa, se aísla del cliente y de la organización, y
todo se canaliza a través del llamado scrum master, el cual realiza tres
preguntas a los integrantes del equipo.

 ¿Qué hice ayer?

 ¿Qué voy a hacer hoy?
 Si tengo obstáculos, ¿qué impedimentos tengo?

Revision Sprint

Una vez finalizado un Sprint de ser posible se debe realizar una demo para
hacer un análisis e inspección del incremento que fue generado, y luego
realizar la adaptación de la pila del producto si es necesario.

Retrospectiva del sprint

Esta reunion se lleva a cabo para hacer una revisión de lo sucedido durante
el transcurso del Sprint, en la que el equipo se detiene a analizar aspectos
operativos, forma de trabajo para poder crear un plan de mejoras para
aplicar al sprint siguiente. Es importante aclarar que debe estar presente
todo el equipo de desarrollo y el scrum master.
También en esta reunion es recomendable la participación del dueño del
producto. En el caso de que se requiera la participación de stakeholders o
gerentes, estos también podrán se convocados.

4
Fase cierre del proyecto

Finalmente, la fase de cierre del proyecto implica la conclusión del proyecto,

donde se completa toda la documentación requerida, como los marcos de
ayuda del sistema y los manuales del usuario, y se registran las lecciones
aprendidas durante el proyecto.

Los roles

El sistema de roles en el núcleo de scrum es el conjunto de roles y relaciones

que son parte del sistema scrum.
Como se mencionó anteriormente, hay tres roles principales:

 product owner o dueño del producto;

 scrum master o facilitador;
 equipo de desarrollo.

Figura 2: Roles Scrum

Fuente: Alaimo, 2013, p. 25.

5
Responsabilidades de los roles

Equipo de desarrollo

Crea y gestiona el desarrollo de software y se compromete a respetar fechas

de entregas estimadas. Además, es responsable de la calidad técnica del
producto. Sus miembros deben mantener el foco en el aprendizaje, la
innovación y manifestar una actitud de mejora continua.
Deben priorizar y promover la comunicación cara a cara y hacer
estimaciones de los ítems de trabajo. También deben ser responsables de
gestionar su propio trabajo durante el sprint y no deben esperar que se les
asigne tareas, ya que cada uno debe asumir ciertas actividades por sí mismo
o por consenso de todo el equipo. Ser multidisciplinario es también una
característica de los equipos scrum ya que aplican sus habilidades en
diferentes tipos de tareas.

Product owner o dueño del producto

Es el responsable del negocio y del producto o servicio. Es quien vela por que
el equipo tenga una visión clara sobre qué es lo que se tiene que construir y
una estrategia.
Es quien va determinar el mejor producto a conseguir y quien va proveer las
hipótesis de requerimiento. Es responsable por el artefacto product backlog
y tiene la obligación de entender los requerimientos que va contener,
escribirlos y transmitirlos de manera eficaz. También es responsable del
retorno de la inversión ROI y de los resultados empresariales, por lo que
debe evaluar continuamente el impacto en el negocio.
En su rol, debe asegurar la colaboración efectiva y la participación de los
stakeholders en el proyecto: administrar sus expectativas, mantener una
comunicación regular con ellos y monitorear el progreso del proyecto.

Scrum master

Es el responsable de velar por el cumplimiento de la metodologia brindar

apoyo a las prácticas de scrum, gestionar los riesgos y problemas junto con
los demás roles y siempre buscar remover los obstáculos e impedimentos
del proyecto.
Es también el encargado de lograr la mejora continua del proceso o sistema
de trabajo. Debe estar cien por ciento comprometido con el proyecto, ya
que es mensajero, representante y protector del equipo.
Además, debe monitorear el progreso y el éxito con el resto de los roles del
equipo y ayudar con la entrega de incrementos del producto.
La presencia en las reuniones diarias no es obligatoria para el scrum master,
pero si es necesario puede estar presentecomo moderador, no debe

6
estimar junto al equipo de desarrollo, ni hacer tareas de otros roles, como
por ejemplo, desarrollar, programar, probar.
Es importante dejar en claro que el rol del scrum master no es jefe ni gerente
de proyecto. No debe gestionar al equipo de desarrollo. Tampoco es
responsable por la planificación del proyecto. No debe asignar tareas, sino
procurar que estas sean auto asignadas o asumidas por voluntad propia.

Escalamiento en proyectos ágiles

Las metodologías ágiles fueron pensadas para usarse en equipos pequeños,
donde estos trabajan juntos los mismos lugares y manteniendo una
comunicación informal pero fluida.
Por lo tanto los mejores resultados se logran en sistemas pequeños y
medianos, pero debido a que esta metodología provoco muy buenos
resultados, hay un enorme interés de poder llevarla a los sistemas de mayor
dimensión, desarrollados por las grandes organizaciones.
¿Por qué el desarrollo de grandes sistemas de software difiere en algunas
formas del desarrollo de sistemas pequeños?
Los grandes sistemas son colecciones de sistemas separados en
comunicación, donde equipos separados desarrollan cada sistema. Dichos
equipos trabajan en diferentes lugares y en ocasiones, con distintas zonas
horarias, lo que imposibilita que cada equipo tenga una visión de todo el
sistema.
Los grandes sistemas y sus procesos de desarrollo por lo general, están
restringidos por reglas y regulaciones impuestas con normativas que deben
ser cumplidas que limitan y a la vez, requieren cierta documentación
exhaustiva del sistema que se va a desarrollar.
Otro aspecto importante es que los grandes sistemas tienen tiempos de
desarrollos largos y en los cuales es difícil mantener los mismos equipos,
porque resulta inevitable que algunas personas cambien sus trabajos o
proyectos y también resulta casi imposible involucrar a todos estos
participantes en el proceso de desarrollo.

7
Referencias
Alaimo, D. M. (2013). Proyectos Agiles con Scrum. Ciudad Autónoma de Buenos
Aires: Kleer.

Sommerville, I. (2011). Ingeniería del Software (9 na ed.). Madrid: Pearson

Educacion S.A.