PCX-SCRUM.pdf

Gerencia
de
Proyectos



 Copyright Procesix Inc. Cualquier copia u otro uso debe ser autorizado expresamente por Procesix Inc.
Procesix
1
1
e-SCM © 2006 by Carnegie Mellon University. All rights reserved.
SM: CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University
ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.
“PMI” and “PMP” are registered marks of Project Management Institute, Inc.
COBIT 4.1 is property of the IT Governance Institute (ITGI)
Marcelo Amadio – Procesix Argentina
www.procesix.com

Gerencia
de
Proyectos
Este curso tiene como objetivo preparar a los profesionales que realizan
funciones de gestión de proyectos y servicios para entender cómo las
metodologías ágiles pueden facilitar la gestión de tareas y proyectos.
Descripción del Curso
Este curso ayudará a preparar a los
asistentes para:
Entender los conceptos, los métodos, las



Procesix
2
2
Entender los conceptos, los métodos, las
técnicas, las herramientas y aspectos más
importantes de las disciplinas ágiles y como
aplicarlas.
Dar una visión general completa del
contexto de la disciplina de gestión de
proyectos usando métodos ágiles y que se
puede esperar de ella.
Describir los elementos principales de la
gestión tradicional de proyectos (PMI)
Comparar métodos ágiles con tradicionales
de gestión de proyectos.

Gerencia
de
Proyectos
Durante el curso se proporcionan los conceptos que permitan enfrentar los
siguientes desafíos comunes:
Métodos agiles y sus principios
Scrum técnico
Roles
Eventos
Artefactos
Descripción del Curso



Procesix
3
3
Artefactos
Medición y Estimación Ágil
Scrum prágmatico
Lean
Kanban
Principios de gerencia tradicional de proyectos (PMI)
Comparación entre modelos

Gerencia
de
Proyectos
Presentación y expectativas
Nombre
Rol y experiencia
Expectativas del curso
Expectativas de los participantes



Procesix
4
4

Gerencia
de
Proyectos Reglas de participación
Celulares
Sugerimos que sus celulares estén en modo vibración y sólo se
salgan de la presentación si es estrictamente urgente (a su criterio
profesional)



Procesix
5
5
Participación
Esperamos su participación. Les haremos muchas preguntas
durante toda la presentación.

Gerencia
de
Proyectos
Gestión de Proyectos y los
Métodos Ágiles



Procesix
6
6

Gerencia
de
Proyectos Estamos perdiendo la carrera de relevos
“En enfoque de ‘carrera de relevos’ en el
desarrollo de productos ... puede entrar en
conflicto con los objetivos de máxima
velocidad y flexibilidad. En su lugar, un
enfoque holístico o estilo ‘rugby’ - donde un



Procesix
7
7
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review,
January 1986.
enfoque holístico o estilo ‘rugby’ - donde un
equipo intenta ir a la distancia como una
unidad, pasando la pelota hacia adelante y
hacia atrás -pueden servir mejor a los
actuales requisitos competitivos.

Gerencia
de
Proyectos
El Manifesto Ágil – una declaración de valores
Procesos y
herramientas
Procesos y
herramientas
Individuos e
interacciones
Individuos e
interacciones
sobre
Documentación
exhaustiva
Documentación
exhaustiva
Software que
funciona
Software que
funciona
sobre



Procesix
8
8
Seguimiento
de un plan
Seguimiento
de un plan
Responder
ante el cambio
Responder
ante el cambio
sobre
Fuente: www.agilemanifesto.org
exhaustiva
exhaustiva
funciona
funciona
sobre
Negociación de
contratos
Negociación de
contratos
Colaboración
con el cliente
Colaboración
con el cliente
sobre

Gerencia
de
Proyectos Clima de Trabajo
Espacio abierto
Mesas centrales
Cubículos en el espacio exterior



Procesix
9
9

Gerencia
de
Proyectos Clima de Trabajo
Reunión diaria: “Stand-up Meeting”
Todo el equipo
Problemas
Soluciones
De pie en un círculo
Evitar discusiones largas
Sin conversaciones separadas



Procesix
10
10
Sin conversaciones separadas

Gerencia
de
Proyectos Scrum - Principios Fundamentales
Revisión de las iteraciones.
Desarrollo incremental.
Autoorganización.
Colaboración



Procesix
11
11
Colaboración

Gerencia
de
Proyectos Scrum
Es una metodología ágil que entre sus principales características están:
Desarrollo de software por medio de iteraciones (Sprints).
Indicado para proyectos con un rápido cambio de requerimientos.
Gran protagonismo de reuniones a lo largo del proyecto.



Procesix
12
12
Gran protagonismo de reuniones a lo largo del proyecto.

Gerencia
de
Proyectos Scrum
Los actores que intervienen en esta metodología son:
Propietarios del producto
Usuarios del poducto
Scrum master



Procesix
13
13
Scrum master
Equipo de scrum.

Gerencia
de
Proyectos Scrum



Procesix
14
14

Gerencia
de
Proyectos Scrum
Los sprints son la base del desarrollo en scrum, consisten en una serie de
actividades previamente definidas en un lapso de 30 días.
El product backlog es la lista de las tareas a realizar durante todo el
proyecto. No es una lista fija. Se prioriza las tareas según los requisitos de
los usuarios o del propietario de la aplicación.



Procesix
15
15

Gerencia
de
Proyectos Scrum



Procesix
16
16
Ejemplo de Product Backlog

Gerencia
de
Proyectos Scrum
Sprint planning meeting: reunión que se realiza antes de cada Sprint.
Se hace conjuntamente con el Propietario del producto el Scrum Master y
el equipo Scrum.
Enfocar la reunión hacia los requisitos más prioritarios.



Procesix
17
17

Gerencia
de
Proyectos Scrum
Revisión del sprint: se realiza al final de cada Sprint.
Se deben reunir el propietario de la aplicación los usuarios así como el
Scrum Master y su equipo , además también es recomendable que acudan
ingenieros de otros proyectos para dar su punto de vista.



Procesix
18
18

Gerencia
de
Proyectos Scrum
Un rol de suma importancia en esta metodología es el escuchar.
Muchos problemas de desarrollo se pueden solucionar fácilmente si se
escucha a los clientes, usuarios finales y equipos de desarrollo.



Procesix
19
19

Gerencia
de
Proyectos Cultura y Valores
El motor de la agilidad son los valores ágiles. La agilidad no la proporciona
el cumplimiento de prácticas, sino de valores.
Delegación de atribuciones.
Respeto entre las personas.
Autodisciplina.
Trabajo centrado en el valor para el cliente.
Transparencia y visibilidad.



Procesix
20
20

Gerencia
de
Proyectos Práctica Scrum
Dividirse en grupos y seguir las instrucciones del ejercicio, proporcionadas
por el instructor
Construcción de aviones de papel por cada equipo.
Cantidad limitada de recursos
Solo un doblez por participante
Definición de hecho
Elegir el product owner
Ejercitarse



Procesix
21
21
Ejercitarse
Resultados?

Gerencia
de
Proyectos
• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos semanas
o un mes).
Scrum en 100 palabras



Procesix
22
22
o un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.

Gerencia
de
Proyectos Características
• La Gestión de Proyectos Agiles no se formula
sobre la necesidad de predicción , sino sobre la
necesidad de adaptación continua.
• Equipos auto-organizados
• El producto avanza en una serie de “Sprints de dos semanas a un mes
de duración



Procesix
23
23
de duración
• Los requisitos son capturados como elementos de una lista de
“Product Backlog
• No hay prácticas de ingeniería prescritas
• Utiliza normas generativas para crear un entorno ágil para la entrega de
proyectos
• Uno de los “procesos ágiles”

Gerencia
de
Proyectos Nivel de ruido de un proyecto
Complejo
Anarquía
Requisitos
Lejos de
Acuerdo



Procesix
24
24
Simple
Complejo
Tecnología
Requisitos
Cerca de
Acuerdo
Cerca
de
Certeza
Lejos
de
Certeza
Fuente: Strategic Management and
Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and
Mike Beedle.

Gerencia
de
Proyectos
El flujo de Scrum
El flujo de Scrum
Pila del sprint
Nueva funcionalidad
Gestión ágil de proyectos: Scrum



Procesix
25
25 25
Visión:
ROI – versiones
hitos
Pila de producto
Requisitos priorizados
Selección de la
Pila de producto
Fuente: Agile Project Management with Scrum
Ken Schwaber

Gerencia
de
Proyectos
El flujo de Scrum
El flujo de Scrum



Procesix
26
26 26

Gerencia
de
Proyectos Scrum
Sprint
2-4 semanas
Objetivo del Sprint
24 horas



Procesix
27
27
Cancel
Gift wrap
Return
Sprint
Backlog
Incremento del producto
potencialmente entregable
Product
Backlog

Gerencia
de
Proyectos Poniendo todo junto



Procesix
28
28
Imagen disponible en
www.mountaingoatsoftware.com/scrum

Gerencia
de
Proyectos Sprints
• En Scrum los proyectos avanzan en una serie de “Sprints”
• Análogo a las iteraciones en XP
• La duración típica es 2–4 semanas o alo sumo un mes calendario
• La duración constante conduce a un mejor ritmo
• El product es diseñado, codificado y testeado durante el Sprint
• Fundamental: Definicion de Listo (Definition of Ready)



Procesix
29
29

Gerencia
de
Proyectos Incremento
• Es la parte de un producto realizada en un sprint, potencialmente
entregable.
• Terminado
• Probado.
• Fundamental: Definicion de Hecho (Definition of Done).



Procesix
30
30

Gerencia
de
Proyectos
Desarrollo secuencial vs. superpuesto
En lugar de hacer todo
de una cosa a la vez ...
Requisitos Diseño Código Test



Procesix
31
31
Source: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review, January
1986.
de una cosa a la vez ...
...los equipos Scrum hacen
un poco de todo todo el
tiempo

Gerencia
de
Proyectos No hay cambios en un sprint
Cambios



Procesix
32
32
• Planee la duración del sprint en torno a cuánto tiempo usted puede
comprometerse a mantener los cambios fuera del sprint

Gerencia
de
Proyectos Scrum Framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•
Reuniones



Procesix
33
33
•Sprint review
•Sprint retrospective
•Daily scrum meeting
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos

Gerencia
de
Proyectos Scrum framework
•Sprint planning
•
Reuniones
•Product owner
•ScrumMaster
•Team
Roles



Procesix
34
34
•Sprint review
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos

Gerencia
de
Proyectos Product Owner
• Define las funcionalidades del producto
• Decide sobre las fechas y contenidos de los releases
• Es responsable por la rentabilidad del producto (ROI)
• Prioriza funcionalidades de acuerdo al valor del mercado/negocio



Procesix
35
35
• Prioriza funcionalidades de acuerdo al valor del mercado/negocio
• Ajusta funcionalidades y prioridades en cada iteración si es necesario
• Acepta o rechaza los resultados del trabajo del equipo

Gerencia
de
Proyectos El ScrumMaster
• Representa a la gestión del proyecto
• Responsable de promover los valores y prácticas de Scrum
• Remueve impedimentos
• Se asegura de que el equipo es completamente funcional y productivo
• Permite la estrecha cooperación en todos los roles y funciones
• Escudo del equipo de interferencias externas



Procesix
36
36
• Escudo del equipo de interferencias externas

Gerencia
de
Proyectos El Team
• Típicamente de 5 a 9 personas
• Multi-funcional:
• Programadores, testers, analistas, diseñadores, etc.
• Los miembros deben ser full-time
Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
•



Procesix
37
37
• Los equipos son auto-organizativos
• Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización
Solo puede haber cambio de miembros entre los sprints

Gerencia
de
Proyectos Características de un buen equipo
• Motivación:
• Auto-organizados
• Es mejor comprometernos a que nos comprometan
• Bajo presión: se reduce la calidad.
• Desempeño:
• Máximo desempeño sin interrupciones.



Procesix
38
38
• Es mejor que cada equipo resuelva sus propios problemas
• Comunicaciones abiertas y sin lineas de mando son mas eficientes.
• Composición
• Los equipos trabajan mejor que los individuos.
• Numero máximo?
• Es mejor si hay funcionalidad cross.
• Equipos estables.

Gerencia
de
Proyectos Responsabilidad del liderazgo
• Mantener el nivel de desafios al equipo (sprint goal)
• Proveer recursos.
• Definir el equipo.
• Remover impedimentos
• Tener informado al PO sobre el valor que se agrega.
• Tener informado al SM sobre el estado del equipo
• Happiness metric?



Procesix
39
39
• Happiness metric?

Gerencia
de
Proyectos Práctica Scrum
Dividirse en grupos y seguir las instrucciones del ejercicio, proporcionadas
por el instructor
Describir las responsabilidades de un líder tradicional de proyecto
Enunciarlas en un conjunto de etiquetas o stickers
Ordenarlas en estas categorías: PO/SM/Team/Otros/Desperdicio?



Procesix
40
40

Gerencia
de
Proyectos
Roles: gallinas y cerdos
Roles: gallinas y cerdos
Una gallina y un cerdo paseaban por la carretera. La gallina dijo al
cerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró la
propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. La
gallina respondió: “Huevos con tocino”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor,
creo que no voy a abrir un restaurante contigo. Yo estaría
realmente comprometido, mientras que tu estarías sólo implicada”.



Procesix
41
41 41
COMPROMETIDOS EN EL PROYECTO (cerdos)
Propietario del producto
Equipo
IMPLICADOS EN EL PROYECTO (gallinas)
Marketing
Comercial
Etc.
Scrum diferencia entre estos dos grupos
para garantizar que quienes tienen la
responsabilidad tienen también la autonomía
necesaria para poder lograr el éxito, y que
quienes no tienen la responsabilidad no
producen interferencias innecesarias

Gerencia
de
Proyectos
Comunicación
Comunicación
Reunión diaria



Procesix
42
42 42
Revisión del sprint
Reunión retrospectiva
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de
un equipo de desarrollo es mediante la conversación cara a cara.
Manifiesto Ágil

Gerencia
de
Proyectos
•Product owner
•ScrumMaster
•Team
Roles
Scrum Framework
•Sprint planning
Reuniones



Procesix
43
43
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
•Sprint planning
•Sprint review

Gerencia
de
Proyectos
Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del Sprint
Objetivo
del Sprint
Objetivo
del Sprint
Condicione
s del
Condicione
s del
Capacidad
del Equipo
Capacidad
del Equipo
Product
Backlog
Product
Backlog



Procesix
44
44
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del Product
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Sprint
Backlog
Sprint
Backlog
s del
Negocio
s del
Negocio
Tecnología
Tecnología
Producto
Actual
Producto
Actual

Gerencia
de
Proyectos Planificación del Sprint
• El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a
completar
• Se crea el Sprint Backlog
• Se identifican tareas y cada una es estimada (1-16 horas)
• Realizado colaborativamente, no solo por el ScrumMaster
• El diseño de Alto Nivel es considerado



Procesix
45
45
COMO planificador
de vacaciones, YO
QUIERO ver fotos
de los hoteles.
COMO planificador
de vacaciones, YO
QUIERO ver fotos
de los hoteles.
Codificar la capa intermedia (8
hs)
Codificar la interfaz de usuario (4)
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)

Gerencia
de
Proyectos Definicion de Hecho (Dod)
• El equipo debe establecer y acordar una definición de cuando se
entiende que un incremento esta hecho (Definition of Done).
• Existe una clara relación entre Dod y testing.
• Esta definición puede tener niveles.
• Alto nivel (release)
• Mayor detalle (product backlog)
• Maximo nivel (user story)



Procesix
46
46
• Maximo nivel (user story)
• Errores comunes:
• Probado? (unit, integration, validation test)
• Entregable?
• Sin incremento de deuda tecnica?
Codificar la capa intermedia (8
hs)
Codificar la interfaz de usuario (4)
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)

Gerencia
de
Proyectos
Medición y Estimación Agil
Niveles de zoom
Gestión técnica y del producto.
Gestión de la organización.
Gestión del proyecto.
Medir es COSTOSO.
Medir no es un fin en si mismo.



Procesix
47
47
Medir no es un fin en si mismo.

Gerencia
de
Proyectos
Métricas
Story point
Días ideales
Deuda técnica.
Precisión de la estimación
Mejora limitada al aumentar el tiempo de estimación
Los que hacen la tarea
Estimación, no compromiso



Procesix
48
48
Estimación, no compromiso

Gerencia
de
Proyectos
Velocidad: Trabajo / Tiempo
Tiempo real vs tiempo ideal.
Trabajo realizado
Trabajo pendiente



Procesix
49
49
Trabajo pendiente
Diferencias entre personas?
Se puede estimar con exactitud?

Gerencia
de
Proyectos
Unidades de trabajo
Tiempo ideal
Puntos



Procesix
50
50

Gerencia
de
Proyectos Gráficos de Sprint



Procesix
51
51

Gerencia
de
Proyectos Gráficos de Sprint



Procesix
52
52

Gerencia
de
Proyectos
Formas de estimar
Expertos
Analogía
Dividir
Planning Poker
Cartas con 1, 2, 3, 5, 8, 20, 40, 100
Aprendizaje
Timeboxed



Procesix
53
53

Gerencia
de
Proyectos Planning Poker - Preparacion
El experto en requerimientos debe conocer en detalle las user stories.
Cada user story debe tener una granularidad tal que no exceda los 10 dias de
trabajo.
Cada participante dispone de un mazo de cartas.
Cada carta representa una estimacion.



Procesix
54
54

Gerencia
de
Proyectos Planning Poker
Ejemplos de valores de estimacion :
0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
1, 2, 3, 5, 8, 13, BIG.
½, 1, 2, 3, 4, 5, 6, 7, ∞



Procesix
55
55

Gerencia
de
Proyectos El proceso
1. Cada participante del equipo recibe un mazo de cartas.
2. El moderador expone la user story por no mas de 2 minutos.
3. Se da un tiempo para preguntas
4. Cada participante elije una carta
5. Todos dan vuelta su carta al mismo tiempo.
6. En la primera vuelta, puede haber diferencias significativas



Procesix
56
56
6. En la primera vuelta, puede haber diferencias significativas

Gerencia
de
7. En caso de diferencias, la mayor y menor estimacion es explicada.
8. Se dan unos minutos para discusión.
9. Se genera una segunda vuelta de votaciones.
10. El proceso se repite.



Procesix
57
57

Gerencia
de
11. Cuando las estimaciones convergen, finaliza el proceso y la estimación es
considerada como definitiva.
12. Si se tienen mas de 3 ruedas de votacion, se deben tomar otros caminos:
Dejar la estimación para después.
Descomponer la user story



Procesix
58
58
Descomponer la user story
Promediar los valores de la estimacion.

Gerencia
de
Proyectos
Estimación de release
Definir prioridades y aceptación
Estimar tamaño de ítems
Estimar Velocidad
Días reales
Plan del Release
Buffer



Procesix
59
59

Gerencia
de
Proyectos Daily Scrum
• Parámetros
• Diaria
• Dura 15 minutos
• Parados
• No para la solución de problemas



Procesix
60
60
• Todo el mundo está invitado
• Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar
• Ayuda a evitar otras reuniones innecesarias

Gerencia
de
Proyectos Todos responden 3 preguntas
¿Qué hiciste ayer?
¿Qué hiciste ayer?
1
1
¿Qué vas a hacer hoy?
2
2



Procesix
61
61
• No es dar un status report al Scrum Master
• Se trata de compromisos delante de pares
¿Hay obstáculos en tu camino?
¿Hay obstáculos en tu camino?
3
3

Gerencia
de
Proyectos Sprint review
• El equipo presenta lo realizado durante el sprint
• Normalmente adopta la forma de una demo de las nuevas características o la
arquitectura subyacente
• Informal
• Regla de 2 hs preparación
• No usar diapositivas
•



Procesix
62
62
• Todo el equipo participa
• Se invita a todo el mundo

Gerencia
de
Proyectos Sprint retrospective
Periódicamente, se echa un vistazo a lo que funciona y lo que no
Normalmente 15 a 30 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa
• ScrumMaster
• Product owner



Procesix
63
63
• Product owner
• Equipo
• Posiblemente clientes y otros

Gerencia
de
Proyectos Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les gustaría:
Comenzar a hacer
Comenzar a hacer



Procesix
64
64
Dejar de hacer
Dejar de hacer
Continuar haciendo
Continuar haciendo
Esto es sólo una
de las muchas
maneras de
hacer una
retrospectiva.

Gerencia
de
Proyectos
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•
Reuniones



Procesix
65
65
•Sprint review
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos

Gerencia
de
Proyectos Product Backlog
• Los requisitos
• Una lista de todos los trabajos deseados en el
proyecto
• Idealmente cada tema tiene valor para el usuarios
o el cliente
• Priorizada por el Product Owner
• Repriorizada al comienzo de cada Sprint



Procesix
66
66
• Repriorizada al comienzo de cada Sprint
Este es el
product backlog
Este es el
product backlog

Gerencia
de
Proyectos
User stories
Como rol de usuario, quiero función de sistema para lograr valor de
negocio
Consiste de
Descripción escrita
Conversación (detalle, documentos,…)
Pruebas de aceptación (def. completo)



Procesix
67
67

Gerencia
de
Proyectos
User stories
Unidad más pequeña de incremento del sistema
Unidad de estimación y control
Incluye los objetivos y motivaciones del usuario
Origen de BDD (Behavior driven development)



Procesix
68
68

Gerencia
de
Proyectos Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5



Procesix
69
69
Como invitado, quiero cambiar las fechas de una reserva. 3
Como un empleado de hotel, puedo ejecutar informes de los ingresos por
habitación disponible
8
Mejorar el manejo de excepciones 8
... 30
... 50

Gerencia
de
Proyectos El objetivo del Sprint
• Una breve declaración de cual será el foco del trabajo durante el sprint
Aplicación con B.Datos
Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de



Procesix
70
70
Aplicación con B.Datos
Servicios Financieros
necesarios para estudios de
genética de poblaciones.
Soportar más indicadores
técnicos que la empresa ABC en
tiempo real y streaming de
datos.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle.

Gerencia
de
Proyectos Gestión del Sprint Backlog
• Los individuos eligen las tareas
• El trabajo nunca es asignado
• La estimación del trabajo restante es actualizada diariamente
• Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint
Backlog
• El trabajo para el Sprint emerge



Procesix
71
71
• Si el trabajo no está claro, definir un tema del Sprint Backlog con una
mayor cantidad de tiempo y subdividirla luego.
• Actualizar el trabajo restante a medida de que más se conoce

Gerencia
de
Proyectos Ejemplo de Sprint Backlog
Tareas
Codificar UI
Codificar negocio
Testear negocio
L
8
16
8
M
4
12
16
M J
4
11
V
8
8
10
16



Procesix
72
72
Testear negocio
Escribir ayuda online
Escribir la clase foo
8
12
8
16
8
11
8
4
8
8
Agregar error logging
16
8
8

Gerencia
de
Proyectos Un Sprint Burndown Chart
Hours



Procesix
73
73
Hours

Gerencia
de
Proyectos
Tareas
Codificar UI
Codificar Negocio
Testear Negocio
Escribir ayuda online
L
8
16
8
12
M M J V
4
12
16
7
11
8
10
16 8
50



Procesix
74
74
Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
50

Gerencia
de
Proyectos Escalabilidad
• Normalmente los equipos son de 7 ± 2 personas
• La escalabilidad proviene de equipos de equipos
• Factores a tener cuenta
• Tipo de aplicación
• Tamaño del equipo
• Dispersión del equipo
• Duración del proyecto



Procesix
75
75
• Duración del proyecto
• Scrum se ha utilizado en múltiples proyectos de más de 500 personas

Gerencia
de
Proyectos
Problemas!
Pérdida de ritmo
Chickens hablando en Daily Scrum
Pigs que no están en el Daily Scrum
Grupos que no aprenden
Trabajo asignado (por el ScrumMaster)
Daily Scrum para el ScrumMaster
Roles especializados



Procesix
76
76
Roles especializados

Gerencia
de
Proyectos
Práctica Scrum
¿Cómo funciona el ejercicio?
Objetivo: Desarrollar un Brochure en sprints de 3 días
Armar grupos, definir un Product Owner
Cada día es de 15 min
Sprint
Día 1: 7 min planificación + 8 min
Día 2: 2 min Daily Scrum + 13 min



Procesix
77
77
Día 2: 2 min Daily Scrum + 13 min
Día 3: 2 min Daily Scrum + 8 min + 5 min demo

Gerencia
de
Proyectos Práctica Scrum -Tablero de Control



Procesix
78
78

Gerencia
de
Proyectos Dia de Spa de la Mascota
Crear diseño tapa, logo, y/o marca
Definir principales áreas de cuidados
Definir servicio “Ultra Doggy Spa”
Esbozo de opciones de ingreso
Escribir testimonios
Definir toda la oferta de servicios
Fijar los precios de los servicios



Procesix
79
79
Fijar los precios de los servicios
Delinear el menú semanal
Completar un certificado de garantía
Incluir testimonios de clientes satisfechos
Completar una estructura de certificaciones
Delinear requerimientos mínimos (vacunas,caracter, raza, etc.)
Biografias de los empleados (experiencia,entrenamientos, intereses)
Definir descuentos para socios de negocio

Gerencia
de
Proyectos
Process is
continuously improving
The bottom line
Delivering working, tested
software every 4 weeks or less
Delivering what the
business needs most
Retrospective happens after
every sprint
Results in concrete
improvement proposals
Some proposals actually get
implemented
Whole team + PO
participates
Team has a sprint backlog Have sprint planning meetings
PO has a product backlog
(PBL)
Top items are prioritized by
business value
Top items are estimated
PO understands purpose of
all backlog items
Top items in PBL small
enough to fit in a sprint
Estimates written by the
team
Clearly defined product owner
(PO)
PO is empowered to
prioritize
PO has knowledge to
prioritize
PO has direct contact with
team
PO has direct contact with
stakeholders
PO speaks with one voice
(in case PO is a team)
If you achieve these you can ignore the
rest of the checklist. Your process is fine.
These are central to Scrum. Without these
you probably shouldn’t call it Scrum.
Core Scrum
PO has product vision that is in
sync with PBL
PBL and product vision is highly
visible
Everyone on the team
participates in estimating
PO available when team is
estimating
Team members not locked into
specific roles
Team has all skills needed to
bring backlog items to Done
Velocity is measured
Velocity only includes
items that are Done
PO uses velocity for
release planning
Team has a sprint burndown
chart
PBL items are broken into tasks
within a sprint
Estimates for ongoing tasks
are updated daily
All items in sprint plan have
an estimate
Sprint tasks are estimated
Estimate relative size (story
points) rather than time
Most of these will usually be needed, but not always all of them. Experiment!
Recommended but not always necessary
Iterations that are doomed to
fail are terminated early
Scrum y Qa



Procesix
80
80
Have Definition of Done (DoD)
DoD achievable within
each iteration
Team respects DoD
Demo happens after every
sprint
Shows working, tested
software
Feedback received from
stakeholders PO
Highly visible
Updated daily
Owned exclusively by the
team
PO participates
Whole team participates
Results in a sprint plan
Whole team believes plan is
achievable
PO satisfied with
priorities
PO brings up-to-date PBL
Iteration length 4 weeks or
less
Always end on time
Team not disrupted or
controlled by outsiders
Timeboxed iterations
Team members sit together
Team has a Scrum Master (SM)
Whole team knows top 1-3
impediments
SM has strategy for how to
fix top impediment
SM focusing on removing
impediments
Escalated to management
when team can’t solve
chart
Highly visible
Updated daily
PO participates at least a
few times per week
SM sits with the team
Daily Scrum is every day, same
time place
points) rather than time
Max 15 minutes
Each team member knows
what the others are doing
Daily Scrum happens
Whole team participates
Problems impediments
are surfaced
You have a Chief Product
Owner (if many POs)
Dependent teams do Scrum of
Scrums
Dependent teams integrate
within each sprint
Scaling
Having fun! High energy level.
Overtime work is rare and
happens voluntarily
Discussing, criticizing, and
experimenting with the process
Positive indicators
http://www.crisp.se/scrum/checklist | Version 2.2 (2010-10-04)
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
Team usually delivers what
they committed to
Leading indicators of a
good Scrum implementation.
These are pretty fundamental to any
Scrum scaling effort.
Max 9 people per team

Gerencia
de
Proyectos Lean
En una era donde ser esbelto es lo in , ¿podemos poner a dieta nuestros
procesos de desarrollo de software?
No existe una definición formal de metodologías esbeltas
simplemente se usan los principios del pensamiento ágil. Cada autor
varía los principios manejados. A continuación se muestran algunos
principios básicos.



Procesix
81
81

Gerencia
de
Proyectos Principios
Eliminar el desperdicio
Construir con calidad
Crear conocimiento
Postergar compromiso



Procesix
82
82
Postergar compromiso
Entregas rápidas
Repetar a las personas
Optimizar el todo

Gerencia
de
Proyectos Eliminar el desperdicio
Brindar un liderazgo técnico y de mercado - la organización puede ser
exitosa si produce productos innovadores y tecnológicamente avanzados,
pero es importante comprender lo que valoran nuestros clientes y conocer
la tecnología que se está usando.
Crear sólamente cosas de valor - debemos ser cuidados con todos los
procesos que sigamos. Por ejemplo, debemos asegurarnos que todos
estos procesos son útiles y están enfocados en crear valor.
Escribir menos código - mientras más código se tenga, más pruebas se



Procesix
83
83
Escribir menos código - mientras más código se tenga, más pruebas se
van a necesitar, por lo que se necesitará más trabajo. Si escribiemos
pruebas para funcionalidad que no se necesita estamos perdiendo el
tiempo.
¿Qué es desperdicio?
Lo que no agrega valor
Retraso en la entrega
¿Qué es valor?
Ejemplos
Stock: Requerimientos, Diseño, Bugs, …
Funcionalidad no usada

Gerencia
de
Proyectos Construir con calidad
Sincronizar - para lograr una alta calidad en el software nos debemos
empezar a ocupar de él antes de empezar a escribir una sola línea de
código.
Automatizar - automatizar las pruebas, la construcción, las instalacionoes,
y cualquier cosa que sea rutinaria. Hay que automatizar de una manera
inteligente, de forma que las personas puedan mejorar el proceso y
cambiar cualqueir cosa que quieran sin preocuparse por si el cambio hace
que las cosas dejen de funcionar.



Procesix
84
84
que las cosas dejen de funcionar.
Refactor - eliminar la duplicación de código a CERO - cada vez que
aparezca la oportunidad, realizar el refactor del código, de las pruebas y de
la documentación para minimizar la complejidad.
Pruebas automatizadas antes que el código
De aceptación
Unitarias

Gerencia
de
Proyectos Construir con Calidad: Hacerlo bien la primera vez
Cuidado…
El código cambia
Mucho código es desperdicio
Menos código, menos oportunidad de defectos
Solución
KISS
Refactoring



Procesix
85
85

Gerencia
de
Proyectos Crear conocimiento
Crear equipos de diseño y construcción - el líder del equipo de
desarrollo tiene que escuchar a los miembros y hacerles preguntas
inteligentes que los insite a buscar respuestas y volver lo más pronto
posible con los problemas que surgen, o con las soluciones inventadas.
Mantaner una cultura de mejora continua - crear un ambiente en donde
las personas estén mejorando continuamente en lo que trabajan - deben
saber que no son y no deben ser perfectas - y que siempre tienen algún
área que pueden mejorar.



Procesix
86
86
área que pueden mejorar.
Enseñar métodos de resolución de problemas - los equipos de
desarrollo deberían comportarse como pequeños centros de investigación,
estableciendo hipótesis y realizando varios experimentos rápidos para
verificar su validez.
No es posible
Conocer las necesidades al inicio
Diseñar sin implementar
Desarrollo de producto como aprendizaje y mejora
Del producto / negocio
Del proceso
Difundir el conocimiento!

Gerencia
de
Proyectos Postergar compromiso
Agendar las decisiones irreversibles hasta el último momento
responsable - debemos saber hacia donde queremos ir pero no
conocemos el camino del todo, lo vamos descubriendo día a día - lo más
importante es mantener la dirección correcta.
Romper con las dependencias - los componentes deben estar lo más
desacoplados posible para que puedan implementarse en cualquier orden.
Mantener opciones - desarrollar múltiples soluciones para todas las
decisiones críticas y ver cuales funcionan mejor.



Procesix
87
87
decisiones críticas y ver cuales funcionan mejor.
Tomar decisiones irreversibles
Buscar soluciones reversibles

Gerencia
de
Proyectos Entregas rápidas
Trabajar en bloques pequeños - reducir el tamaño del proyecto, acortar
los ciclos de entrega, estabilizar el ambiente de trabajo (escuchá lo que te
dice la velocidad), repetir lo bueno y erradicar las prácticas que crean
obstáculos.
Limitar el trabajo a la capacidad - limitar la cola de tareas al mínimo
(una o dos iteraciones por delante es suficiente), no hay que tener miedo
al quitar elementos de la cola - rechazar cualquier trabajo hasta que se
haya vaciado un lugar en la cola.



Procesix
88
88
haya vaciado un lugar en la cola.
Enfocarse en el tiempo del ciclo, no en la utilización - agregar tareas
pequeñas a la cola que no puedan atascar al proceso por un tiempo largo
- reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola
Considerar:
Alta calidad
Bajo costo
Menos cambios
Habilita a pruebas de concepto y mayor conocimiento del cliente

Gerencia
de
Proyectos Respetar a las personas
Capacitar a los líderes de equipo - darles a los líderes de equipo
entrenamiento, guías y espacio libre para implmenetar el pensamiento
Lean en su ambiente.
Mover la responsabilidad y la toma de decisiones al nivel más bajo
posible - dejar que las personas piensen y decidan por su cuenta - ellos
saben mejor que nadie cómo implementar algoritmos dificiles y aplicar
tecnologías de última generación.
Fomentar orgullo por el trabajo - fomentar la pasión y la participación del



Procesix
89
89
Fomentar orgullo por el trabajo - fomentar la pasión y la participación del
equipo hacia lo que hacen y cómo lo hacen.
Considerar:
Líderes emprendedores
Expertos técnicos
Control basado en objetivos
Mito: existe la mejor manera de hacerlo

Gerencia
de
Proyectos Optimizar el todo
Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera
completa (que es el software). No hay que gastar esfuerzo en optimizar
ineficiencias locales, sino en ver el todo y optimizar a la organización en su
totalidad.
Entregar un producto completo - los equipos necesitan tener buenos
líderes, y también buenos ingenieros, vendedores, especialistas de
marketing, secretarias, etc. Todos juntos pueden entregar un gran producto
final a los clientes.



Procesix
90
90
final a los clientes.
Ejemplos:
El cliente quiere algo para ayer
Testing está sobrecargado
Las cadenas de valor que cruzan entre empresas pueden ser costosas
Mito: optimizar por descomposición

Gerencia
de
Proyectos
Gestión de Proyectos y los
métodos Tradicionales



Procesix
91
91

Gerencia
de
Proyectos
Proceso general de la gerencia de proyectos
y sus mejores prácticas
Inicio Planeación Ejecución Cierre
C
l
i
e
C
l
i
e



Procesix
92
92
Inicio Planeación Ejecución Cierre
e
n
t
e
e
n
t
e
Monitoreo y Control

Gerencia
de
Proyectos



Procesix
93
93
Los Grupos de Procesos interactúan en un proyecto

Gerencia
de
Proyectos
y sus mejores prácticas – entregables por grupo
Ejercicio: Definir lo entregables por grupo de proceso



Procesix
94
94

Gerencia
de
Proyectos
y sus mejores prácticas – entregables por grupo
• Acta Constitución del Proyecto e Identificación de
Interesados
Inicio
• Plan de Proyecto
• Planes subsidiarios: Calidad, Recursos Humanos,
Comunicaciones/Admon datos, Adquisiciones,
Riesgos, Comunicaciones
• Línea base alcance, cronograma, costos
Planeación



Procesix
95
95
• Línea base alcance, cronograma, costos
• Entregables
• Ejecución planes
• Informe General del Proyecto
• Ejecución del alcance del servicio/producto
Ejecución
• Control integrado de cambios
• Análisis de variaciones, control de los planes
Seguimiento
• Cierre de Adquisiciones
• Cierre de Proyecto
Cierre

Gerencia
de
Proyectos
Procesos de Gestión de Proyectos
según PMBOK del PMI
5 Grupos de Procesos de Dirección
de Proyectos
9 Áreas de Conocimiento de la



Procesix
96
96
9 Áreas de Conocimiento de la
Dirección de Proyectos
42 procesos de dirección
PMBOK: Project Management Body of Knowledge
PMI: Project Management Institute

Gerencia
de
Proyectos Términos
Qué es Administración de Proyectos - Project Management?
Es la aplicación de conocimiento, habilidades, herramientas y técnicas para
ejecutar actividades del proyecto con el objetivo de cumplir o exceder las
necesidades y expectativas de un stakeholder con respecto a un proyecto.
Qué es Administración de Programas - Program Management?



Procesix
97
97
Qué es Administración de Programas - Program Management?
Es la aplicación de conocimiento, habilidades, herramientas y técnicas para
gestionar programas que incluyen varios proyectos.
Un programa es un conjunto de proyectos adminsitrado en forma coordinada
para obtener logros que no se pudieran conseguir manejándolos
individualmente

Gerencia
de
Proyectos Términos
Qué es Portafolio de Proyectos – Portfolio Management?
Se refiere a la agrupación de proyectos y programas que al ser agrupados
facilita la gestión efectiva del trabajo para lograr los objetivos estratégicos de
negocio.
Portafolio



Procesix
98
98
Portafolio
Programa 1
Proyecto
1.1
Proyecto
1.2
Programa 2
Proyecto
2.1
Proyecto
2.2
Proyecto
A
Proyecto
B

Gerencia
de
Proyectos Proceso de Gestión de Proyectos
Grupos de Procesos de Dirección de Proyectos
Iniciación
Planificación
Ejecución
Seguimiento y Control
Cerrar



Procesix
99
99
Cerrar

Gerencia
de
Proyectos
Iniciación:
Aquellos procesos realizados para definir un nuevo proyecto o una nueva fase
de un proyecto ya existente, mediante la obtención de la autorización para
comenzar dicho proyecto o fase.
1. Desarrollar el Acta de
Constitución del Proyecto
Proceso de Gestión de Proyectos



Procesix
100
100
Constitución del Proyecto
2. Identificar a los
interesados

Gerencia
de
Proyectos
Planificación
Aquellos procesos requiridos para
establecer el alcance del proyecto,
refinar los objetivos y definir el
curso de acción necesario para
alcazar los objetivos para cuyo
logro se emprendió el proyecto



Procesix
101
101
logro se emprendió el proyecto

Gerencia
de
Proyectos
11.Preparación del Presupuesto
12.Plan de Calidad
13.Plan de los Recursos
Humanos
14.Plan de las Comunicaciones
15.Plan de la Gestión de
Riesgos
Planificación
1. Desarrollar el Plan de
Gestión del Proyecto
2. Recopilar requisitos
3. Definir el Alcance
4. Crear WBS – EDT
5. Definición de las Actividades



Procesix
102
102
Riesgos
16.Identificación de Riesgos
17.Análisis Cualitativo de
Riesgos
18.Análisis Cuantitativo de
Riesgos
19.Plan de la Respuesta a los
Riesgos
20.Plan de Adquisiciones
5. Definición de las Actividades
6. Establecimiento de la
Secuencia de las Actividades
7. Estimación de Recursos de las
Actividades
8. Estimación de la Duración de
las Actividades
9. Desarrollo del Cronograma
10. Estimación de Costos

Gerencia
de
Proyectos
1. Dirigir y Gestionar la
Ejecución del Proyecto
2. Realizar Aseguramiento de
Calidad
Ejecución
Aquellos procesos realizados para completar el trabajo definido en el plan



Procesix
103
103
Calidad
3. Adquirir el Equipo del
Proyecto
4. Desarrollar el Equipo del
Proyecto
5. Dirigir el equipo del
proyecto
6. Distribuir la Información
7. Gestionar las expectativas
de los interesados
8. Efectuar adquisiciones

Gerencia
de
Proyectos
Aquellos procesos requeridos
para dar seguimiento, analizar
y regular el progreso y
desempeño del proyecto



Procesix
104
104

Gerencia
de
Proyectos
1. Dar seguimiento y Controlar
el Trabajo del Proyecto
2. Control Integrado de Cambios
3. Verificar el Alcance.
4. Controlar el Alcance
5. Controlar el Cronograma.



Procesix
105
105
5. Controlar el Cronograma.
6. Controlar Costos.
7. Realizar Control de Calidad.
8. Informar el desempeño.
9. Dar seguimiento y controlar los
riesgos.
10. Administrar las adquisiciones

Gerencia
de
Proyectos
1. Cerrar el Proyecto o Fase
Cierre
Aquellos procesos realizados para finalizar todas las actividades a través de
todos los grupos de procesos, a fin de cerrar formalmente el proyecto o
una fase del mismo



Procesix
106
106
1. Cerrar el Proyecto o Fase
2. Cerrar las Adquisiones

Gerencia
de
Proyectos
Para qué identificar los stakeholders o
participantes del proyecto?
INICIO PLANEACION EJECUCIÓN SEGUIMIENTO Y
CONTROL CIERRE



Procesix
107
107
participantes del proyecto?
Y además de identificarlos,
cómo analizar sus intereses e influencia
dentro del proyecto?

Gerencia
de
Proyectos
Para qué tener un acta de constitución del
proyecto?
CONTROL CIERRE



Procesix
108
108
proyecto?
Qué debe contener?

Gerencia
de
Proyectos
Qué debe contener?
Acta de constitución del proyecto
CONTROL CIERRE



Procesix
109
109
Acta de constitución del proyecto
ÍNDICE
1 Información general
2 Interesados del proyecto
3 resumen ejecutivo
4 justificación del proyecto
4.1 Necesidades del negocio
4.2 Objetivos del negocio
5 Descripción del proyecto
5.1 Descripción del proyecto
5.2 Alcance del proyecto
5.3 Asunciones
5.4 Restricciones
6 Requerimientos del proyecto/Entregables
7 Hitos y entregables de la gestión de proyectos
8 Presupuesto
9 Recursos
10 Riesgos
11 Organización del proyecto
11.1 Organigrama del proyecto
11.2 Responsabilidades
12 Aprobación del acta

Gerencia
de
Proyectos
Quién es responsable de la planeación
del proyecto?
CONTROL CIERRE



Procesix
110
110
del proyecto?
Quiénes deben participar
en la planeación?
Cuáles son las actividades principales de
la planeación?

Gerencia
de
Proyectos
Cómo entender mejor el alcance?
CONTROL CIERRE



Procesix
111
111
Para qué es una WBS?
Cómo estimar? Para qué sirven los datos
históricos? Qué métodos de estimación
conoce?

Gerencia
de
Proyectos
Qué diferencia hay entre esfuerzo y
duración?
CONTROL CIERRE



Procesix
112
112
duración?
Cuáles son las mejores prácticas para
definir la duración de las actividades?
Porqué hay que hacer todo
esto antes de crear el
cronograma?

Gerencia
de
Proyectos
Qué se debe tener en cuenta en la
estimación de costos?
CONTROL CIERRE



Procesix
113
113
estimación de costos?
Qué diferencia hay entre costos y
presupuestos?
Cómo se interrelacionan los costos con
los riesgos?

Gerencia
de
Proyectos
CONTROL CIERRE
Riesgos
desconocidos



Procesix
114
114
Riesgos
conocidos
Riesgos
conocidos

Gerencia
de
Proyectos
Qué es calidad?
CONTROL CIERRE



Procesix
115
115
Qué le interesa al cliente con respecto a
calidad?
Qué no nos cuenta el cliente pero en todo
caso debemos tener en cuenta al planear
la calidad del proyecto?

Gerencia
de
Proyectos
Cómo identificar los roles y
responsabilidades en el proyecto?
CONTROL CIERRE



Procesix
116
116
responsabilidades en el proyecto?
Cómo comunicarlos?

Gerencia
de
Proyectos
CONTROL CIERRE
RACI: Responsible, Accountable, Consulted, Informed



Procesix
117
117

Gerencia
de
Proyectos
Qué necesidad de comunicaciones
tenemos en el proyecto?
CONTROL CIERRE



Procesix
118
118
tenemos en el proyecto?
Dónde puede ir toda
esta información?

Gerencia
de
Proyectos
CONTROL CIERRE
Que Quien A quien Frecuencia Medio Retroali
mentacion



Procesix
119
119

Gerencia
de
Proyectos
Cómo identificar riesgos?
CONTROL CIERRE



Procesix
120
120
Cómo valorar los riesgos?
Cuándo construir planes de mitigación y
de contingencia? Para qué es cada uno?

Gerencia
de
Proyectos
CONTROL CIERRE
MATRIZ DE PROBABILIDAD E IMPACTO



Procesix
121
121
MATRIZ DE PROBABILIDAD E IMPACTO
Muy Alto Alto Moderado Bajo
0.80 0.40 0.20 0.10
Alta 0.70 0.56 0.28 0.14 0.07
Media 0.50 0.40 0.20 0.10 0.05
Mínima 0.30 0.24 0.12 0.06 0.03

Gerencia
de
Proyectos
CONTROL CIERRE
Condiciones definidas para escala de impacto de un riesgo sobre los principales objetivos del Proyecto
Objetivo del
Proyecto Bajo/0.10 Moderado/0.20 Alto/0.40 Muy Alto/0.80



Procesix
122
122
Costo
Aumento del coste
10%
Aumento del Coste del
10-20%
Aumento del Coste del
20-40% Aumento del Coste 40%
Tiempo
Aumento del tiempo
5%
Aumento del Tiempo
del 5-10%
Aumento del Tiempo del
10-20%
Aumento del Tiempo
20%
Alcance
0- 5 Áreas del Alcance
Secundarias afectadas
0-2 Áreas del Alcance
Principales afectadas
2-4 Áreas del Alcance
4 Áreas del Alcance
Calidad 0-5 Modificaciones 6-8 modificaciones 9-12 modificaciones 12 modificaciones
Clima Laboral
Afectación del 0 al 2%
del grupo Afectación del 2% al 5% Afectación del 5% al 10% Afectación 10%

Gerencia
de
Proyectos
CONTROL CIERRE



Procesix
123
123

Gerencia
de
Proyectos
Qué construir internamente y qué
comprar/subcontratar?
CONTROL CIERRE



Procesix
124
124
comprar/subcontratar?
Si vamos a comprar/subcontratar, cómo
elegimos los proveedores?
Cómo hacemos seguimiento y control?

Gerencia
de
Proyectos
CONTROL CIERRE



Procesix
125
125

Gerencia
de
Proyectos
CONTROL CIERRE
Cuál es el principal entregable de la
ejecución?



Procesix
126
126
ejecución?
Los entregables:
productos o
servicios para lo cual
fue creado el proyecto.

Gerencia
de
Proyectos
CONTROL CIERRE
Cuál es el rol principal del gerente de
proyectos en esta etapa?



Procesix
127
127
proyectos en esta etapa?
Dirigir y gestionar la
ejecución del proyecto.
Asegurar que las actividades planeadas
se ejecuten tal y como están planeadas.

Gerencia
de
Proyectos
INICIO PLANEACION EJECUCIÓN
SEGUIMIENTO Y
CONTROL
CIERRE



Procesix
128
128

Gerencia
de
Proyectos
SEGUIMIENTO Y
CONTROL
CIERRE
Cómo asegurar que los cambios en el
proyecto sean gestionados de forma



Procesix
129
129
proyecto sean gestionados de forma
controlada?
Con un proceso de
control integrado de
cambios.

Gerencia
de
Proyectos
SEGUIMIENTO Y
CONTROL
CIERRE
Cómo asegurar que los productos o
servicios producidos son los que espera el



Procesix
130
130
servicios producidos son los que espera el
cliente?
Verificando y validando el alcance.

Gerencia
de
Proyectos
SEGUIMIENTO Y
CONTROL
CIERRE
Cómo asegurar que los procesos
estándares de la organización para



Procesix
131
131
estándares de la organización para
ejecución de proyectos se están
usando/siguiendo?
Con los resultados de aseguramiento de
la calidad: revisiones y auditorías

Gerencia
de
Proyectos
SEGUIMIENTO Y
CONTROL
CIERRE
Cómo controlamos la ejecución del
proyecto y el desempeño del equipo de



Procesix
132
132
proyecto y el desempeño del equipo de
trabajo?
Para el proyecto: con los indicadores definidos
en el plan, como por ejemplo: SPI, CPI…
Para el equipo: con la productividad, calidad de
los entregables…

Gerencia
de
Proyectos
SEGUIMIENTO Y
CONTROL
CIERRE
Si ya hice una identificación inicial de
riesgos en la planeación, cómo logro



Procesix
133
133
riesgos en la planeación, cómo logro
mantener los riesgos del proyecto
controlados?
Monitoreándolos periódicamente, con reuniones de seguimiento
con los participantes relevantes, para revisar si alguno ha cambiado
su prioridad e impacto, si se necesita ejecutar algún plan de
mitigación o contingencia, si alguno se ha materializado o ha
surgido un nuevo riesgo.

Gerencia
de
Proyectos
SEGUIMIENTO
Y CONTROL CIERRE



Procesix
134
134

Gerencia
de
Proyectos
SEGUIMIENTO
Y CONTROL CIERRE
Qué cierro primero: los contratos o el
proyecto?



Procesix
135
135
proyecto?
Los contratos

Gerencia
de
Proyectos
SEGUIMIENTO
Y CONTROL CIERRE
El cierre se hace solo al momento de
terminar el proyecto o se puede usar este



Procesix
136
136
terminar el proyecto o se puede usar este
proceso para cerrar fases?
También se puede usar para cerrar fases

Gerencia
de
Proyectos
SEGUIMIENTO
Y CONTROL CIERRE
El cierre de proyectos solo ocurre cuando
el proyecto se completa?



Procesix
137
137
el proyecto se completa?
No, el proyecto puede cerrarse por varias
razones:
1. Se completó exitosamente (el más deseado)
2. Se canceló por diversas razones: falta de
presupuesto, dejó de ser relevante, etc

Gerencia
de
Proyectos
SEGUIMIENTO
Y CONTROL CIERRE
Qué actividades implica un cierre de
proyectos?



Procesix
138
138
proyectos?

Gerencia
de
Proyectos Método Tradicional vs Ágil
Metodología Ágil Metodología Tradicional
Pocos Artefactos. El modelado es prescindible, modelos
desechables.
Más Artefactos. El modelado es esencial, mantenimiento de modelos
Pocos Roles, más genéricos y flexibles Más Roles, más específicos
No existe un contrato tradicional, debe ser bastante flexible Existe un contrato prefijado
Cliente es parte del equipo de desarrollo (además in-situ) El cliente interactúa con el equipo de desarrollo mediante reuniones



Procesix
139
139
Orientada a proyectos pequeños. Corta duración (o entregas
frecuentes), equipos pequeños ( 10 integrantes) y trabajando
en el mismo sitio
Aplicables a proyectos de cualquier tamaño, pero suelen ser
especialmente efectivas/usadas en proyectos grandes y con equipos
posiblemente dispersos
La arquitectura se va definiendo y mejorando a lo largo del
proyecto
Se promueve que la arquitectura se defina tempranamente en el
proyecto
Énfasis en los aspectos humanos: el individuo y el trabajo en
equipo
Énfasis en la definición del proceso: roles, actividades y artefactos
Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto durante el proyecto

Gerencia
de
Proyectos CMMI vs SCRUM



Procesix
140
140

Gerencia
de
Proyectos
Referencias
www.procesix.com
Marcelo Amadio: marcelo.amadio@procesix.com
www.agilemanifesto.org
Americalatina.pmi.org
www.scrum.org



Procesix
141
141

Gerencia
de
Proyectos
Conclusiones
Asistencia
Encuesta
Preguntas?



Procesix
142
142
Preguntas?
Gracias!

PCX-SCRUM.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a PCX-SCRUM.pdf

Similar a PCX-SCRUM.pdf (20)

Último

Último (16)

PCX-SCRUM.pdf