El manifiesto para el método Agile de Desarrollo de Sistemas 

Los 17 "anarquistas Agiles" acuerdan: Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valer:

Metodología TenStep

de Dirección de Proyectos

Individuos e interacciones sobre los procesos y herramientas.

Software funcionando sobre documentación extensa.

Colaboración del cliente sobre la negociación contractual.

Respondiendo al cambio sobre el seguimiento del plan.

La experiencia del autor es que múltiples proyectos en ejecución dentro de una organización tienen muchas más posibilidades de éxito con un conjunto consistente,  flexible y escalable de procesos. Si estos procesos se han usado con éxito en el pasado, hay una mayor probabilidad de que los de otra organización sean exitosos también.

Esto es, mientras apreciamos los elementos de la columna derecha, valoramos más los elementos de la izquierda. Seguimos los siguientes principios:

Nuestra prioridad más alta es la satisfacción del cliente a través de la entrega anticipada y continua de software valioso

La filosofía Agile es para el desarrollo iterativo, con la recopilación anticipada de requerimientos seguida por el trabajo en la codificación, seguida por más requerimientos y más código. Esto está bien, pero el desarrollo iterativo no es el mejor enfoque para todos los proyectos de software. Sin embargo, en donde pueda implementarse, debe intentarse.

Bienvenidas las Solicitudes de Cambio, aun tarde en el proceso de desarrollo. Los procesos Agile toleran el cambio en favor de la ventaja competitiva del cliente.

Bajo el desarrollo iterativo, las solicitudes no necesitan ser “congeladas” en etapas tempranas. Sin embargo, aun con el desarrollo iterativo tradicional, en algún punto, las solicitudes necesitan ser congeladas en favor de poder entregar algo. En ese punto, el proceso de gestión de cambios en el alcance entra en vigor.

En el desarrollo Agile, las solicitudes pueden cambiar en cualquier punto. Esto es correcto desde el punto de vista de desarrollo, pero la gestión de cambios en el alcance se usa también en beneficio del cliente. El cliente patrocinador acordó financiar un proyecto con base en la obtención de cierta solución a cierto coste en un cierto tiempo. Si el equipo de proyecto continua haciendo cambios en el alcance en cualquier momento, el proyecto puede finalizar consumiendo mucho mayor tiempo y dinero de lo que el cliente acordó pagar.

El punto central es que cuando los cambios de negocio suceden, el equipo de proyecto debe estar preparando para responder. Sin embargo, los cambios a las solicitudes tienen consecuencias en términos de presupuesto y fechas de entrega y éstos deben ser aprobados por el patrocinador. Si el equipo de proyecto hace esto, están practicando la gestión de cambios en el alcance.

La entrega de software funcional frecuentemente, de un par de semanas a un par de meses, con preferencia a escalas de tiempo más cortas

El Proceso TenStep recomienda que proyectos largos sean divididos en una serie de proyectos menores, cada uno de ellos puede ser entregado más rápido y de manera repetitiva. No todos los proyectos tienen esta flexibilidad, pero la preferencia es hacia proyectos menores siempre que sea posible.

Los procesos Agile pueden llevar el ciclo corto de entrega al extremo. Algunos proyectos de programación extrema, entregan en periodos realmente cortos, aun cada semana. Aunque esto pueda ser duro de gestionar, no hay nada inherentemente equivocado con esto.

La gente de negocio y los desarrolladores trabajan juntos diariamente a lo largo del proyecto.

Este es el mejor enfoque para mantenerse en contacto con las necesidades del cliente.

Construir proyectos alrededor de individuos motivados. Se les propicia el ambiente  y apoyo que necesitan, y se confía en que ellos harán el trabajo.

Algunas veces, gente muy motivada tiene problemas para entregar proyectos a tiempo. Pueden centrarse  mucho en detalles del desarrollo y no mucho en la gestión del presupuesto y el calendario. Si la gente motivada siempre entregara sus proyectos a tiempo, habría un porcentaje mayor de proyectos exitosos. Algunas veces es necesario colocar al personal motivado en ambientes más estructurados en dónde puedan ser más eficientes. El autor considera que el mejor enfoque es integrar proyectos alrededor de gente motivada y después asegurar que cuenten con las herramientas, los procesos y habilidades  apropiadas para llevar a cabo el trabajo.

El método más efectivo y eficiente para transmitir información hacia y entre el equipo de desarrollo, es la conversación cara a cara.

No hay duda de que la comunicación personal es mejor en cualquier circunstancia. Sin embargo, hay ocasiones en que otros medios de comunicación son efectivos, por ejemplo, cuando se envía un informe del avance del proyecto a 20 individuos. Alguna información relevante también tiene que ser escrita – no necesariamente para el día que finaliza el proyecto, sino después cuado todos los desarrolladores originales se hayan ido. Esta documentación debe ser solo información importante. La documentación rara vez es actualizada por el equipo de apoyo, por lo que puede volverse menos valiosa con el tiempo.

El software funcionando es la medida primaria del progreso

En el proceso de desarrollo iterativo, el contar con software funcionando al final de cada iteración es una buena medida del progreso. Sin embargo, no todos los proyectos pueden ser realizados a través del desarrollo iterativo, por ejemplo la implementación de paquetes. Así que en la mayoría de los proyectos, es necesario continuar monitoreando los hitos mayores del plan, para asegurar que el cronograma se cumple.

Los procesos Agile promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante indefinidamente.

El método de desarrollo Agile enfatiza una semana de 40 horas y un ritmo de trabajo que puede ser sostenido indefinidamente. Por supuesto, con la planificación y gestión adecuadas, este es el mejor enfoque.

La atención continua a la excelencia técnica y el buen diseño, mejora la agilidad.

La excelencia técnica y el buen diseño son elementales. Sin embargo, si el trabajo de diseño es intercambiado por la prioridad de tener rápidamente software funcionando, esto puede ser problemático.

Simplicidad – el arte de maximizar la cantidad de trabajo no realizado – es esencial.

De acuerdo. Los desarrolladores de software y clientes deben centrarse  en cumplir con las solicitudes principales en primer término. Esto “maximiza el trabajo no realizado”. También permite que el software sea entregado más rápidamente.

Las mejores arquitecturas, requerimientos y diseños emergen de los equipos auto-organizados.

Si cada equipo fuera de alto desempeño y técnicamente superior, sería más fácil estar de acuerdo con este punto. Sin embargo, la mayoría de los equipos de proyecto no son lo suficientemente maduros y no poseen las habilidades adecuadas para desarrollar los mejores diseños y arquitecturas. Especialmente, las arquitecturas deben ser diseñadas a nivel organización o compañía. Si ese trabajo se dejara a equipos individuales, el resultado serían tecnologías duplicadas y caos.

A intervalos regulares, el equipo reflexiona acerca de cómo ser más efectivo, entonces realiza los ajustes y modifica su comportamiento en consecuencia.

De acuerdo. Los equipos constantemente deberían esforzarse por entender sus fortalezas y debilidades y la forma en que los procesos de Dirección de Proyectos pueden ser mejorados. El Proceso TenStep también cree que los cambios recomendados debieran elevarse a nivel organización de modo que las ideas de mejora puedan compartirse por todo el personal.

FIRMADO: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Para más información ver el website:
www.agileAlliance.org