1. La gestión ágil de proyectos y sus paralelos con el PMBoK® Guide
Alejandro Gabay, PMP, PMI-ACP, CSM
JORNADAS ARGENTINAS DE DIRECCION DE PROYECTOS
Córdoba 2014

2. Expositor
•Computador Científico – Facultad de Ciencias Exactas y Naturales (UBA)
•Certificado PMP (2002) y PMI-ACP (2012)
•Certified Scrum Master (2009)
•Miembro fundador del 1er capítulo argentino del PMI (1996)
•10 años como Docente de Dirección de Proyectos en la Asociación ORT Argentina, en la Universidad de Buenos Aires y en el Centro de Estudios en PM de UTN-FRBA (Posgrado en dirección de proyectos).
•Fue docente en Ciencias de la Computación en FCEN (UBA) como docente a cargo y jefe de trabajos prácticos.
•Más de 30 años de experiencia en IT en dirección de proyectos de desarrollo, consultoría e implementación de metodologías de dirección de proyectos. Experiencia realizada en Argentina, EEUU, Brasil y América Latina.

3. Agenda
•Manifiesto Agil
•Breve Introduccion a Scrum
•Actores
•El Proceso y sus Ceremonias
•El PMBoK® Guide
•Notas sobre Scrum en las Areas del PMBoK
•Mitos sobre Agile y PMI
•Cuando usar Agile
•Bibliografía

4. La gestión ágil de proyectos y sus paralelos con el PMBoK® Guide
El PMI® ya reconoce la importancia del enfoque ágil y ha creado la certificación PMI-ACP®, mientras las organizaciones aún discuten si las metodologías ágiles son o no la solución para la gestión de proyectos y si son compatibles con la gestión tradicional.
En esta disertación revisaremos brevemente los conceptos básicos del Manifiesto Agil y del framework Scrum (la metodología ágil más difundida) y se trazarán paralelos entre PMBoK® y las prácticas ágiles.
Se presentarán conceptos, procesos y herramientas generales, más allá del mundo de IT y aplicables en diferentes industrias.

5. Manifiesto Agil (Agile Manifesto)
(a.k.a. Manifiesto por el Desarrollo Ágil de Software)
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Web: http://agilemanifesto.org/ …en español: http://agilemanifesto.org/iso/es/

6. Agilidad
•¿Qué es Agilidad?
Según Jim Highsmith, uno de los creadores del manifiesto:
“Agilidad es la capacidad de crear y responder al cambio con el fin de obtener ganancias en un entorno empresarial turbulento”
“Agilidad es la capacidad de equilibrar flexibilidad y estabilidad”
“El software funcionando es la medida principal de progreso”
6

7. Varios colores de Agile
Scrum
Es un marco de trabajo (framework) para la gestión y desarrollo de software. Utiliza un proceso iterativo e incremental para optimizar la previsibilidad y controlar el riesgo.
7
oScrum
oCrystal Methods
oUnified Process (UP)
oLean Development (LD)
oExtreme Programming (XP)
oDynamic Systems Development Method (DSDM)

8. Scrum - Actores
•Product Owner
oResponsable de maximizar el valor del trabajo del trabajo que realiza el scrum team. Es el representante del usuario/dueño del producto.
oAdministra y prioriza los requerimientos (Product Backlog).
•Scrum Master
oResponsable de asegurarse que el proceso es comprendido y utilizado adecuadamente.
oPrepara/entrena al equipo de trabajo, elimina impedimentos y trabaja constantemente para asegurarse que el equipo pueda conseguir los objetivos del Sprint
•Scrum Team
oEl equipo que realiza el trabajo. Tamaño óptimo 7 personas
oEl equipo se auto-organiza y es responsable en forma conjunta de los resultados del trabajo.
8

9. Scrum - Proceso
Product Backlog
Sprint Backlog
24 hs
Producto Instalable
Iteracion /Sprint 2 a 4 semanas
Planificación Release
Planificación sprint
Qué?
Cómo?
Retrospectiva Sprint
Daily Standup
1. Qué hizo?
2. Qué hará?
3. Impedimentos?
Revisión del sprint

10. ¿Qué es el PMBoK®?
•Guía publicada por el Project Management Institute
–Va por la 5ta. edicion (Diciembre de 2012)
•Describe un conjunto de buenas prácticas para la dirección de proyectos, incluyendo:
–procesos, habilidades, técnicas y herramientas
•Proporciona y promueve un lenguaje común.
•Se focalize en 5 grupos de procesos.
–Inicio, Planificación, Ejecución, Monitoreo y Control, y Cierre.
•Enumera un total de 47 procesos distribuidos en 10 áreas de conocimientos.

11. PMBoK: Areas de Conocimiento
11

12. PMBoK®: Sobre Metodología
•Pag.35. Entre estas restricciones(*), así como las limitaciones adicionales de tiempo y presupuesto, es función del PM y del equipo del proyecto determinar el método más adecuado para llevar a cabo el proyecto.
El equipo elige la metodología
(*) Según modelo de Governance
•Pag.48. Para un proyecto determinado, el PM, en colaboración con el equipo de proyecto, tiene siempre la responsabilidad de determinar cuáles son los procesos adecuados, así como el grado de rigor adecuado para cada proceso.
El equipo determina los procesos

13. PMBoK®: Tipos de Ciclo de Vida
•Ciclos de Vida Predictivos
–Son aquellos en los cuales el alcance del proyecto, el tiempo y costo requeridos para lograr dicho alcance, se determinan lo antes posible en el ciclo de vida del proyecto.
•Ciclos de Vida Iterativos e Incrementales
–Son aquellos en los cuales, dentro de las fases (o iteraciones), se repiten de manera intencionada una o más actividades el proyecto a medida que aumenta el entendimiento del producto por parte del equipo de proyecto.
•Ciclo de Vida Adaptativos
–Conocidos como métodos orientados al cambio o métodos ágiles.
–Son iterativos e incrementales.
–…

14. PMBoK®: Ciclo de Vida Adaptativo
…
•Pretenden responder a niveles altos de cambio y la participación continua de los interesados.
•Difieren en que las iteraciones son muy rápidas y de duración y costos fijos (normalmente con una duración de 2 a 4 semanas)
•Generalmente ejecutan varios procesos en cada iteración
–Aunque las iteraciones iniciales pueden concentrarse en planificación.
•Al final de cada iteración el producto debe estar listo para su revisión por el cliente.
•Los representantes del patrocinador deben estar continuamente involucrados en el proyecto para proporcionar retroalimentación sobre los entregables.

15. PMBoK®: Ciclo de Vida Adaptativo
Generalmente se opta por métodos adaptativos en entornos que cambian rápidamente, cuando los requisitos y el alcance son difíciles de definir con antelación y cuando es posible definir pequeñas mejoras graduales que aportarán valor a los interesados.
(PMBoK pag. 46)

16. Notas sobre Gestión de la Integración
•Plan de Proyecto
“Los planes son inútiles. La planificación es esencial”.
- Dwight D. Eisenhower, General y Presidente (1890-1961)
–Plan para el release y planes iterativos a medida que se avanza.
–El team es dueño y se compromete con el plan.
–Estilo de planificación gradual (“Rolling wave”)
•Gestión Integrada de Cambios
–Este proceso se simplifica e integra a la rutina diaria del equipo.
–Los cambios al producto se trabajan a través del Product Backlog.
–Sprint Review y Sprint Retrospective sirven también como parte de control de cambios, de producto y de proceso.
•Cierre de Proyecto
–Retrospectivas cumplen la función de lessons learned.
16

17. Notas sobre Gestión del Alcance
•Recolección de Requerimientos
–User Stories, Sprints Reviews.
•Definicion del Alcance y WBS
–Partiendo del Product Backlog se definen en el Sprint Planning.
–Cada User Story se puede asimilar a un work package.
–Epics y Themes para hablar de descomposición.
•Validación del Alcance
–Se realiza con cada iteracion durante el Sprint Review con el Product Owner e Interesados
17

18. Notas sobre Gestión del Alcance
•Corrupción del Alcance (Scope Creep)
–La plaga en los proyectos tradicionales de desarrollo,
–En SCRUM se convierte en algo esperado y bienvenido.
Valoramos más la rrespuesta ante el cambio sobre seguir un plan
18

19. Notas sobre Gestión de Tiempos y Costos
•Estimación
–La estimación básica de Tiempos será cantidad de Sprints:
»Cantidad de Story Points / Velocidad del Team
–La estimación básica de costos será simplemente:
»Costo del Team x Duración del Release
–Velocidad del equipo: Se mide en Story Points x Sprint.
•Focalización en impedimentos
–No se requiere identificar el camino critico del proyecto.
–Se registran y atacan los impedimentos para avanzar.
•Control de Avance
–Se utilizan los Burn Down charts.
•Una buena medida para proyeccciones
–Uso de Valor Ganado (Earned Value)
19

20. Notas sobre Gestión de la
•Planificar la Calidad
–Terminado (done). Debe haber un criterio único para todos los actores e interesados.
–Establecer claramente qué es la “definición de done” (DoD).
–Definir los tipos de pruebas a realizar.
•Aseguramiento de la Calidad (QA)
–Sprint Review y Sprint Retrospective incluyen QA.
–Mejora Continua está embebida en el concepto de iteraciones.
•Control de la Calidad (QC)
–Se pone el énfasis en trabajar con los desarrolladores durante cada iteración para encontrar y eliminar los defectos.
–Automatización de pruebas
20

21. Notas sobre Gestión de RRHH
•Los equipos son multi-funcionales
–Gran desafío:
»Cómo trabajar con especialistas que no se requieren 100% del tiempo.
»La gente cumple con más de un rol.
•Equipos auto-gestionados y motivados
–Los miembros están involucrados y comunicados.
•Capacidades del equipo
–Aumenta gracias a la colaboración y el trabajo en equipo.
21

22. Notas sobre Gestión de las Comunicaciones
•Plan y Distribución de Información
–Formalización de reuniones y documentos establecida.
–Simplificación utilizando Pizarras y post-it.
Simplicidad es el arte de maximizar la cantidad de trabajo no realizado
–Burn Down charts, CFD, Kanban y EVM para reportar
22

23. Notas sobre Gestión de Riesgos
•Planificación de Riesgos
–No hay necesidad de un plan formal.
–El método para abordar los riesgos está incluído en los procesos de Scrum.
•Análisis
–En general el análisis es solo cualitativo.
–Las cortas iteraciones y revisiones hacen que esto sea efectivo.
•Monitoreo y Control
–La re-evaluación de los riesgos se hace durante las retrospectivas.
–El monitoreo se hace hasta en los daily standups donde se exponen los riesgos potenciales, los disparadores y los nuevos obstáculos.
–La tercera pregunta del daily standup: ¿Qué impedimentos tiene?
23

24. Notas sobre Gestión de Interesados
•Identificar y Gestionar Interesados
–Nada está oculto, los problemas se discuten
–El contacto constante es clave para el éxito del proyecto
–Manejo de expectativas a través de los Sprint Review
–Product Owner es parte del equipo
–Contratistas y proveedores se integran con el equipo
24

25. Mitos sobre Agile y PMI (1)
•Los procesos agiles eliminan la necesidad de tener Aseguramiento de la Calidad y Gestión del Proyecto
–Muchas de las actividades tradicionales de QA y PM fueron distribuidas a lo largo de los procesos y en el team.
•Los equipos agiles no planifican ni documentan su trabajo
–Los planes se revisan y reconstruyen en forma regular y con el nivel de detalle necesario en cada etapa, con un estilo “rolling wave” (Ciclo de vida adaptativo)
•Quienes practican agile ven la definición de requerimientos y diseño como ceremonias a evitar y que no aportan valor para el cliente.
–La definición de requerimientos es fundamental para el éxito de las iteraciones.
25
Falso
Falso
Falso

26. Mitos sobre Agile y PMI (2)
•Los métodos ágiles entran en conflicto con los procesos del PMBoK®.
–Las áreas del PMBoK se deben aplicar en cada iteración y deben ser planificadas y gestionadas para cumplir con los requerimientos en tiempo y según el presupuesto.
•Los proyectos ágiles se pueden hacer más rápido, con menos recursos y sin un PM.
–El PM debe ser un facilitador, dedicándose más a liderar y menos a gerenciar.
26
Falso
Falso

27. ¿Cuándo utilizar Agile?
•Agile SI
–Si el cliente del proyecto está involucrado y disponible.
–El equipo de trabajo está altamente calificado y motivado.
–El proyecto es innovador, experimental o novedoso para la organización.
–Si va a haber colaboración dentro del equipo y con el cliente en forma diaria
27
oAgile NO
–Si el proceso de control de cambios es formal y se requiere mucha documentación.
–Equipos de trabajo con personal con poca experiencia en puestos claves
–Si el cliente tiene una limitada participación.

28. Bibliografía recomendada
•Autores más recomendados
–Jim Highsmith, Ken Schwaber, Jeff Sutherland, Mike Cohn
–Mary and Tom Poppendieck, Michele Sliger
•Videos en youtube
–Buscar “scrum in under 10 minutes” by Hamid Shojaee
–Buscar Ken Schwaber en google talks (1 hora).
•White papers y artículos
–http://www.pmi.org En pmi.org (gratis para miembros)
–http://www.scrumalliance.org
–http://www.agilealliance.org
–http://www.versionone.com
–http://www.infoq.com
28

29. Vamos a probar
algo llamado
programación agil
Esto significa nada de Planificar y nada de documentación. Solo empiecen a programar y a quejarse
Me alegra que tenga un nombre
Este fue su entrenamiento

30. Preguntas y Respuestas

31. Muchas Gracias!
Alejandro Gabay, PMP, PMI-ACP, CSM
alejandro.gabay@gmail.com
JORNADAS ARGENTINAS DE DIRECCION DE PROYECTOS
2014