Metodologías Agiles para el desarrollo de Software

 Conceptos Básicos

Proceso Ágil

El proceso de gestión es muy beneficioso para las compañías de software porque les permite analizar y mejorar su producto.  Es un proceso que permite al equipo dar respuestas rápidas e impredecibles a las valoraciones que reciben sobre su proyecto. Crea oportunidades de evaluar la dirección de un proyecto durante el ciclo de desarrollo. Los equipos evalúan el proyecto en reuniones regulares, llamadas sprints o iteraciones.

El método ágil es un proceso de empoderamiento que ayuda a las empresas a diseñar y crear el producto idóneo.

Agilidad 

Tal concepto es el de Agilidad (Agile), el cual definimos como:

“Metodología focalizada en el cliente, para proporcionarle valor, a través de entregas incrementales a las soluciones demandadas, y todo basado en trabajo de equipos de alto desempeño”. La metodología Agile se implementa a través de diferentes métodos, siendo el Scrum el método ágil más popular del concepto. La metodología detrás de Agile se considera adaptativa, ya que se adapta perfectamente a los cambios que se suceden (lógicamente) en el entorno en la cual operan las instituciones. Es por ello que Agile se proclama sin cesar en cambiante, y da la bienvenida a los cambios.

Valores y Políticas de desarrollo Ágil 

Individuos e interacciones sobre procesos y herramientas

Es el postulado más importante. Las personas son el activo más importante que tiene cualquier organización, en cualquier nivel jerárquico y disciplinar, e independientemente del tipo de proyecto en el que estén trabajando. El capital humano está por encima de cualquier otro proceso o herramienta, pues son las personas quienes aportan creatividad y capacidad de innovación.

Software funcionando sobre documentación extensiva

Todos hemos tenido que leer alguna vez algún manual para entender cómo funciona el último aparato que acabamos de comprar. Cuánto tiempo nos habría ahorrado si ese producto hubiese sido funcional e intuitivo, ¿verdad? Pues bien, esto es precisamente lo que proponen las metodologías ágiles.

Colaboración con el cliente sobre negociación contractual

En un mundo en constante evolución, es importante que el producto final se corresponda con las necesidades del mercado en el momento de su lanzamiento o de la prueba de un prototipo. De nada sirve hacer un buen diseño si el producto se ha quedado obsoleto cuando sale al mercado o en alguna etapa intermedia.

Respuesta ante el cambio sobre seguir un plan

La principal riqueza de cualquier metodología ágil es su capacidad de evolución y adaptación al mercado. Con una estructura rígida, la respuesta a las necesidades de un mercado cambiante sería muy difícil, pues el seguimiento del proyecto se realiza conforme a un plan establecido del que prácticamente no podemos salirnos.

Sin embargo, una metodología ágil propone que, ante cualquier imprevisto, se dé más importancia a cómo se responda a esta circunstancia antes que al propio seguimiento de las acciones.

Valoración de individuos y las interacciones del equipo de desarrollo, procesos y herramientas.

Individuos

El primer punto de este grupo de valores, y no es sencillo. Tenemos un doble sentido.

El primer sentido es en la importancia de los individuos. Gente motivada y buena te crea un equipo bueno. Gente mediocre y pasota, te crea un equipo malo. La gente, los individuos, que forman los equipos son uno de los puntos clave del éxito. Esto, como he indicado antes, choca con esa visión de que cuando algo no funciona, se intentaba cambiar el procedimiento. Seguro que este ejemplo os suena: Si los desarrollos no cumplían con las expectativas de negocio, se ponía una fase de aprobación entre la definición del requisito y el desarrollo, que asegure que ese requisito es lo que quiere negocio. El valor del individuo nos llevaría no a cambiar el procedimiento, sino a trabajar con esos desarrolladores para que entiendan qué necesita negocio y se alineen con él. No se trata de cambiar el procedimiento y añadir fases. Se trata en ver que esos individuos, si son buenos y están formados como toca, no se equivocarán.

Interacciones

En los procesos las interacciones se suelen describir con flechas que unen cajas. Y muchas veces se basan en herramientas, como aplicaciones o formularios. Se trata de estandarizar estas interacciones, y muchas veces limitarlas, para que queden bajo el control del procedimiento. ¿Por qué va a hablar un programador con el usuario cuando un analista funcional ya ha descrito exactamente lo que hay que hacer? ¿Por que va a preguntar un programador a sus compañeros si necesitan ayuda, cuando tiene un cuaderno de carga que le describe exactamente lo que debe hacer?

Pero es lógico que se llegase a pensar. Las interacciones son la base del caos. El número de interacciones posible en un equipo crece de forma cuadrática con el tamaño del equipo.

Procesos

Los procesos son las grandes tareas que realizamos. Los procedimientos son las reglas de juego bajo las que las personas se coordinarán para hacer estas tareas. Cuando se habla de dar un enfoque de proceso o ponerse a considerar los procesos, hablamos de procedimentales, de darles reglas. Si los pones en primer plano, como gestores deberíamos volcarnos en definirlos e intentar llegar a los mejores. Pero cuando los pones en segundo plano lo que sucede es que dejas que los equipo se definan sus procesos. Y esa es la clave en esta primera frase, definir procesos, pero dejar que los equipos se los definan ellos solos.

Herramientas

Las herramientas son buenas. Pero volvemos al concepto de ponerlas en segundo plano detrás de las personas y las interacciones. Cuando quedan detrás, implícitamente estamos prohibiendo dos cosas:

• No pueden gobernar o forzar a las personas. No es un elemento de imposición de procesos.
• No pueden sustituir a la comunicación de las personas.

Principios y Características que diferencian un proceso ágil de uno tradicional

Metodologías Tradicionales	Metodologías Agiles
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo	Basadas en heurísticas provenientes de prácticas de producción de código
Cierta resistencia a los cambios	Especialmente preparados para cambios durante el proyecto
Impuestas externamente	Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas políticas/normas	Proceso menos controlado, con pocos principios.
El cliente interactúa con el equipo de desarrollo mediante reuniones	El cliente es parte del equipo de desarrollo
Más artefactos	Pocos artefactos
Más roles	Pocos roles
Grupos grandes y posiblemente distribuidos	Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio
La arquitectura del software es esencial y se expresa mediante modelos	Menos énfasis en la arquitectura del software
Existe un contrato prefijado	No existe contrato tradicional o al menos es bastante flexible