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.