Desarrollo Agil. Nuestro método de trabajo

En un post que escribí con anterioridad hablamos acerca de lo que era y sobre todo, de lo que no era Agile en el desarrollo de aplicaciones. En este post os voy a contar cómo desarrollamos aplicaciones en Belike y sobre todo, cómo hemos creado nuestra propia “metodología” ágil para llevar a cabo los proyectos en los que estamos trabajando.

No he entrecomillado la palabra metodología al azar, lo he hecho porque más que una metodología, en Belike la consideramos más bien un método de trabajo que adaptamos a cada proyecto, atendiendo siempre a:

• Experiencias previas
• Tipo de proyecto
• Tipo de cliente
• Set de Herramientas (ya utilizadas previamente y que conocemos, o nuevas que queremos probar).

Por tanto, entendemos la palabra metodología como un concepto que nos permite ser más eficientes y rápidos en nuestros desarrollos, adaptando las herramientas y los procesos a las distintas circunstancias que nos encontramos y huyendo como alma que lleva el diablo del concepto metodología como aquello estricto y estanco, que no pocas empresas “venden” como un producto más de su portfolio.

Podemos decir que nuestro método tiene una orientación SCRUM, aunque con el paso de los años, el uso que hacemos de SCRUM se ha reducido a cierta nomenclatura y pasos que hemos adaptado a nuestro gusto. Por tanto, nuestro método no es más que una serie de prácticas que hemos adaptado de SCRUM más un conjunto de “reglas” que bajo ningún concepto nos saltamos, y que no son más que los principios del manifiesto ágil:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

En Belike tomamos muy en serio los cuatro puntos anteriores, y no solo en tiempo de desarrollo, sino también en las etapas previas (oferta y contratación). Tanto nuestras propuestas comerciales, como los contratos que firmamos con nuestros clientes están redactados siguiendo de alguna manera los principios ágiles. No tendría mucho sentido escribir un contrato con un alcance súper acotado y posteriormente trabajar bajo el paraguas de la flexibilidad máxima (o viceversa). Pensamos que es preferible que nuestros contratos reflejen lo más fielmente posible, el modelo de desarrollo que posteriormente seguiremos.

Antes de continuar, es necesario aclarar que el método que aquí exponemos está orientado a proyectos de desarrollo de software a medida. En concreto de una foto real del método que estamos utilizando en la actualidad para la construcción de un sistema software de tamaño considerable (+3.000 horas de desarrollo). Nos parecía un ejemplo perfecto, puesto que la comunicación en un proyecto de este estilo (múltiples stakeholders y proveedores) es crítica para el éxito del proyecto.

En nuestro caso, consideramos imprescindibles los siguientes roles. Su identificación, definición de responsabilidades y actuación son realmente importantes para la marcha del proyecto:

• Product owner
  • Es el responsable operativo máximo del proyecto en el cliente. Y digo operativo y no ejecutivo, es decir, estamos hablando de un perfil con capacidades tanto técnicas, como de gestión, capaz de aglutinar y transmitir las necesidades funcionales, técnicas y organizativas del cliente.
  • Será una persona con una alta dedicación al proyecto. Participará en el día a día del desarrollo.
• Technical leader
  • Es el responsable operativo máximo en Belike . Coordina los trabajos de desarrollo, y es el interlocutor principal del proyecto en el día a día.
• Executive manager
  • Existen dos personas con este rol, uno de ellos es el responsable ejecutivo del proyecto en el cliente y el otro es su homólogo en Belike .
• Por supuesto, los distintos roles de los equipos técnicos, tanto en el cliente, como en los distintos proveedores y Belike . No vamos a enumerarlos en este proyecto por no ser relevante (en sucesivos post, hablaremos de los equipos de desarrollo con detalle).

Una vez hemos identificado los roles imprescindibles os podemos mostrar la pócima mágica de nuestro método de trabajo, cuyos ingredientes principales son:

1. Comunicación directa tanto interna, como con los clientes y proveedores

• Apoyándonos en herramientas 100% colaborativas, principalmente:
  1. Trello: Nos permite organizar nuestro trabajo.
  2. Slack: Nos permite estar conectados con el resto de integrantes y conocer los cambios que están ocurriendo en el proyecto en vivo.
  3. Google Drive con todas las aplicaciones Google (y de terceros):
  4. Google Hangout o Skype, para las reuniones con el cliente u otros proveedores que no estén en nuestras oficinas.
• Creamos canales en Slack por distintas temáticas y asuntos, de esta manera tanto los chat, como los documentos que intercambiamos siguen el canal adecuado y llegan a las personas interesadas.
• En Trello configuramos un kanban scrum que adaptamos totalmente a las condiciones del proyecto.

2. Software funcionando a diario

• El cliente debe poder probar los cambios que se están realizando a diario, y casi podríamos decir “en vivo”. De esta manera obtenemos el feedback diario del product owner (Follow up Daily meeting)
• Para ello tenemos seguimos dos estrategias muy conocidas en la actualidad:
  1. Integración Continua (integraciones automáticas continuas de compilación y ejecución de pruebas, permiten detectar fallos cuanto antes).
  2. Entrega Continua (amplía a la integración continua desplegando los cambios en código en un entorno de test y/o producción).
  3. Las herramientas que utilizamos para llevar a cabo estas dos estrategias son múltiples, principalmente jenkins y shippable.
• Ambas estrategias permiten disponer de un entorno de test donde el cliente y el equipo pueden probar los cambios que acaban de confirmarse por los programadores, promocionandolos al resto de entornos una vez estén aceptados, de una manera ágil, eficiente y segura, además de automática.

3. Maximizar el tiempo de programación

• En este punto somos bastante estrictos, cuanto más tiempo estamos en reuniones, menos tiempo estamos programando. Por tanto, minimizamos al máximo las horas de reunión. ¿Y cómo lo hacemos? pues básicamente así:
  1. Cuando hay que decir o preguntar algo a alguien lo hacemos y punto. No montamos una “reunión” para cualquier asunto que se podría solucionar hablando/chateando.
  2. En las reuniones de periodicidad diaria vamos al grano, además de optimizar quién debe o no estar en esa reunión. Por eso mantenemos dos daily meetings, una entre el Product Owner y el Technical Leader, donde el equipo de desarrollo no está (salvo que sea requerido algún programador en concreto) y otra con el equipo de desarrollo. En la primera suele haber más asuntos que debatir, con lo que sacamos a los programadores de este debate salvo que sea necesario.
• Reuniones fijas
  1. Dev team Daily meeting: El equipo de desarrollo, junto al technical leader, tienen una reunión diaria al comienzo de la jornada. Nunca supera los 10 minutos.
  2. Follow up Daily meeting: El product owner y el technical leader mantienen una reunión diaria de seguimiento. En esta reunión se obtiene feedback de lo programado en el día anterior, puesto que el product owner ya ha podido probar las nuevas funcionalidades o cambios que se hicieron el día anterior.
  3. Demo meeting: Periódicamente (de 2 a 4 semanas) hacemos una demo, en la que también están los executive manager, donde se hace una “foto” del estado actual del proyecto. En esta demo no se utiliza ningún soporte que no sea la propia aplicación. De esta reunión se obtiene feedback para reorganizar el backlog.

A modo de conclusión podríamos decir que nuestro método de desarrollo está soportado por un conjunto de herramientas (todas ellas ampliamente conocidas) que unidas con el pegamento de la agilidad y grandes dosis de comunicación, nos permiten aprender a diario de nosotros mismos y adaptar nuestro modo de trabajo con el objetivo final de construir software de calidad que satisfaga las necesidades de nuestros clientes.