We Are Marketing como ponente en Peopleware: así trabajamos y así lo contamos

En el Congreso Peopleware Agile Management celebrado en su primera edición en Madrid, WAM ha desvelado uno de sus secretos mejores guardados: la gestión de nuestros proyectos.

¡The Inbounder World Tour 2017 ha llegado! Cuatro ciudades han sido los escenarios elegidos en España, Europa y Estados Unidos. Tras el éxito de Madrid, Londres y Nueva York la nave The Inbounder llegará a Milán. Las entradas para Milán del próximo 15 de septiembre ya están a la venta. ¡No te quedes en tierra! Sube a la nave #theInbounder

El pasado 22 de octubre asistí como ponente a la primera edición del congreso Peopleware Agile Management (PAM) en La Escuela Técnica Superior de Ingeniería de Sistemas Informáticos de la Universidad Politécnica de Madrid. Organizado por Ana Maria García de la empresa Bq y Javier Garzás entre otros.
 

PAM WAM.jpg-large

 

Este congreso nace con el objetivo de hablar de la gestión de las personas en los proyectos, intentando aportar un granito de arena a la comunidad técnica creando un foro de debate sobre un buen y correcto liderazgo técnico, gestión ágil o peopleware.
 

Captura de pantalla 2015-10-27 a las 10.20.25.png

 

La ponencia que presentamos desde el equipo técnico de We Are Marketing se titula: “I want to believe. Método WAM”, en la que intentamos mostrar que es posible realizar un desarrollo ágil con todas las técnicas, metodologías o herramientas que hay actualmente y que ayudan al desarrollo de proyectos.

 

 

Después de la presentación de Javier Garzás sobre Peopleware Management 3.0 en la que presentaba el congreso y explicaba por qué nace esta iniciativa, y tras la keynote de David Tomas http://www.davidtomas.com/ CEO y Cofundador de Ciberclick Group (empresa galardonada con el premio BestWorkplaces 2014) me tocaba a mi. Simultáneamente a mi charla comenzaba la de Cristina Cohi Anchía Recruiter de King (la empresa de videojuegos que hizo el Candy Crush entre otros) por lo que pensaba que no habría mucha gente en mi charla. Sorpresa la mía cuando no paró de llegar gente y en la sala de 100 personas de capacidad no había sitio para sentarse y se tuvo que quedar gente de pie. Y no lo dice solo el twitter de WAM sino también el propio Javier Garzás en su cuenta :-P Y con todo ese subidón comencé a contar lo que muy humildemente intentamos hacer todos los días entre todos en el equipo técnico.

 

 

PAM WAM 2.jpg-large

 

 

Comencé presentándome y presentando a la empresa y al equipo:

  • Edgar Tebar

  • Paola Salillas

  • David Velasco

  • Mario Araque

  • Miguel Vilata

  • Germán Figna

  • Francisco Martínez

  • Alfonso Machado

 

A continuación fuí “desvelando” mitos que existen en el desarrollo de proyectos en equipos ágiles que la gente no aplica pero que nosotros aplicamos:

 

 

  • “No se puede gestionar producto y proyecto a la vez”

 

Nosotros lo hacemos - con nuestros más y nuestros menos - pero vamos avanzando. El CMS que desarrollamos tiene unas librerías comunes a todos los proyectos y cada proyecto lo comenzamos con la última versión de nuestras librerías core y todas las novedades, fallos, mejoras o errores que encontremos desarrollando el proyecto lo incluimos a éstas.
 

Captura de pantalla 2015-10-27 a las 10.24.08.png

 

  • “Existe un equipo ágil, multiproyecto, que funciona y yo lo he visto”

 

Somos ocho personas en el equipo y quizás próximamente nos dividamos en dos equipos pero, a día de hoy, funcionamos como un único equipo. Todos los viernes dos personas del equipo técnico se reúnen con el resto de áreas de la empresa y vemos qué cosas hay que hacer para la siguiente semana, se listan y se decide que entra. El lunes a primera hora nos reunimos el equipo técnico y se dice qué hay que hacer esa semana y cada uno expone qué tiene pendiente y qué puede hacer esa semana. De esta forma, tanto la empresa como el equipo sabe que hay qué cumplir esa semana.

 

  • Levantar un proyecto nuevo con un solo comando, ¿realidad o ficción?

 

Toda una realidad. Usamos Virtual Box, Vagrant y Ansible. Aunque tiene un pequeño “truco” ya que casi todos los proyectos comparten el mismo stack tecnológico. Esto nos permite que en aproximadamente 15 min puedas levantar cualquier proyecto y tenerlo en marcha.

 

  • Todos sabemos de todo y no venimos de otro planeta

 

Así es: todos conocemos mucho - o más o menos - todos los proyectos. Intentamos que, aunque generalmente una persona ha sido la que ha llevado la mayor parte de la programación, todos hayan tocado en algún momento el proyecto para hacer alguna nueva funcionalidad, arreglar algún error o hacer alguna tarea de soporte.

 

  • Houston, ¡no tenemos ningún problema!

Aunque es prepotente la frase - ya que siempre surge algún problema - es cierto que intentamos mantener una suite de test que nos permite asegurar que las páginas van a funcionar. Por otro lado, antes de pasar a producción pasa siempre por un servidor de staging donde se verifica que todo esté correctamente.

 

  • Ataque alienigena, yo te cubro.

 

En todos nuestros desarrollos alguien tiene que revisar el código del otro antes de fusionarse en la rama de desarrollo o en la principal. Para ello usamos un “círculo de revisión” en el que estamos todos los miembros del equipo. Así durante un mes o mes y medio se nos asigna la tarea de revisar el código de nuestro compañero. De esta manera, reducimos el número de errores que pudieran generarse y a los nuevos que entran en la empresa vamos enseñándoles como trabajamos para ir mejorando.

 

  • Pasar a producción con un solo comando

 

Para ello usamos capistrano con la gema capifony. De esta forma tenemos preconfigurado todos las instrucciones necesarias para hacer un correcto despliegue a cualquier entorno que tengamos configurado ahorrando mucho tiempo y posibles errores.

 

  • Se mantienen las distintas ramas y se aplican los bug fixes a todas las ramas de core

 

El clásico mantenimiento de un producto que usa versionado semántico. Cuando surge algún error en alguna de las versiones de nuestras librerías de core se propaga la solución al resto de versiones.

 

  • Conseguí instalar y configurar Jenkins y hacer que la empresa lo usara

 

Aunque la configuración inicial nos llevó bastante tiempo, a día de hoy es super sencillo añadir Jenkins a una nueva tarea para cada nuevo proyecto. En Jenkins tenemos tareas de todo tipo: verificación del estándar de código, detección de duplicidad de código, generación de documentación, ejecución de los tests, etc.

 

  • Todos los proyectos usan las librerías de core

 

Como he comentado anteriormente, por cada proyecto que comenzamos usamos siempre las mismas librerías.
 

Captura de pantalla 2015-10-27 a las 10.24.51.png

 

  • Nuestro stack tecnológico

 

PHP, Symfony2, Doctrine, MySQL, Sonata Project, Symfony CMF, Composer, Behat, Mink, PHPUnit, Mockery, Sass, Gulp, Susy, Jquery, BreakPoint, Browserfy, HTML5, CSS3, , Capistrano, Capifony Virtual Box, Vagrant, Ansible, Bitbucket y GitHub.

 

  • Metodología WAM

 

Al final hemos hecho nuestra versión de SCRUM en la que seguimos el siguiente proceso:

1 Reuniones con el cliente

2 Sprint 0

2.1 Definición de historias de usuarios y tareas
2.2 Reuniones de Grooming

3 Sprint 1

3.1 Sprint Plan Meeting
3.2 Desarrollo de las funcionalidades
3.3 “Testing Combat”
3.4 Bug fixing

4 Review

5 Retrospectiva

6 Go to -> 3 si es necesario

7 Review con cliente

8 Retrospectiva de todo el proyecto

 

Por último, descubrí algunas cosas que tenemos pensadas hacer para seguir mejorando. Todo esto y mas podrás verlo en las slides de la presentación.

 

 

 

¿Aún no te has suscrito a nuestra Newsletter?

¡Tenemos un montón de cosas que contarte! Actualidad, entrevistas, artículos de interés, herramientas imprescindibles, curiosidades… Todo, cada dos semanas en tu buzón.

amachado
amachado
27/10/2015

OMG

¿Aún no te has suscrito a nuestra Newsletter?

¡Tenemos un montón de cosas que contarte! Actualidad, entrevistas, artículos de interés, herramientas imprescindibles, curiosidades… Todo, cada dos semanas en tu buzón.