AGILE en Ingeniería

Te llama Juan, del departamento comercial, y te dice «He estado con el comercial de Imposinegniería SL, – aquí ya te echas a temblar, es el último cliente que ha llegado al estudio, llevas trabajando 2 meses en su proyecto y estás en las fases finales – me dicen que quieren cambiar el material de la superficie a uno nuevo que han visto en…». Ya no escuchas a Juan. Tu mente ya está sopesando todas las implicaciones que tiene este cambio de última hora. Solo cabe un concepto en tu cabeza: Imposible. Seguro que esto ya lo has vivido, y no pocas veces, ¿verdad?..

Los cambios se suceden constantemente. Oponerse a ellos, por lo general, no es una opción que se contemple en el horizonte. Es mejor estar dispuesto y ágil para responder al cambio. Y esa es la razón de ser del Agile Project Management.

¿Qué es Agile Project Management , o Agile ?

En esta serie de artículos veremos primero unas nociones básicas de Agile para quienes quieren conocer esta filosofía de trabajo y, próximamente, cómo aplicamos Agile en proyectos de ingeniería en Bloquetech. Pero para comprender algo nuevo, a menudo, conviene conocer sus orígenes.
Permíteme contarte como el paso de una pagina en la historia, el cambio de siglo, trajo una nueva altura de miras con la que empezar un nuevo capítulo.

El origen de Agile Project Management

Eran los comienzos de 2001, en EEUU.
17 líderes de compañías de desarrollo de software se juntaron un fin de semana buscando un anhelado cambio en la forma de trabajar. Coincidieron en que las empresas estaban tan centradas en la planificación y documentación que se perdía de vista lo realmente importante, satisfacer al cliente.
Con viejos métodos, como la metodología waterfall (desarrollo en cascada), donde se requiere toda la documentación del proyecto desde el inicio y no admite cambios, el cliente no ve el valor del producto hasta el final del proyecto. Esta idea queda desfasada en estos tiempos. Valores como la excelencia y la integridad hacían poco por guiar a los empleados a un mejor modo de alcanzar el objetivo final.
Para tener éxito en la nueva economía, en la nueva era de la web y el e-commerce tenían que dejar atrás los viejos métodos y políticas. Tras largos intercambios de opiniones, llegaron a unos puntos de acuerdo que reflejaron en el «Agile Manifesto» y los 12 principios en los que se sustenta. Así se definió una nueva cultura de trabajo.

Definición y desarrollo de Agile

De dicho manifiesto, se extrae que Agile es una filosofía sobre la que los proyectos que precisan de una especial rapidez y flexibilidad en su proceso, son gestionados e implementados en pequeñas partes. En cada parte se repite un ciclo o iteración: definir – desarrollar – entregar.

Al final de cada ciclo el cliente recibe esa pequeña parte del proyecto, la revisa y devuelve sus impresiones mientras se continúa con la siguiente iteración. Los cambios son bienvenidos y pueden incluirse en sucesivas etapas del proyecto. Los métodos ágiles también fomentan las comunicaciones cara a cara, en vez de recopilar una extensa documentación en inicio, y realizar una toma de decisiones compartidas cliente-desarrollador en corto plazo. Lo importante es que desde las fases iniciales del proyecto el cliente está viendo valor en nuestro trabajo.

Agile aplicado a la ingeniería

Veamos ahora cómo el paradigma del desarrollo ágil de software se traslada al desarrollo de proyectos de ingeniería llevándonos a lograr mejores resultados. La flexibilidad de las metodologías ágiles nos permite adoptar aquellos aspectos que realmente nos aportan valor a la gestión del proyecto y al cliente en definitiva. Esto nos permite adaptarnos con mayor facilidad a las necesidades y formas de trabajar de nuestros clientes. En Bloquetech basamos nuestra gestión en Kanban con algunas pinceladas de Scrum.
Scrum y Kanban son dos de las metodologías que existen para aplicar los principios del Agile.

Scrum

Con Scrum un proyecto grande se divide en pequeñas partes que, una vez terminadas, son entregadas al cliente. Estos «paquetes» entregables se planifican para ser completados en periodos determinados de tiempo, llamados sprints. Los sprints se pueden ajustar según el proyecto o cliente, pero tienen una duración fija a lo largo del proyecto; se determinan dentro de una horquilla de una a cuatro semanas. Los equipos de desarrollo conocen cómo van a ser los sprints para ajustar los ciclos y asegurar los entregables al final de cada uno.

Antes de cada sprint se planifican todas las tareas a realizar por el equipo, con el objetivo de presentar al cliente una parte significativa del proyecto al final del sprint. Al final de cada iteración el cliente ve valor, ve cómo crece su proyecto.

Sprints + Standups – La clave del Scrum

Antes de cada sprint se realiza una reunión en la que se planifica todo el trabajo que debe completarse en él. Después de cada sprint tiene lugar otra reunión, esta vez, de carácter restrospectivo para identificar y solucionar aquellos aspectos del sprint que no han ido bien. Durante el sprint , cada día se realizan reuniones breves (entre 10 y 15 minutos máximo) y dinámicas con el equipo. Estas reuniones son conocidas como dailys, o también llamadas standups, ya que son muchos los equipos que las hacen de pie.
En ellas cada integrante del equipo responde 3 preguntas:

• ¿Qué hice ayer?
• ¿Qué tengo planeado hacer hoy?
• ¿Existe algún obstáculo o bloqueo que me impida terminar el trabajo planificado?

Estas reuniones son clave para allanar el camino a todo el equipo y asegurarse de que el proyecto marcha según el rumbo establecido.

Kanban

Por otro lado, el enfoque Kanban se centra en la visualización del estado de las tareas a lo largo de un flujo de trabajo, limitando el trabajo en curso. Kanban viene del japonés que significa letrero, símbolo visual. «Kan» significa pictograma o símbolo visual, y «ban» representa una tarjeta o cartón.

Los trabajos o tareas a realizar se representan como tarjetas en un tablero Kanban visible a todo el equipo de trabajo. Cualquiera puede ver el estado en el que se encuentran todas las tareas que deben realizarse para completar un proyecto. En el tablero se representa el flujo de trabajo por el que pasan todas las tareas mediante columnas, cada columna es un estado de ese flujo de trabajo. Los flujos de trabajo los podemos adaptar a las necesidades o particularidades de cada cliente o proyecto, añadiendo o quitando estados según el caso. El flujo de trabajo más sencillo es: por hacer – en progreso – finalizado.  Si tomamos este flujo de trabajo básico, inicialmente todas las tareas se listan en la columna «por hacer».

Normalmente, dentro de cada columna, se ordenan las tarjetas por prioridad, dejando en la parte superior las más prioritarias. Cada miembro del equipo cogerá una, y la desplazará a la columna «en progreso», y cuando termine el trabajo, la llevará a la columna «finalizado». En Kanban las entregas a cliente son continuas, al contrario que en Scrum, donde es regular y está fijada de antemano por la duración de los sprints.

1 Persona 1 Tarea – La clave del Kanban

Un punto clave del método Kanban, es que el trabajo en curso está limitado. Esto previene el exceso de compromiso en la cantidad de tareas que cada miembro del equipo puede completar, además de ayudar a mantener el foco y evitar la peligrosa multitarea, mejorando así en calidad y rapidez. Un límite lógico y común es una tarea por persona. De esta manera, cada miembro del equipo se concentra en completar tareas y trasladar sus correspondientes tarjetas a «finalizado». El compromiso individual siguiendo este sencillo método, da una clara visión en tiempo real de cómo está avanzando el proyecto, tanto al equipo como a responsables y clientes.