Archivo de la categoría: Gestión ágil

Gestión de proyectos con metodologías ágiles

Redmine para la gestión de la contratación de un organismo

En una entrada anterior, “Redmine como herramienta para la gestión de un departamento TIC”,  comenté como el uso de aplicativos de gestión de procesos o tareas puede ayudar en la gestión de las actividades de una unidad TIC. Igualmente, estos gestores de tareas pueden ampliarse fácilmente para utilizarlos como herramientas más específicas del control del trabajo de un área determinada del negocio. En este caso, comentaré como se puede utilizar Redmine para la gestión de la contratación de un organismo.

Todo organismo público tiene una unidad o área dedicada a la contratación o a la coordinación de la contratación del resto de unidades. Comúnmente, esta unidad o área es también la responsable de la gestión presupuestaria del organismo ya que son tareas que van muy unidas. Es común también que estas unidades o áreas utilicen, para la gestión de los expedientes de contratación y la gestión presupuestaria de los mismos, las aplicaciones que informática de la Intervención General del Estado pone a disposición de los organismos. Siendo estás aplicaciones muy adecuadas para la gestión desde el punto de vista de la parte contable y presupuestaria, no es posible en ellas realizar un seguimiento de las tareas propias del organismo o unidad. En el caso de la contratación y la gestión presupuestaria, las tareas a realizar son en muchos casos labores de intermediación entre la unidad que realiza el contrato y los organismos fiscalizadores o que actúan como órgano de contratación, por lo que es muy importante para el aumento de la eficiencia llevar un control preciso de esas tareas de intermediación y de los tiempos de las mismas. La respuesta a toda mejora organizativa no es siempre una herramienta informática pero es cierto que algunas herramientas informáticas permiten una mejora de los flujos de trabajo, y este es uno de esos casos.

En este caso y después de analizar varias opciones, nos hemos decidido de nuevo por Redmine como sistema de seguimiento de las tareas de contratación en la Dirección General del Catastro. Dado que la herramienta estaba implantada en el área de informática con muy buenos resultados, la implantación de la misma para la Secretaría General, responsable de la contratación y los presupuestos del organismo, era una tarea muy abordable y con un rápido retorno.

En primer lugar, fue necesario crear un área específica de trabajo en el ámbito de la contratación, obviamente con acceso restringido a los usuarios apropiados. En este caso, se ha establecido un acceso a distintos niveles:

  • Área de contratación de la Secretaría General: responsable de la tramitación contable y presupuestaria de los expedientes de contratación
  • Área de presupuestos de la Secretaría General: responsable del seguimiento presupuestario de los expedientes.
  • Áreas de negocio de otras subdirecciones, responsables del negocio de los contratos e impulsoras de los mismos. Estas áreas pueden iniciar los expedientes, así como realizar el seguimiento del estado de tramitación de los mismos.

 

Área de contratación en Redmine
Área de contratación en Redmine

Posteriormente y quizás el trabajo más importante de configuración, hay que establecer los tipos de peticiones que vamos a ser capaces de gestionar con el sistema. En nuestro caso son variados:

  • Procedimientos abiertos y negociados (y sus prórrogas) en los que el órgano de contratación es la Junta de Contratación del Ministerio.
  • Procedimientos abiertos y negociados (y sus prórrogas) en los que sí somos órgano de contratación.
  • Acuerdos Marco.
  • Contratos menores.
  • Contratos de gestión centralizada, es decir, aquellos que nos prestan servicios pero son llevados por otros órganos, como el de correos postales por ejemplo. Nos interesa reflejar duración y pliegos en este caso.
  • Encomiendas de gestión.
Vistazo del área de SG en Redmine
Vistazo del área de SG en Redmine

Para cada una de estas peticiones es necesario definir campos customizados en Redmine y flujos de estado. Este es un trabajo que requiere gran esfuerzo y debe ser realizado con minuciosidad. Sirve, en nuestro caso y creo que en el de muchas organizaciones, para definir correctamente los estados y flujos de la tramitación de los diferentes expedientes, lo cual es un gran avance para una unidad que vive de la tramitación de expedientes de contratación. Es sorprendente como habitualmente los flujos de contratación no son conocidos al detalle por la totalidad del personal dedicado a estas labores por lo que el trabajo de definición y documentación es un gran paso para la unidad y permite realizar una simplificación de algunas tareas internas relacionadas con estos procesos de contratación.

Flujo de trabajo para un procedimiento abierto
Flujo de trabajo para un procedimiento abierto

En el caso de los campos, nosotros hemos definido, a través de campos fecha, toda interacción que se realiza con unidades y organismos externos a la Secretaría General, generalmente fecha de ida y fecha de vuelta. Esto nos permite tener muy controlados las siguientes tareas a realizar, en el tejado de quién está la pelota y cuanto tiempo lleva en manos de otro o en nuestras manos un trabajo. Así hemos economizado mucho los tiempos de tramitación.

Campos de tipo fecha para un expediente de contratación
Campos de tipo fecha para un expediente de contratación

Obviamente, también hemos tenido que definir campos propios de la contratación que nos permiten el control presupuestario o el enlace con aplicaciones externas que llevan también temas de contratación, como Sorolla2 o la Junta de contratación. Esto último es muy útil para el personal que se ve obligado a trabajar con varias aplicaciones y permitirá, a la larga, una redirección automática.

Campos propios de la contratación
Campos propios de la contratación

Además, hemos definido otros campos de texto o tipo link para diferentes utilidades, como enlaces a la plataforma de contratación, adjudicatarios, controles internos o simplemente  observaciones del tramitador.

Obviamente, una parte fundamental para nosotros es guardar todos los documentos que componen el expediente y tenerlos accesibles a un solo click, así como la historia de su tramitación a través de las notas de las peticiones.

Documentos anexos a un expediente de contratación
Documentos anexos a un expediente de contratación

Respecto a los documentos, inicialmente no guardamos los documentos contables ya que estos los tenemos en Sorolla2, pero posteriormente y por comodidad de los tramitadores, se han ido incorporando. Se ha creado un flujo de digitalización de entrada y archivo  de todos los documentos que nos llegan en papel para que dichos documentos sean puestos a disposición de los tramitadores en formato electrónico a través de la herramienta según nos llegan y no circulen físicamente por las mesas, dado que en alguna ocasión se ha producido algún extravío de la documentación. De esta forma, la unidad de archivo gestiona el flujo de documentos en papel y realiza la custodia y expurgo de los mismos.

Un aspecto muy útil para nosotros que viene incorporado al sistema es la personalización de búsquedas sobre las peticiones, los cuales nos permite definir diferentes avisos o consultas para el seguimiento de las tareas. Algunos ejemplos son:

  • Expedientes en trámite (agrupados por subdirección, por aplicación presupuestaria, etc),
  • Tramites de la Secretaría General pendientes: solicitud de inicio, envío a fiscalización, solicitud de insuficiencia de medios, etc.
  • Trámites de otros organismos que están pendientes.
  • Siguientes solicitudes de comprobación que debemos realizar.
  • Etc.
Avisos sobre trámites de contratación en Redmine
Avisos sobre trámites de contratación en Redmine

Además de estos avisos, Redmine dispone de su propio sistema de alertas ante eventos de las peticiones, que permite seguir por email, mediante suscripciones a la petición, los expedientes que interesen. Sin embargo, aunque el sistema de alertas y avisos de Redmine cubre todo lo principal, en la Secretaría General se requería de alguna actuación complementaria más avanzada que permitiese realizar un control sobre los expedientes incorporados, generar avisos más sofisticados o cambiar el estado e importe de las peticiones según se van tramitando.  En concreto, requeríamos realizar las siguientes acciones de forma automática:

  • Cambiar el estado de un expediente  cuando se producen ciertos eventos registrados en campos de tipo fecha que indican un estado de tramitación diferente. Por ejemplo, al rellenar el campo de aprobación del expediente, éste pasa automáticamente a estado “Aprobado”.
  • Comprobar automáticamente la corrección de los importes, las fechas de inicio y fin y las anualidades reflejadas, las aplicaciones presupuestarias consignadas, etc.
  • Generar avisos por correo de ciertas actuaciones que la dirección quiere conocer, como envíos realizados al Secretario de Estado, finalización e inicio de contratos, etc.
  • Calcular el importe facturado. En una segunda fase de evolución del sistema hemos incluido los pagos como otro tipo de petición hija de un expediente de contratación. En este caso, nos interesa actualizar en el expediente padre la información agregada de los pagos realizados.

Para ello, hemos desarrollado una sencilla aplicación que realiza todas estas comprobaciones, genera los avisos y actualiza las peticiones en función de los campos de tipo fecha que se han rellenado.

Código de la aplicación
Código de la aplicación

La aplicación está escrita en Java con maven como gestor de despliegues. He publicado su código en mi página de Bitbucket por si le quieres echar un ojo.

La aplicación se ejecuta tantas veces al día como queramos a través de un sencillo proceso Jenkins.

Trabajo en Jenkins
Trabajo en Jenkins

Por último, indicar también que dentro del proyecto de digitalización de procesos en la Secretaría General nos ha sido de gran utilidad el módulo wiki de Redmine, ya que nos ha permitido definir colaborativamente las principales tareas de contratación de la unidad. Cada usuario de la Secretaría General involucrado en contratación y presupuestos puede insertar o editar las entradas de la wiki que versan sobre materias como las siguientes:

  • Aplicaciones utilizadas en la contratación.
  • Principales trámites para la gestión de contratos.
  • Principales documentos gestionado y requeridos en los expedientes de contratación.
  • Agenda de contacto con otras unidades.
  • Instrucciones dadas por organismos externos.
  • Etc.
Wiki de la Secretaría General
Wiki de la Secretaría General
Detalle wiki Secretaría General
Detalle wiki Secretaría General

En conclusión, la implantación de Redmine en la Secretaría General de la Dirección General del Catastro ha sido un completo éxito. Todos los expedientes de contratación “vivos” en 2017 han sido incorporados al sistema y han sido tramitados electrónicamente a través de él. La herramienta ha tenido una gran aceptación y nos ha permitido mejorar la eficiencia de los trabajos realizados. En concreto, destacaría los siguientes puntos de mejora:

  • Permite tener registro histórico de todas las actuaciones realizadas de forma que es posible la utilización de esa experiencia en tramitaciones similares.  El conocimiento queda ampliado a través de la
  • Permite ver el grado de avance de la tramitación de los expedientes, tanto por el personal directivo del área de contratación y presupuestos como por las unidades de negocio.
  • Permite el acceso sencillo a la documentación de los expedientes.
  • Permite la implementación de controles automáticos más fiables que los humanos.

De cara al futuro, la herramienta tiene un gran potencial de mejora. Desde conectarse a otros sistemas de tramitación de la intervención, Junta de contratación o Plataforma de Contratación del Estado hasta extender la herramienta a otras áreas del negocio.

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.

Agilidad en las Administraciones Públicas

Como os comenté, en febrero dí una charla sobre Agilidad en las Administraciones Públicas dentro de la comunidad Managment 3.0.

En la charla, tratamos los principales problemas que presenta la aplicación de metodologías ágiles dentro de la Administración Pública. Surgieron temas como contratación pública, cesión ilegal de trabajadores, establecimiento de objetos en los pliegos, etc. En definitiva, creo que quedó clara la idea entre los asistentes (muchos del sector público) de que la Administración es un sitio diferente y que, por tanto, la aplicación de técnicas de agilidad requiere de una visión algo diferente.

Os dejo la presentación aquí por si queréis echarle un ojo.

Retos del Peopleware y el Agile Management en la Administración Pública española

Hace poco asistí a un curso sobre desarrollo ágil dado por Javier Garzás. Lo cierto es que era el segundo curso de este tipo que recibía de este mismo ponente y, como el primero, me resultó muy productivo.

El curso tenía por objeto formar a nuestro departamento de desarrollo en frameworks ágiles y, en general, en prácticas ágiles. Desde hace tiempo, estamos intentando implantar métodos más ágiles de desarrollo que nos permitan avanzar más rápido y nos parecía que todo debe partir de una visión al exterior y de un cambio cultural de nuestro propio personal de desarrollo.

Como digo, el curso resultó muy productivo en cuanto a contenidos y exposición de los mismos pero, según iba avanzando, nos dimos cuenta de que las mismas preguntas surgían una y otra vez. Todas ellas tienen que ver con cómo se hacen las cosas en la Administración y con el encorsetamiento en el que viven nuestros procesos internos.

Comentando esto con Javier me propuso dar una charla sobre la implantación de metodologías ágiles en la Administración, algo que llevo intentando hacer desde hace tiempo. La idea me pareció buena y, por eso, os animo a que asistáis si podéis.

El evento, que tiene lugar dentro de la comunidad Managment 3.0, se llevará a cabo el último jueves de febrero.

Nos vemos allí.

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.