Gestión Ágil de Proyectos

Manifiesto Ágil - Pecados Capitales

Febrero 2001

¿tenemos que aplicar todos los procesos del

PMBOK®, manual de buenas prácticas para la

dirección de proyectos del PMI®, a todos los

proyectos?

La respuesta es un rotundo NO. Si siempre

quisiéramos aplicar todos los procesos, los proyectos

se pondrán demasiado lentos y burocráticos. Pero es

muy importante conocer todos los procesos de la

dirección de proyectos, para saber cuáles de esos

son los que mejor aplican a cada proyecto en

particular.

En lugar de escribir varias páginas explicando los

estados de avance de un proyecto, o cuando lo

haremos funcionar, o en qué porcentaje estimado de

avance se encuentra; es preferible ver si el software

está funcionando o no, y dedicar los escasos recursos

a hacerlo funcionar, en lugar de estar redactando

testamentos explicativos.

¿Sirve estar de manera permanente negociando los términos contractuales? ¿Agrega valor derivar los

conflictos al departamento legal de cada una de las partes?

Es preferible reconocer que no hay un contrato perfecto y ambas partes se pueden haber

equivocado en su redacción y/o comprensión. Si entendemos que nuestro cliente es un aliado

estratégico y logramos mantener una relación fluida de colaboración, los proyectos terminarán más rápido y con mayor valor, en relación a destinar

escasos recursos a peleas contractuales.

No existe un solo proyecto que termine exactamente

igual a lo que decía su plan original. Tenemos que

entender que el plan perfecto no existe. Además el

contexto cambia de manera permanente, y si

queremos realizar el proyecto siguiendo al pie de la

letra lo que dice el plan, muchas veces vamos a

estrellar el proyecto.

Tenemos que ser flexibles a los cambios que necesita

el cliente.

Principios del Manifiesto Ágil1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los

procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al

cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con

preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo

y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores

y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia.

Manifiesto de las AMsagilemanifesto.org

Principios:

1. La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor

2. Dar la bienvenida a los cambios. Los AMs capturan los cambios para que el cliente tenga una ventaja competitiva

3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente

… Manifiesto de las AMs

4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto

5. Construir proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo

6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo

7. El software que funciona es la medida principal de progreso

… Manifiesto de las AMs

8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante

9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad

10. La simplicidad es esencial

11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos

12. En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento

Gestión Tradicional vrsGestión Ágil

Los procesos de producción empleados por la gestión de proyectos tradicional tienen como finalidad la repetibilidad de los resultados: conseguir el trabajo planificado (y conocido de antemano) en el plazo planificado y por el coste previsto.

La gestión ágil no tiene un carácter predictivo o de anticipación. No conoce de antemano el detalle del producto o servicio que va a desarrollar; por eso su objetivo no es la fiabilidad en el cumplimiento de los planes, sino en el valor del resultado y el tiempo de salida al mercado.

Los procesos de la gestión tradicional son buenos cuando consiguen desarrollar de forma repetible los productos especificados en el tiempo y con los costes previstos.

Los procesos de la gestión ágil

son buenos, cuando consiguen

entregar de forma repetible valor innovador.

Comparación Ágil - No Ágil

Metodología Ágil Metodología No Ágil

Pocos Artefactos Más Artefactos

Pocos Roles Más Roles

No existe un contrato tradicional o al

menos es bastante flexible

Existe un contrato prefijado

Cliente es parte del equipo de

desarrollo (además in-situ)

El cliente interactúa con el equipo

de desarrollo mediante reuniones

Grupos pequeños (< 10 integrantes)

y trabajando en el mismo sitio

Grupos grandes

Menos énfasis en la arquitectura La arquitectura es esencial

Estructura del desarrollo Ágil

Descripción de Fases•En la fase de concepto se crea la visión del producto o servicio que se

quiere obtener. Se decide y selecciona al equipo de personas que lo llevarán a cabo.

1.Concepto

•Desarrollo y revisión de requisitos / Desarrollo de lista de funcionalidades esperadas / Construcción de un plan de entrega / Puede incluir planes de riesgos e información administrativa y financiera.

2. Especulación

•Se desarrollan las funcionalidades de un incremento del producto, que han sido determinadas por el equipo en la fase anterior3. Exploración

•El equipo y los usuarios revisan las funcionalidades construidas hasta ese momento. Trabajan y operan con el producto real para determinar su alineación y dirección con el objetivo

4. Revisión

•Al llegar a la fecha de entrega de una versión de producto (fijada en la fase de concepto y revisada en las diferentes fases de especulación), se obtiene el producto esperado.

5. Cierre

¿Cuándo un método es Ágil?

El desarrollo del producto es

• Incrementalo liberaciones pequeñas y ciclos rápidos.

• Cooperativoo clientes y desarrolladores trabajando juntos.

• Simple y Directoo el método es fácil de aprender y modificar.

• Adaptativoo es posible realizar cambios de último momento.

Baches de Tiempo

Pecados Capitales

7 Pecados capitales del tiempo

1. - Parálisis en la toma de decisiones: pereza por no avanzar,

postergando siempre las decisiones para más adelante. El

proyecto no avanza, y a veces una “mala decisión” podría

ser preferible a este estado crónico de “no decisión”.

2. - Ciclos de aprobación recurrente: gula por trabajar en exceso con múltiples aprobaciones burocráticas, que

originan un ciclo lechero recurrente sin final, que impide que

el proyecto avance.

3. - Formalidad de la documentación: avaricia de querer más y

más información formal excesiva, en lugar de avanzar con

buena información preliminar.

4. - Reuniones regulares: ira que nos da cada vez que nos invitan a una reunión donde no hacemos nada, no agregamos valor al proyecto, y nos quitan innecesariamente

nuestro escaso tiempo de trabajo, lo que retrasa el proyecto.

7 Pecados capitales del tiempo

5. - Esperas en colas: envidia que tenemos de aquellas organizaciones que gestionan sus tiempos con un esquema eficiente de turnos, en lugar de la ineficiencia de estar esperando en largas colas hasta que nos toca a nosotros para poder avanzar.

6. - Dueños de la información: soberbia de aquellos sabelotodo que no comparten la información con el resto del equipo, lo que genera cuellos de botella y retrasos en los avances del proyecto.

7. - Lujuria: La combinación de varios de los pecados anteriores se convierte en una especie de lujuria, que tenemos que evitar si queremos un proyecto rápido y eficiente.

7 Pecados capitales de los costos

1. - Falta de un lenguaje común: soberbia de creernos que nuestro idioma tecnicista es mejor que el de los demás. Deberíamos utilizar diccionarios, capacitación y traductores para unificar el lenguaje.

2. - Formalidad excesiva: avaricia de querer más y más control en los proyectos. Esta burocracia excesiva la deberíamos eliminar pensando en el flujo de valor al cliente sin interrupciones.

3. - Repeticiones sin final: envidia de los gerentes funcionales hacia los directores de proyectos, que no los dejan avanzar metiendo trabas con aprobaciones recurrentes sin final. Los gerentes funcionales y directores de proyecto deberían trabajar en equipo.

4. y 5. - Falta y excesos de información: pereza por no conseguir todos los datos para entender realmente las necesidades del cliente; o gula de plagarnos de información que nos genera costos innecesarios. Evitar los extremos, tanto la falta de información como el exceso de información son perjudiciales para el proyecto.

7 Pecados capitales de los costos

6. - Distancias: ira que separa a los miembros del

equipo y hace que se comuniquen menos. Si fuera

posible, colocar a los miembros del equipo de

proyecto lo más cerca posible.

7 Pecados capitales de los costos

7. - Pobre elección de medios de comunicación:

lujuria de abusar del mal uso de los medios de

comunicación. Evitemos la emailitis y aquellos

medios con los que seguramente tenemos

demasiados costos de transacción.

Algunas recomendaciones

Estadísticas de comunicación

Pecados típicos por el mal uso del e-mail

1. Colocar en copia a todo el mundo, ya que es más cómodo copiar a

todos en lugar de pensar quiénes realmente deberían recibir el mail.

2. Responder el mail que nos mandan con copia a todos, con tonteras

como “qué lindo”, “yupi”, “aleluya”, etc., etc., etc. Y nuestros colegas

también responden con copia a todos, y cuando nos descuidamos ya

tenemos cientos de emails del mismo tema en nuestra casilla.

3. Re-enviar un mail que ya lleva varios ciclos de envío recepción,

donde si alguien lo quiere entender, tendrá que hacer varias páginas

de scroll-down para empezar a leer desde abajo hacia arriba.

4. Colocar varios adjuntos en el mail, ya que es más simple meter todos

los documentos que tenemos en la computadora, que pensar cuáles

son realmente los documentos críticos que deberíamos enviar.

5. Escribir un mail de cientos de renglones donde se parece más a un

testamente que a un mensaje.

6. Utilizar siempre el signo “!” de mail prioritario, aunque no sea de

carácter “urgente” lo que estamos enviando.

Recomendaciones para el uso de e-mail

1. Pensar muy bien a quiénes debo poner en copia. Más de tres personas ya puede ser una pista de que empiezo a pecar en exceso.

2. No responder los mails con copia a todos.

3. No enviar un mail que ya tenga más de dos ciclos envío-recepción. En su lugar, redactar nuevamente el resumen ejecutivo de lo que queremos comunicar.

4. No enviar adjuntos innecesarios.

5. No escribir un mail que tenga más de 20 renglones. Para asuntos largos escribir en el procesador de textos y enviar como adjunto.

6. Reservar el signo “!” para asuntos realmente urgentes o prioritarios.