En los últimos años seguro que habéis escuchado hablar de: Git, rama por caso, pull requests, integración continua... Sobre estos términos comunes se han desarrollado los pilares de populares proyectos open source.
Si esto es tan maravilloso ¿Por qué hay tanta reticencia en el mundo empresarial?
Recuerdo una vez explicándole a una consultora los beneficios de trabajar con esta metodología, el diálogo fue algo así como:
[Consultora] Tenemos un problema, y es que siempre se no van los proyectos de madre.
[Lemoncode] ¿Cómo trabajáis?
[Consultora] Por supuesto, somos ágiles y seguimos scrum.
[Lemoncode] ¿Eso en qué consiste?
[Consultora] En que acordamos un precio cerrado con el cliente y cada dos semanas entregamos lo que podemos.
[Lemoncode] Ehhh ummm... bueno, podrá ser "Scrum de Cuenca", ... ¿ Y cómo hacéis con el código y las entregas?
[Consultora] Bueno pues tenemos nuestro repo y todo el mundo va haciendo checkin - checkout como podemos. Es un TFS es la leche.
[Lemoncode] ¿Os habéis planteado utilizar Git?
[Consultora] ¿Eso no es de los hippies del open source? ¿ Qué es eso?
[Lemoncode] Es un repositorio de fuente distribuido, tiene una gran potencia y rapidez a la hora de manejar ramas.
[Consultora] En TFS también puedo crear ramas...
[Lemoncode] No es lo mismo, aquí el coste de crear una rama practiamente cero, es muy rápido y ágil. Esto te permite abrir ramas por cada caso que se cree.
[Consultora] ¿ Eso que es?
[Lemoncode] Consiste en que cuando se le asigna implementar una funcionalidad a un desarrollador (un caso), este abra una rama nueva desde la rama maestra y empieza a trabajar en el mismo de forma aislada, cuando le haga falta puede sincronizar los cambios de la rama maestra a la suya, para así tener la última versión de código disponible.
[Consultora] Y...?
[Lemoncode] Esto te permite trabajar con pull request, es decir... cuando un desarrollador tiene su caso listo, pide una revisión por parte del equipo (pull request), el equipo analiza el código, comenta, pregunta, propone mejoras (o si está mal de raíz rechaza la pull), una vez que la pull está aprobada, el desarrollador puede llevar su código a la rama maestra.
[Consultora] Entiendo, ¿mucha gente trabajando en el mismo código?
[Lemoncode] Si, además de esto, puedes montar un servidor de integración continua, es decir,nos permite comprobar que nuestro código funciona en una máquina limpia ¿No os ha pasado que alguien ha subido cambios que compilaban en su máquina y en la del resto del equipo no? También puedes montar un servidor de despliegue continuo (consiste en que cada vez que llega un cambio a la rama principal se lanza un proceso de build y despliegue a un servidor, por ejemplo, un entorno de desarrollo).
[Consultora] Aham... ¿ Y para qué tamaño de equipos de desarrollo podemos aplicar ésto?
[Lemoncode] Tanto para equipos pequeños, medianos o grandes. Hasta para un sólo de desarrollador, trabajar en rama por caso y el mismo revisar su trabajo, es útil.
[Lemoncode] ... resumiendo vas a ofrecer más calidad a tus clientes
[Consultora] A mí no me pagan por ofrecer calidad, así no ganaría dinero.
Ante esta respuesta la primera reacción fue pensar... bueno si no ofreces calidad y teniendo en cuenta como avanza la globalización y las tecnologías, ¿Cómo te vas a diferenciar de un centro offshore que trabaja a la mitad de precio que tu empresa? La segunda reacción, fue evaluar, el porqué de esta reticencia inicial y si realmente trabajando de forma mediocre se ahorran costes, tras darle varias vueltas, hemos encontrado los siguientes beneficios:
- El responsable del proyecto tiene acceso al servidor de demo en el que pueda ver el estado actual del proyecto.
- El responsable del proyecto puede ver el avance real del proyecto, lo que no está en máster no está listo (menos síndrome del ... "¿Cómo vais? Bien bien...").
- No existen los "checkin bomba", es decir una persona sube su trabajo a su rama, este nunca se lleva a la rama principal hasta que tenga un nivel de calidad ¿ Cuántas veces os ha pasado que alguien se ha bajado la última versión del repo y cambios de un tercero han roto su funcionalidad?
- No se lleva código de mala calidad a la rama principal.
- El código deja de tener nombre y pertenece al equipo ¿Cuantas veces os ha pasado que ciertos ficheros sólo los tocaba "Paquito" porque nadie más sabía cómo iba?
- Se elimina el efecto "se abre la caja de los truenos", recuerdo en un cliente un desarrollador que se fue y a la semana cuando alguien fue a tocar la parte de código en la que había estado trabajando, se dieron cuenta de que no tenía ni pies ni cabeza.
- Todo el equipo aprende, los comentarios de las pull requests sirven para que otros desarrolladores crezcan profesionalmente, y también para preguntar dudas.
- El servidor de integración continua nos permite comprobar que nuestro código funciona en una máquina limpia ¿No os ha pasado que alguien ha subido cambios que compilaban en su máquina y en la tuya no?
- Si se cae el servidor puedes seguir trabajando, si el servidor se ha muerto puedes montar otro, tienes el repositorio en tu local replicado.
- Detectas a los perfiles "carniceros": esos que producen mucho, pero suben código basura que sólo sirve para crear castañazos de proporciones bíblicas una vez que estás en producción.
- Detecta a los perfiles "esquiva balas" tipo matrix: cada persona tiene sus casos asignados, la productividad y la calidad es fácil de medir.
Caso real
A continuación, os contamos como nos fue en un cliente implantando esta forma de trabajo.
Características del equipo:
- Sobre el equipo, era el clásico en que existe un desarrollador por el que pasa todo y hay partes del proyecto que sólo él conoce.
- El equipo estaba oxidado y tenía conocimientos dispares del producto que estaban realizando (era normal la frase "tal módulo hay que esperar a que venga Manuel de vacaciones para poder tocarlo).
- Cada vez que se lanzaba una release del producto tocaba un mes de estabilización.
- Cada desarrollador tenía su estilo de desarrollo, con lo que era complicado de seguir y entender.
- Cuando se incorporaba un desarrollador nuevo al equipo, estimaban que tardaba unos dos meses en empezar a ser productivo.
Prerequisitos:
- Avisamos al cliente de que este proceso al principio es muy complicado de implantar, y que no valían medias tintas, nos tenían que dar dos meses de margen y confianza la metodología.
- Le comentamos que, si tenían algún desarrollador con mucho ego, iban a tener problemas para poder trabajar de forma colaborativa.
- También le indicamos que la forma de medir el avance iba a ser distinta, acostumbrados al modo anterior de trabajo de primeras el avance iba a parecer mucho más lento, pero midiendo el total el resultado sería otro.
Desarrollo del proyecto
- Arrancó el proyecto con el equipo de desarrollo con una formación. Gran parte del equipo estaba con ganas, otra era un poco escéptico.
- En las primeras revisiones empezaron los problemas. Es normal cuando se arranca con esta manera de trabajar una rama no llegue a master hasta después de 8 rechazos de Pull Request (revisión), el código se va puliendo y todo el equipo va aprendiendo y haciendo homogénea su forma de trabajar. Esto empezó a crear malestar en parte del equipo.
- Al par de semanas vino el gran conflicto, el arquitecto del proyecto aplico la "quinta enmienda" y por "urgencia" decide mezclar una rama que no estaba aprobada, llego el momento de hablar con los responsables y plantear nuestra salida y volver a modo de trabajo antiguo, o no volver a romper la regla, se decidió continuar.
- El equipo sigue trabajando y la calidad de las ramas empieza a mejorar (todo el equipo aprende de los comentarios) con una o dos tandas de revisión se aprueba las ramas.
- Se configura un despliegue continuo a un servidor de desarrollo, así el equipo funcional puede ver en todo momento como avanza el proyecto.
- El arquitecto del proyecto no se encuentra agusto en el equipo y decide marcharse de la empresa. Esto ya no es un problema, ya que todo el resto de miembros tiene el conocimiento del producto.
- Se incorporan nuevos miembros al equipo, el tiempo de poner en productivo a los desarrolladores pasa de ser de dos meses o una o dos semanas.
- Los desarrolladores se acostumbran a tener más de un caso en desarrollo, cuando piden pull de un caso, saltan al otro mientras este se revisa.
- El proyecto sigue, el equipo va cogiendo más velocidad y todo el mundo está al tanto de cómo se han implementado los desafíos más importantes de la aplicación.
Resumen / Resultados:
- Los dos primeros meses fueron muy duros, cuesta cambiar la mentalidad del equipo y se necesita apoyo de la dirección del equipo para poder llevarlo a cabo.
- El equipo ya no depende de una persona.
- Es más sencillo añadir nuevas incorporaciones a la empresa.
- El producto es más robusto, han bajado el número de incidencias en producción.
- La velocidad de desarrollo es buena.
Conclusión
Pasar a trabajar de esta manera no es fácil, tanto la dirección del proyecto como el equipo de desarrollo tiene que estar concienciado del coste de arranque inicial y beneficios que tiene implantar esta metodología.
En las implantaciones que hemos hecho, el punto más gratificante es cuando pasan 3 / 4 meses y los propios desarrolladores son los que dicen "no me imagino trabajar volver a trabajar sin esta metodología".