Desarrollo de software. Requisitos detallados o visión del producto

Los enfoques clásicos se basan en una especificación detallada de requisitos para, a partir de la misma, proceder al desarrollo del producto, de manera que la relación con los usuarios es más intensa en ese momento y vuelve a recobrar importancia cuando se acerca la implantación del sistema.

Mientras tanto, habrá reuniones de seguimiento para informar al área usuaria del estado del proyecto, en las que se podrían mostrar incluso funcionalidades del producto ya implementadas. Estas reuniones sirven sobre todo para mantener tranquilo al cliente, ya que el tiempo que transcurre entre el análisis y la entrega puede ser significativo.

Esta estrategia de desarrollo supone que las especificaciones se van a mantener estables durante el proceso de construcción.

Ahí acaba la teoría porque todos sabemos lo que pasa en estos casos: los requisitos permanecen abiertos hasta el final porque el usuario se irá dando cuenta de funcionalidades que no ha descrito de manera adecuada o de nuevos módulos que quiere incorporar al sistema.

Por tanto, se ha realizado un esfuerzo importante en tener unos requisitos al detalle y lo normal es que más adelante un buen número de los mismos se tengan que redefinir. Ojalá el problema solo fuera ese, ya que el principal es que en muchos casos, estos cambios se solicitan demasiado tarde, cuando buena parte del producto ya está construido, por lo que el coste de hacer las modificaciones suele ser importante.

Y ahí es donde entran en conflicto desarrolladores y área usuaria porque los segundos entienden de manera equivocada y por regla general, que los cambios son de escasa entidad y que el proveedor debe soportarlos.

Las estrategias, enfoques y metodologías ágiles parten de la visión del producto, de tal forma que no es necesario tenerlo especificado al detalle sino de tener presente qué se tiene y a dónde se quiere ir. En este contexto, solo es necesario tener especificada la materia prima de la siguiente iteración (aunque normalmente se trabaja mirando un poco más hacia adelante).

Por tanto, no se define el sistema por completo, sino que vamos trabajando con las funcionalidades más prioritarias (sin perder la visión del producto) y al final de cada sprint se obtiene el feedback del usuario que le permitirá ir haciendo ajustes sobre lo definido.

De esta forma, se hace el esfuerzo que necesita el sistema, no requiere esos largos períodos de análisis que terminan en documentación en donde buena parte de ella no termina ajustándose al producto final (salvo que se haya hecho el esfuerzo considerable de ir actualizándola). Y no solo eso, permite incrementar el valor del producto conforme se desarrolla, a diferencia del enfoque clásico que limita el valor (teóricamente) al que existe en el momento en que se aprueba el análisis.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: