Quizá uno de los principales actores, de los más afectados, de los mayores detonantes en el cambio que está sufriendo la ingeniería del software (cambio que se lleva fraguando casi 40 años) han sido los requisitos.
Los requisitos han sido, en el mundo del software, una de las mayores fuentes de dolores de cabeza… “los clientes no saben lo que quieren”, “nos han cambiado los requisitos”, “debemos cerrar los requisitos”, etc.
Frente a la visión clásica, la visión moderna, digo contemporánea, asume que demasiadas veces los requisitos no pueden cerrarse de antemano, no sólo porque puede que no podamos extraer las ideas de los usuarios antes de construir un sistema, también porque aunque lo hagamos en el momento cero, para cuando el software esté listo en el momento n el mundo habrá cambiado y las necesidades también, recuerda aquello de que hoy lo más determinante es la velocidad de desarrollo. ¿Eres rápido? Tu empresa lo tiene todo
Años atrás, la mayoría del software que se desarrollaba trabajaba con requisitos más estables en el tiempo, no en vano, la mayoría de los desarrollos automatizaban procesos muy conocidos: la implementación de nominas (todo el mundo sabía como hacerlas a mano y era hora de hacerlas en un sistema software), contabilidad, gestión de clientes, rrhh, etc.
Pero ahora, gran parte de los desarrollos software soportan nuevos modelos de negocio, modelos que alguien intuye pero nadie sabe realmente como van a funcionar. Ahora, aún más, es casi imposible cerrar de ante mano grandes y pormenorizadas listas de requisitos. Y ahí la agilidad, frente a los métodos clásicos, se lleva la partida.
Déjame que te sintetice 3 diferencias de la versión clásica de trabajo con requisitos frente a la contemporánea (llámala ágil si quieres):
1 – Antes la investigación en ingeniería software se centraba en cómo extraer todas y cada una de las ideas de lo que el usuario quería / necesitaba, ahora asumimos que la mejor manera de saberlo es creando un prototipo, real con parte de los requisitos, y enseñándoselo a los usuarios reales para que ellos nos digan sobre algo construido cuales son los siguientes requisitos.
2 – Antes, una vez cerrada una gran lista de requisitos, los cambios en requisitos eran un problema, los ciclos de vida como el cascada no estaban preparados para ello, ahora asumimos que el cambio controlado no es malo y es bienvenido.
3 – Antes, la documentación era voluminosa, grandes “especificaciones de requisitos”, eran populares estándares como la IEEE 830, documentación completa y previa a la construcción, ahora documentos de cosas que no se van a implementar, o se implementan y son inútiles, nadie las usa, es “desperdicio”, por ello buscamos documentar previamente lo mínimo y si hay que documentar en detalle que sea a posteriori, después de implementarlo y comprobar que eso era lo que realmente quería el cliente.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Soy novato en este mundo y gracias a post como este estoy aprendiendo un poco más y mejor sobre como funciona el mercado laboral en el que en un futuro me moveré, las técnicas actuales que se emplean, así como una serie de consejos constructivos que me hacen definir este blog como altamente gratificante!!