Agile de­ve­lo­p­me­nt: ¡así funciona!

El de­sa­rro­llo ágil de software hace ya un tiempo que existe, pero también en otros ámbitos se han co­n­so­li­da­do los métodos ágiles. No obstante, para muchos, el término aún no está muy claro. ¿Cómo di­fe­re­n­ciar cuándo una empresa actúa según pri­n­ci­pios ágiles y cuándo aplica un método tra­di­cio­nal de trabajo adornado con una palabra de moda?

Ya en la década de los noventa, los equipos de de­sa­rro­lla­do­res de software co­me­n­za­ron a trabajar con métodos que a día de hoy se co­n­si­de­ran agile de­ve­lo­p­me­nt. A finales del siglo XX, varios de­sa­rro­lla­do­res y equipos de software de­ci­die­ron hacer más ligero, más light, el trabajo de pro­gra­ma­ción, dándose a conocer el método con la palabra clave “li­gh­t­wei­ght”. Durante este periodo apa­re­cie­ron también los métodos Scrum y Kanban, que por aquel entonces no podían en­glo­bar­se bajo el concepto de agile de­ve­lo­p­me­nt o de­sa­rro­llo ágil, pues en ese momento aún no se había de­sa­rro­lla­do.

En 2001 se puede encontrar el punto de inflexión: en este año se celebró una reunión, conocida en la ac­tua­li­dad como Snowbird meeting (nombre que hace re­fe­re­n­cia a las es­ta­cio­nes de esquí de Utah donde se produjo el encuentro), en la que 17 de­sa­rro­lla­do­res crearon el Agile Manifesto o Ma­ni­fie­s­to por el de­sa­rro­llo ágil de software: todos ellos pre­se­n­ta­ron sus re­s­pe­c­ti­vas ex­pe­rie­n­cias en el de­sa­rro­llo de software y en el trato conjunto con equipos, en­co­n­tra­ron so­lu­cio­nes, es­ta­ble­cie­ron pri­n­ci­pios y re­su­mie­ron todo en el concepto de de­sa­rro­llo ágil que hoy es sinónimo de métodos de trabajo modernos.

Trabajar de forma más flexible, creativa y pro­du­c­ti­va había sido siempre el objetivo, tanto cuando se empezaron a cue­s­tio­nar los métodos de de­sa­rro­llo de software a pequeña escala, como cuando se logró es­ta­ble­cer una nueva forma de trabajo con el Ma­ni­fie­s­to Ágil. A di­fe­re­n­cia de otros métodos tra­di­cio­na­les, como por ejemplo el modelo en cascada, que sigue un proceso muy pla­ni­fi­ca­do, lineal y bu­ro­crá­ti­co, en este caso el proyecto se pone en marcha con más facilidad. El de­sa­rro­llo ágil otorga mucha más re­s­po­n­sa­bi­li­dad al equipo de pro­gra­ma­do­res.

Además, prá­c­ti­ca­me­n­te permite decir adiós a los proyectos de gran en­ve­r­ga­du­ra: en lugar de pasar meses o incluso años de­sa­rro­lla­n­do un producto, los equipos ágiles necesitan solo unas pocas semanas para finalizar una fase de trabajo. Como resultado se obtiene un producto terminado, una ac­tua­li­za­ción o una parte del programa que se puede presentar al cliente. Para obtener un buen resultado, el Ma­ni­fie­s­to Ágil ha acordado doce pri­n­ci­pios y cuatro valores.

Los valores del de­sa­rro­llo ágil de software es­ta­ble­cen el enfoque que han de tener en cuenta los equipos en su trabajo de de­sa­rro­llo. Se anotan como pares de opuestos: ambos aspectos son im­po­r­ta­n­tes, pero uno se antepone al otro en el de­sa­rro­llo ágil:

• In­di­vi­duos e in­ter­ac­cio­nes sobre procesos y he­rra­mie­n­tas: las personas in­vo­lu­cra­das y su coope­ra­ción entre sí son más im­po­r­ta­n­tes que las cue­s­tio­nes en torno a un proceso o he­rra­mie­n­ta en pa­r­ti­cu­lar.
• Software funcional sobre do­cu­me­n­ta­ción detallada: se busca conseguir un producto final que funcione. La do­cu­me­n­ta­ción del trabajo tiene una im­po­r­ta­n­cia se­cu­n­da­ria.
• Co­la­bo­ra­ción con el cliente sobre ne­go­cia­ción co­n­tra­c­tual: el de­sa­rro­llo ágil de productos está más enfocado a ajustarse al cliente y sus re­qui­si­tos que a negociar contratos.
• Responder ante el cambio sobre seguir un plan es­ta­ble­ci­do: el de­sa­rro­llo de software debe responder a cambios co­n­s­ta­n­tes. Por ello, puede ser necesario anular un plan pre­via­me­n­te definido.

Estos valores deben en­te­n­de­r­se a modo de mantra. No pro­po­r­cio­nan in­s­tru­c­cio­nes de­ta­lla­das, pero están diseñados para que los de­sa­rro­lla­do­res no olviden los aspectos más im­po­r­ta­n­tes de la pro­du­c­ción: trabajar en equipo, co­n­ce­n­trar­se en el software, pensar en el cliente y ser flexible ante los cambios. Todas las demás facetas, sin duda también im­po­r­ta­n­tes, han de estar su­bo­r­di­na­das a estos puntos.

Los doce pri­n­ci­pios del Ma­ni­fie­s­to Ágil se asimilan más a in­s­tru­c­cio­nes concretas. Estos pro­po­r­cio­nan in­fo­r­ma­ción adicional y amplían las ideas de los valores. Pero, incluso en este caso, no se trata de una guía como tal, pues no es ese el fin del ma­ni­fie­s­to. Los pri­n­ci­pios son muy extensos y sirven para separar los métodos ágiles de los no ágiles.

• Sa­ti­s­fa­c­ción del cliente: con una pu­bli­ca­ción rápida y continua, conocida como entrega continua, el cliente ha de estar sa­ti­s­fe­cho en todo momento.
• Fle­xi­bi­li­dad: los equipos ágiles siempre ven el cambio como algo positivo, incluso si tienen lugar al final del proceso de de­sa­rro­llo. Siguiendo el Ma­ni­fie­s­to Ágil, las ada­p­ta­cio­nes a los re­que­ri­mie­n­tos ca­m­bia­n­tes ofrecen a los clientes una ventaja frente a la co­m­pe­te­n­cia.
• Entrega: el software operativo se entrega di­re­c­ta­me­n­te en un plazo de unas pocas semanas o meses. Los plazos de entrega cortos son siempre bie­n­ve­ni­dos.
• Trabajo en equipo: los de­sa­rro­lla­do­res y miembros del área de ventas tienen que trabajar mano a mano. El Ma­ni­fie­s­to Ágil contempla reuniones diarias.
• Apoyo: para que los tra­ba­ja­do­res de­sem­pe­ñen su tarea con mo­ti­va­ción y los equipos trabajen de forma creativa, el ambiente debe ser el adecuado. Para ello necesitan el apoyo de los demás y, sobre todo, la confianza de sus su­pe­rio­res.
• Cultura de diálogo: para tra­n­s­mi­tir in­fo­r­ma­ción de la manera más eficaz posible y sin ma­le­n­te­n­di­dos, lo mejor es la co­mu­ni­ca­ción directa. Hablar cara a cara permite hacer preguntas y evitar co­n­clu­sio­nes erróneas.
• Éxitos: el éxito de un equipo puede medirse sobre todo con la pu­bli­ca­ción de software funcional.
• So­s­te­ni­bi­li­dad: conviene que el de­sa­rro­llo siga un proceso uniforme. Todos los pa­r­ti­ci­pa­n­tes, y no solo los de­sa­rro­lla­do­res, deben continuar tra­ba­ja­n­do de forma constante en las entregas.
• Calidad: los de­sa­rro­lla­do­res siempre deben ase­gu­rar­se de que sus productos cumplan con los es­tá­n­da­res más altos, tanto desde el punto de vista técnico como en términos de diseño.
• Sencillez: el trabajo debe ser lo más simple posible. Eliminar lo superfluo conduce a un proceso más ágil y, por lo tanto, a mejores re­su­l­ta­dos.
• Or­ga­ni­za­ción: solo si se permite que los equipos se organicen por su cuenta, se pueden esperar re­su­l­ta­dos ex­trao­r­di­na­rios.
• Re­tro­s­pe­c­ti­va: un aspecto im­po­r­ta­n­te del de­sa­rro­llo ágil de software es cue­s­tio­nar los propios métodos cuando sea necesario. Para mejorar co­n­s­ta­n­te­me­n­te el trabajo del equipo, es im­po­r­ta­n­te que los miembros in­te­r­ca­m­bien sus puntos de vista sobre la forma en que trabajan y que adapten sus acciones en co­n­se­cue­n­cia.

En el ámbito del agile de­ve­lo­p­me­nt, se han es­ta­ble­ci­do algunas prácticas con las que se puede im­ple­me­n­tar el enfoque ágil en tu equipo o empresa –el de­sa­rro­llo ágil se convierte, así, en el término general. Muchas de estas técnicas se pueden encontrar en ma­te­ria­li­za­cio­nes del de­sa­rro­llo ágil de software como, por ejemplo, Scrum, Kanban, pro­gra­ma­ción extrema, de­sa­rro­llo basado en fu­n­cio­na­li­da­des, de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to o Chrystal.

• Backlog: la idea de un catálogo que reúne todas las tareas que aún deben rea­li­zar­se, pero en las que ac­tua­l­me­n­te no se está tra­ba­ja­n­do, es in­di­ca­ti­va del enfoque ágil. La razón de esto radica en las fases breves de trabajo. En lugar de ocuparse de varias tareas al mismo tiempo o de asignar un intervalo de tiempo fijo a cada tarea dentro de un plan de­te­r­mi­na­do, se cuenta con una serie de tareas flexibles en segundo plano. A partir de esto, el equipo puede se­le­c­cio­nar la siguiente tarea.
• Re­tro­s­pe­c­ti­va: las reuniones regulares no solo están presentes en los métodos ágiles como un principio abstracto, sino que se fomentan en parte. Scrum, por ejemplo, incluso fija un plan de reuniones. Solo si el equipo no solo aborda los desafíos y problemas, sino también los logros, se puede conseguir una mejora a largo plazo.
• Historia de usuario: las historias de usuario sirven para ase­gu­rar­se de que el cliente o el usuario está en el centro del de­sa­rro­llo. Con esta técnica se recurre a un lenguaje sencillo para explicar bre­ve­me­n­te lo que una función debe poder hacer desde la pe­r­s­pe­c­ti­va del usuario. Esta de­s­cri­p­ción se anota en una tarjeta (story card) y con todas se elabora un mapa (story map).
• Agile testing: en el de­sa­rro­llo ágil de software, las pruebas se co­n­si­de­ran parte integral del proceso. No­r­ma­l­me­n­te, al final de una iteración (fase de trabajo corta), el producto se prueba en equipo antes de que se considere “terminado” y se entregue al cliente. Solo entonces comenzará la siguiente iteración con una nueva tarea.
• Pro­gra­ma­ción en pareja: el principio de los cuatro ojos encuentra apli­ca­ción en la pro­gra­ma­ción en pareja, también conocida por su de­no­mi­na­ción en inglés pair pro­gra­m­mi­ng. Dos de­sa­rro­lla­do­res comparten un espacio de trabajo. Mientras uno de ellos escribe el código, el otro verifica la entrada. Aunque esto conlleva más tiempo (el exa­mi­na­dor podría estar es­cri­bie­n­do código también), pero reduce los errores en el código.
• Ti­me­bo­xi­ng: algunas formas de de­sa­rro­llo ágil tienen re­s­tri­c­cio­nes de tiempo. Nue­va­me­n­te, Scrum es un buen ejemplo de ello, ya que aquí los sprints tienen una longitud de­te­r­mi­na­da. Al final, el equipo tiene que presentar un producto terminado. Esto requiere que las tareas se diseñen y se­le­c­cio­nen ade­cua­da­me­n­te.

Hay muchas más técnicas en­co­n­tra­das en los métodos ágiles. Todas tienen en común el objetivo de hacer que el flujo de trabajo sea más efectivo y de aumentar la calidad del producto.

A sus de­fe­n­so­res les gusta presentar el enfoque del de­sa­rro­llo ágil de software como la única forma de de­sa­rro­llar productos en la ac­tua­li­dad. Pero la agilidad no es la solución adecuada para todos los equipos y empresas. De­pe­n­die­n­do de la situación de la empresa, las de­s­ve­n­ta­jas pueden superar los be­ne­fi­cios.