En el entorno corporativo o empresarial, todos los días se tienen que tomar decisiones cruciales sobre los distintos proyectos que se están gestionando. El problema es que, muchas veces, es preciso adecuar los criterios de trabajo en los equipos según las características de cada proyecto, tal como en el siguiente estudio de caso.

El escenario de partida es una compañía local donde colabora Romina, ingeniera de software que se desempeña como administradora de proyectos. Actualmente tiene asignados dos proyectos que deberá gestionar con equipos de trabajo multidisciplinarios.

El primer proyecto es para una compañía que requiere un sistema de generación de facturas para sus clientes. Sus requerimientos son específicos y el resultado final es previsible. El equipo de desarrollo podría construir el sistema con la confianza de que los cambios serían mínimos.

En lo que respecta al segundo proyecto, es para una empresa startup, que busca ofrecer un servicio innovador basándose en el IoT, es decir, el Internet of Things o Internet de las cosas. La idea es colocar dispositivos que permitan recopilar información del rendimiento del motor de automóviles eléctricos vía Internet. En este caso, los requerimientos son mínimos, pero no se tiene claro hasta qué punto se avanzará ni tampoco se sabe si se terminará el proyecto ni las funcionalidades que tendrá.

Por fortuna, en este tema obtendrás los conocimientos para ayudar a Romina a tomar la mejor decisión para que seleccione el enfoque más adecuado para gestionar cada proyecto, basándose en la estabilidad de los requerimientos, el tiempo y los recursos financieros disponibles, así como la incertidumbre con relación al resultado final o el alcance de cada proyecto.

Proyectos de software

Una parte importante de las responsabilidades de un líder de proyectos de desarrollo de software es decidir si el enfoque ágil de Scrum será el mejor marco de trabajo para llevar la gestión de las actividades del proyecto que está a punto de realizar.

De acuerdo con el Project Management Institute (2017), los líderes deben tomar esta decisión, dando respuesta a las siguientes preguntas sobre los proyectos:

• ¿Tienen alta incertidumbre con relación a los requerimientos del cliente o los riesgos?
• ¿Presentan complicaciones para estimar inicialmente el tiempo disponible y el alcance de los mismos?
• ¿Su meta final es difícil de describir?

Para darte una mejor idea de los elementos que intervienen en esta decisión, a continuación, se presenta un esquema basado en el planteamiento del Project Management Institute (2017):

Figura 1. Modelo de incertidumbre y complejidad.

Como pudiste observar en la imagen anterior, en el eje vertical se encuentra la escala sobre la incertidumbre de los requisitos, la cual te permite situar el grado de incertidumbre de los clientes que no tienen la certeza de sus necesidades específicas. Por su parte, en el eje horizontal se ubica el nivel de incertidumbre existente con relación a los requerimientos técnicos de los proyectos.

De esta forma, si se tienen claros los requisitos y se conoce la plataforma tecnológica, el enfoque del proyecto será lineal. En cambio, cuando aumenta la incertidumbre en ambos sentidos (requerimientos + tecnología), aumentará la probabilidad de cambio, así como el tiempo y costo de los proyectos, por lo que el enfoque a usar sería un desarrollo adaptativo, iterativo, incremental y que además genere entregables rápidos y funcionales.

Por ejemplo, considera el desarrollo de la aplicación web de Spotify. Fue un proyecto basado en una idea: crear una herramienta de streaming que ofreciera al usuario cualquier canción de manera inmediata, sin la necesidad de descargarla localmente. Este proyecto implicó un gran desafío para el equipo de desarrolladores, primero porque era una idea radicalmente disruptiva en comparación con las alternativas disponibles en aquel entonces y, en segundo lugar, porque a nivel técnico no había claridad sobre los retos que se tenían que afrontar.

A fin de exponer los distintos enfoques que puedes adoptar para la realización de proyectos, a continuación, se presentan diversos esquemas para ilustrar el funcionamiento general de cada uno de los enfoques.

Enfoque predictivo

El primero es el enfoque predictivo, en el que existe la plena certeza sobre los requerimientos completos del desarrollo. Aquí podrás perfilar que prevalece la dinámica clásica de waterfall o cascada, que se recuperó del diagrama de Layoan (2022) y se expone en el recuadro correspondiente.

Enfoque iterativo

Después se ubica el enfoque iterativo. Este se emplea cuando se trabaja con proyectos en los que existe una constante retroalimentación sobre el trabajo que está en proceso. Dicha retroalimentación se da hasta llegar a un resultado final que cumple con todas las expectativas del cliente. Así lo puedes constatar en el diagrama adjunto inspirado en el gráfico de Efecto digital (s.f.).

Enfoque incremental

Otro de los enfoques disponibles es el enfoque incremental, que, tal como su nombre lo indica, va agregando nuevas funcionalidades en cada entrega del proyecto. Basándose en la propuesta de Sarco (2012), en el siguiente diagrama puedes observar sus características.

Enfoque ágil

Por último, se encuentra el enfoque ágil, el cual te permitirá satisfacer todos los requerimientos de los clientes en periodos cortos de tiempo.

Para resumir los rasgos centrales de los diferentes enfoques, la siguiente tabla, basada en el planteamiento de los ciclos de vida del Project Management Institute (2017), sintetiza las características básicas de los enfoques, comparándolos con los tipos de requisitos, actividades, entregas y metas por alcanzar.

Tabla 1. Características de los enfoques.

De igual forma, en la imagen que se expone líneas abajo, realizada con base en la propuesta del Project Management Institute (2018), podrás observar el enfoque de la gestión de proyectos con relación a la frecuencia de entregas y al grado de cambio. Mientras se den menos cambios y bajas frecuencias de entrega, el enfoque sería predictivo. En contraste, conforme se incrementan la cantidad de los cambios y hay numerosas entregas, el enfoque sería ágil.

Figura 2. Enfoques por frecuencias de entrega y grado de cambios.

Planeación y ejecución de proyectos ágiles

Los proyectos de software que se desarrollan bajo cualquiera de los enfoques ágiles, incluso Scrum, requieren de una etapa de planeación. A continuación, se muestran algunas buenas prácticas antes de iniciar este tipo de proyectos:

1. Acta constitutiva

Project Management Institute (2017) recomienda generar este documento como un resumen ejecutivo del proyecto. Dicho documento tiene como objetivo explicarle al equipo de trabajo el objetivo del proyecto, por qué se considera importante para la organización, la asignación de roles y los criterios que se utilizarán para declarar la liberación del proyecto.

En proyectos predictivos, una parte esencial en el acta constitutiva del proyecto o charter es la declaración del estimado del costo y el tiempo de entrega. Sin embargo, para proyectos de software con enfoques ágiles estas partes suelen ser omitidas o estimadas a muy alto nivel debido a la incertidumbre de los requerimientos.

2. Planeación estratégica y refinamiento

Matarranz (2020) propone realizar un plan flexible y adaptable a las necesidades cambiantes del cliente, a través de una planeación multicapa, también llamada Cebolla de la planificación.

Esta comienza con una planeación de alto nivel llamada Visión. Es una capa que explica la estrategia de la organización, típicamente se plantea a largo plazo (de 2 a 5 años), que ayuda a entender el valor que recibirá el cliente con el producto y las ventajas competitivas que generará.

Continúa con el nivel de Roadmap, en el que se declara cómo se logrará la visión a mediano plazo (próximos meses o años), enfocándose en el nivel de cumplimiento de los objetivos de la organización, los requerimientos del mercado, las preferencias del cliente, los diferenciadores clave, etcétera.

El siguiente nivel de detalle sería el Release, donde se especifican las funciones a través de historias de usuario, flujogramas, diseños y prototipos de alto nivel que explican la experiencia del usuario. Para el enfoque Scrum, este nivel sería el Product Backlog.

Después se encuentra el nivel de Iteración o sprint, en el que se selecciona un paquete del nivel de Release o Backlog, que se divide en tareas con un alcance limitado.

Por último, se encuentra el nivel más bajo de planeación llamado Diario, en el que se acuerda lo que se trabajará en un día de trabajo durante una stand-up meeting.

El siguiente diagrama representa el proceso de la cebolla de planificación.


Figura 3. Cebolla de planificación.
Fuente: Matarranz, A. (2020). Niveles de planificación de producto en Agile. Recuperado de https://conversisconsulting.com/2020/03/07/niveles-de-planificacion-de-producto-en-agile/

3. Ejecución

Una vez que se estableció cómo es la planeación, a continuación, se revisarán algunas características de la ejecución de proyectos con el enfoque ágil. En este punto, es importante enfatizar, empleando los términos del Project Management Institute (2017), que "si el equipo no presta atención a la calidad, pronto será imposible liberar algo rápidamente".

De igual forma, tales expertos sugieren algunas prácticas técnicas cuando se usan enfoques ágiles en los que se integran las iteraciones y los incrementos para el producto final.

Control y monitoreo de proyectos

Cualquier proyecto destinado a generar un entregable que resuelva alguna necesidad o solucione una problemática requiere de un esfuerzo de control y monitoreo de avances durante su ejecución. De otra manera, no se sabría con certeza si está recorriendo el camino correcto o si durante la ejecución se debe corregir el rumbo.

Para ejemplificar la importancia del control y monitoreo de la ejecución de trabajos de los proyectos, considera el caso del proyecto del túnel que atraviesa el Canal de la Mancha, construido en 1988. Una época en la que países como Gran Bretaña y Francia impulsaron este esfuerzo por conectar a las dos naciones a través de la creación de un túnel ferroviario. El proyecto comenzó a desarrollarse en ambos lados del túnel, tanto el personal británico como el francés utilizaron excavadoras con la idea de encontrarse a la mitad del trayecto.

No cabe duda de que ambos esfuerzos de excavación tuvieron que ajustarse en repetidas ocasiones. ¿Te imaginas si se hubieran desviado un solo grado al inicio de los trabajos? ¡Seguramente los equipos no se hubieran encontrado! Y desde luego no se hubiera podido construir el eurotúnel.

Lo mismo sucede en infinidad de proyectos, en los que se tiene que llevar un control preciso de la ejecución de las tareas de los equipos de trabajo.

Para que puedas llevar a cabo esta tarea, enseguida encontrarás algunos indicadores del desempeño que permiten llevar el control y monitoreo de un proyecto de software:

1. Puntos de historia (Story points)

Sirven para estimar la cantidad de trabajo asignado a cada miembro del equipo. En específico, se asigna un valor numérico a cada historia de usuario basándose en la complejidad de las tareas necesarias para cubrir con la funcionalidad requerida.

Por ejemplo, se podría asignar 1 punto de historia al esfuerzo para crear una funcionalidad sencilla; si se trata del doble del esfuerzo, se asignarían 2 puntos y así sucesivamente.

Hay que aclarar que esta asignación es subjetiva y se realiza de forma colectiva, por lo que debe acordarse antes con el equipo y no debe modificarse mientras se encuentra en el sprint.

En este caso, para reflejar con mayor precisión la incertidumbre, no se usa una escala lineal, sino la secuencia Fibonacci (Figura 4), la cual consiste en la suma progresiva de los números: 0+1=1, 1+1=2, 1+2=3, 2+3=5, 3+5=8, 5+8=13, 8+13= 21, etcétera.


Figura 4. La espiral de Fibonacci.
Fuente: Maguregui, C. (2019). La matemática incrustada en la inmensa variedad de formas de vida. Recuperado de https://www.educ.ar/recursos/132013/la-matematica-incrustada-en-la-inmensa-variedad-de-formas-de-vida

2. Estimación del trabajo

Una vez que se asignaron los puntos de historia a cada user story, se puede calcular la estimación del trabajo de la siguiente manera:

Supón que 1 punto de historia se completa en 2 horas de trabajo de un desarrollador experto y 3 horas por un desarrollador novato.

Entonces, si una tarea tiene asignados 55 puntos y está dividida en tres partes: 55/3= 18.3 puntos por cada parte. De modo que, si un experto realiza las dos primeras partes y la tercera se le asigna a un novato, la estimación sería completar esta user story en 126 horas.



3. Trabajo pendiente de los sprints

Cada equipo de trabajo elige las tareas que realizará en cada sprint, lo cual constituye el presupuesto de actividades. Por su parte, las tareas que no se han realizado conforman el trabajo pendiente, también conocido como sprint Backlog.

Aquí es importante considerar que el trabajo pendiente se asigne con base en la prioridad de los mismos, así como la disponibilidad de recursos que están libres o recién terminaron alguna tarea previamente asignada.

En este sentido, una de las herramientas más útiles para medir el trabajo pendiente son los gráficos denominados Burndown, que ofrecen una representación del trabajo estimado versus el trabajo que sí se realizó. Para construir este grafico se utilizará el siguiente escenario:

Imagina que en un proyecto de desarrollo de software se estima dedicarle 60 horas de la semana a un entregable en un sprint. De manera que se le dedicarían 12 horas cada día. Entonces, haciendo una regresión de la cantidad de trabajo que queda por hacer, partiendo de las 60 horas, el lunes se iniciaría con las 60 horas, el martes quedarían 48 horas (60 – 12), el miércoles 36 horas (48 – 12) y así sucesivamente.



El paso siguiente sería registrar las horas reales de cada tarea, es decir, lo que pasó en esa semana.



Como podrás apreciar, el primer día se consumieron 15 horas, por lo que restan 45 (60 – 15 = 45). El segundo día se invirtieron 14, quedaron 31 (45 – 14 = 31) y así sucesivamente. Al graficar el estimado y compararlo contra el real, se obtiene el gráfico Burndown. Idealmente, se busca que la línea de horas reales esté muy cercana a la gráfica de horas estimadas.



4. Velocidad del trabajo entregado

Mide la cantidad de trabajo que un equipo es capaz de realizar en un periodo específico. Además, ofrece información sobre la capacidad de trabajo del equipo. Se puede medir por unidades de puntos de historia o por estimados de tiempo promedio.



Para calcular la velocidad se promedian los puntos de historia o story points que sí se terminaron (25+10+21+40+11+19+56) / 7 =25.14.

En este caso, se estima que el equipo puede atender 25 story points por sprint.

5. Cantidad de defectos que no se han detectado a tiempo

Los defectos no detectados a tiempo se contabilizan durante el periodo de construcción del software. Para ello, se requiere contar con un sistema de registro de incidentes detectados por el usuario una vez entregada la funcionalidad.

Cada incidente deberá ser asignado a una historia de usuario. Desde luego, se espera que este valor sea muy bajo, de lo contrario, el equipo tendría un serio problema de gestión de la calidad.

En este tema se revisaron diferentes enfoques de gestión de proyectos de software, basándose en el grado de incertidumbre de sus requerimientos y en la frecuencia de sus entregables. Asimismo, se analizaron algunas recomendaciones sobre cómo planear un proyecto de software usando métricas que te ayudan a mantener el control del trabajo, así como la vigilancia estrecha sobre la ejecución de las actividades del proyecto.

Aunque las metodologías ágiles se enfocan en el trabajo autogestionado por el equipo, esto no se logra de la noche a la mañana, por consiguiente, es importante apoyarse de herramientas que ayuden a alcanzar esta madurez entre los miembros del equipo.

Por tanto, la selección de la métrica más adecuada es un trabajo del administrador del proyecto. En la mayoría de los casos será necesario implementar ajustes que se adapten mejor a cada circunstancia, por lo cual será necesario adoptar una dinámica de trabajo iterativa hasta que logres ubicar la métrica más adecuada.

Al final del día, cada proyecto debe comunicar al cliente y a los interesados el avance real del proyecto. Recuerda que las herramientas de gestión de los proyectos no son importantes en sí mismas ni de forma aislada, sino que son relevantes en la medida en la que permiten controlar y monitorear el esfuerzo del equipo en conjunto.

Asegúrate de:

• Reconocer las características del enfoque ágil para la gestión de proyectos de software.
• Planear el esfuerzo de un proyecto de desarrollo de software para guiar al equipo de trabajo hacia la producción de los entregables esperados.
• Conocer las métricas que ayudan a monitorear y controlar la ejecución de un proyecto.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca del control y monitoreo de proyectos ágiles, te sugerimos revisar lo siguiente:

• Development That Pays. (2018, 20 de junio). Fibonacci Series = Accurate Agile Estimates? + FREE Cheat Sheet [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=iZYSapFCg4A
• The Agile Shop. (2022, 26 de junio). What are Story Points in Agile [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=5wc8fQn1Y_g

Lecturas

Para conocer más acerca de las métricas ágiles, te sugerimos revisar lo siguiente:

• Aguirre, M. (2021). Burndown Chart, Cómo hacer el seguimiento eficaz del avance de tu proyecto. Recuperado de https://www.appvizer.es/revista/organizacion-planificacion/gestion-proyectos/burndown-chart
• Radigan, D. (2022). Cinco métricas ágiles que no odiarás. Recuperado de https://www.atlassian.com/es/agile/project-management/metrics

• Chiva, G. (2019). Métricas Kanban. Recuperado de https://aktiasolutions.com/es/metricas-kanban/
• Coloma, D. (2020). Cuáles son los principios de Kanban. Recuperado de https://itnove.com/blog/kanban/equipos/los-principios-de-kanban/
• Ladas, C. (2009). Scrumban: Essays on Kanban Systems for Lean Software Development. Estados Unidos: Modus Cooperandi Press.
• Martins, J. (2022). ¿Qué es la metodología Kanban y cómo funciona? Recuperado de https://asana.com/es/resources/what-is-kanban
• Molina, D. (2022). Qué es Work in Progress (WIP) en Kanban y cómo utilizarlo. Recuperado de https://www.iebschool.com/blog/que-es-work-in-progress-wip-en-kanban-y-como-utilizarlo-agile-scrum/