archivo

Archivo de la etiqueta: Alfresco

Se ha publicado en el repositorio oficial de Redmine un par de plugins que pueden resultar de mucha utilidad, ya que permiten almacenar documentos en una ubicación distinta de la que Redmine te ofrece por defecto, lo que ofrece una serie de ventajas.

En el primero de ellos Redmine se integra con el servicio Dropbox y en el segundo con sistemas compatibles con CMIS como por ejemplo Alfresco.

Ambas alternativas permiten otra forma de acceder y compartir la documentación que se ha incorporado a través de Redmine, lo cual puede resultar de interés si lo que se quiere es compartir documentación sin necesidad de dar acceso a la herramienta de gestión de proyectos.

Por otro lado, el plugin de CMIS permite, si se estima conveniente, la incorporación de documentos a sistemas de gestión documental, lo que permite optimizar el almacenamiento y organización de los mismos.

La implantación de procedimientos dentro de un departamento de desarrollo de software produce beneficios y por tanto un retorno de la inversión.

El principal inconveniente que encuentra es la reticencia del personal a cumplirlos ya que en su mayoría piensan que toda esa burocracia es una pérdida de tiempo.

El primer error es pensar que se trata de burocracia o por lo menos en el sentido negativo en el que se suele entender ese término, obligarte a seguir una serie de pasos para realizar determinadas acciones no es burocracia, son procedimientos. Esto no quita que el diseño de los procedimientos deba ir acorde con las posibilidades que tiene el departamento, si se va más allá de lo que se puede abarcar, estamos ante una situación contraproducente (no se terminarán por seguir los procedimientos y además se producirá una reducción de la eficiencia).

No es necesario empezar a procedimentarlo todo de la noche a la mañana. Lo mejor es ir poco a poco, que el personal se vaya acostumbrando a esta otra forma de trabajar, más ordenada, que permite, por todos, una mayor control de las acciones que se realizan.

Los procedimientos irán acompañados de herramientas (o por lo menos es aconsejable). En mi organización los procedimientos internos del departamento de desarrollo y nuestra interacción con el resto de departamentos del área TIC se realizan básicamente con 5 herramientas:

– Un Service Desk como componente que integra todo el conjunto de incidencias y peticiones en producción.
– Redmine como sistema de gestión de proyectos: planificación de tareas e interfaz con el repositorio documental (en nuestro caso Alfresco, aunque perfectamente se podría haber utilizado la propia herramienta como gestor documental).
– Alfresco, como repositorio documental.
– Mantis para el reporte de incidencias en la fase de pruebas de la aplicación.
– Una software de agenda compartida, para la gestión de nuestras citas y reuniones.

Como comenté antes, no se trató de implantar un conjunto de procedimientos de la noche a la mañana, sino que se hizo paulatinamente, asimismo no todas las herramientas se implantaron a la vez, ni el grado de uso de las mismas fue intenso desde el primer momento. Ha sido el tiempo y también determinadas decisiones de los responsables de informática los que han consolidado los procedimientos y las herramientas.

No son las únicas herramientas que utilizamos en el departamento de desarrollo ya que la realización de determinados procesos, requieren de otras herramientas complementarias que nos aportan, además una serie de ventajas:

– Subversion: Como sistema de gestión de fuentes y sus versiones.
– Artifactory: Como repositorio de librerías dependientes.
– Hudson: Para la automatización del proceso de compilación, generación del desplegable e interacción con Sonar (tenemos previsto próximamente el uso de Hudson para realizar el despliegue completo de una aplicación).
Sonar: Para el análisis estático de código.
– Enterprise Architect: Diseño de modelos (requisitos, casos de uso, etc…) y de documentación a partir de los mismos.

Como he comentado antes, los procedimientos requieren herramientas y las herramientas procedimientos, los unos sin los otros no terminan por producir buenos resultados.

Los procedimientos deben estar por escrito y ser dados a conocer por quienes los tienen que cumplir y se debe hacer un seguimiento de su implantación, por lo menos hasta que se consiga que la organización asimile la nueva dinámica de funcionamiento.

¿Por dónde se empieza? Supongamos que ya tenemos definida una dinámica de trabajo en cuanto al propio proceso de codificación de software, si no es así, ese debe ser el inicio (es decir, habría que establecer un framework de desarrollo, la selección de un IDE, de un sistema de gestión de versiones, una herramienta de integración continua, etc…, unos entornos de preentrega, un sistema de atención interna de dudas, sugerencias, etc… en el proceso de desarrollo (así como la persistencia de aquellas que sean más interesantes, para permitir la consulta futura), etc…

A partir de ahí, el siguiente paso debe ser controlar hacia dónde se enfoca la dedicación de los empleados, lo que hace necesario la existencia de una herramienta de imputación horaria. Esta gestión de incurridos es fundamental si la función principal de tu organización es la prestación de servicios a terceros. En el caso de mi organización no tenemos ninguna herramienta de esas características porque somos principalmente clientes de los trabajos (lo que ha hecho que no sea algo prioritario).

A continuación se debe trabajar en la gestión de las entradas de incidencias y peticiones por parte de terceros, así como su planificación. De esta forma se consigue dar un orden al trabajo, saber qué esta haciendo cada cual en cada momento y poder planificar los recursos humanos en el tiempo, de manera que se reduzca el número de tiempos muertos y cada persona se utilice, en la medida que sea posible, en aquellos proyectos y actividades donde se pueda aprovechar de mejor manera su potencial.

Lo comentado en el párrafo anterior se puede hacer en paralelo, con la obligación de que cada reunión con un cliente tenga como resultado final un acta (siguiendo en la medida de lo posible un mismo formato y que se almacena de la misma forma para todos los proyectos), que además debe ser enviada a los mismos. Como podéis ver, estos procedimientos que no requieren gran esfuerzo implantarlos, producen beneficios innegables. Solo requiere pequeños cambios en algunas de las rutinas de los empleados (el desarrollo de software es mucho más que tener abierto Eclipse toda la jornada laboral).

Una vez llegado a este punto resulta recomendable integrar el sistema de imputación horaria con el sistema de planificación de proyectos para tener el tiempo real que se ha invertido en cada tarea.

Sabemos cuánto se ha presupuestado cada proyecto, cuánto se lleva invertido en cada uno y aproximadamente el grado de avance en los mismos. Con esas variables es posible conocer el estado de los costes de cada proyecto, algo fundamental para detectar desviaciones a tiempo y tomar medidas (de nada sirve detectar que hay problemas si no se toman decisiones al respecto).

¿Por dónde se sigue? A partir de aquí, entrarán en juego, las preferencias personales. En mi caso, yo potenciaría el establecimiento de una normativa documental en los desarrollos apoyada en una herramienta CASE. Los desarrolladores odian documentar, principalmente porque no se sabe documentar (duele, pero es la verdad) y porque no se tiene un procedimiento, técnica y mecánica para hacer que ese proceso “insufrible” sea menos doloroso, es decir, que haga que el proceso de documentación sea más eficiente y productivo. Si con documentación vas a tener problemas con el cliente de todas maneras, ya sabemos todos los problemas que se tiene cuando se carece de ella, donde al final el cliente meterá casi tantos goles por la escuadra como quiera, ya que él dispone de todas las cartas y tú de ninguna. Además, la documentación puede guiar el proceso de desarrollo, cuestión de acostumbrarse a trabajar con ella y además permite dar un acabado a los proyectos que puede dar lugar, en muchos casos, a marcar la diferencia entre un proveedor y otro.

¿No crees en los procedimientos? Prueba a implantar alguno, hazle un seguimiento y mide los resultados, lo mismo cambias de opinión.

El principal problema de los inventarios es que tienden a quedarse obsoletos y esto pasa con cualquier inventario que quieras hacer, ya entren, salgan o se modifiquen elementos del mismo, con más o menos frecuencia (evidentemente el grado de obsolescencia del inventario es mayor cuanto más movimiento tenga).

Para mantener un inventario actualizado hay dos opciones (la primera de ella puede ser muy costosa, en función de lo que se quiera inventariar):

1) Contratar a tantas personas como sean necesarias para mantener el inventario al día (la dedicación no tendría que ser completa, pero sí debería ser su mayor prioridad que el inventario esté siempre actualizado).

2) Integrar el mantenimiento del inventario, dentro de los procesos que pueden modificar su estado. Por ejemplo, si tenemos un software que gestiona las compras, una vez realizada la compra este software debería actualizar el inventario.

En el proceso de desarrollo de software hay muchos inventarios que mantener:

– Fuentes.
– Componentes.
– Documentación.
– Librerías.
– Participantes.
– Planificaciones.
– Contrataciones (si se externaliza el proceso de desarrollo) y su ciclo de vida.
– Sistemas de información, etc…

Y además necesitan estar integrados entre sí, ya que no se debe entender una versión de un sistema de información sin al menos las librerías (no funcionaría), componentes reutilizables (no funcionaría) y la documentación del mismo.

En los departamentos TICs de las organizaciones es fundamental tener el inventario software actualizado (y otros inventarios: hardware, relación elementos físicos con elementos lógicos, etc…) y la única forma de conseguirlo, por la naturaleza de los desarrollos de software, es integrar el mantenimiento de los inventarios dentro del proceso de desarrollo de software. Cuanta más rica sea la integración, mayor calidad tendrá el inventario y un mayor conocimiento de lo que es todo el proceso de desarrollo de software en su conjunto.

Incluso teniendo integrados en su mayor parte los elementos que conforman un desarrollo, se requiere siempre un esfuerzo para que el mantenimiento del inventario sea de calidad. Ese esfuerzo consiste en utilizar además de los elementos que se recomiendan en la organización, como pueden ser: SVN, Artifactory, Redmine, Alfresco, etc…, en seguir las políticas y procedimientos de la organización. Es decir, si la política de la organización es que semanalmente se actualice la planificación y avance del proyecto en Redmine y no se sigue, perderemos la visión del estado de los proyectos (la gestión del proyecto en sí: planificación, participantes, incurridos, etc… es otro inventario), algo que es fundamental en los procesos de construcción y mantenimiento del software.

En mi departamento seguimos dando pasos pequeños, pero firmes para tener una infraestructura de desarrollo de software en condiciones.

– El uso de Subversion ya es generalizado, por lo que tenemos un control absoluto sobre los fuentes de las aplicaciones.
– El uso de Artifactory también es generalizado, por lo que también tenemos un control absoluto sobre las librerías que se utilizan y las tenemos en un espacio distinto a los fuentes.
– El uso de maven para las entregas e implantación también es generalizado y se está generalizando la implantación mediante Hudson.
– Tenemos un libro blanco de desarrollo que de un tiempo a esta parte ha orientado los desarrollos a una arquitectura y una tecnología común, lo que facilita la reutilización y el mantenimiento. En la actualidad se está retocando dicho libro para actualizarlo tecnológicamente, acotar un poco más el abanico de posibilidades y soluciones a utilizar y modificar drásticamente la forma de documentar los proyectos, basándonos en una herramienta CASE (independientemente de que haya documentación extra-CASE).
– La metodología de peticiones de entregas y de comunicación de incidencias en las pruebas con las empresas desarrolladoras también se está generalizando.
– La documentación de los proyectos está centralizada en un ECM (en nuestro caso Alfresco), con una estructura de carpetas por proyectos. Esta forma de organizar la documentación va a variar con la nueva versión del libro blanco que como he comentado se va a basar en el uso de una herramienta CASE.
– Se ha terminado de implantar una herramienta para gestionar los proyectos de manera que no tengamos la gestión en diversas herramientas y soluciones. A partir de ahora vamos a tratar de que la gestión de todos los proyectos esté centralizada en Redmine. Probablemente más adelante “truquemos” Redmine para comunicarlo con Alfresco, para añadirle alguna característica como la gestión de incurridos, etc…

Todavía nos queda mucho camino por recorrer, pero creo que la dirección que hemos tomado es adecuada. Mi único mérito en todo este asunto ha sido escuchar y dejarme aconsejar por gente que sabe mucho, muchísimo de lo que es el proceso de desarrollo de software. También hay que destacar la acogida que ha tenido esta infraestructura entre mis compañeros porque sin su colaboración nada hubiera sido posible.