Las metodologías ágiles

Seguro que os habéis dado cuenta de que cada vez hay más ofertas de Agile Coach o Scrum Master, pero, ¿realmente sabemos que son las metodologías ágiles? Pues hoy os traemos un post para sacaros de dudas.

¿Qué son las metodologías ágiles?

Estas metodologías engloban un enfoque para la gestión y toma de decisiones en proyectos de tipo software.

Durante años, los proyectos de software han seguido el camino de otras ingenierías, copiando y adaptando su forma de trabajar. En 1987, el Departamento de Defensa de EEUU financia una iniciativa para definir buenas prácticas de gestión, dando lugar al Capability Maturity Model Integration (CMMI). Este manifiesto no resultaba lo suficientemente útil para el propósito que se perseguía, por lo que un grupo de rebeldes desarrolló el manifiesto ágil. Esta nueva metodología se basa en la premisa de que en la construcción de software se puede solapar diseño y construcción. Esto da lugar al desarrollo por iteraciones, y el uso de prototipos incrementales.

En los proyectos desarrollados mediante este enfoque se busca dividir las tareas en incrementos, cuya planificación sea mínima y de una corta duración. De esta forma se reducen riesgos y se agiliza la adaptación al cambio. En cada uno de los incrementos se obtiene una versión funcional que puede ser revisada por el cliente.

En la siguiente imagen os dejo algunas de las razones por las que conviene adoptar las metodologías ágiles en cualquier proyecto de tipo software.

Razones por las que las empresas adoptan las metodologías ágiles
Razones para adoptar metodologías ágiles

¿Cómo se planifica un proyecto mediante metodologías ágiles?

Bueno, pues aquí entran las famosas historias de usuario. Se suelen emplear post-it para su representación, por su fácil manejo. De esta manera también se evita que se conviertan en extensos documentos de especificación de requisitos.

Las historias de usuario favorecen la participación del equipo en la toma de decisiones, evolucionan a lo largo del proyecto, y tienen capacidad de interacción con el cliente. Lo principal que hay que tener en cuenta es que se trata de peticiones muy concretas, con información imprescindible.

Estructura User Story
Estructura de una User Story

Estas historias de usuario se construyen gracias a la empatía, poniéndonos en el lugar del usuario. Normalmente siguen una estructura definida del tipo: como paciente/médico/enfermero, quiero poder consultar mi expediente/crear un historial/planificar mis tareas para obtener una segunda opinión/historificar las visitas de mi paciente/optimizar mi tiempo de trabajo.

Estas historias de usuario se priorizan a medida que se van acumulando. Aunque existen diferentes enfoques que se pueden seguir para ello, el más común es el Moscow:

  • Must: Debe incluirse. Son aquellas funcionalidades imprescindibles sin las cuales el producto no funcionará o no cumplirá con la lógica de negocio.
  • Should: Debería incluirse. Hacen referencia a las funcionalidades importantes, aunque no son imprescindibles para que el producto funcione.
  • Could: Son aquellas funcionalidades que sería conveniente incluir en el producto, de manera que se mejore la experiencia de cliente.
  • Won´t: Son aquellas que no deben incluirse, por lo menos en este momento. Pueden llegar a pasar a alguno de los otros estados posteriormente.

Estimación de proyectos ágiles

Los que trabajamos en proyectos de software sabemos que la mayor causa de fracaso se debe a a la presión del calendario por haber hecho malas estimaciones.

Para realizar estimaciones óptimas necesitaremos saber el trabajo que debemos realizar, su tamaño, el tiempo ideal, y el tiempo real de realización. El problema es que no existe ningún método exacto. Todos tienen cierto grado de incertidumbre.

Es importante mencionar que la exactitud de la estimación es directamente proporcional a la definición del producto.

En metodologías ágiles, esta estimación se lleva a cabo a partir de las historias de usuario. A estas se les asigna unos puntos de historia, que dependen de su complicación y su tiempo de desarrollo. Uno de los métodos más empleados para la asignación de los puntos de historia es el planning poker, del que otro día hablaremos en otro post.

Para la estimación en horas, se tiene en cuenta la velocidad de desarrollo. Esta velocidad se define mediante la suma de los puntos de historia resueltas dividido por el tamaño del proyecto. Este tamaño viene determinado por el número total de puntos de historia de todas las historias de usuario. Dividiendo la velocidad entre el tamaño, podemos obtener una estimación del número de iteraciones que necesitaremos en nuestro proyecto.

Generalmente, las iteraciones de 4 semanas suelen ser las más apropiadas, aunque esto dependerá de negocio y del equipo. Es vital que el equipo esté cómodo con la duración. Si no, esto se traduce en una pérdida de la productividad.

Y vosotros, ¿cómo gestionáis vuestros proyectos?

Please follow and like us:

Deja una respuesta

Cerrar menú
LinkedIn
Share