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

17 anarquistras 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:

Proceso de Dirección de Proyectos TenStep

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 consistemte,  flexible y escalable de procesos. Si estos procesos 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 elelemtos 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 promueve 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.

Bienvenidos los requerimientos de cambio, aun tarde en el proceso de desarrollo. Los procesos Agile toleran el cambio en haras de la ventaja competitiva del cliente.

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

En el desarrollo Agile, los requerimientos pueden cambiar en cualquier punto. La idea es que el cliente puede continuar haciendo cambios en tanto que estén priorizados en la iteración apropiada. Por ejemplo, si el cliente solicitó tres reportes y después desea uno más, el cuarto reporte puede ser agregado a la lista de requerimientos sin problema. En algún punto, el cliente va a necesitar priorizar este nuevo reporte y cuando lo haga dicho reporte se escribirá. Si el presupuesto del cliente está abiertamente concluido, entonces no habrá un proceso formal de cambio de alcance. Se entregará lo que desee y priorice. Si el cliente tiene un presupuesto fijo, priorizar un cambio para completarlo va a significar en esencia que alguna otra pieza de trabajo no va a ser concluida. En este escenario, el cliente esta haciendo cumplir la gestión del cambio de alcance al asegurarse que solo los cambios que tienen la más alta prioridad son priorizados mientras que otros no lo son.

El enfoque TenStep señala que cuando los cambios de negocio suceden, el equipo de proyecto debe estar preparando para responder. Sin embargo, los cambios a los requerimientos 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 de 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 tomar el corto ciclo de entrega a un 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 soporte que necesitan, y se confía en que ellos harán de trabajo.

Algunas veces, gente muy motivada tiene problemas para entregar proyectos a tiempo. (lo que fue reconocido hace medio siglo). Pueden enfocarse 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 exitosos. 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 apropiados 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, enviar correos electrónicos puede estar bien por ejemplo, cuando se envía un informe de estado del proyecto a 20 individuos. Alguna información relevante también tiene que ser escrita, si la información se necesita cuando todos los desarrolladores originales se hayan ido. Esta documentación debe ser solo para información importante. La documentación rara vez es actualizada por el equipo de soporte, por lo que puede volverse menos valiosa con el tiempo.

El que el software esté 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 implantació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 cumpla.

Los procesos Agile promueven el desarrollo sustentable. 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.

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

Proceso de Dirección de Proyectos TenStep

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 decisiones esenciales para hacer que los procesos Agile funcionen.

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

De acuerdo. Los desarrolladores de software y clientes deben enfocarse en cumplir con los requerimientos 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 ni poseen las habilidades adecuadas para desarrollar los mejores diseños y arquitecturas. Particularmente, las arquitecturas deben ser diseñadas a nivel organizacional. Si ese trabajo se dejara a equipos individuales, el resultado sería tecnología 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 debiesen elevarse a nivel organización de modo que las ideas de mejora puedan apalancarse por todo el personal.

—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
www.agileAlliance.org