La Conferencia de dos días Agilefest 2011 es una valiosa oportunidad para que usted se familiarice con Ágil. ¿Cómo Ágil puede concretamente ayudarle en su desarrollo de software? Este artículo tiene el objetivo de proveerle suficiente información al respecto como para que le motive a saber más sobre Ágil.

Hoy en día, la industria del software convencional tiene un "pobre historial" en lo que respecta a la entrega de software funcionando a tiempo y dentro del presupuesto. El IEEE ha estimado conservadoramente que más de $60 mil millones se destinaron en fallidos proyectos de software.  ¡Eso es un desastre!

Las Principales 5 Razones por las que los Proyectos Fracasan

Cuando se les pregunta por qué sus proyectos fallan, los gerentes y empleados citan una amplia gama de razones. Sin embargo, estas 5 razones surgen una y otra vez, como las principales por las que sus proyectos fallan:

• Falta de participación del usuario final (cliente)
• Requerimientos pobres
• Cronogramas poco realistas
• Falta de gestión del cambio
• Falta de pruebas
• Procesos Inflexible e innecesarios

Así es cómo Ágil soluciona esos problemas de frente

Así que, claramente, con tantos proyectos que fallan, debe existir una mejor manera. Y aunque Ágil puede no tener todas las respuestas para todos los problemas, a continuación le mostramos cómo ágil aborda directamente los motivos principales de fallo para los proyectos:

El Cliente es el Rey

Para hacer frente a la falta de participación del usuario final o cliente, Ágil convierte al cliente en un miembro del Equipo de Producto. Como miembro de ese equipo, el cliente trabaja con el equipo de desarrollo para garantizar que sus necesidades sean satisfechas. El cliente aporta a los requisitos, aprueba el resultado final y tiene la última palabra a la hora de decidir qué funcionalidades se añaden, modifican o se se eliminan.

Los Requerimientos se Escriben como Pruebas de Aceptación antes que cualquier Código se Escriba

Para abordar el problema de las requerimientos pobres Ágil insiste en que usted escriba las Pruebas de Aceptación antes de escribir código. A medida que los requerimientos se recolectan, ellos se definen como funcionalidades que contienen uno o más casos de uso con criterios de aceptación concretos. Los criterios de aceptación se utilizan para escribir una prueba de aceptación antes de que el código se escriba. Eso significa que alguien en realidad tiene que pensar en qué es lo que se quiere antes de que se le pida a alguien más que lo construya. Este enfoque cambia radicalmente el proceso de recopilación de requisitos y mejora drásticamente la calidad de la estimación y creación de cronogramas.

Los Cronogramas no son Asignados, Son negociados

Para abordar el problema de los cronogramas poco realistas, Ágil hace que la estimación y manejo de cronograma sea un proceso de colaboración entre el Equipo del Producto y el Equipo de Desarrollo. En el comienzo del ciclo de desarrollo, el Equipo del Producto da una estimación del nivel de esfuerzo para un conjunto de funcionalidades. Entonces se le pide al equipo de desarrollo que examine, revise y proporcione información sobre las estimaciones. Los dos equipos trabajan en colaboración en las estimaciones hasta que un cronograma razonable se logra. Entonces todo el mundo se compromete al cronograma y se comienza el trabajo.

Nada está Escrito en Piedra, Excepto la Fecha de Entrega

Para abordar el problema de la falta de gestión del cambio, Ágil insiste en que todos abracen el cambio, que lo acepten, que todo el mundo sea realista sobre el cambio, y que todo puede cambiar a excepción de la fecha de entrega. En otras palabras, conforme el producto se mueve hacia a la fecha de liberación, el cliente (miembro Equipo de Producto) puede añadir, cambiar o eliminar una funcionalidad basado en su prioridad y valor. Sin embargo, tiene que ser realista. Si se agrega una funcionalidad, probablemente tendrá que quitar otra, con el fin de cumplir con la fecha de entrega. Y, la fecha de entrega siempre se cumple. Punto.

Las Pruebas se Escriben Antes que el Código se Escriba y esas Pruebas son Automatizadas

Para abordar el problema de la falta de pruebas, Ágil pide escribir primero esas pruebas y esas pruebas se ejecutan continuamente en todo el proceso de construcción del producto en lugar de esperar hasta la última hora para lanzar un código malo a un Equipo de Pruebas impotente. Cada desarrollador tiene que escribir la prueba primero, y luego escribir el código para que pase la prueba. La prueba se ejecuta automáticamente cada vez que se cambia el código. Este enfoque hace que probar sea la responsabilidad de todos en el proceso de desarrollo y asegura la integridad de la construcción del producto desde el inicio del proyecto.

La Gestión del Proyecto no es una Actividad Separada

Para abordar el problema de los procesos inflexibles e innecesarios, Ágil integra la gestión de proyectos en el proceso. La función de gestión de proyectos es compartida por el equipo de desarrollo. Por ejemplo, cada equipo de desarrollo de 7 personas (Scrum) se compromete a un cronograma que ellos personalmente negocian. Además, la base del código genera automáticamente la información de seguimiento de proyectos. Por ejemplo, los gráficos de velocidad, burndown, y pruebas falladas-pasadas son generados automáticamente.

Ágil es un Enorme Paso en la Dirección Correcta

Como hemos dicho anteriormente, Ágil no puede abordar todos los problemas de desarrollo de software, pero es un enorme paso en la dirección correcta. Ágil es un intento serio para abordar muchos de los principales problemas con los actuales procesos de desarrollo de software mediante la potenciación y el respeto a las personas que son parte del proceso y la adopción de un enfoque pragmático y realista hacia la empresa de desarrollo de software.

Para saber cómo usted puede ser Ágil, empiece por asistir al Agilefest 2011.