archivo

Archivo de la etiqueta: documentación

Los procesos y la documentación generada en los mismos son instrumentos dentro de un desarrollo de software que de por sí no solucionan los problemas que podamos encontrarnos en los mismos.

Cuando se cree que por sí solos permiten que el proyecto avance estamos pasando de una visión orientada al producto a una visión orientada al cumplimiento de trámites que no es lo mismo ni se le parece.

Puede vestir mucho el cumplimiento a rajatabla de los procesos y la entrega de toneladas de papel, pero lo único que importa realmente es que el producto software satisfaga las expectativas de los usuarios y sea de calidad.

Hay una cita de Jim Highsmith al respecto que no requiere más comentarios: “La documentación no es comprensión, el proceso no es una disciplina, la formalidad no es una habilidad”.

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

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.

Para empezar habría que definir qué se entiende cómo documentación de calidad. Para mi una documentación de calidad es un instrumento que sirve como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

Por tanto, la documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria. ¿Formalismos? Puedo entender que una organización quiera una homogeneidad en la documentación de los proyectos pero las normas deben ser lo suficientemente flexibles para que cumpliendo ese objetivo no sobrecarguemos a los desarrollos con exceso de documentación (más documentos de los necesarios), con excesos en cada documento (que cada documento tenga más contenidos de los necesarios) y con exceso de formalismo.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado y con menor deuda técnica.

Cuando la documentación pasa de ser un medio o una herramienta a ser considerado un fin es un síntoma de que algo no marcha bien en la definición de los procesos de desarrollo.

¿Cuándo se considera un fin? Cuando las normas y procedimientos exigen de los documentos una formalidad y unos contenidos que superan las necesidades que se tienen en el proyecto y en consecuencia se produce un sobrecoste y un esfuerzo innecesario que se incrementa conforme hay que ir realizando actividades de mantenimiento de dicha documentación.

No debemos olvidar que muchos documentos por mucho formalismo y por mucho contenido que se les quiera dar son prácticamente de usar y tirar, es decir, sirven para un momento concreto del desarrollo y después terminan estando desfasados y su utilidad es prácticamente nula. Y esto en el mejor de los casos porque después hay documentos que nadie lee.

Por este motivo dos variables que se deben tener en cuenta a la hora de definir la carga documental de un proyecto o las políticas de desarrollo de software de una organización son el período de validez o vigencia del documento y su valor como herramienta de apoyo al proceso de desarrollo.

Existen reglas en la organización en la que estamos trabajando y tenemos que cumplirlas, otra cosa es que se abra un debate interno sobre la necesidad de relajar ciertos aspectos que se controlan en los procesos y que dificultan un desarrollo ágil de los proyectos sin que exista un beneficio evidente en unos procesos tan rígidos.

Si ese debate interno no existe, se debería iniciar, siempre con un máximo respeto ante las personas que se encargan de supervisar el cumplimiento de los procesos y que también son los encargados de su actualización.

Con respeto se pueden cambiar las cosas, sin respeto tal vez también se consiga pero se abrirán brechas que tardarán mucho en cicatrizar y que afectará la relación entre personas, lo que a su vez impactará en los proyectos.

Dentro de esas reglas, se encuentran las relacionadas con la documentación de los proyectos. Por muy rígidas que sean siempre tendremos nuestro margen de maniobra en la revisión del contenido del documento, en aspectos formales o en el continente tengamos poco que hacer ya que probablemente sea revisado por terceros en base a una serie de reglas definidas. Mi consejo es que valores realmente si el contenido cumple el propósito que se pretende con él y no pierdas el tiempo en revisar aspectos formales adicionales a los definidos en las reglas (yo he hecho eso y es un error, ya que no aporta nada y supone un esfuerzo extra tanto para ti como para el desarrollador).

Los manuales de una aplicación, de una interfaz de comunicación presentan los problemas típicos de cualquier documentación y es que si no se contempla dentro del proceso de desarrollo de software su actualización y/o una correcta gestión de la configuración nos encontraremos con mucha documentación que realmente ha servido mucho menos que el esfuerzo que ha sido necesario para generarla y otra que probablemente haya quedado desfasada.

Ya sabéis mi opinión sobre la documentación: cada proyecto debería tener solo aquella que sea estrictamente necesaria para el mismo respetando las directrices de calidad del proceso de desarrollo de nuestra propia organización y de la organización para la que se desarrolla debiendo tenerse en cuenta en los costes del proyecto el necesario para gestionar la documentación como parte del propio proceso de desarrollo.

Si la documentación se entiende como un elemento aparte, sucede lo que en la mayoría de los proyectos, algo que Ray Simard resume de manera muy acertada cuando define de manera irónica lo que es un manual: “Unidad de documentación en la que hay siempre tres o más unidades y/o versiones. Una está accesible y alguien tiene las otras. La información que necesitas se encuentra en las otras”.