Archivo de la etiqueta: Gestión de proyecto

Redmine como herramienta para la gestión de un departamento TIC

En los últimos años, uno de los proyectos más interesantes en los que he participado es la implantación de un sistema de gestión de proyectos TIC en la unidad en la que prestaba servicios.  Las unidades TIC son, en general, complejas de organizar debido sobre todo a la variedad de aplicaciones y tecnologías existentes, a la gran demanda que las unidades de negocio hacen de dichos aplicativos y a lo complejo que es compaginar los proyectos que el negocio demanda con los proyectos que son requeridos por la propia organización TIC y por la evolución de la tecnología.

Existen muchos modelos de unidades TIC pero, además de lo comentado anteriormente, todas ellas comparten cierta complejidad derivada del modelo de contratación y del modelo de gestión de la demanda implantado. Podemos destacar los siguientes puntos a este respecto:

  • Gestión de la contratación con proveedores y acompasamiento de la misma con las necesidades de las unidades de negocio. La contratación en general, y la contratación TIC en particular, es compleja y requiere de una gestión muy pormenorizada para obtener la máxima eficiencia.
  • Gestión de los objetos de la contratación, los cuales pueden variar a lo largo de la vida del contrato a demanda de las unidades de negocio. Existen fórmulas de contratación que permiten este modelo de demanda cambiante, aunque tradicionalmente no ha sido así y las unidades han estado muy restringidas por la definición de los objetos de un contrato, realizada con mucha antelación y sin los datos adecuados (fallo del modelo tradicional de desarrollo en cascada).
  • Implicación y descripción funcional. Es complejo implicar a las unidades funcionales en el propio ciclo de desarrollo (por ejemplo como Product Owners si hablásemos de SCRUM) de forma que participen en las pruebas y evolución de los requisitos. Normalmente los requisitos llegan muy poco formalizados (lo cual no es un problema en un modelo iterativo cuando la implicación funcional posterior es alta pero si lo es en un modelo de definición previa de entregables) y , casi siempre, en el último momento y con poco margen de maniobra.

Es por todo esto que es necesario dotar a la unidad TIC de los más eficientes mecanismos de gestión que minimicen toda esta complejidad y, es ahí, donde alguna herramienta nos puede ser de gran utilidad. Creo que las organizaciones se dividen en dos tipos: las que cambian cuando lo hace su entorno y, por tanto, se ven obligadas a cambiar, o las que se adelantan al entorno para propiciar y gestionar sus propios cambios. Sin duda, las organizaciones tipo 2 son más eficientes por lo que no se deben posponer este tipo de proyectos internos para “cuando haya un hueco”, sino que deben ser acometidos como parte estratégica de la unidad. Como he comentado antes, no es fácil compaginar estos proyectos estratégicos internos con el despliegue de nuevas funcionalidades demandadas por el negocio pero es la labor del profesional TIC saber hacerlo porque de eso depende el éxito de la unidad ya que, inevitablemente, el desarrollo de negocio no podrá sostenerse en el tiempo sin una evolución continua en los métodos de gestión y en el aprovisionamiento de nuevas infraestructuras tecnológicas.

Centrándonos en el tema de las herramientas, muchas son las opciones disponibles. Lo que buscamos es un sistema que nos permita enlazar todas nuestras tareas de desarrollo (y explotación y sistemas) con los requisitos del negocio e incluso con la gestión de la configuración. De esta forma, es muy fácil obtener ventajas y resultados a corto plazo:

  • Alineamiento de cada actividad de la unidad con los objetivos de la organización. Su visualización en cuadros de mando puede ser de gran impacto para la dirección.
  • Seguimiento y gestión de las tareas desde un nivel de agregación propio de la dirección (TIC y no TIC) hasta el nivel más detallado posible.
  • Gestión de los objetos de la contratación e incluso, seguimiento de un contrato gestionado basado en unidades de trabajo (facturación, recepción, etc.). Esto puede ser de gran importancia incluso en contratos de servicios en los que el equipo de la empresa no está en nuestras instalaciones.
  • Gestión de la configuración como paso previo y necesario en la integración o despliegue continuo.
  • Etc.

El proyecto que describo partía de la utilización de unos ficheros Excell, de tratamiento muy complicado, en los que se reflejaban los principales proyectos e hitos de la Subdirección. Estos ficheros se revisaban en las reuniones mensuales que tenían lugar dentro de la gestión de las diferentes áreas de desarrollo y sistemas y eran la herramienta básica de control para la Oficina de Gestión de Proyectos, de reciente creación. Es cierto que se disponía, en algunas áreas, de la herramienta Team Foundation Server de Microsoft para la gestión de ciertos proyectos de desarrollo en tecnología .NET pero, claramente, estas herramientas no proporcionaban lo que la unidad demandaba por lo que optamos por realizar un proyecto de implantación y distribución al negocio de una herramienta para la gestión de procesos de la unidad TIC.

La herramienta que elegimos nosotros, después de sondear el mercado, fue Redmine, por ser software libre y, sobre todo, por ser sencilla y altamente configurable. Sobre la versión inicial del producto, que puedes instalar en una máquina física o virtual e incluso, de una forma más cómoda, como contenedor Docker, hicimos algunos cambios para “customizar” la aplicación a nuestro entorno corporativo. Para ello, lo primero que hicimos fue cambiar el tema y crear una división basada en las sub-unidades que componían la Subdirección TIC.

Áreas en Redmine

Obviamente, hubo que realizar un gran trabajo de instalación, configuración de roles y permisos, tipos de peticiones y campos de las mismas, parametrización de áreas, etc, y sobre todo, un gran trabajo de concienciación y gestión del cambio implantando la herramienta área por área. Destaco lo poco que tuvimos que invertir en optimización de la herramienta siendo un único nodo el que puede dar servicio a toda la subdirección sin ningún tipo de problema.

Configuración de Redmine

Es importante señalar que, como ocurre muchas veces en este tipo de proyectos, el principal escollo del proyecto no fue la parte tecnológica, sino la gestión del cambio. Hubo que realizar una gran labor de comunicación, formación y persuasión interna para minimizar la resistencia al cambio y conseguir llevar a cabo el proyecto con éxito implantándolo a nivel global dentro de toda la unidad.

Vistazo en el panel de Redmine

Mediante el uso de Redmine logramos dar un gran vuelco a la forma en la que se gestionaban los proyectos en la unidad consiguiendo llevar un control más exhaustivo y, por tanto, corrigiendo desviaciones mucho más rápido, así como dotando de transparencia a los diferentes procesos de la unidad.

Los usos principales que le dimos nosotros al sistema son los siguientes:

  • Gestión de proyectos de desarrollo y operación. Esto comprende la definición de requisitos (incluso con documentos adjuntos), la gestión de tiempos y calendarios, la gestión de sub-tareas y su asignación, etc. Esta gestión era especialmente útil en las diferentes reuniones de seguimiento que se llevaban a cabo en la unidad.
  • Seguimiento del trabajo por la dirección. A través de la herramienta es muy fácil ver en qué está la unidad y cual es su grado de avance de cara a presentar resultados a la dirección del organismo (no TIC). Igualmente, es muy fácil clasificar proyectos y alinearlos con la estrategia de la dirección del organismo obteniendo una alineación perfecta de la unidad TIC con los objetivos de la organización.
  • Seguimiento del trabajo por las unidades de negocio. A través de la herramienta las unidades de negocio pueden aportar requisitos, seguir la evolución de los desarrollos y comprender la complejidad y diferentes partes que entran en juego en el desarrollo de sistemas de información.  El sistema de avisos de Redmine, basado en el envío de correos, resultó muy útil para avisar de cambios en el estado de un desarrollo a una unidad de negocio, de forma que puede implicarse en la definición de objetivos, realización de pruebas y corrección de desviaciones. Destaco lo importante que puede ser para las unidades no TIC tener visibilidad y participación en el desarrollo, ya que reduce tensiones y aumenta la sinergia entre las unidades.
  • Gestión de la configuración. Cualquier cambio en código debe ser asociado a una petición (historia de usuario, tarea o error) de Redmine, permitiendo un seguimiento preciso de los requisitos de negocio que propiciaron un cambio. De cara a la implantación de un sistema de integración o despliegue continuo, esta conexión del código (que se despliega automáticamente) con el requisito es fundamental.
Conexión Redmine – Git
  • Seguimiento de la contratación. Los diferentes objetos fruto de la contratación de servicios, son seguidos y gestionados por la unidad desde esta herramienta, asociando proyectos a contratos.

Además de esto, la unidad hizo gran uso del módulo Wiki que incluye Redmine como herramienta colaborativa para la reducción de la documentación en la Subdirección, dentro de un desarrollo mucho más ágil y no basado en documentación.

Wiki en Redmine

Por último, añadir que esta herramienta puede ser utilizada para otros propósitos más generales, especialmente para la gestión de incidencias a modo a como actualmente se utiliza de forma muy extendida Jira (muy parecida a Redmine). La utilización de la herramienta  también para la gestión de las incidencias  de los aplicativos permite cerrar completamente el ciclo de desarrollo, es decir, permite tener enlazada una incidencia con  el código que la corrige y la historia de usuario que generó la funcionalidad a corregir, avisando de un evento a los distintos roles (funcionales o TIC) involucrados en el proceso cuando se produce una corrección.

Primeros pasos en SCRUM

De cara a poner en marcha un proyecto gestionado con SCRUM son muchas las cuestiones a tener en cuenta. Algunas de las más importantes, en mi opinión, son las siguientes.

El primer punto a considerar es el equipo de desarrollo del que se dispone. Las metodologías ágiles recomiendan la utilización de equipos pequeños que se autogestionen. Esto, en realidad, no es algo nuevo de las metodologías ágiles, sino que parte del sentido común y la experiencia. Los equipos con pocos miembros (4-6) son más sencillos de controlar y la información fluye mejor entre los componentes.

En segundo lugar hay que tener en cuenta el espacio en el que se ubica el equipo. Es muy aconsejable que todos los componentes estén juntos y que tengan la lista de tareas visible en todo momento. En mi opinión, no hay herramienta más potente  para recoger la lista de tareas de un sprint que un tablón visible por todos los miembros del equipo y ante el que realizar el SCRUM diario. Yo utilizo este:

Además del tablón, es útil emplear una herramienta informática en la que registrar toda la lista de tareas (pila de producto y pila de sprint) y poder asociarla a cambios de código. Son muchas las herramientas disponibles en el mercado para ello.  Yo utilizo Microsoft Team Foundation Server porque es el gestor de configuración del que disponemos.

En tercer lugar, hay que definir cómo tratar las diferentes clases de tareas que intervienen en el desarrollo de software y definir el concepto de terminado para cada una de ellas. Cuando digo los diferentes elementos del desarrollo me refiero a análisis, bugs, tareas de configuración de los sistemas, pruebas, manuales de usuario, etc. Cómo gestionar estos elementos depende del tipo de proyecto en el que se esté trabajando e incluso puede ser conveniente realizar adaptaciones a medida que se avanza. Te cuento cómo tratamos nosotros algunos elementos, por si te sirve de ayuda:

  • Los bugs los gestionamos como cualquier otro elemento no planificado que surja en un sprint, es decir, se registra, se valora su importancia y se estima el esfuerzo necesario para resolverlo. En base a esto se decide qué hacer con él. Un error muy común en el desarrollo, y al que tienden todos los equipos irremediablemente, es abandonar el trabajo que estaban haciendo cuando aparece un error, por poco importante que sea.
  • La inclusión de tareas de análisis en SCRUM es complicada. Son elementos complicados de estimar y que tienden a retrasarse. No hay una regla para incluir estos elementos. Una buena idea puede ser demorar el inicio del sprint algunos días realizando tareas de análisis con el objetivo de poder estimar mejor posteriormente el esfuerzo de cada tarea y no tener que incluir en el sprint elementos de análisis. Esta demora también puede servir para romper (no por mucho tiempo porque también es un riesgo) el alto ritmo de desarrollo en el que se encuentra un equipo durante un sprint y proporcionarle un respiro.
  • Las pruebas de cualquier elemento desarrollado se incluyen dentro del concepto terminado de la tarea, es decir, para que una funcionalidad esté terminada tiene que incluir sus diferentes pruebas (unitarias, integración, aceptación, etc.).
  • Los manuales o guías de usuario los considero un elemento más de una funcionalidad, por lo que se añaden y planifican como el resto de elementos. Cuando no lo hemos hecho así, este tipo de tareas tiende a dejarse para última hora, con mucho riesgo de no hacerse al final.

En cuarto y último lugar, lo fundamental es implicar al equipo en el proceso de gestión del proyecto. Una tarea fundamental del SCRUM master es conseguir que el equipo crea en el sistema, participe en su mejora, sea participativo en las reuniones y aprenda a utilizar las herramientas de gestión disponibles. Esto genera equipos autogestionados y mucho más productivos.

 

 

Gestión de proyectos con SCRUM

A lo largo de mi experiencia laboral en la empresa privada y en la Administración Pública, he visto pocos equipos y proyectos que se gestionen adecuadamente.
Adecuadamente, para mi, significa cumplir una serie de condiciones que considero básicas en la gestión de proyectos:

  • Existe control del estado de avance del proyecto.
  • Existe capacidad de planificación y cumplimiento de plazos.
  • Se extrae el máximo rendimiento de los miembros del equipo.
  • Se genera un producto mantenible y de calidad.
Algunos equipos consiguen de forma aislada algunos de estos puntos, pero es complicado encontrar equipos que cumplan con todos. Quizás yo haya tenido mala suerte, pero creo que es fiel reflejo de lo que ocurre en la mayoría de centros de desarrollo software en España.
Aunque cada vez son más comunes los proyectos que se gestionan con metodologías ágiles, la tendencia hasta hace poco ha sido aplicar ciclos de vida en cascada a los pocos desarrollos que seguían algún tipo de metodología. En la administración pública española, la metodología recomendada es Métrica 3, la cual plantea un modelo de ciclo de vida en cascada.
Desde mi punto de vista, pocos son los proyectos a los que este tipo de ciclos de vida en cascada son aplicables. La principal razón de esto radica en que los requisitos rara vez pueden establecerse y congelarse, sino que tienden a variar. La metodología de gestión de nuestro proyecto debe proporcionar flexibilidad en este sentido.
Por eso, y tras varias experiencias fallidas con otras metodologías, hace tres años que utilizo en mis proyectos SCRUM como metodología de gestión y, a día de hoy, puedo decir que pocas veces he acertado tanto en una decisión. Las metodologías ágiles te puede ayudar a conseguir varias cosas, para mí, de vital importancia en la gestión de proyectos:
  •  Flexibilidad ante cambios en los requisitos. 

La variación de los requisitos es algo mucho más común de lo que querríamos dado que el usuario del negocio no suele saber lo que quiere hasta que lo ve. Incluso aunque se establezcan largas tareas de análisis de requisitos, habrá que realizar cambios y nuestra metodología de gestión debe dar soporte a estos procesos.

El objetivo de las metodologías ágiles es la liberación frecuente (un mes como mucho) de entregables que el usuario puede utilizar, de forma que no es necesario esperar a tener todo el producto para corregir posibles desviaciones. Esta característica está muy en consonancia con el tipo de software que se desarrolla en estos tiempos: productos que se implantan y se hacen evolucionar adaptándolos a nuevas necesidades hasta que quedan obsoletos.
  • Alineación con una estrategia corporativa de despliegues periódicos. 
La mayoría de organizaciones de cierto tamaño realizan actualizaciones frecuentes de las aplicaciones para corregir incidencias o sacar nuevas funcionalidades siguiendo un calendario de paradas. En mi organización, por ejemplo, la periodicidad es mensual. Una metodología ágil, como SCRUM, se adapta perfectamente a estos escenarios.
  • Priorización de objetivos por el usuario de negocio.
La sensación que tenemos ahora mismo en la Administración es que cada vez somos menos, tenemos que hacer más cosas y de una forma más eficiente. Desde el negocio cada vez se nos pide más y se nos dan menos recursos para ello. SCRUM te puede ayudar, a través de la figura del dueño de producto (en este caso el usuario de negocio), a definir prioridades y a calcular cuanto puedes hacer en cada entregable. De esta forma, es el propio usuario el que debe decidir que quiere tener el próximo mes y de qué funcionalidades puede prescindir.
  • Control diario del avance del proyecto y del trabajo del equipo.
Si utilizas una metodología ágil, como SCRUM, realizarás una revisión diaria del estado del proyecto. Podrás saber diariamente cuál es el grado de cumplimiento de lo planificado y qué trabajo ha realizado cada miembro del equipo. La información fluye con rapidez y las malas decisiones se corrigen muy rápidamente.
  • Mayor implicación del equipo de desarrollo
Otras de las grandes máximas que he sacado en mi experiencia desarrollando software es que los equipos grandes no funcionan. Muchos son los motivos de esto (información que no fluye, gestión compleja de muchas personas, etc.) pero en mi opinión, uno de los factores importantes es la poca implicación de los componentes del equipo de desarrollo. Es más complicado mantener motivadas a 15 personas que a 6.
La gestión ágil se basa en trabajar con equipos  pequeños, no jerarquizados y autogestionados  en los que la información se comparte con periodicidad diaria. Cuando un miembro del equipo conoce los objetivos del desarrollo, es participe del proceso de gestión del proyecto y de la toma de decisiones y debe exponer su trabajo con periodicidad, su motivación y su rendimiento aumentan muy significativamente.

La utilización de SCRUM como metodología de trabajo ha sido, en perspectiva, un gran acierto para el correcto desarrollo de los proyectos en los que trabajo. La implantación no ha sido fácil. Hemos tenido que definir nuevas formas de trabajo y adaptar la metodología a lo que nosotros necesitábamos para nuestros proyectos (situaciones de análisis, BUGs, manuales de usuario, eliminación de burocracia interna, sistemas de estimación, tablón de SCRUM, etc…).

En posteriores entradas detallaré cómo hemos resuelto nosotros algunos de los aspectos más conflictivos de la implantación de SCRUM por si pueden serte útiles.