archivo

Archivo de la etiqueta: requisitos

En los enfoques clásicos se trabaja en procesos en donde los entregables finales: catálogo de requisitos, análisis, diseño, construcción, etc… tratan sobre un producto completo, ¿existe sobreproducción?.

Si se entiende que se ha contratado el desarrollo de un software en base a unas especificaciones de partida (un alcance), un coste y unos plazos y que se ha decidido que la metodología de desarrollo sea esa, no deberíamos hablar de sobreproducción: se ha hecho lo que se ha contratado.

Otra cosa es que buena parte del trabajo realizado sea efectivo y no lo digo porque crea más o menos en este tipo de enfoques (que ya sabéis que no, pero sin cerrar la puerta a que en proyectos concretos sea la solución más válida), sino porque la propia naturaleza de los proyectos de desarrollo de software y nuestra propia experiencia nos demuestra que trabajar con la hipótesis de que los requisitos van a ser estables, es algo más utópico que real.

Esto quiere decir que si nos cambian requisitos (modificación, eliminación o adición) en cualquier momento (incluso haciéndolo bien y adaptando el alcance), se debería producir una modificación en cadena del conjunto de entregables y elementos de proceso.

¿Hay sobreproducción? Ya dije antes que desde una perspectiva a alto nivel no, pero si lo miramos a una escala de mayor detalle sí que hay un trabajo excedente que se ha realizado y que después lo mismo no se ejecuta o como consecuencia de modificaciones de otras funcionalidades también requiere cambios.

Desde este punto de vista un enfoque clásico se convierte en ineficiente conforme se van rompiendo las premisas iniciales de estabilidad.

Aunque la intención sea que sí la realidad es que no.

Se puede tratar de plasmarlo todo y por muy cuidadoso que se sea siempre habrá algún detalle que se escape. Y lo más importante de todo, cada persona que lea los requisitos podrá darle una interpretación diferente.

De hecho muchos líos que se montan en los proyectos son precisamente por eso, por interpretarse de manera distinta lo que se indica y por cubrir cada cual a su modo los huecos que no se han especificado de forma completa.

Por ese motivo, los requisitos, vistos como el traspaso de los mismos a un documento electrónico o digital es insuficiente si no vienen acompañados por un diálogo continuo entre desarrolladores, product owners, usuarios, etc…, por eso las historias de usuario están venciendo a los requisitos tradicionales ya que parten desde una perspectiva basada en la colaboración.

Pero no solo es eso, los requisitos parten como verdades absolutas, sin embargo, muchas de ellas van perdiendo fuerza conforme avanza la elaboración del producto, surgen nuevas necesidades, se redefinen prioridades y se descubre que diversas percepciones iniciales son incorrectas.

El prototipado, el cartón piedra, el mockup en definitiva, es una herramienta muy poderosa. En el desarrollo de software existe desde tiempos inmemoriales y, desde mi punto de vista, no se le da la importancia que se merece.

Parece que resulta más interesante trasladar requisitos, especificaciones o historias de usuario al lenguaje natural que tener testimonios gráficos de lo que se desea obtener.

Y no solo se trata de tener los requisitos acompañados por un prototipo, lo realmente interesante es que el desarrollador lo explique al responsable funcional, product owner o usuarios implicados, de esta forma se puede comprobar, en primera instancia, que el desarrollador ha entendido el comportamiento y en segunda instancia permite ofrecer una perspectiva menos abstracta de la solución a las personas que deben definirla, algo que agradecerán y agradareceremos porque se conseguirá obtener una descripción más real de lo que se pretende obtener, gracias a esa colaboración que se consigue a través de un instrumento intermedio que las diferentes partes entienden.

No se trata de acertar a la primera, algo que sabemos que es complicado, con y sin estas técnicas, sino de tratar que el desarrollo tenga la mayor intención posible, es decir, que nos ahorremos iteraciones que podían haber sido evitadas.

Podemos discutir el porcentaje pero no el fondo de la siguiente reflexión de Larry Bernstein: “Sólo entre el 40 y 60% de los requisitos de un sistema se conoce al comienzo del proyecto. El resto emerge con el uso. Barry Boehm acuñó el término requisitos emergentes para describirlos”.

Y no se trata de requisitos que aparecen por arte de magia sino que son consecuencia de la evolución que existe entre lo que el usuario cree que quiere y lo que realmente necesita y de la separación que existe entre la visión abstracta de un producto y su implementación real.

De ese porcentaje inicial de requisitos previsibles, una parte importante de los mismos tiene a su vez que ser perfilada también con la utilización del sistema.

Esto al final nos hace ver que los desarrollos llave en mano y/o los ciclos de vida en cascada no se adaptan a esta realidad y por ese motivo no suelen ofrecer buenos resultados y si lo consiguen es porque todas las partes en alguna parte del proceso de desarrollo se dan cuenta de que es necesario llegar a un acuerdo para que el producto se dirija hacia lo que realmente se necesita y no hacia lo que inicialmente era previsible.

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección.

M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

Existen requisitos que tardan en salir a la luz. A veces el usuario lo da por entendidos, en otros casos se da cuenta más tarde o bien se trata de ajustes sobre alguno de los ya especificados.

Es complicado traducir la imagen abstracta del sistema de información que el usuario tiene en la cabeza que en la mayoría de los casos está como cubierta con niebla y que solo se empieza a ver con claridad cuando nos aproximamos a ella (conforme el usuario tenga más claro el producto final con el que se va a encontrar).

Es importante sacar cuanto antes estos requisitos ocultos a la superficie porque a su vez pueden sacar a la luz otros requisitos ocultos y porque pueden tener importancia en el resultado final del producto. Para ello es importante aplicar enfoques iterativos incrementales para que en cada iteración el usuario esté más cerca del producto final y empiece a ver con mayor nitidez determinados aspectos del producto que está esperando así como aplicar otras estrategias o instrumentos como puede ser el prototipado.

Si el usuario no solicita cambios sobre las especificaciones iniciales es una señal de alarma ya que lo más probable es que no haya dedicado suficiente atención a la especificación de los requisitos, a la revisión de los mismos o a las diferentes iteraciones del producto que se están liberando. ¿Es posible que se haya acertado a la primera? Sí, es posible pero yo por si acaso pondría un intensa luz parpadeante de color rojo como alarma.

Cuando el usuario quiera cambiar cosas deberá negociar y en esa negociación suelen quedar tocados tanto desarrolladores como usuarios, los primeros porque el esfuerzo a realizar tras el cambio será mayor, ya que el cumplimiento de la agenda recaerá sobre sus espaldas y los segundos porque no podrán llevar al producto todos los cambios que entienden que son necesarios (el valor del producto está fuertemente limitado por el valor teórico del producto en su especificación) y tendrán, probablemente, un producto de mayor deuda técnica (se descuidará la calidad del desarrollo como consecuencia de incrementar el ritmo de trabajo y del más que probable overtime que tengan dedicar) y con una peor ejecución funcional porque se habrá dedicado menos tiempo (si es que se ha dedicado alguno) a la detección y corrección de incidencias y deficiencias funcionales.

Pero, ¿dónde comienza la gestión de agenda?, ¿antes o después de tener el catálogo de requisitos?. La respuesta natural a la pregunta es que poca agenda puedes gestionar si no sabes lo que vas a hacer y en base a ellos se ha definido un presupuesto y unos plazos equilibrados.

Sin embargo, nos encontramos con dos escenarios:

1) Definición de agenda, una vez definido el alcance inicial del proyecto.

2) Definición de agenda, sin tener una versión inicial del catálogo de requisitos y por tanto, con una estimación del presupuesto y plazos un tanto irreal.

El primer escenario es en el que realmente tendría sentido la gestión de la agenda ya que se da por conocido el sistema que hay que desarrollar y para ello se ha dedicado un presupuesto y previsto unos plazos. Sin embargo, al final, el problema sigue siendo el mismo, porque cuándo surjan modificaciones en los requisitos tocará negociar para mantener la agenda y en caso de desacuerdo el perjudicado en primera instancia será el producto final, en segunda instancia todo el resto de implicados.

En el artículo de mañana analizaremos el segundo escenario que, por desgracia, suele ser el más habitual.