archivo

Archivo de la etiqueta: especificaciones

Me parece muy interesante la siguiente reflexión de Jim Horning: “La importancia de las especificaciones formales finalmente debe descansar en su utilidad en si o no se utilizan para mejorar la calidad de software o para reducir el costo de producción y mantenimiento de software”.

Al final, por tanto, es conveniente tener unos objetivos y medir si esas especificaciones, procesos y metodologías nos están llevando a los mismos y hacer las adaptaciones y rectificaciones que sean necesarias para alcanzar esas metas y también, ¿por qué no?, ajustar esos objetivos a la realidad de la organización, ya que, a veces, se pretende alcanzar unos umbrales que no se corresponden al contexto del mercado, de la organización, etc… o que requiere unos tiempos para alcanzarse que son superiores a las expectativas que se tienen.

No se trata de definir normas de desarrollo de software exclusivamente por el simple hecho de armonizar unos esquemas de funcionamiento de los equipos de trabajo o de las propias arquitecturas del software. Esto es importante y generalmente ofrecerá resultados, pero es conveniente plantearse si es posible mejorar, en qué y qué dirección y sentido se debe elegir para conseguirlo.

Como decía al principio, es importante, muy importante, medir y también recoger las impresiones de las personas que trabajan con esos esquemas de funcionamiento, es importante lo objetivo pero es interesante complementarlo con lo subjetivo porque no siempre se acierta con los indicadores que se miden o simplemente no se está midiendo bien.

A partir de ahí, retrospectivas, análisis y adaptación para que cada vez nos encontremos más cerca de las expectativas.

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.

Que los desarrolladores tenemos gran culpa de lo que sigue siendo la crisis del software no nos debe caber duda.

Sé que no es justo que englobe a todos en esto porque hay muchas personas y muchos equipos que tratan de luchar contra esto y están invirtiendo poco a poco la tendencia, no obstante la realidad de nuestro sector sigue siendo esa y por ese motivo, entre otros, no tenemos el reconocimiento que tienen otras profesiones.

Ahora bien, también tienen gran parte de culpa los responsables funcionales, por lo menos para repartirla casi de manera igualitaria, por haber dado malas especificaciones de lo que realmente necesitan y/o por no implicarse de la manera que deberían en los proyectos.

Da igual que tu desarrollo sea perfecto si la orientación que se le ha dado al mismo no ha sido la adecuada.

Una vez puestas las cartas sobre la mesa, tenemos el atenuante de que desarrollar un buen software es una tarea muy compleja y también lo es traducir pensamientos e intuiciones abstractas en especificaciones.

Partiendo de esa base, la elección de una buena estrategia adaptada a las necesidades del proyecto y su contexto, la aplicación de buenas prácticas, la intención de todas las partes por tratar de sacar el producto adelante y la existencia de un presupuesto acorde a las necesidades resultan fundamentales para incrementar las probabilidades de éxito.

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.

En los enfoques clásicos los cambios tardíos en los requisitos suponen un golpe muy duro al proyecto porque suelen llegar cuando se están mostrando los avances en la construcción del proyecto, en las pruebas de aceptación o con el sistema en producción.

Ese feedback dará lugar a nuevas peticiones de cambio por parte del usuario ya advertirán aspectos que no han tenido en cuenta, otros que son mejorables y otros que son incorrectos (ya sea por una mala especificación del usuario, por una mala interpretación de la misma por parte del desarrollador o por una mala ejecución de los trabajos). Como el desarrollo del producto está tan avanzado el coste de estos ajustes será importante en muchos casos, sobre todo si se plantean cambios severos en el núcleo de la aplicación (teniendo en cuenta que la deuda técnica va creciendo conforme crece el tamaño del producto).

En otras palabras, que te cambien los requisitos tarde es un marrón y lo peor de todo es cuando esto sucede en un enfoque predictivo como el clásico en el que teóricamente se espera que esto no suceda (aunque hasta el mayor defensor a ultranza de los enfoques clásicos sepa que esto va a pasar) y en donde resultará complicado hacer ajustes en el presupuesto (algo que habría que hacer cuando los cambios no sean motivados por fallos o negligencia del desarrollador).

¿Es un marrón en un enfoque de carácter evolutivo? No puedo decir que este enfoque sea a prueba de cambios porque no lo es. Si pese a que se ha seguido un desarrollo iterativo incremental en donde el usuario ha aportado su feedback desde etapas tempranas resulta que en fases muy tardías hay cambios severos en el proceso o procesos que se implementan o se descubre que el usuario ha sido negligente te revienta el proyecto, quieras o no, y darle la vuelta al calcetín resulta complicado cuando no imposible si no se ajusta el presupuesto y se resuelven determinados problemas que han dado lugar a esta situación (por ejemplo si el usuario ha sido negligente será necesaria su sustitución).

Partamos de la base de que los cambios son ajustes, unos más grandes que otros pero moderados, y que el objetivo es, como no podría ser de otra manera, desarrollar un producto de calidad que satisfaga las expectativas del usuario, si el usuario detecta que es necesario hacer cambios sobre un producto maduro (incluso con varias iteraciones en producción) se hacen, recordemos que no desarrollamos para nosotros sino que desarrollamos para el usuario y él sabe mejor que nadie qué es lo que necesita y más en estas etapas donde ya están trabajando sobre algo real y en producción.

Lo complicado de esto es que el usuario entienda que todo ajuste tiene un coste, ahí es donde se sustancia el problema, en querer que con un presupuesto inicial realizado desde la más absoluta incertidumbre y con gran desconocimiento del resultado final del producto se cubra todo el trabajo. Si se supera esa resistencia, bienvenidos sean los cambios siempre que los mismos den lugar a una mejor versión de la aplicación.

En un enfoque iterativo incremental se pretende que el producto vaya adquiriendo un mayor valor en cada iteración como consecuencia de la propia evolución del mismo y el feedback que el usuario proporciona al final de cada ciclo.

Esto puede dar lugar (y dará lugar) a una mejora continua de las especificaciones que se han realizado sobre el producto ya que resultará muy complicado que el product owner, por muy bien asesorado que esté, acierte siempre a la primera.

Cuanto más complejas sean las funcionalidades a especificar más probabilidad existirá de que se tenga que iterar varias veces sobre ellas.

Por otro lado, trabajar en base a una agenda implica partir de base con unos plazos y con un presupuesto fijo, los cuales probablemente se han definido sin tener una visión completa del producto a desarrollar, que además será abstracta y sin tener en cuenta los riesgos (imaginando, por tanto, unas condiciones ideales).

De entrada, si los plazos y presupuesto no se corresponden con el trabajo a realizar, el proyecto nace tocado y si la desviación importante, nace hundido (Death March Project) y será muy complicado, cuando no imposible, darle la vuelta salvo que la agenda pueda ser modificada.

Por tanto, en el momento en que estamos iterando y, por tanto, repitiendo determinado trabajo, nos estamos cargando la agenda, es decir, si ya es difícil cumplir con los objetivos de una agenda definida en las condiciones que he indicado anteriormente, más lo será si aplicamos un enfoque iterativo incremental.

La cuestión es, ¿qué se prefiere?, ¿cumplir agendas o intentar que el producto tenga el mayor valor posible?. En muchos casos, la respuesta a estas cuestiones no es negociable, hay por contrato un presupuesto, unos plazos y un alcance.

Si el usuario no termina de tenerlo claro o nosotros no terminamos de entender o captar lo que quiere necesitamos ir puliendo la funcionalidad a través del feedback. En este caso no es recomendable huir hacia adelante y esperar al feedback tras la nueva versión del producto, ya que estaríamos ante una situación de prueba y error, alejándonos del background en el que debe basarse toda iteración: la intención.

Es una generalización, lo mismo si el desarrollo no requiere mucho esfuerzo y el ciclo es corto se puede optar por obtener el feedback tras la construcción de la funcionalidad, como digo siempre: analiza el contexto, las necesidades y decide.

Lo más recomendable en estos casos es trabajar la funcionalidad con prototipos (utilizarlos como un canal de aprendizaje) que requieran el menor esfuerzo posible ya que interesa obtener el feedback cuanto antes y seguir trabajando a partir de él.

Es importante que entendamos lo que quiere el usuario y que el propio usuario traspase a un plano más real lo que tiene en la cabeza. El prototipo no cubrirá toda la distancia entre lo abstracto y la solución final pero si se trabaja bien y el usuario muestra interés ofrece una aproximación interesante que después se puede seguir trabajando a través del feedback de las distintas versiones del producto.