El documento presenta los conceptos y principios básicos de la metodología ágil Scrum para la gestión de proyectos de software. Scrum utiliza roles, artefactos y reglas para permitir el desarrollo incremental de funcionalidades en ciclos cortos (sprints) de 2-4 semanas, con el objetivo de entregar valor al cliente de forma continua y responder ante cambios. El documento describe los roles de Product Owner, Scrum Master y Equipo de Desarrollo, así como los artefactos clave como el Product Backlog, Sprint Backlog y los resultados del sprint

1. Mitos y Leyendas de la
Gestión Ágil deGestión Ágil de
Proyectos
Ing. Mariel Feder Szafir, MC, PMP

2. El contexto
• Proyectos de TI, la constante es el cambio.
• Introducción de nuevas tecnologías
• Reglas de negocios que cambian rápidamente.
• Liberaciones parciales que modifican las expectativas
Los requerimientos
están apareciendo en
mi mente en este
momento
Ahora están cambiando…
Cambiando… cambiando…
Cambiando… Ok. No,
espere… cambiando…
Cambiando… fin.
Por supuesto,
no compartiré
estas ideas con
el
departamento
de Ingeniería.
Ok, Ya
presupuesté
matones para
obtenerlas

3. Manifiesto Ágil
• Priorizar:
• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación completa
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan• Respuesta ante el cambio sobre seguir un plan
• Esto es, aunque se valora los elementos de la derecha, se
prioriza los primeros.

4. 12 principios
• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
• Entregamos software funcional frecuentemente, entre dos semanas
y dos meses, con preferencia al periodo de tiempo más corto
posible.posible.
• Los responsables de negocio y los desarrolladores trabajamos juntos
de forma cotidiana durante todo el proyecto.
• 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.
• 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.

5. 12 principios
• El software funcionando es la medida principal de progreso.
• Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.
• A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.

6. Concepto Ágil
• La agilidad es un marco común, las metodologías
implementaciones

7. “Metodologías”Ágiles más populares
• SCRUM
• Lean
• XP = Exterme Programming
• TDD = Test Design Driven
• Dynamic Systems Development
Method (DSDM)
(FDD)
• Lean Software Development
(LSD)
• Kanban
• Open Unified Process (OpenUP)
• Programación Extrema (XP)Method (DSDM)
• 1643551(ASD)
• Agile Unified Process (AUP)
• Crystal Clear
• Agile Modeling
• Essential Unified Process (EssUP)
• Feature Driven Development
• Programación Extrema (XP)
• Método de desarrollo de
sistemas dinámicos (DSDM)
• G300 (o también llamada del
300%).

8. Conceptos en Común
• Desarrollo incremental con ciclos cortos
• Cooperación entre cliente y desarrollador y mucha
comunicación personal
• Capacidad de adaptación, incorporación de cambios (vs PLAN-
DRIVEN )DRIVEN )

9. Comparación
Área Ágiles Tradicionales/Predictivas
Desarrolladores Ágiles, con mucho conocimiento,
comprometidos, colaboración
Orientados al plan, habilidades
adecuadas, acceso a conocimiento
externo
Clientes Dedicado, relación de confianza,
colaborador, representativo,
empowered
Acceso al conocimiento, colaborador,
representativo, empowered
Requerimientos Emergentes, cambian rápidamente Definidos al comienzo, mayormenteRequerimientos Emergentes, cambian rápidamente Definidos al comienzo, mayormente
estables
Arquitectura Diseño para los requerimientos en
curso
Diseño para requerimientos actuales y
previstos
Cambios No es tan caro Caro
Tamaño Productos y equipos chicos y
medianos
Grandes equipos y productos
Objetivo principalGenerar valor rápidamente Generar seguridad

10. SCRUM

11. SCRUM
• Es un proceso de gestión. No hace referencia al proceso de
ingeniería.
• Aplicado a programas se conoce como Scrum de Scrums

12. Principio básico
• Durante un proyecto los clientes pueden cambiar
de idea sobre lo que quieren y necesitan
(requirements churn), y que los desafíos
impredecibles no pueden ser fácilmente
enfrentados de una forma predictiva yenfrentados de una forma predictiva y
planificada.
• Como el problema no puede ser completamente
entendido o definido, y centrándose en maximizar
la capacidad del equipo de entregar rápidamente
y responder a requisitos emergentes

13. Elementos de la metodología
• Roles
• Reglas
• Artefactos

14. SCRUM - Roles
• Product Owner: La voz del cliente
• Scrum Master: Facilitador
• Equipo de desarrollo
• Roles auxiliares:• Roles auxiliares:
• Stakeholders (interesados)
• Managers (administradores)

15. Product Owner
• Define los requerimientos que conforman el producto.
• Decide la fecha de entrega y el contenido de cada una.
• Responsable del Retorno de la Inversión con el cliente.
• Prioriza cada requerimiento en base al valor del mercado.
• Único responsable del listado global de requerimientos.• Único responsable del listado global de requerimientos.
• Aprueba o rechaza versiones entregables y funcionales post
iteración.
• Es la voz del cliente para con el equipo.

16. Scrum Master
• Representa y administra el proyecto.
• Responsable de la correcta aplicación de la metodología.
• Promueve la eficiencia del equipo.
• Optimiza la sinergia entre el equipo, los interesados y el
cliente.cliente.
• Es la barrera entre el equipo y los interesados.

17. Equipo de Desarrollo
• Multidisciplinario: Analistas, Programadores,
Diseñadores, Testers, QA,DBA, etc.
• De tiempo completo. Casi excluyente.
• Auto‐organizado: No necesitan un líder para• Auto‐organizado: No necesitan un líder para
funcionar. La asignación de tareas es dinámica.
• Modificable únicamente entre sprints.
• Comprometidos con el objetivo de cada sprint y los
objetivos globales de negocio.

18. Artefactos
• Product Backlog
• Sprint Backlog
• Product
• Sprint Goal

19. Product Backlog
• A cargo del Product Owner.
• Es una lista de funcionalidades priorizadas por el cliente y
estimadas según el esfuerzo a realizar para desarrollarlas.
• Deben ser simples para no generar complejidades y
re-trabajo.re-trabajo.

20. Sprint Backlog
• No se modifica durante la iteración.
• Son las funcionalidades, en orden de prioridad, a realizar
durante la siguiente iteración.
• Es el Team el encargado de auto-organizarse para realizar el
trabajo planificado.trabajo planificado.

21. Sprint Goal
• Objetivo del Sprint.
• El Team debe tener siempre en claro el mismo, para estar
enfocado en su cumplimiento.
• Este objetivo es informado en la Sprint Planning Meeting.

22. Producto
• Entregable producto de la iteración
• No es un prototipo, es un entregable funcional sobre lo
pactado en el Sprint.
• No se puede generar un entregable parcial, debe ser tal como
se comprometió que se realizaría.se comprometió que se realizaría.

23. Reglas
• Sprint
• Sprint Planning Meeting
• Daily Scrum Meeting Sprint
• Sprint Review Meeting
• Sprint Retrospective Meeting• Sprint Retrospective Meeting

24. Sprint
• Duración de 2 a 4 semanas.
• El trabajo se realiza de manera dinámica pero se debe
documentar lo realizado (sin que la misma atrase el
trabajo realizado).
• El sprint backlog es fijo sin poder modificarlo hasta el final• El sprint backlog es fijo sin poder modificarlo hasta el final
de la iteración.
• En caso de que se considere, el Scrum Master con la
aprobación del cliente puede cortar la iteración y
re‐planificar las siguientes.

25. Sprint
• Si se termina antes de lo planeado, se puede
hablar con el Product Owner para analizar si es
conveniente incluir nuevas funcionalidades a la
misma.misma.
• En caso de que se considere, el Scrum Master con
la aprobación del cliente puede subdividir las
funcionalidades en unidades más pequeñas e
incluirlas en la iteración corriente y dejar las otras
pendientes para ser replanificadas

26. Sprint planning Meeting
• 2 segmentos de 4 horas cada una.
• En la 1er sección se genera el product backlog.
• En la 2da sección se genera el sprint backlog.
• No debe estar presente ningún interesado• No debe estar presente ningún interesado
• Luego de trabajado el product backlog se trabaja
sobre los supuestos del mismo para producir el
Sprint Backlog.

27. Daily Scrum Meeting
• Reunión de 15 minutos.
• Se responde a 3 preguntas.
• ¿Qué se ha hecho desde la última reunión?
• ¿Qué se hará hasta la próxima reunión?• ¿Qué se hará hasta la próxima reunión?
• ¿Qué inconvenientes se presentaron para impedir que
el trabajo se realizara como estaba planeado?
• Si se genera algún tipo de debate, se deja
debidamente registrado y se trata en otra
reunión.

28. Sprint Review Meeting
• Duración 4 horas.
• Se invierte 1 hora máximo en la preparación de la misma.
• La presenta el Team al Product Owner e interesados.
• No se informa funcionalidad incompleta.

29. Sprint Review Meeting
• Se debe realizar sobre el ambiente de prueba
correspondiente.
• Se comienza informando el objetivo de la
iteración para luego mostrar las funcionalidades
que permiten alcanzarlo.que permiten alcanzarlo.
• Se obtiene información sobre lo realizado para
usarlo como lección aprendida.
• Al final se planifica la fecha y el lugar para la
próxima reunión.

30. Sprint Retrospective Meeting
• Duración 3 horas.
• Están presentes el Team, el Scrum Master y
opcionalmente el Product Owner.
• Se realizan 2 preguntas:• Se realizan 2 preguntas:
• ¿Qué se hizo bien en la iteración pasada?
• ¿Qué se puede mejorar para la próxima iteración?
• Se registran las respuestas de los participantes
para plasmarlas como lecciones aprendidas para
futuras iteraciones.

31. Conceptos adicionales
• Ciclo de trabajo cortos
• Replanificaciones controladas
• Team Velocity

33. Estimación
• Story Points
• Dias Ideales
• Se prioriza y analiza por funcionalidad y no por actividad.
• Se separa la estimación de la duración.• Se separa la estimación de la duración.
• En base a las funcionalidades, la estimación y la duración
deducida se genera el calendario.

34. Supuestos para la estimación
• Sólo trabajaré en la User Story que estoy estimando.
• Todo lo que necesite para desarrollar la User Story estará
disponible cuando lo necesite.
• No habrá interrupciones durante el transcurso del desarrollo
de la User Story.de la User Story.

35. Reestimaciones
• La cantidad de Story points de una User Story no varía salvo
que se modifique el alcance.
• La duración en el tiempo va cambiando al final de cada
iteración en función de la velocidad obtenida.

36. Planificación – Release Plan
1- Determinar
las condiciones a
satisfacer
2-Estimar las
user stories
3- Determinar la
duración de la
iteración
4-Estimar la
velocidad del
equipo
5-Priorizar las
user stories
6-Seleccionar las
user stories y la
fecha del release

37. Planificación

39. Sprint Planning Meeting – “Velocity
Driven”
1 -Ajustar
prioridades
2-Determinar
la velocidad del
equipo
3-Identificar el
objetivo de la
iteraciónequipo iteración
4-Seleccionar
las user stories
5-Dividir las
user stories en
actividades
6-Estimar las
actividades

40. Sprint Backlog - Ejemplo

41. Kanban

42. Dimes y Diretes

43. Mito nro 1
• Ser ágil implica informalidad
• dinámico no es lo mismo que informal

44. Mito nro 2
• En un proyecto Ágil no es necesario estimar ni planificar
• estimación continua
• planificación iterativa

45. Mito nro 3
• Se puede aplicar gestión ágil en todos los proyectos de software
y con todos los clientes.

46. Factores a considerar
• tamaño
• complejidad
• criticidad
• competencias del personal
• cultura, riesgo, limitaciones• cultura, riesgo, limitaciones
• dependencias entre funcionalidades
• estimación de costo y esfuerzo
• alineación con la estrategia, planes de TI y otros
• intereses de los stakeholders.

47. Factores a considerar

48. Criterios a considerar
• Personas
• Tecnología
• Procesos

49. Mito nro 4
• No es necesario definir el alcance del proyecto. No se requiere
gestión del alcance.

50. Mito nro 5
• No es necesario un Project Manager. El equipo se autogestiona.
• El rol de Scrum Master sustituye al Project Manager
completamente

51. Mito nro 6
• Se pueden introducir cambios en cualquier momento del
proyecto, en el momento en que se hacen necesarios. No es
necesario realizar gestión del cambio.
• Distinguir entre corrección y nuevo requerimiento
• Incorporación del cambio en el proyecto
• La clave está en la gestión del cambio• La clave está en la gestión del cambio

52. Mito nro 7
• No es necesario realizar gestión de riesgos.

53. Mito nro 8
• Como no hay un “plan”, no es necesario realizar tareas de
monitoreo. Tampoco hay indicadores o gráficos que puedan
utilizarse.

54. Ejemplos de monitoreo
• Team Velocity = velocidad del equipo

55. Ejemplos de monitoreo
• Release Burndown chart

56. Ejemplos de monitoreo
• Release Burndown BAR chart

57. Ejemplos de monitoreo
• Parking lot

58. Ejemplos de monitoreo
• Iteration Burn down chart

59. Ejemplos de monitoreo
• Diagrama de Gantt / Release Plan

60. Mito nro 8
• Todas las estrategias Ágiles son Metodologías Ágiles .
• Todas las Metodologías Ágiles son o incluyen metodologías de
Gestión.
• Scrum y las metodologías ágiles en general cubren las 9 áreas
del conocimiento.del conocimiento.

61. Cobertura

62. Mito Nro 9
• El product backlog es suficiente para todas las actividades.

63. Mito nro 10
• Es simple realizar contratos asociados a proyectos gestionados
en base a metodologías ágiles.
• Contratos de alcance variable

64. Conclusiones ….

65. Reflexiones
Vamos a intentar algo
que se llama
Programación Ágil
Eso significa no más
planificación y no más
documentación. Solo
escribir código y quejarse
Que bueno que lo que
hacemos ahora
tiene un nombre

66. Bibliografía
• Manifiesto Ágil: www.agilmanifesto.org
• Project Management the Agile Way
John C. Goodpasture
Describe varios métodos agiles. Es una guía de como evaluar y
seleccionar la mejor para un caso particular y cuando las metodologías
agiles no son la mejor opción.agiles no son la mejor opción.
• Making sense o Agile Project management: Balancing Control And Agility
Charles G. Cobb (2011)
Como los proyectos agiles encajan en el modelo general de gestión
para lograr estrategias mas efectivas. Trae casos resales mostrando
buenas y malas aplicaciones de ágil, discutiendo las metodologías
agiles y no agiles.

67. Biblografía
• Scrum Project Management
Kim H. Pries y Jon M. Quigley (2010)
Introduce los conceptos básicos de scrum y aplica como adaptarlos para gestionar
efectivamente un amplio ramo de programas y proyectos complejos. Provee métodos
de planificación para controlar el alcance y asegurar que el proyecto cumple el
cronograma, incluyendo métodos scrum de seguimiento para ayudar al equipo a
mejorar su resultados y comunicación. El autor demuestra como combinar elementos
de gestión de proyectos tradicional con scrum y discute la improvisación, solucionesde gestión de proyectos tradicional con scrum y discute la improvisación, soluciones
creativas a problemas y fenómenos emergentes.
• Agile Estimating and Planning
Mike Cohn; Prentice Hall Professional Technical Reference, 2006
Traditional, deterministic approaches to planning and estimating simply don't cut it on
the slippery slopes of today's dynamic, change-driven projects. Mike Cohn's
breakthrough book gives us not only the philosophy, but also the guidelines and a
proven set of tools that we need to succeed in planning, estimating, and scheduling
projects with a high uncertainty factor. At the same time, the author never loses sight
of the need to deliver business value to the customer each step of the way.

68. Bibliografía
• Balancing Agility and Discipline: A Guide for the Perplexed
Barry Boehm, Richard Turner; Addison‐Wesley, 2002
Nowadays, there are many methodologies you can introduce your to students. On the one
hand, there are the more agile methods that focus on individual projects, and how to get them
done fast--the camp represented by Beck and Cockburn. On the other hand, there are the
more disciplined methods, focused on setting up organizational processes for getting projects
done with predictable high quality--the camp best represented by the SEI, the CMMI, and
Humphrey. Although these methods are often presented as mutually exclusive, they actually lie
on a continuum. The authors of Balancing Agility and Discipline have worked out clear
guidelines for determining where on that continuum a particular software development
project is located--and therefore, how agile or disciplined a chosen methodology can or has to be.
guidelines for determining where on that continuum a particular software development
project is located--and therefore, how agile or disciplined a chosen methodology can or has to be.
• Succeeding with Agile: Software Development Using Scrum
Mike Cohn; Addison‐Wesley, 2003
This is a guide to starting fast with Scrum and agile–and then succeeding over the long haul.
Leading agile consultant and practitioner Mike Cohn presents detailed recommendations,
powerful tips, and real-world case studies drawn from his experience helping many software
organizations make Scrum and agile work

69. Bibliografía
• Agile Project Management with Scrum (Microsoft
Professional)
Ken Schwaber; Microsoft Press, 2003
The rules and practices for Scrum—a simple process for managing complex projects—are few,
straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be
disarming, and new practitioners often find themselves reverting to old project management
habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-
creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and
failures—culled from his years of experience coaching companies in agile project management.
Through them, you’ll understand how to use Scrum to solve complex problems and drive better
results—delivering more valuable software faster.
• Scrum and XP from the Trenches (Enterprise Software
Development)
Henrik Kniberg; C4 Media, 2007
Analiza casos reales de proyectos gestionados utilizando estas metodologías

70. Bibliografía
• J. Highsmith and A. Cockburn, “Agile Software Development: The Business of Innovation,”
Computer, Sept. 2001
• L. Copeland, “Developers Approach Extreme Programming with Caution,” Computerworld, 22
Oct.2001
• Extreme Programming Explained, G. Succi and M. Marchesi, eds.,Addison Wesley Longman,
Reading, Mass., 2001
• M. Fowler, “Is Design Dead?” Extreme Programming Explained, G. Succi and M. Marchesi,
eds., Addison Wesley Longman, Reading, Mass., 2001
• Fowler Martin, “Fixed Scope Mirage”, September 30th on http://www.martinfowler.com• Fowler Martin, “Fixed Scope Mirage”, September 30th on http://www.martinfowler.com
• Beck, Kent and Fowler, Planning Extreme Programming, Addison Wesley, New Jersey 2001.
• Beck, Extreme Programming Explained, Addison Wesley, Boston 2004
• Robert Martin, Extreme Programming Development Through Dialog, IEEE software, July
August 2000
• Kent Beck, Embracing change with Extreme Programming, IEEE Computer, Octobre 1999.
• Peter Stevens, http://www.dosideas.com, Mayo 2009, visited June 2009

71. Bibliografía
• Utilizing Agile principles alongside A Guide to the Project
Management Body of Knowledge(PMBOK® Guide) for better
project execution and control in software development projects.
Mike Griffiths. Originally published as part of 2004 PMI Global Congress
Proceedings – Anaheim, California
• Enriching PMBOK Guide by practices and techiques of agile• Enriching PMBOK Guide by practices and techiques of agile
project management of software development.
Alexander S. Lesnevsky. Originally published as part of 2007 PMI Global
Congress Proceedings, Budapest.
• Agile Project Management and the PMBOK Guide.
Michele Sliger. Originally published as part or 2008 PMI Global
Congress Proceedings, Denver, Colorado, USA.

72. Preguntas?Preguntas?

73. Porquéel Pollocruzóla carretera ágilmente?
• EL ANALISTA DE NEGOCIO: Hoy tuve 12 reuniones y no tengo tiempo
para entrar en toda la Historia de Usuario. Pero te puedo adelantar
que involucra un gallo en un equipo distribuido.
• El PROJECT MANAGER AGIL: El pollo no va a poder cruzar la
carretera este mes. Los requerimientos estaban previstos para el
viernes pasado. Va a tener que esperar su turno en el backlog. A lo
mejor puede cruzarla en la iteración 9.mejor puede cruzarla en la iteración 9.
• EL DESARROLLADOR: Porque así estaba indicado en los
requerimientos. La catapulta resultó el método más eficiente. Cómo?
Que tenía que llegar vivo al otro lado? Figuraba esto en los
requerimientos?
• EL SCRUM MANAGER: Iteremos compañeros. Llevemos al pollo al
centro de la ruta hoy, y conversaremos sobre el resto del camino
mañana.

74. Muchas gracias
Ing. Mariel Feder Szafir, MC, PMP
mfeder@netgate.com.uy