Jummp’s Blog

Jean-Philippe Lang ha publicado hoy que ya está disponible la versión 0.8.5 de Redmine.

En mi organización vamos a esperar todavía a la liberación de la 0.9 antes de migrar la versión que utilizamos actualmente.

Quien lo desee puede descargarse la versión 0.8.5, a través del siguiente enlace.

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.

Me había registrado en la web de Redmine para solicitar que fuera interoperable con Alfresco, antes de hacer la petición, me puse a buscar y encontré que otra persona se ha adelantado. Me gustaría que lo tuvieran en cuenta para la 1.0.

Petición de integración con un ECM.

Para ver lo vivo que está el proyecto, os animo que se paséis por la web de Redmine y veáis la cantidad de peticiones que hay abiertas.

Como ya he comentado en posts anteriores, en mi organización hemos implantado Redmine como herramienta de gestión de proyectos. Le hemos dado muchas vueltas y sopesados diversas soluciones, no obstante, tras la recomendación de un amigo la probé en un proyecto piloto y surgió el flechazo.

De momento las impresiones no pueden ser más positivas.

Es muy sencilla de utilizar y permite integrar una gran cantidad de información relativa a los proyectos. El hecho de que permita guardar documentación, leer del SVN, poder gestionar un wiki y llevar la planificación e incluso la gestión de incidencias, hacen de esta herramienta una solución muy atractiva. Esta integración de información, hace muy interesante la opción denominada Actividad, que prácticamente permite llevar una bitácora todos los proyectos (la sensación cuando le das a Actividad y existen muchos proyectos vivos y actualizándose es impresionante y habla bien a las claras de lo que es una organización que busca la calidad en el proceso de desarrollo de software).

¿Qué no es perfecta? Así es, pero… ¿qué herramienta de gestión de proyectos lo es?.

Además de las funcionalidades tan interesantes que tiene la herramienta, cuenta también a su favor el hecho de que sea software libre y que su comunidad de desarrollo tenga una gran actividad, lo que hará muy probablemente que la herramienta siga adquiriendo funcionalidades nuevas y mejorando las ya existentes en su core y vayan saliendo extensiones que aporten valor añadido a la solución. Ahora mismo la última versión liberada es la 0.83, pero la siguiente versión la 0.9, con más funcionalidades está a la vuelta de la esquina.

Si estás pensando en implantar una herramienta de gestión de proyectos, ni lo dudes, prueba Redmine, no te dejará indiferente en absoluto.

Evidentemente poner en marcha una herramienta de gestión de proyectos no es sencillo, ya que la información no se almacena sola en la misma y es necesario que exista una disciplina detrás de su uso, pero eso será motivo de otro post…

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.

Pese a que la llevo utilizando desde hace algún tiempo para la gestión de mis proyectos, he tomado la decisión de implantarla en mi organización para que pueda ser utilizada por el resto de jefes de proyecto.

Lo que más me gusta de Redmine es su extremada sencillez, eso, junto al ser un producto libre y ser un proyecto muy activo han sido claves para la decisión final.

Con esto no quiero desmerecer a otras opciones como por ejemplo dotProject, que me parece muy completa, pero la veo más orientada a su utilización por parte de una empresa de desarrollo de software.

Lo que he encontrado con Redmine es la sencillez y la inmediatez de las acciones que se hacen con la herramienta.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

- Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

- Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

- Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

- Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

- Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

- Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

- Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.

Independientemente de la carga de trabajo que tiene cada uno, resulta fundamental realizar una adecuada planificación de las tareas. Si además, la carga de trabajo es crítica, la planificación resulta fundamental.

En mi caso me dedico a la gestión de proyectos informáticos, lo cual en el ámbito de mi organización significa hacer multitud de tareas además de la propia gestión ordinaria de los proyectos. Si no llevara una planificación de las tareas diarias a realizar (independientemente de que muchos días la planificación se vaya al traste al surgir de forma “espontánea” asuntos de mayor urgencia o aparezca un cambio de prioridades por parte de los superiores) la gestión de mi tiempo sería nefasta (con esto no quiero decir que sea buena, ya que tengo que mejorar mucho en lo que a gestión del tiempo se requiere, pero seguro que sería peor y los resultados de mi trabajo además serían peores).

Además, sin una planificación de los proyectos y sus principales hitos, el control de los mismos sería mucho más complicado. Además de dicha planificación temporal de los proyectos que cualquier que se dedica a esto la realiza, es muy importante la herramienta a utilizar, la cual es de sumo interés (a mi juicio) que sea compartida por las dos partes: el cliente y el desarrollador.

A mi particularmente me gusta dotProject, aunque últimamente he hecho una prueba con Redmine y probablemente termine imponiéndose esta última para llevar a cabo la planificación temporal de los proyectos.