7 prácticas ágiles que puedes aplicar en proyectos no ágiles

No hace mucho leí un post en el que se hablaba de prácticas ágiles que todo desarrollador de software debería aplicar. El problema (y esto es una opinión) que le veo al agile (o agilismo) es esa sensación de que son demasiadas cosas que debes aprender, de que el camino está lleno de dificultades, ese valle de la desesperación, esa sensación de no dominar nunca la ‘técnica’. En resumen darte cuenta de los años malgastados aprendiendo cosas que no te han llevado a construir mejor software y la necesidad de desaprender todo eso.

Donde trabajo no somos ágiles y no lo somos por muchos motivos que no voy a contar aquí. Y el hecho de que no seamos estrictamente ágiles no quiere decir tampoco que seamos unos patanes, peores que nadie, que nuestros proyectos fracasen o que no apliquemos prácticas ágiles a proyectos que no son ágiles.

Bien, aún así, en mi lucha por encontrar la manera de agilizar proyectos que son una mole y en definitiva, trabajar más a gusto, esta semana he recapitulado 7 buenas prácticas ágiles que no implican desmontar la empresa entera, “vender” que eres lo más ágil del mundo o pasarte meses intentando aplicar TDD sin ser productivo.

¿Qué prácticas ágiles puedes aplicar en proyectos no ágiles sin desmontar tu empresa?

Se me ocurren estas siete buenas prácticas ágiles que se pueden aplicar en cualquier proyecto de software y muchas de ellas, en cualquier proyecto de cualquier ámbito (ni siquiera hace falta que sean de ingeniería)

1. Reunión diaria

La típica reunión o sprint diario de Scrum en el que el equipo habla de: Qué hice ayer, qué voy a hacer hoy y problemas que he tenido.

Esto es algo que se puede hacer en cualquier proyecto del mundo mundial, sea de software o no. Y tampoco hace falta ‘institucionalizarlo’, es decir, reunirse de pie con un sombrero de copa y unas pipas. Se puede hacer tranquilamente, al llegar cada mañana en 5 minutos, cada uno desde su silla.

El objetivo: que el equipo sepa el estado actual de las tareas y atacar problemas cuanto antes.
 

2. Cuánto queda

Esta es la pregunta que todos los que alguna vez hemos dirigido un proyecto, más veces hacemos: ¿Cuándo va a estar esto terminado?

Estimar cuánto te falta para terminar una tarea cuesta menos cuanto más tiempo llevas trabajando en ella, así que no veo el motivo por el cual no apuntarlo en algún sitio. Y si ya haces un gráfico Burn Down y lo haces durante la reunión diaria, entonces no sé qué haces leyendo esto.

3. Define terminado

Esto es algo que me ha pasado hoy con un compañero. Trabaja muy bien y lo hace todo muy rápido, pero cuando he hurgado un poco he visto que tareas, incluso historias que ya habíamos dado por ‘terminadas’ realmente no lo estaban.

Pequeñas tareas transversales a todas las historias como gestión de permisos, internacionalizar cadenas, pequeños parámetros de configuración, no estaban. La respuesta: ‘No, es que eso lo dejo para el final porque así no pierdo tiempo’.

¿El final? ¿Y cuándo es el final? ¿El día de antes de desplegar? No tiene sentido… hay que definir cuándo algo lo damos por terminado porque si no, todo está a medias.

4. Tu proyecto debe compilar siempre

Esto es algo que lo he vivido en mis propias carnes y en las de otros. Llega tu jefe, te pide que le enseñes en lo que estás trabajando y justo media hora antes, la acabas de liar parda y has entrado en un ciclo de refactor que te va a llevar todo el día y tu proyecto no va a compilar ni de lejos.

¡Error! Y error muy grande.

Uno de los objetivos de hacer TDD es que tu proyecto pase el menor tiempo posible sin poder ser construido. Y bien, ¿si no has hecho tests y necesitas refactorizar? Búscate la vida pero no rompas tu proyecto.

En el proyecto en el que trabajo ahora no tengo tests y tengo que migrar media aplicación a otro framework. ¿Cómo lo he resuelto? Adaptando el actual y poco a poco ir migrando funcionalidad, ¡pero el proyecto siempre construye! (Y tengo la suerte de que es Javascript :))

5. Automatiza dentro de tus posibilidades

Otra situación que he vivido en mi empresa. Llega tu jefe y quiere probar no sé qué cosa. Tu proyecto no compila en local, pero es que además ni siquiera tienes una versión ‘estable’ en ningún servidor de desarrollo o pre.

Otro craso error. O peor aún, todo funciona, pero desplegar te cuesta 3 horas. No seas perro y automatiza como mínimo tus despliegues.

6. Trabaja en equipo pero juntos

Esto es algo que nunca entenderé… ¿Por qué en una oficina pequeña las personas que trabajan en el mismo proyecto, están cada una en una esquina? ¿o de espaldas? Para hablar tienen que levantarse o peor aún, hablar por Skype. Nadie sabe lo que está haciendo el otro, pasan días y cada uno va a su bola…

Hace unas semanas decidí cambiarme de sitio en mi oficina cerca de mis actuales compañeros de proyecto, lo que implica irme a otra zona de la oficina lejos de los compañeros que he tenido alrededor los últimos 5 años y con los que he trabajado muy ocasionalmente.

Las personas que trabajan en un proyecto trabajan mejor juntas y si además son un equipo que se mantiene a lo largo de diferentes proyectos, ¡mucho mejor! Y si además se llevan bien ya ni te cuento.

7. Desarrolla en parejas

Esto es algo que sin ‘formalizarlo’ hago muy a menudo. Diseñar una base de datos por parejas, resolver un bug, construir un proyecto… Muchas de estas cosas en ocasiones cuestan menos de hacer por parejas y cuando uno de los dos sabe menos del tema sirve para que el otro no se coma siempre los marrones o haya una dependencia fuerte.

 
Bonus track

Hay otra práctica que la verdad sólo hemos hecho una vez y que en realidad es fundamental: reuniones de retrospectiva. Imagínate, estas en un proyecto, transcurre como el culo, acaba como el culo, cliente descontento, equipo asqueado; termina y ahí acaba todo.

Parece que tiene sentido tras un proyecto comentar la jugada ¿no? Que ha ido bien, que no ha ido tan bien, cómo mejorar para el siguiente, etc.

Hay quien se aficiona a estas reuniones y no las hace sólo al acabar un proyecto, a mí me parece que como mínimo una vez por proyecto no hace daño 🙂
 

¿Cónoces más prácticas ágiles?

Seguro que hay muchas más prácticas ágiles, fáciles de aplicar en cualquier proyecto sin necesidad de seguir estrictamente una metodología o ser un maestro de la técnica. Si sabes más o aplicas alguna más, soy todo oídos 🙂