archivo

Archivo de la etiqueta: catálogo de requisitos

Comenta Frederick Brooks en su libro “The Mythical Man Month” que: “La mayoría de la documentación falla en que se da muy poca visión global. Se describen los árboles, se comentan la corteza y las hojas pero no hay un mapa del bosque”.

Estoy bastante de acuerdo con esa afirmación ya que resulta complejo obtener una visión global del sistema simplemente con la lectura de la documentación del proyecto porque como dice Brooks la información está segmentada y se describe con más o menos detalle cada uno de esos segmentos pero no el funcionamiento en conjunto de todos ellos.

Y todo esto en el caso de que haya alguien que revise la documentación de manera más o menos concienzuda, porque esa es otra, se pueden invertir innumerables horas de trabajo en tratar de hacerla con la mayor calidad posible, pero al final hay personas que tienen que leerla y entenderla y no suele haber gente con mucho tiempo y/o paciencia para iniciar sobre ella un proceso iterativo de revisión y mejora.

Esto es un problema importante cuando se desarrolla basado prácticamente en exclusividad en la documentación y no se suple esa carencia a través de la comunicación con personas que puedan ofrecer la información necesarias para cubrir los huecos en la misma lo que provoca generalmente problemas de coherencia en el sistema y aspectos funcionales a los que el desarrollador da una solución sin entender realmente qué lugar ocupa esa funcionalidad dentro del sistema.

La solución, como comento en el párrafo anterior, es la comunicación y además (y en lo posible) en explicar lo que tiene que hacer el sistema y las expectativas del usuario a quien no haya tenido la oportunidad de conocerlo, algo que generalmente (y desgraciadamente) no se suele hacer.

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.

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.

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”.

Estoy de acuerdo con Jeff Sutherland cuando comenta que “Los documentos con requisitos de gran tamaño, rara vez se leen y mucho menos se siguen”, realmente lo que interesa es conocer lo necesario para desarrollar una funcionalidad, ni más ni menos y eso va más allá de la formalidad que requieren los catálogos de requisitos.

Como es lógico en el caso de sistemas críticos se podría plantear una mayor formalidad y un mayor nivel de detalle, pero la realidad es que la mayoría de los sistemas no requieren de catálogos de requisitos de esas características que además quedan obsoletos en la siguiente iteración del producto, salvo que se sigan escrupulosamente los procesos y se utilicen las herramientas adecuadas, lo que requiere un importante esfuerzo que habría que evaluar lo realmente necesario que resulta.

No se trata de renunciar a los requisitos sino de utilizar fórmulas que resulten más livianas como pueden ser las historias de usuario que tienen como misión específica describir una determinada funcionalidad que vamos a implementar a corto plazo. En el futuro la historia de usuario será una referencia de lo que se desarrolló en un momento concreto del tiempo que no es poco porque realmente: ¿necesitamos mucho más?.

Se trata de iterar en el lugar equivocado.

Iterando en el análisis lo único que estaremos haciendo será depurar cada vez más unos requisitos que no son más que meras hipótesis (con más o menos fundamento) de lo que quiere el usuario.

Un prototipo, otro prototipo, tal vez algún esqueleto andante, una nueva versión del catálogo de requisitos, otra, otra, para que después, cualquier circunstancia (cambio de interlocutores, cambio de prioridades, cambio de los procesos que se pretenden informatizar, etc…), todo se pueda desmoronar y el proyecto, con una gran cantidad de esfuerzo invertido se quede sin nada o casi nada.

Para que la iteración tenga utilidad requiere de una entrega completa, que pueda ser usada por el usuario y de ahí obtener el feedback necesario para obtener una versión y más completa en el siguiente incremento.

Las pruebas de aceptación son aquellas realizadas por los usuarios con carácter previo al paso a producción de una nueva versión del producto. Se trata de pruebas de caja negra en un entorno de preproducción en la que se verifican si las funcionalidades pactadas para la entrega y recogidas en catálogos de requisitos, casos de uso, historias de usuario u otro hito documental, cumplen las expectativas del usuario.

El problema de este tipo de pruebas es que en demasiadas ocasiones los usuarios (o sus jefes) rechazan invertir tiempo suficiente para realizar estas tareas de testing y en otras, los equipos de desarrollo tampoco ponen demasiado interés en ello.

En desarrollos siguiendo metodologías clásicas o en cascada si no se ha hecho participar al usuario en fases posteriores al análisis y no se han hecho ajustes, las pruebas de aceptación servirán para poco porque probablemente, salvo que el desarrollo sea de poco alcance, habrán variado las condiciones iniciales o bien el usuario se encontrará con una implementación que aún respetando los requisitos (que está por ver) será complicado que verifique lo que se imaginaba que iba a hacer el sistema.

Sin embargo en mantenimiento evolutivos o correctivos pequeños, ciclos de vida iterativos incrementales (con sprints de corta duración) o mediante la aplicación de metodologías ágiles, este tipo de pruebas sí que tendrían una gran utilidad porque se evita pasar evoluciones a producción que pueden afectar a un trabajo eficiente de los usuarios con la aplicación.

Un amigo me comentó hace poco que efectivamente los principios y metodologías ágiles establecen un marco de trabajo y un proceso de ingeniería del software que sientan unas bases para la entrega de un software de calidad, entendiéndose en este caso como la consecución de un producto que satisfaga las necesidades y expectativas del usuario, pero que tenía serias de que pudiese solucionar el ajuste al presupuesto (sobre todo) y plan de proyecto establecido.

Los principios y metodologías ágiles como bien indicaba mi amigo son instrumentos y los mismos por sí solo no garantizan nada. Es lógico pensar que con las mejores herramientas se trabaja mejor y se pueden obtener mejores resultados de una manera más eficiente. Sin embargo, lo que se obtiene al final es el resultado de la aplicación de las mismas por personas (ya pertenezcan al equipo de desarrollo, al área usuaria o a los responsables técnicos del cliente) en un proyecto concreto. Si las personas fallan, los instrumentos no pueden solucionar por sí solo nada, tal vez pueden hacer que el estropicio sea menor, pero poco más.

Por ese motivo en el desarrollo de software lo más importante son las personas, todo lo demás puede ser más o menos importante, pero viene después.

Partiendo de esa base, la aplicación de estrategias ágiles ni garantiza nada, ni produce milagros.

Si un proyecto tiene un presupuesto y/o plazos que no se ajustan a la realidad del objeto del trabajo y/o de las expectativas del usuario da igual que el equipo de proyecto sea el mejor, que estén motivados y que la metodología sea la más apropiada al proyecto, ya que lo más probable es que no se consigan los resultados que se esperan a nivel de calidad, presupuesto o plazos.

Los que nos dedicamos al desarrollo de software no estamos para hacer milagros sino que estamos para intentar hacer nuestra labor de la mejor manera posible y para ello se requiere un equilibrio entre lo que se pide, se espera, se tarda y lo que cuesta.

Lo anterior es complejo, sobre todo porque la estimación de esfuerzo a alto nivel de un proyecto (no de tareas concretas) puede fallar y a partir de ahí, lo más probable es que fallen también los plazos.

Para estimar un proyecto que se va a desarrollar siguiendo estrategias ágiles soy de la opinión que hay valorar el proyecto en primer lugar sin tener en cuenta el feedback del usuario en cada iteración y sobre esa estimación inicial aplicar un factor de ajuste, teniendo en cuenta la complejidad funcional y técnica del proyecto, así como las características de los usuarios que van a intervenir.

Por tanto, aplicando ese método el coste que debe salir será superior que el de si se realizase el cálculo teniendo en cuenta una metodología en clásica o en cascada, ya que mientras en esta segunda los costes de mantenimiento se aplican después, en las metodologías ágiles se pueden realizar mantenimientos desde la primera entrega, por lo que hay que tenerlos en cuenta en el propio coste del proyecto.

Con respecto a los plazos es importante conocer las expectativas del usuario en ese sentido y desde el primer momento darle a conocer lo factible o no que resultan sus deseos y que la estrategia a seguir será establecer una priorización de sus requisitos, para que cuando la fecha límite llegue, se tenga construido lo más importante.

Como decía al principio, todo esto son ideas, consideraciones, herramientas y estrategias, que como fundamento teórico para la realización de un proyecto pueden estar bien (o no estar de acuerdo con ellas), sin embargo, al final, lo realmente decisivo son las personas.

Opciones hay muchas. Precisamente hoy he estado hablando de este asunto con algunos compañeros. Hemos consensuado que la solución con menos overhead y más flexible, es utilizar un documento por cada tipo de documento del proyecto, es decir, un catálogo de requisitos, un documento de casos de uso o cualquiera que se utilice en función de la metodología y del tipo de proyecto, siendo extensible por ejemplo a historias de usuario, diagramas de despliegue, etc… que vaya creciendo de manera incremental con cada evolución, pero que en contenido vaya creciendo de manera diferencial.

Es decir, el documento contiene el contenido de las iteraciones anteriores y el de la actual, pero en la parte dedicada a la actual solo se incluye lo correspondiente a esta evolución y solo recoge de las anteriores lo estrictamente necesario para ayudar a la comprensión de la misma.