Conferencia dictada en ORT Buenos Aires, Argentina el 19.07.2011 por Alejandro Gabay
Presentacion del Manifiesto Agil, Proceso de Scrum y comparación entre PMBoK y PMI.
Agile Methodologies for Project Management
2. Agenda
Manifiesto Agil
Breve Introduccion a Scrum
Actores
El Proceso y sus Ceremonias
Notas sobre Scrum en las Areas del PMBoK
Herramientas
Burn Down Charts
AgileEVM
Mitos sobre Agile y PMI
Cuando usar Agile
Bibliografía
2
3. 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/
4. 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
5. Varios colores de Agile
• Scrum
• Crystal Methods
• Unified Process (UP)
• Lean Development (LD)
• Extreme Programming (XP)
• Dynamic Systems Development Method (DSDM)
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
6. 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
8. PMBoK: Grupos y Areas de Conocimiento
Procesos Procesos de
de Inicio Planificación
Procesos de Procesos de
Control Ejecución Integración
Alcance Tiempos
Procesos
de Cierre Costos Calidad
RRHH Comunicaciones
Riesgos Adquisiciones
8
9. 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.
9
10. 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.
Verificación del Alcance
Se realiza con cada iteracion durante el Sprint Review con el
Product Owner e Interesados
10
11. 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”
Enfoque Tradicional SCRUM
Restricciones Funcionalidad Costo Cronograma
Guiado por
Visión / Valor
Guiado
por
Plan
Estimaciones Costo Cronograma Funcionalidad
11
12. 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 (Velocity)
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)
12
13. Burn Down Charts
Release Burn Down Chart
Muestra la cantidad de Story Points
faltantes en el release, por cada
iteración.
La línea verde representa el óptimo
“consumo” de Story Points.
Sprint Burn Down Chart
Se estiman la cantidad de horas
de esfuerzo faltantes de la iteración.
Se mide por día.
13
14. AgileEVM – Valor Ganado
¿Qué necesito saber? Funcionalidad SP SP
Cantidad de Sprints del release (4) Est. Comp.
Cantidad de Story Points (120) Home 10 10
Prespuesto del Release (BAC) ($ Somos ? 5 5
160.000)
Login 10 10
Publicidad 5
Mediciones Catalogo 15
Cantidad de SP completados (25) Fotos 15
Cantidad de iteraciones Ver Carrito 10
completadas (1) Agr. Carrito 20
Costo Real (AC) ($ 50.000)
Envio 10
Cantidad de SP agregados o
removidos (0) Check-out 20
Total 120
14
15. AgileEVM – Valor Ganado
# Iteraciones Completadas 1
% Esperado Completado (EPC) = = = 25%
# Iteraciones Totales 4
# SP Completados 25
% Real Completado (APC) = = = 21%
# SP Estimados 120
PV Iteracion = EPC x BAC = 25% x 160.000 = 40.000
EV = APC x BAC = 21% x 160.000 = 33.600
CPI = EV / AC = 33.600 / 50.000 = 0.672 CV, SV, ETC, EAC...
SPI = EV / PV = 33.600 / 40.000 = 0.84
15
16. 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
17. 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
18. Notas sobre Gestión de las Comunicaciones
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.
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
19. 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
20. Mitos sobre Agile y PMI (1)
Los procesos agiles eliminan la necesidad de tener Aseguramiento
de la Calidad y Gestión del Proyecto Falso
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 Falso
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. Falso
La definición de requerimientos es fundamental para el éxito de las
iteraciones.
20
21. Mitos sobre Agile y PMI (2)
Los métodos ágiles entran en conflicto con los procesos del
PMBoK®. Falso
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. Falso
El PM debe ser un facilitador, dedicándose más a liderar y menos
a gerenciar.
21
22. ¿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
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.
22
23. 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
23
24. Esto significa nada de
Planificar y nada de Me alegra
Vamos a probar documentación. Solo que tenga Este fue su
algo llamado empiecen a programar un entrenamiento
programación agil y a quejarse nombre