archivo

Archivo de la etiqueta: requisitos

Es cierto que llegado el momento puedes abrir la mano y permitir cambios en las especificaciones, pudiendo negociar el intercambio de requisitos, pero la verdad es que no suele dar buenos resultados por diversas razones: el intercambio no es real (generalmente las tareas que entran suponen más esfuerzo que las que salen, si es que sale alguna), se cambian requisitos sobre visiones abstractas del producto por lo que se siguen realizando a ciegas independientemente de que la visión tenga menos niebla que al principio y además, cambiar de enfoque en determinadas funcionalidades, con el producto avanzado tiene un coste alto.

Esto último también se puede producir en un desarrollo iterativo incremental, lo que lo diferencia es que en muchos casos, la detección del problema se habrá realizado en etapas más tempranas (en el caso de que no sea un cambio de enfoque por cambios en el proceso) ya que los usuarios estarán interactuando con el producto mucho antes.

La gestión de proyectos basados en enfoques clásicos o predictivos es en realidad una gestión del desgaste porque el cumplimiento de la agenda implicará falta de flexibilidad una vez que el análisis inicial se ha completado.

En ese triángulo que forman: alcance, coste y plazos, la modificación de uno de los vértices impacta sobre el resto salvo que exista un margen suficiente que por otra parte casi nunca existe o casi nunca es suficiente. Si no existiendo ese margen se modifica el alcance (o el esfuerzo para conseguir los objetivos, ya que lo mismo el alcance es similar pero la modificación de requisitos sobre componentes construidos hace que sea necesario un esfuerzo mayor ya que el ya invertido hay que contarlo) y se quieren mantener costes y plazos, el primer afectado será la calidad final del producto.

El enfoque clásico o en cascada del desarrollo de software es un modelo de carácter predictivo. Se realiza un análisis del sistema a desarrollar o de los módulos a evolucionar (alcance), se estiman costes y plazos y se trata de gestionar esta agenda (lo que se denomina triángulo de hierro) durante el resto del proceso de desarrollo.

Resulta razonable que pueda funcionar, sin embargo, es un modelo basado en la estabilidad del contexto y en la rigidez de los requisitos y ahí es dónde empieza a tener problemas porque una vez sentadas las bases, lo que cobra prioridad es el cumplimiento de la agenda ya que se entiende que el producto está definido.

La realidad es que los requisitos van a cambiar, conforme vaya avanzando el desarrollo del producto el usuario se dará cuenta de que determinadas especificaciones no son buenas o son mejorables, que se le ha olvidado tal o cual gestión o que las prioridades indicadas tienen que modificarse.

No se trata de que el desarrollador (analista o el componente del equipo que haya hecho ese trabajo) o el usuario lo hayan hecho mejor o peor (por supuesto que un buen trabajo permite trabajar en unas condiciones mucho más favorables) sino de algo que es natural en un proyecto de desarrollo de software y es que haya una evolución ya sea del negocio y/o de la percepción que tienen los usuarios con respecto al sistema de información o algo tan simple y tan frecuente (y humano) como que nos hayamos equivocado.

Esto no es algo que yo me esté inventando, ¿en cuántos proyectos has trabajado en los que no se hayan tenido que cambiar algunos de los requisitos iniciales o se hayan tenido que añadir otros nuevos?.

Como la realidad es esta, tenemos que gestionarla: hay un catálogo de requisitos que permanece vivo a lo largo del proceso de desarrollo.

Como esa es la realidad, los enfoques iterativos incrementales son, a mi juicio, la mejor estrategia para afrontarla, teniendo en cuenta pueden existir proyectos, ¿por qué no?, donde el enfoque clásico sea el más apropiado.

Recuerdo un día en el que charlaba con otra persona sobre las bondades e inconvenientes de las metodologías clásicas y los enfoques ágiles. Me decía que en su organización se había perdido mucho dinero en proyectos desarrollados con metodologías ágiles, antes de preguntarle más detalles, le pregunté que cuánto dinero habían perdido con las cascadas y obtuve el silencio por respuesta.

Dado que por ahí no iba a conseguir avanzar mucho, decidí cuestionarle sobre cómo se habían aplicado las metodologías ágiles y la verdad es que tampoco supo darme mucha más información, en base a lo que me decía interpreté que se aplicaron ciclos de vidas iterativos incrementales con sprints de corta y media duración.

Le comenté que la aplicación de ese ciclo de vida era un primer paso pero que no era suficiente para considerar el enfoque cómo ágil ya que no solo se trataba de aplicar una metodología concreta, sino que detrás debe haber una base conceptual asimilada por buena parte de los intervinientes.

Le pregunté que por qué creía que esos proyectos fracasaron y la respuesta fue que se desarrollaba sin tener una visión clara del sistema a desarrollar, lo que hacía que en cada iteración se tuviera que rehacer buena parte de lo desarrollado en la anterior.

Antes de indicarle mi diagnóstico (y advertirle que para poder ser más preciso necesitaría más información y hablar con más personas), siguió hablando y me comentó que el problema era debido a que no se había hecho un estudio exhaustivo de lo que se quería y eso se obtenía a partir de un catálogo de requisitos.

Le dije que no se necesita llegar a tanto para tener una visión del producto y que el catálogo de requisitos es solo una ilusión, un traslado a un documento de una visión abstracta de lo que se quiere, que probablemente se encuentra lejos de la solución concreta que los usuarios necesitan y que la aproximación a la misma se conseguía a través del feedback.

Es cierto que se necesita tener una visión de lo que se quiere hacer para poder desarrollar con la mayor intención posible pero también que el feedback es inevitable y necesario.

No sé que es peor, si intentar por todos los medios que el contenido del análisis o del catálogo de requisitos sea inmutable o pensar que lo va a ser.

Si has participado en proyectos de desarrollo de software sabrás que (entre otras muchas cosas):

– Los usuarios van aprendiendo conforme el producto se va desarrollando y como consecuencia de ese aprendizaje te van a pedir cambios.

– Lo que en papel o en un generador de prototipos parece sencillo, a la hora de enfrentarse a su construcción puede ser tan complejo que resulte recomendable aplicar otro tipo de estrategia.

– El negocio y/o las prioridades puede cambiar y como consecuencia algunas de las especificaciones iniciales ya no sirven.

En base a estas situaciones pensar que el análisis es inmutable es dejarse cegar por la teoría y exigirlo es ir en contra del valor del producto final.

Te podrás reunir con el usuarios mil veces y las mil veces te cambiará cosas ya sea sobre un análisis o sobre el sistema de información en funcionamiento. En ese camino sin fin hacia la perfección el límite lo pone (o lo debería poner) siempre el usuario en base a las restricciones presupuestarias que tenga el proyecto.

El usuario tiene la llave pero debemos recordarle que se tiene que centrar en sus prioridades y que si invierte excesivo esfuerzo en una determinada funcionalidad es posible que no se cuente con recursos para tener una mínima unidad del producto que sea utilizable.

Es decir, el usuario manda pero tenemos la obligación de comunicarnos con él, expresar nuestras opiniones y de informar sobre los costes, de lo contrario nos encontraremos con una panorama en el que el usuario querrá llegar a mucho más de lo presupuestado y a partir de ahí se entra en una espiral peligrosa en el proyecto que no sabemos realmente hacia donde nos llevará pero que sabemos que ocasionará desgaste, pérdida de dinero y a un producto con una calidad cuestionable.

El usuario siempre estará predispuesto a hacer cambios sobre lo definido y lo implementado algo que se agrava exponencialmente si entran en juego otros usuarios porque cada cual tiene una percepción y gustos distintos. Es cierto que sobre papel y maquetas los cambios tienen poco coste pero también es cierto que son cambios sobre algo que no están viendo en funcionamiento y que les hace tener menos precisión en sus especificaciones (por la complejidad de entender una idea abstracta como es el sistema de información que se va a desarrollar).

Soy partidario de desarrollar con intención y no del prueba y error, también de ir dando pasos hacia adelante y no perdernos en una etapa de análisis sin fin. Alcanzar ese justo medio no es sencillo. Es decir, creo en el desarrollo iterativo e incremental, creo en el desarrollo de software como un proceso evolutivo y creo también que se tiene que entender lo que el usuario quiere y eso puede requerir un tiempo antes de empezar a construir.

Se ha hablado tanto, se ha escrito tanto, son tantos años aplicando ese esquema de trabajo, enseñando ese paradigma como el único camino para el desarrollo de software que desgraciadamente seguimos encontrando casos y casos en los que se sigue pensando que el ciclo de vida clásico o en cascada es el único camino para desarrollar software y que cualquier fisura sobre esa idea es provocada por personas que no creen que el software es un producto de ingeniería.

Me mantengo en lo que digo siempre, cada proyecto requiere su medicina y es posible que en algún caso, la estrategia más adecuada sea la cascada, si bien lo más normal es que lo más adecuado sea tender hacia un enfoque iterativo e incremental y a partir de ahí aplicar los enfoques, estrategias, actitudes, prácticas, instrumentos y herramientas más apropiadas. Pero como decía si crees que la cascada es lo mejor para el contexto del proyecto, aplícala.

Lo que no voy a compartir nunca es que la ingeniería del software está en el lado de las cascada y no existe fuera de él. No es así, es otra forma de entender el desarrollo de software más ajustada, a mi entender, a su propia naturaleza, a la propia naturaleza de los desarrollos, personas y organizaciones.

Querer capturar todos los requisitos a la primera y aceptar es muy complicado porque requiere por un lado que el usuario sea capaz de materializar en palabras una idea abstracta como la que es un producto software y por otro que el desarrollador sea capaz de captar la visión del usuario, todo ello prácticamente a la primera y que después no surjan cambios en los procesos, en la organización, en las personas o en las prioridades que echen parte o todo al traste.

Lo peor de lo que acabo de contar es que en muchas ocasiones pese a que se conoce que hay errores en las especificaciones o que es necesario realizar correcciones motivadas por cambios de contexto no se llevan a cabo las modificaciones necesarias porque ya existe un compromiso entre las partes basado en un catálogo de requisitos inicial. Generalmente no nos encontramos con situaciones de tanta inflexibilidad sino que se llegan a soluciones intermedias que no dejan de ser parches que impiden que el producto final satisfaga las expectativas que se tenían puestas en él.

Me parece muy interesante la reflexión que hace Mike Cohn sobre este tema (traducción libre): “Queremos animar al enfoque de proyectos en los que la inversión, planificación y decisión sobre las funcionalidades sean periódicamente revisados. Un proyecto que cumple con todas las especificaciones del plan inicial no tiene por qué ser necesariamente un éxito. Los usuarios y el cliente probablemente no se sentirán satisfechos cuando vean que nuevas ideas en las especificaciones han sido rechazadas en favor de otras mediocres por el simple hecho de que estaban en el plan inicial”.

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…