Se entiende como desarrollo ágil de software a un paradigma de desarrollo de software basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

En muchas ocasiones, los modelos de gestión tradicionales no nos sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces nos ha ocurrido: cuando el proyecto se encuentra bastante avanzado nos damos cuenta de que no vamos por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios nos obligan a tirar por la borda todo el trabajo realizado hasta entonces, y nos impiden acabar en el plazo previsto.

Dado que los cambios nunca van a dejar de existir, lo que necesitamos es ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses Takeuchi y Nonaka estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard. De ahí extrajeron la base de lametodología SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.

Seguro que puedes utilizar algunas de sus técnicas y procedimientos para mejorar la gestión de los proyectos en tu empresa. Estas son algunas de las claves de SCRUM:

Mejor con equipos pequeños y auto-organizados.

Los equipos pequeños y formados por miembros de diferentes disciplinas consiguen mejores resultados. Es fundamental que el equipo pueda organizarse por sí mismo y la comunicación sea transparente. Esta es la manera de que todos los miembros se compromentan y se encuentren motivados. De hecho, la palabra SCRUM procede del vocabulario del rugby y significa melé; es decir, esa "figura" en la que los compañeros del equipo se amontonan, forman una piña y empujan todos en la misma direccion.

Punto de vista del usuario

La recogida de requisitos para crear un producto se realiza teniendo en cuenta la visión del cliente y del usuario. Para ello se utilizan las historias de usuario, unas sencillas tarjetas en las que se recoge -de forma esquemática y en un lenguaje claro- QUÉ es lo que queremos hacer.

Con esas historias de usuario construimos la lista de requisitos del producto o"product backlog". A cada item de la lista se le asigna una prioridad. El equipo tiene que estimar cuánto tiempo es necesario para realizar cada una de las tareas.

Sprints cortos, entregas frecuentes

El mercado exige ciclos de desarrollo cada vez más cortos. Para lograrlo se utiliza el sprint de requisitos o "sprint backlog", una lista en la que se detalla CÓMO se van a construir los diferentes requisitos del producto.

Los requisitos del product backlog se "trocean" para transformarlos en tareas de no más de 16 horas. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y se puedan introducir los cambios necesarios antes de que sea demasiado tarde. Esto es lo que nos permitirá ser flexibles.

Este documento es un breve resumen de la metodologia de trabajo que utilizamos aqui en Silver Leaf Software, si usted esta interesado en saber mas no dude en escribirnos, algun acesor estara a su disposicion.