Gestión Ágil de Proyectos Manifiesto Ágil - Pecados Capitales

Transcripción

1 Gestión Ágil de Proyectos Manifiesto Ágil - Pecados Capitales

2 Febrero 2001

3 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.

4 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.

5 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.

6 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.

7 Principios del Manifiesto Ágil 1. 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.

8 Manifiesto de las AMs agilemanifesto.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

9 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

10 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

11 Gestión Tradicional vrs Gestió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. 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. 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 ágil son buenos, cuando consiguen entregar de forma repetible valor innovador.

12 Comparación Ágil - No Ágil Metodología Ágil Pocos Artefactos Pocos Roles No existe un contrato tradicional o al menos es bastante flexible Cliente es parte del equipo de desarrollo (además in-situ) Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio Menos énfasis en la arquitectura Metodología No Ágil Más Artefactos Más Roles Existe un contrato prefijado El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos grandes La arquitectura es esencial

13 Estructura del desarrollo Ágil

14 Descripción de Fases 1.Concepto 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. 2. Especulación 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. 3. Exploración Se desarrollan las funcionalidades de un incremento del producto, que han sido determinadas por el equipo en la fase anterior 4. Revisió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 5. Cierre 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.

15 Cuándo un método es Ágil? El desarrollo del producto es Incremental o liberaciones pequeñas y ciclos rápidos. Cooperativo o clientes y desarrolladores trabajando juntos. Simple y Directo o el método es fácil de aprender y modificar. Adaptativo o es posible realizar cambios de último momento.

16 Baches de Tiempo Pecados Capitales

17 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 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 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 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.

18 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 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 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.

19 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 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 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.

20 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.

21 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 itis y aquellos medios con los que seguramente tenemos demasiados costos de transacción.

22 Algunas recomendaciones

23 Estadísticas de comunicación

24 Pecados típicos por el mal uso del 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 s 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.

25 Recomendaciones para el uso de 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íorecepció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.

26