archivo

Archivo de la etiqueta: Redmine

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.

Ha sido liberado el plugin de Chuck Norris para Redmine en su plataforma oficial de plugins.

La funcionalidad es sencilla, en la sección de Overview del proyecto aparece una cita de Chuck Norris y en la parte inferior de la pantalla aparece una imagen del mismo aprobando el proyecto si más del 50% de las peticiones están cerradas y se mostrará contrariado en caso contrario.

No era de extrañar que el amigo Chuck Norris terminase por llegar a esta herramienta de gestión de proyectos que tanto éxito está teniendo, aunque él piense realmente que para gestionar proyectos le baste con una servilleta y un lápiz.

Aquí podéis ver una imagen del plugin ya instalado en Redmine.

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.

Se ha liberado la primera versión oficial de Redmine 1.0. Personalmente me alegro mucho de que este proyecto siga evolucionando ya que es la opción de gestión de proyectos que hemos implantado en mi organización y con bastante éxito y satisfacción entre el resto de responsables de proyecto.

No fue idea mía implantar esta herramienta ya que fue una recomendación, pero lo importante, como he repetido en tantas ocasiones no es que a uno se le ocurra la idea sino que aunque sea de otro, el rendimiento que se le pueda sacar a la misma sea positivo.

Yo recomiendo el uso de este software ya que es tremendamente sencillo y potente y sobre todo por la capacidad de evolución que tiene que lo irá dotando progresivamente de cada vez más utilidades y además permite personalizar determinadas funcionalidades a través de plugins ya sean propios o desarrollados por terceros (los más significativos se van implementando dentro del núcleo del producto, como por ejemplo la posibilidad de definir subtareas que ya no requiere la utilización de plugins).

Para ver las novedades de esta versión os dejo un par de enlaces (de la página oficial de Redmine), uno referido a la última release candidate y otro a las novedades de la 1.0.1 respecto a la versión candidata:

Redmine 1.0.0 Release Candidate

Redmine 1.0.1

De un tiempo a esta parte en mi departamento, se ha tomado la decisión de comenzar a procedimientar determinados procesos que tenían lugar dentro del mismo, algo que por otra parte era necesario ya que muchas tareas llegaban a los técnicos que las tenían que ejecutar por múltiples medios (correos electrónicos, Service Desk, teléfono, oralmente, etc…), lo que por un lado impide medir la carga real de trabajo, por otro impide priorizar tareas de manera adecuada y por último daba lugar a que se perdiesen determinadas peticiones e incidencias.

De esta manera se han dado los pasos adecuados para centralizar todas las peticiones e incidencias a través del Service Desk, tanto las que procedan de usuarios por diversos motivos (microinformática, aplicaciones, etc…), las de consumo interno dentro del Departamento de Informática, así como las que procedan de proveedores de servicios TIC que tengan contratadas determinadas tareas, como por ejemplo desarrollo de software (el proveedor, con la autorización pertinente de la Dirección del Proyecto, puede también reportar incidencias (por ejemplo, se ha caído tal servidor de aplicaciones) o realizar peticiones (por ejemplo, solicitar la asociación de un determinado usuario a un proyecto en SVN).

Una vez que se ha tomado la decisión de centralizar peticiones e incidencias en el Service Desk, toca delimitar su competencia con otras herramientas que utilizamos dentro del departamento, como por ejemplo Redmine (esto es más sencillo, ya que aunque Redmine gestiona peticiones, son aquellas relacionadas con la actividad interna de un proyecto concreto) y Mantis, que gestionaba peticiones e incidencias para procesos concretos del departamento de desarrollo (generalmente peticiones relacionadas con la solicitud de recursos sobre alguna de las herramientas que componen nuestra infraestructura de desarrollo e incidencias producidas en el proceso de paso a producción de las aplicaciones). En este nuevo marco, Mantis quedará como bugtracker dentro del proceso de desarrollo de software, de uso interno en cada proyecto.

Vale, tenemos Redmine y es estupenda, pero la herramienta por sí sola no hace nada, hay que meterle datos y actualizarla. Las políticas que estamos intentando poner en práctica en nuestra organización son:

1.- Dar de alta los proyectos y subproyectos con una descripción muy detallada de sus objetivos y funcionalidades.
2.- Asociar a cada proyecto como mínimo los jefes de proyectos, analistas y directores técnicos.
3.- Asociar a cada proyecto su rama del Subversion correspondiente, tirando de la raíz de la rama y no solo de la rama trunk.
4.- Que se planifiquen todas las tareas del proyecto y se realice un seguimiento semanal de las mismas, de manera que si hay que hacer un ajuste de la planificación se realice semanalmente y explicando el por qué. Además semanalmente se deberá indicar el grado de avance en porcentaje del proyecto (no requerimos una precisión matemática, pero sí una aproximación realista).
5.- Que mensualmente se reporten los incurridos en cada una de las tareas.
6.- Todos la documentación de los proyectos se deberá entregar por Redmine, discriminando la que afectan a todo un proyecto o a una tarea del mismo.
7.- Administración distribuida. Todos los directores técnicos son administradores, además de existir una administración específica para atender a las peticiones de los proveedores.

Como veis, no son muchas reglas y son sencillitas, con el paso del tiempo tal vez le demos una vuelta de tuerca más, pero en principio son suficientes para poner en marcha el producto con garantías.