En la empresa tenemos como una de las reglas principales, ir mejorando en base a experiencias y recomendaciones brindadas por el equipo de trabajo.
Muchas de estas recomendaciones nos han servido para mejorar y/u ordenar nuestra forma de trabajo y por qué no? mejorar tambien nosotros como profesionales.

Hace un tiempo conversando con el bueno de @phpleo llegamos a la conclusión de lo bueno que sería tener una botella para controlar los builds.

[Fuente Imagen: Pensamientos Agiles]

Para resumir el asunto, mantener una botella de builds implica que luego de que el equipo de desarrollo define reglas de la compilacion del producto, se establezca una multa simbólica si un miembro del equipo empieza a “romper el build”, claro… juntar estas multas implica que luego de tener un buen número de monedas se puedan comprar hamburguesas para todos! O lo que se decida cuando se tenga la botella llena 🙂

En nuestro caso al comenzar con la botella se tuvo como única regla ser cautelosos al integrar todos los proyectos que maneja la solución.

El proyecto lo trabajamos bajo Visual Studio 2010 y Team Foundation Server 2010 con su respectivo controlador de código y versiones, pero como algunos no tenian experiencia en el caso, se tuvo la consideración correspondiente para luego de algunos traspies comenzar con el experimento.

Debo confesar que creo que por mas buena que sea la herramienta o en este caso, el controlador de código fuente, los errores humanos nunca dejarán de existir.
Es por ello que no pasó mucho tiempo sin que la botella se mantenga vacia, hubo un error de integración de proyectos que generó un inconveniente con el resto del equipo, ustedes me deben comprender, demoras, molestías y bueno, retrabajo.

Por suerte, esos momentos no han sido muchos, pero los hemos celebrado en equipo con incluso un aplauso generalizado cuando (oh sorpresa!) @phpleo tuvo que colocar la respectiva multa en la botella de los lamentos 🙂

Desde esa fecha los errores de integración se han detenido, la botella del build ha dejado de llenarse y bueno, los muchachos (incluyéndome) estamos ansiosos por tener ya un fondo que nos permita comprar algo para un refrigerio, pero como el build se mantiene estable, el día de hoy decidimos ampliar las reglas y consideramos aspectos como por ejemplo:
– Incumplimiento de reglas básicas de programación, por ejemplo aspectos que pueden resultar simples como la nomenclatura misma de un archivo, clase o método.

– No documentar objetos de uso general, puesto que, como internamente manejamos una wiki (gracias claro al Team Foundation :D), tenemos un espacio para aquellos objetos de uso general, como mensajería, métodos, helpers o incluso librerías que si no se cuenta con documentación centralizada, pues tendremos problemas de comunicacion y/o de repreguntas cada vez que se quiera usar algo del repositorio común.

Les muestro un ejemplo de lo que bosquejamos en la pizarra

Cómo experiencia general debo compartir:
– El orden y la comunicación del equipo ha incrementado considerablemente.
– En la oficina seguimos muchas prácticas (ágiles y no ágiles) y a la vez tenemos mucho por mejorar.
– Los muchachos (incluyéndome) tenemos más cuidado al subir nuestro código al repositorio pues a pesar de tener buenas herramientas y reglas de control, los errores humanos existen y bueno las monedas no nos caen del cielo!

Un Abrazo
@Jersson