archivo

Archivo de la etiqueta: especificación

Parece políticamente incorrecto en el mundo ágil la utilización de la palabra requisito. También, aunque algo menos, la palabra especificación. El motivo principal es su asociación a los desarrollos en cascada y a un modelo de desarrollo basado, yéndonos a un extremo, al dicto, interpreto/apunto, construyo.

Parece que el concepto de historia de usuario se asocia más a la colaboración que es la base en la que se sustenta la agilidad y el enfoque de desarrollo iterativo incremental (os recuerdo que un enfoque o ciclo de vida concreto de desarrollo no es en esencia ágil ya que depende de la actitud con que se aborde).

Estoy de acuerdo en que en determinados momentos usar la palabra adecuada puede ser importante pero tampoco se pierde valor si el fondo realmente dice lo que queremos transmitir. Lo realmente importante, independientemente del nombre que le demos, es que en los ciclos de vida clásicos se piensa en el producto, por encima de analizar y trabajar sobre los problemas reales que se quieren resolver y esto es así, entre otras cosas, porque los desarrollos en cascada piensan en los productos en términos finalistas y en los enfoques evolutivos en términos de valor ganado en aproximaciones sucesivas hacia una determinada solución.

Llega un momento en la evolución de un producto o en un proyecto de desarrollo de software donde echamos en falta todo ese esfuerzo que no se ha aprovechado de manera adecuada, ¿por qué? lo necesitamos ahora o prevemos que lo vamos a necesitar pronto y ya ha desaparecido.

Una de las causas que hacen que el aprovechamiento del esfuerzo no sea óptimo es trabajar con historias de usuario, requisitos o especificaciones que no están claros y en los que existe una probabilidad importante que la solución implementada requiera ser modificada de manera sensible más adelante.

Es mejor invertir el esfuerzo en aquellas tareas donde el retorno de la inversión sea más probable, en donde el efecto sobre el valor del producto sea más inmediato.

Lo que no esté claro debe tratar de solventarse hasta donde se pueda ya que de esta manera se desarrollará con una mayor intención y los ajustes posteriores serán de menor entidad.

Tampoco podemos estar paralizando indefinidamente el desarrollo de una funcionalidad que sea crítica o importante para el sistema pero sí podemos esperar hasta el último momento posible para tratar de que esté lo mejor definida posible.

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

La productividad de un equipo de trabajo dependerá de la efectividad de la solución que desarrollen. De nada vale todo el trabajo realizado si el producto final no es lo que el cliente estaba esperando o lo que es lo mismo, de nada vale todo el esfuerzo invertido si buena parte del desarrollo tiene que ser modificado o directamente se tiene que tirar.

Al final, unas buenas especificaciones del sistema afinadas a través del feedback obtenido en las distintas iteraciones del desarrollo son las que permiten que la productividad del equipo de trabajo salga a relucir, en caso contrario la productividad se desvanece junto al producto.

Milt Bryce consideraba la obtención de buenas especificaciones como la pieza clave para la productividad del programador y los expresaba de la siguiente forma: “Las buenas especificaciones siempre llevarán a la productividad de los programadores más lejos que cualquier herramienta o técnica de programación”.

Incluso en el mejor de los casos donde realmente sean relativamente pocos los cambios a realizar en el producto software una vez entregado, siempre será necesario disponer de un presupuesto para el mantenimiento del sistema de información.

Si esto sucede incluso en la mejor de las situaciones, ¿qué pasa con esos proyectos mastodónticos desarrollados en cascada donde han existido infinidad de contingencias y en los cuales no ha existido una previsión para el mantenimiento del sistema o la previsión se ha quedado muy lejos de lo necesario?.

Pues que probablemente el sistema fracase o que tras mucho, mucho tiempo empiece a ver la luz. Eso sí, tras un desgaste tremendo por parte del equipo de desarrollo que tendrá que trabajar con un sistema mucho más grande que lo que puede abarcar y en un entorno de producción donde las presiones del área usuaria y de la dirección serán constantes.

Me resulta muy curioso cómo determinados directores usuarios se niegan a pagar el mantenimiento del sistema porque entienden que ya han pagado lo suficiente y todo eso a pesar de que son conscientes de que han estado cambiando especificaciones hasta el final y que muchas de ellas no han resultado acertadas.

Al final, uno descubre que se trata, en gran parte, de un problema pedagógico y es que una de las líneas de actuación (tal vez no la más importante, pero sí a tener en cuenta) para empezar a dignificar nuestra profesión, mejorar el resultado de nuestros productos y a la vez la satisfacción del cliente y luchar contra la crisis del software es empezar a formar a los stakeholders no desarrolladores en la realidad de los proyectos de desarrollo de software.

Normalmente se considera ciclo de vida del software a todo el tiempo que transcurre desde que comienza su especificación hasta que la aplicación deja de usarse y tener utilidad, dividiéndose el mismo en una serie de etapas que variarán en función de la metodología de desarrollo utilizada.

Sin embargo, desde mi punto de vista, el ciclo de vida del software no comienza con la especificación, sino que comienza mucho antes, en el momento de que una persona, un departamento o una organización tiene una necesidad que requiere ser resuelta con una solución informática.

Desde la necesidad, hasta que comienza la especificación en el proceso de desarrollo (o incluso el mismo proyecto), pasan muchas cosas como para ser pasadas por alto y que condicionan mucho todo lo que va a pasar después (es en este punto donde la batalla puede comenzar perdida, totalmente perdida o con una buena base para la realización de las tareas necesarias para el desarrollo): delimitación del alcance, definición del presupuesto inicial, determinación de expectativas iniciales, selección del proveedor o equipo de desarrollo, ajuste del alcance tras la contratación de los trabajos o selección del equipo, etc…

Mark A. Ardis es un profesor universitario americano especializado en el área de la ingeniería del software. Cuenta con una importante experiencia académica en diferentes instituciones universitarias americanas, además de haber trabajado en el pasado como contratista de determinados departamentos del gobierno americano y formar parte del área de investigación en Bell Laboratories.

Una cita de este autor, constituye el “One Page Principle” y viene a decir que: “Una {especificación, diseño, procedimiento, plan de pruebas} que no se ajuste a una página de de 8.5 por 11 pulgadas no puede ser comprendida”.

Para conseguir ese objetivo es necesario descomponer en unidades más simples cada uno de esos entregables y centrarse en describirlos de una manera clara y concisa.