metodologias agiles de gestion de proyecto. ort 14.05.2014
DESCRIPTION
Dictado en ORT el 14 de Mayo de 2014. Las organizaciones de IT discuten si las metodologías ágiles son o no la solución para la gestión de proyectos de desarrollo de software. Las oficinas de proyectos (PMO) discuten si las metodologías ágiles son compatibles con los estándares y prácticas propuestos por el PMI. Se hará una breve introducción a Scrum, una de las metodologías ágiles más difundidas, revisando sus procesos, actores y herramientas y se trazarán paralelos entre Scrum y PMI, para finalizar revisando brevemente en qué casos convendría utilizarlo. También se comentará sobre la nueva certificación PM-ACP del PMI y se dispondrá de un espacio para consultas al respecto. Conferencia dictada en ORT Buenos Aires, Argentina el 14.05.2014 por Alejandro Gabay Presentacion del Manifiesto Agil, Proceso de Scrum y comparación entre PMBoK y PMI. Agile Methodologies for Project ManagementTRANSCRIPT
Metodologías ágiles de Dirección
de Proyectos ¿Agile vs. PMI?
Alejandro Gabay, PMP, PMI-ACP, CSM
Mayo 2014
Agenda
Manifiesto Agil
Breve Introduccion a Scrum
Actores
El Proceso y sus Ceremonias
Notas sobre Scrum en las Areas del PMBoK
Mitos sobre Agile y PMI
Cuando usar Agile
Bibliografía
Nueva certificación PMI-ACP
2
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/
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”
4
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.
5
• Scrum
• Crystal Methods
• Unified Process (UP)
• Lean Development (LD)
• Extreme Programming (XP)
• Dynamic Systems Development Method (DSDM)
Scrum - Actores
Product Owner Responsable de maximizar el valor del trabajo del trabajo que
realiza el scrum team. Es el representante del usuario/dueño del producto.
Administra y prioriza los requerimientos (Product Backlog).
Scrum Master Responsable de asegurarse que el proceso es comprendido y
utilizado adecuadamente.
Prepara/entrena al equipo de trabajo, elimina impedimentos y trabaja constantemente para asegurarse que el equipo pueda conseguir los objetivos del Sprint
Scrum Team El equipo que realiza el trabajo. Tamaño óptimo 7 personas
El equipo se auto-organiza y es responsable en forma conjunta de los resultados del trabajo.
6
Pigs & Chickens
7
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
¿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.
PMBoK: Areas de Conocimiento
10
PMBoK®: Sobre Metodología
Pag.35. Entre esas restricciones(*), así como las limitaciones
adicionales de tiempo y presupuesto, es función del PM y del equipo
del proyecto determinar el método 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 apropiados, así como el grado de rigor
adecuado para cada proceso.
El equipo determina los procesos
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 team.
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.
12
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
13
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.
Manifiesto:
“Valoramos más respuesta ante el cambio sobre seguir un plan”
14
Restricciones Funcionalidad Costo Cronograma
Estimaciones Costo Cronograma Funcionalidad
Guiado
por
Plan
Guiado por
Visión / Valor
Enfoque Tradicional SCRUM
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)
15
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 Contínua 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
16
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.
17
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.
“Simpleza es el arte de maximizar la cantidad de
trabajo no hecho”
Burn Down charts y EVM para reportar
rendimiento.
18
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?
19
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
20
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”.
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.
21
Falso
Falso
Falso
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.
22
Falso
Falso
¿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
23
Agile 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.
Bibliografía recomendada
PMBok última edición
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
24
Nueva Certificación PMI-ACP
Educación
Título secundario
Experiencia en Proyectos en general
2.000 horas (12 meses) de trabajar en equipos de proyecto
Esta experiencia se debe haber sido obtenida en los últimos 5 años
Esto no se requiere para quién es PMP y/o PgMP
Experiencia en Proyectos Agiles 1.500 horas (8 meses) trabajando en equipos de proyecto ágiles o utilizando
metodologías ágiles
Esta experiencia se debe haber sido obtenida en los últimos 3 años
Esto es además de las 2.000 horas anteriores
Capacitación de Gestión de Proyectos Agiles
21 horas de capacitación en temas de gestión de proyectos ágiles
Aprobar el examen de certificación
Son 120 preguntas a responder en 3 horas.
Requerimientos Certificación PMI-ACP
26
Completar la aplicación Hay 90 días para completarla desde que se comienza
Revisión por parte de PMI
Hasta 10 días desde que se completa
Pago del examen Miembros PMI USD 435. No miembros USD 495.
Auditoría por parte del PMI
Hay 90 días para presentar la información
El PMI toma de 5 a 7 días para revisar el material
Examen multiple-choice Hay 1 año para rendir desde la aprobación de la aplicación
Se puede tomar hasta 3 veces en este primer año
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
Proceso de Certificación
27
Comienza con la aprobación del examen
La certificación dura 3 años
Mantenimiento de la certificación
Se deben obtener y reportar 30 PDUs dentro de los 3 años
Renovación Miembros PMI USD 90. No miembros USD 130.
Suspensión de la certificación
Ocurre pasados los 3 años, por un año si no se obtienen 30 PDUs
Expiración de la certificación Pasado el año de suspensión.
Hay que aplicar de nuevo para obtener la certificación
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
Ciclo de Certificación
28
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
Quién debe aplicar
Requeriemientos
Cómo aplicar
Cómo mantener la certificación
Bajar el PMI-ACP Handbook
Más información…
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