Implantar métodos ágiles y de calidad de desarrollo de software para CEOs y CIOs

Implantar métodos ágiles y de calidad de desarrollo de software para CEOs y CIOs


Hay gente que no entiende muy bien qué es lo que hacemos en Autentia, porque dar SOPORTE A DESARROLLO e IMPLANTAR METODOLOGÍAS AGILES queda muy etéreo pero es muy concreto y complejo. Especialmente con las metodologías ágiles muchos piensan que es tan sencillo como comprar unas herramientas y dar un curso de unas horas, pero la realidad es bien distinta.

Dinamización corporativa y gestión del cambio

Algo que leí hace tiempo me llegó al alma: la construcción de software no es la resolución de un puzzle (donde la solución es conocida) sino se parece más a completar un misterio: sólo cuando vemos las primeras versiones de lo que estamos haciendo sabemos realmente si es lo que queremos.

Por poner un caso práctico en otro contexto más gráfico, cuando un director rueda una película la puede tener conceptualizada en su mente y algo formalizada en un storyboard. Sólo cuando dirige las escenas se da cuenta de si le gusta o no. Pero aún así, hasta que no se hace el montaje final no se valida la versión definitiva, que incluso presenta dudas. Sólo hay que ver los contenidos extra de los DVD para comprobarlo donde incluso encontramos finales alternativos.

Parece por tanto absurdo dedicar semanas o meses a definir un proyecto, entrevistando exhaustivamente a sus posibles usuarios, ahondando en detalles, discutiendo sobre abstracciones y no sobre tangibles Y CONSIDERARLO UN ASUNTO CERRADO.

Si seguimos la dinámica clásica de análisis, diseño, construcción y pruebas durante meses, sin mostrar porciones completas que funcionen con procesos reales, ya estamos empezando mal porque será en la fase de pruebas cuando el usuario verifique si lo que quería es lo que está obteniendo: algo que ni siquiera tenía claro. Con mucho avanzado habrá que tirar o al menos modificar para satisfacer las recientes necesidades.

Una de las primeras cosas que hay que hacer en un acompañamiento ágil es educar a la dirección de la organización en la gestión del cambio de paradigma:

  • No pidas que te den el coste al céntimo de un proyecto que no has sido capaz de definir. Pide la estimación de una primera fase y una dimensión aproximada del total.
  • No te embarques en proyectos titánicos sin ser capaz de resolver problemas en margen temporal de semanas: falla pronto, falla barato.
  • No contrates al más barato que te promete hacerte más en menos tiempo: sólo los necios no dan valor a la complejidad. Evalúa uno a uno a todo el equipo y su experiencia trabajando juntos.
  • Rodéate de la gente más competente y complementaria. Es raro que una sola empresa sea buena en todo. Separa diseño de construcción: son perfiles radicalmente diferentes.
  • Define objetivos claros y las pruebas que demuestren que esos objetivos se cumplen: definir pruebas favorece la conversación y descubrimiento de funcionalidades.
  • Todo no es igual de importante, prioriza. El mercado no espera y todo no se puede tener en una primera fase.
  • Involúcrate en el proyecto y déjate formar: aunque sea en una sesión corta.
  • Participa de tus obligaciones en las prácticas diarias y semanales del proyecto: definir lo que quieres, prioritario y validarlo.
  • Dedica personal en exclusiva a la dirección del proyecto: que su responsabilidad sea que salga bien.
  • Estudia los riesgos sistemática y jerárquicamente para anticiparse a ellos.

Por tanto hay que cambiar la forma de contratar, de definir el proyecto, de empezar… y alguien ha de guiar a estos responsables de proyectos. Un perfil que viene estupendo aquí es un coach ágil. Persona paciente, de gran formación que tiene que agitar un poco el árbol.

Definición útil de un proyecto

Una de las primeras tareas será ayudar a modelar el proyecto, normalmente en dos fases, el producto mínimo viable y todo lo demás. Esto no se hace a modo tradicional, sino en base a historias de usuario o experiencias del uso que haríamos de él si ya estuviera construido, no queremos modelar por ahora cómo lo vamos a hacer (soluciones) sino qué necesidades habría que resolver.

Parece fácil pero no lo es. Requiere técnica, sobre todo porque cómo lo modelemos y lo homogéneas que sean esas definiciones en distintos proyectos es lo que nos permitirá tener cierta capacidad de estimar la dimensión del proyecto.

El centro de la definición es la persona: no debemos hablar de un usuario genérico sino de un miembro de una tribu con características concretas.

En este caso el agile coach junto con scrum master y los analistas del proyecto tendrán que empezar a darle forma de un modo distinto al tradicional: esto no es un catálogo de requisitos. Sobre todo es vital saber cómo no generar desperdicio analizando grandes historias (épicas) que de momento no son transcendentes y concentrándose en separar de aquellas historias más destacadas, lo que tenemos que hacer ahora y lo que puede esperar a más adelante.

Se deberán dejar las decisiones sobre muchas cosas para momentos en los que se posea mayor información: si pides en abstracto a un cliente que te diga qué desea entre varias opciones, de un modo temprano, la decisión posiblemente cambie con el tiempo o surjan nuevas alternativas.

Existen patrones de descomposición de historias de deberemos poner en práctica para desarrollar una técnica y lenguaje común entre los analistas. El Scrum Master puede ayudar a definir un criterio homogéneo de definición de historias y casos de prueba. También forzará a priorizar en base al valor para negocio.

Puesta en marcha de herramientas ágiles

Toda esta información que se va a ir generando debe guardarse en algún sitio, por lo que es necesario elegir, instalar, parametrizar, poblar y habituar a los usuarios en su uso diario. Recordad una cosa: los primeros meses es conveniente llevar en paralelo el trabajo con post-its y en la herramienta. Aunque parezca duplicar trabajo mejora la consolidación de rituales.

Hay muchas opciones en el mercado aunque creedme que la clave no es la herramienta sino la formación del personal en las prácticas diarias.

Una de las herramientas más destacadas del mercado es la suite de Atlassian. Como cualquier herramienta nos costará un periodo de adaptación manejarla correctamente y también requerirá de asesoramiento para encontrar los plugins y extensiones adecuados para sacarle gran partido sin hacer costosas adaptaciones a medida.

La clave es la disciplina diaria y, como pasa en todos los aspecto de la vida, como no pagues a alguien externo no conseguirás un alto rendimiento.

Para verlo en otra realidad sólo tenemos que pensar qué pasa si simplemente nos apuntamos a un gimnasio o, si al mismo tiempo, contratamos a un entrenador personal que nos instruya y motive y, en cierto modo, nos obligue a unas sesiones de entrenamiento de calidad. Claro que el coste es más alto pero considerad la probabilidad de éxito (ponerse en forma, recuperarse correctamente de una lesión, mejorar el rendimiento en un deporte específico) de un modo y de otro.

¿Gastarte poco en mucha gente poco cualificada y/o especializada es por tanto razonable? No lo parece.

Arranque de un proyecto ágil

Sobre una definición conceptual de un proyecto ahora hay que conformar un equipo que sea capaz de ejecutarlo correctamente en ciclos cortos de dos o tres semanas. Para equipos y organizaciones novatas mejor tres. Para equipos entrenados, mejor dos.

Hay que hacer muchas cosas, empezando por montar un correcto entorno de gestión de la configuración:

  • Montar la infraestructura de desarrollo y definición de:
    • Repositorio y estrategia de uso. El ganador suele ser GIT.
    • Entorno de integración continua.
    • Métricas de calidad de software y otras directrices a seguir por todos los miembros.
    • Herramientas de seguimiento de pruebas.

Adicionalmente hay que realizar las prácticas de gestión del proyecto y rituales, como:

  • Detallar más las historias a ejecutar en un ciclo (o grooming) junto con los responsables del negocio.
  • Definir las pruebas de aceptación de las historias: manuales y automáticas.
  • Formar al personal menos cualificado en toda esta disciplina.
  • Asignar las tareas en base a la capacidad de cada miembro y establecer mecanismos que garanticen una formación temprana como la programación por parejas.
  • Construir las gráficas de métricas cuantitativas del proyecto y del ciclo.

Y por supuesto, aunque lo citemos menos, es lo que más esfuerzo y conocimiento requiere: construir.

  • Construir los prototipos técnicos a seguir cuando hay nuevas piezas arquitectónicas a utilizar.
  • Diseñar el código guiado por las pruebas automáticas (TDD).
  • Construir en base a patrones de diseño.
  • Refactorizar constantemente el código: aplicar patrones de refactorización.
  • Levantar lo antes posible los impedimentos y usar el conocimiento colectivo para afrontarlos.
  • Seleccionar e integrar a nuevos miembros en el equipo.

Para esto hace falta personal bien formado que ya tenga una base sobre todas estas dinámicas y que las implante en el equipo ‘de facto’ desde el primer día. Tiene que acompañar a los miembros menos entrenados en ir adquiriendo las habilidades a su ritmo. Incluso no es conveniente sofisticar demasiado el proceso de desarrollo si la base de la que partimos no tiene mucha experiencia.

Y sobre todo, hay que empezar a programar pronto, un producto de calidad y tratar de conseguir entregar la funcionalidad deseada por el cliente lo antes posible. Cualquier desajuste entonces entre en equipo técnico o con este cliente saldrá pronto a la luz.

El equipo deberá mantener una tensión continua y controlada durante todo el desarrollo. Debe generar “números”, que es lo que necesitan los gestores a niveles superiores para validar y patrocinar el modelo. Debe medirse la calidad, el avance de los proyectos y el consumo de horas. Un técnico desarrollado da valor a los números.

El Scrum master tendrá que asegurarse que no se relajan las prácticas diarias, como la reunión diaria de proyecto o de ciclo, como la calidad de las sesiones de demostración, las retrospectivas para la mejora del equipo o la planificación te tiempo de auto-formación (o taller) de miembros del equipo que contribuyan a la mejora de todo el equipo.

El resultado no es la perfección porque somos humanos. Es resultado es una vocalización en necesidades de negocio bien ejecutadas y probadas numerosas veces. Eliminamos gran parte de las “sorpresas”.

Pasadas unas semanas los equipos mejoran considerablemente y ganan autonomía. La asistencia de personal tan cualificado experto empieza a no ser ya tan necesaria porque el equipo entrenado en la disciplina evoluciona y se convierte en autónomo pero suele ser conveniente que no se desliguen del todo los profesionales de referencia forzando a que el equipo continúe con la disciplina porque alguien viene de vez en cuando a apretarles las tuercas.

Como veis, otro modo de trabajar es posible. Ya muchos clientes y proyectos con éxito lo atestiguan. No es un camino fácil ni corto pero es el que queremos recorrer.

Para muestra compartimos con vosotros nuestro último caso de éxito.