Desarrollo de software. Sacar requisitos a la superficie

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.

Desarrollo de software. Margen de maniobra para el programador

En el desarrollo de software los extremos no son buenos. A veces se le da al programador un diseño tan detallado que básicamente lo que hace es traducirlo a código fuente en el contexto del framework con el que trabaja. Otras veces no existe diseño o bien las especificaciones no son completas y son los programadores solos o en colaboración con analistas los que rellenan los huecos.

Desde mi punto de vista es importante que el programador sepa lo que tiene que hacer, es decir, que las especificaciones las conozca y que también conozca los objetivos no funcionales pero sobre esa base es necesario darle libertad para que dentro de esas restricciones pueda realizar la solución que resulta más conveniente.

Es necesario tener en cuenta que si se realiza un desarrollo en base a un análisis y/o diseño que se realizó hace tiempo es muy posible que quien lo hiciera no tuviera en cuenta determinados factores que sí son conocidos en el presente y no resulta lógico no echar cuenta a una solución mejor por tener en cuenta un trabajo que se efectuó sin conocer determinados tipos de detalles.

También es importante precisar que ese margen de maniobra permite que el programador dentro de esas restricciones pueda expresar su creatividad (algo que todos llevamos dentro) y realice su trabajo más motivado, algo que todos sabemos termina produciendo resultados de mayor calidad.

Como siempre es importante evaluar el contexto. No hay verdades absolutas. Es posible que en determinadas situaciones tener un nivel de detalle importante resulta fundamental, por ejemplo, cuando se externaliza a otro equipo de trabajo las tareas propias de programación de un desarrollo (o parte de él), aunque incluso en estos casos hay que tener en cuenta que la comunicación seguirá siendo necesaria (y se debe considerar un problema si no la hay) porque siempre quedará algún detalle que no se ha especificado al 100%.

Desarrollo de software. Thomas L. Holaday. Resistencia, interrupciones, liberación

El autor y especialista en bases de datos Thomas L. Holaday tiene una cita que refleja el sentir de muchos de los que nos dedicamos a esto, cuando nos encontramos de manera frecuente con resistencias que no hacen sino complicar más lo que ya es complejo de por sí (traducción libre): «La clave que explica el atractivo de los desarrolladores por los videojuegos no son ni los monstruos que escupen fuego o las pálidas sirenas semidesnudas, sino la experiencia de llevar a cabo una tarea de principio a fin, sin los requisitos cambiantes de los usuarios».

Las resistencias no son solo los requisitos cambiantes de los usuarios, es más, en muchos casos no son su variable más significativa. Si cambiamos el «requisitos cambiantes de los usuarios» del final de la cita por «habituales bandazos y resistencias que afectan al ritmo del proyecto», reflejaría, al menos en mi caso, mi estado de ánimo en muchas, tal vez demasiadas, ocasiones.

Desarrollo de software. Productividad y experiencia de usuario

Nos podemos encontrar con sistemas de información que funcionalmente cumplan los requisitos marcados por el área usuaria y que incluso tengan una deuda técnica aceptable pero que sin embargo no satisfaga a los usuarios.

¿Por qué? Pues por el hecho de que el sistema se ha centrado en la funcionalidad sin tener en cuenta lo costoso, complicado o improductivo que pueda ser para el usuario. El sistema se ha desarrollado de espaldas a la experiencia del usuario.

Y en este caso, el usuario lleva toda la razón. El sistema de información debe solucionar problemas, no crearlos, el sistema debe en conjunto mejorar la actividad que se informatiza no empeorarla.

Esto es muy frecuente encontrarlo en sistemas desarrollados siguiendo enfoques clásicos o en cascada en donde en la mayoría de los casos, el usuario no se enfrenta al producto hasta que se les entrega.

Los enfoques ágiles o iterativos e incrementales permiten obtener el feedback del usuario desde etapas muy tempranas, de manera que no solo es sistema puede adaptarse mejor al cambio o es capaz de tener los requisitos más prioritarios más trabajados, sino que además ofrece la posibilidad de que en cada iteración la productividad del trabajo que se realiza a través de la misma y la experiencia de usuario vaya mejorando.

Desarrollo de software. Y esto, ¿quién dijo que se hiciera así?

He escuchado lo mismo en muchos proyectos y lo peor de todo es que muchos de los que preguntaban eso habían sido los que pidieron que se hiciera de esa forma o los que habían autorizado y, por tanto, dado validez, a otros que fueron los que realizaron dicha solicitud.

Al final, salvo que se tenga bien atado de dónde procedieron las especificaciones, la cuerda se romperá por el lado más débil, el del desarrollador.

Es importante que el área funcional sepa de su responsabilidad en el proyecto y que las decisiones que tomen impactarán en positivo o en negativo en el balance del mismo tanto a nivel de calidad como a nivel económico.

Por otro lado, el equipo de proyecto debe tener constancia por escrito y a ser posible, firmada, por parte del área usuaria de la petición de trabajo realizada, así como de sus especificaciones.

Desarrollo de software. Hemos hecho lo que el cliente o usuario nos ha pedido

El producto software que se obtiene finalmente es consecuencia de las directrices que ha indicado el área usuaria. Nos habrá dado unos requisitos, a lo largo del proyecto, habrá cambiado el enfoque de algunos de ellos, otros se desecharán y aparecerán algunos nuevos. Esto es independiente de la metodología utilizada.

Sin embargo el equipo de proyecto no debe ser una serie de ovejitas que van detrás de un partorcito (el usuario), ¿dónde está el valor que aporta el equipo al proyecto? Traducir especificaciones a un lenguaje de programación tiene su complejidad, sobre todo si se hace bien, pero, ¿solo somos traductores?, ¿no somos capaces de proponer alternativas al usuario?, ¿no somos capaces de hacerle vez que tal vez determinadas funcionalidades que solicita en términos coste/beneficio no son ventajosas?, ¿no somos capaces de aportar al cliente toda nuestra experiencia?.

Es muy fácil lavarse las manos y echar toda la culpa al cliente o al usuario (que la tendrán y en algunos proyectos mucha o casi toda) pero, ¿seguro que no somos responsables de nada?.

Desarrollo de software. Contratación ágil II

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

– Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

– Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

– Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un «crédito» a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese «crédito» a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

Desarrollo de software. Antipatrón. Esto no es ciencia de cohetes

Tal vez sea más conocido por «Esto no es la NASA».

Alcanzar el justo medio en el análisis de una solución (ya sean requisitos, modelado de datos, arquitectura, etc…) no es sencillo, tanto es así que lo más normal es que en la mayoría de los casos nos aproximemos al mismo y exista una desviación en defecto o en exceso.

Este antipatrón se produce cuando ante una situación que requiere un análisis y en la que hay que dedicar un tiempo y esfuerzo para realizarla de manera adecuada se decide prescindir del mismo, ya que al fin y al cabo «esto no es la NASA» y tampoco es necesario una solución prácticamente perfecta.

Tan malo es intentar alcanzar algo que no se puede conseguir (la perfección) como prescindir del estudio de un problema, asumiendo que las diferentes contingencias que nos vayamos encontrando las iremos superando y que cualquier aspecto que no se haya definido tendremos conocimientos y bagaje suficiente como para completarlos por nosotros mismos (aplicando por ejemplo otros antipatrones como «el martillo de oro«, «bala de plata» o «introducción de dificultad por analogía«).

Desarrollo de software. Antipatrón. Requisitos ocultos

En el antipatrón «Requisitos esparcidos por la pared» nos encontrábamos en una situación de desorden general en los requisitos: podían encontrarse en distinto grado de acabado, no existía priorización de los mismos o la misma era demasiado general como para poder hacer una ordenación adecuada por ese criterio, etc…, circunstancia que normalmente era provocada por una colaboración (si es que existe) inadecuada por parte del área usuaria.

En el caso de los requisitos ocultos, el origen puede ser el equipo de proyecto o el área usuaria:

– El equipo de proyecto conocedor de la dificultad o coste de implementar un determinado requisito lo obvia dentro del catálogo de requisitos, le asigna una prioridad muy baja o lo engloba dentro de un requisito de mayor nivel quedando difuminado en el mismo. En este caso, el equipo de proyecto es el que origina el antipatrón, pero también tiene responsabilidad el área usuaria y/o el área técnica del cliente por no haber revisados los mismos de manera adecuada.

– El área usuaria no especifica un requisito o no lo especifica de manera adecuada, en algunos casos con el objeto de obstaculizar (o sabotear) el desarrollo del sistema de información y/o el trabajo del equipo de proyecto y en otros simplemente por no haber dedicado la atención adecuada en la etapa o distintas etapas (en función de la metodología) de especificación de requisitos, solicitando explicaciones a posteriori por la no implementación de ese requisito o por su comportamiento incorrecto.

Desarrollo de software. Antipatrón. Requisitos esparcidos por la pared

También por el suelo… o en la papelera.

A este antipatrón se llega por la no asunción de sus responsabilidades por parte del área usuaria a la hora de definir las especificaciones del sistema, priorizar trabajos, responder dudas y realizar feedback.

Si se deja que el equipo de proyecto cubra los huecos en los requisitos el sistema solo cumplirá las expectativas del usuario por casualidad (es cierto que si se tiene en el equipo especialistas en el negocio se reduce el margen de error, pero no hay que olvidar que somos desarrolladores y nuestra visión es siempre de desarrollador, no de usuario).

Si el área usuaria no colabora tendremos una serie de requisitos (unos más completos que otros) y probablemente no exista una priorización de los mismos o la misma sea muy generalista, el efecto es como si tuviéramos una serie de requisitos en post-it esparcidos por una pared, sin orden ni concierto.

Cuando el área usuaria deja de colaborar o no lo hace de manera adecuada, hay que levantar la mano y escalar el problema a nivel directivo de los stakeholders ya que no se puede hacer un proyecto de espalda a los usuarios pese a que estos se la den al mismo.

Si no se pone remedio al final liberaremos un producto que rechazarán total o parcialmente los usuarios, que ahora sí, reclamarán aquel requisito que no se realizó, los que no se interpretaron de manera adecuada (algo que es tan malo como el propio hecho de que no harán feedback ni prestarán más atención que la simple advertencia de su no implementación, de aquellas funcionalidades no incorporadas en la versión liberada de la aplicación) y por qué se ha priorizado tal funcionalidad y no tal otra.

Por supuesto, no lo dudéis, todas las miradas se dirigirán a la parte más débil, el equipo de desarrollo.