Gestión de Proyectos

Héctor Moya Henríquez

Ingeniero Comercial
Mg. en Liderazgo, diplomado en Gestión Curricular e
Innovación Educativa
Programa Alumno 10C, Universidad de Huelva-Sevilla
hector.moya.henriquez@gmail.com
 Requerimientos fuera de control

No cumplimiento de los tiempos planificados (desvíos)

¿Cómo Estimaciones deficientes

Re trabajo excesivo
Surge? Baja calidad

Costos excedidos

Insatisfacción del Cliente

Insatisfacción de los profesionales participantes

 Respetar a las personas, porque el equipo es quien conoce
cómo mejorar el proceso en que trabaja.

Eliminar los desperdicios que se producen en el proceso, todo

aquello que no produce valor agregado en el producto.

Conocimiento, tener feedback regular con el cliente para

alinearse con sus expectativas.

Principios Hacer entregas rápidas, para permitir que el cliente pueda

aprovechar antes los beneficios que le aporta el proyecto.

Desarrollar con calidad interna, de manera que el producto

pueda ir creciendo con una velocidad sostenida.

Optimizar la totalidad del proceso, desde la idea hasta su

entrega.
¿Cuando un No se basa en el seguimiento de un plan
sino en la adaptación continua a la evolución

Método es del proyecto. El desarrollo de software es:

• Incremental: liberaciones pequeñas y

Ágil? ciclos rápidos.

• Cooperativo: clientes y desarrolladores
trabajando juntos.
• Simple y Directo: el método es fácil de
aprender y modificar.
• Adaptativo: es posible realizar cambios de
último momento.
Diferencias entre el Método Tradicional V/S
el Ágil
Metodologías tradicionales
• Basadas en normas provenientes de
estándares
• Seguidos por el entorno de desarrollo
• Cierta resistencia a los cambios
• Proceso menos controlado, por la presión del
tiempo
• El cliente es parte del equipo de desarrollo
mediante reuniones
• Grupos grandes y posiblemente distribuidos
• Pocos artefactos y pocos roles pero muy
importantes
Metodologías Ágiles
• Basadas en prácticas de producción
de código
• Especialmente preparados para
cambios durante el proyecto
• Flexibilidad
• Proceso mucho más controlado, con
numerosas políticas/normas
• El cliente interactúa con el equipo de
desarrollo
• Grupos pequeños (<10 integrantes)
• Más artefactos y más roles
proveniente de la especialización de
departamentos
 Introducción a SCRUM
• La palabra SCRUM procede del rugby;
donde el equipo se amontona para
luego empujar todos en la misma
dirección.
• SCRUM es una estrategia de gestión
donde se aplican de manera regular un
conjunto de prácticas para mejorar el
trabajo colaborativo y obtener el mejor
resultado posible en la gestión de un
proyecto software.
El Manifesto Ágil – es una
declaración de valores.
Aunque los elementos a
la derecha tienen valor,
se valora por encima de
ellos los que están a la
izquierda.
Atributos del SCRUM
Scrum es un proceso iterativo e incremental que puede ser utilizado para desarrollar
cualquier producto o administrar cualquier trabajo. Sus principales atributos son:
• Un enfoque orientado a que los equipos desarrollen productos de manera iterativa e
incremental cuando los requerimientos cambian de manera rápida
• Un proceso que controla el caos de conflictos de intereses y necesidades
• Una manera de mejorar las comunicaciones y maximizar la cooperación
• Una manera de maximizar la productividad
• Escalable a múltiples proyectos y la organización
• Una forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus
contribuciones hizo lo mejor que podía hacer
Desarrollo secuencial vs.
Superpuesto
Principios
La prioridad es satisfacer al cliente a través de la entrega temprana y continua productos con valor.
Requisitos cambiantes, incluso en etapas avanzadas.
Entregas frecuentes.
Los responsables de negocio y los desarrolladores deben trabajar juntos permanentemente.
Conversación constante entre equipos y cliente.
Software que funciona es la principal medida de progreso.
Los procesos ágiles promueven el desarrollo sostenible.
La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad.
Simplicidad.
Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo.
 • Establece de forma precisa e inequívoca el seguimiento de un
producto y/o servicio durante todo su ciclo de vida.
• Formado por un conjunto de acciones, medidas y procedimientos
técnicos que permite identificar y registrar cada requerimiento de
manera que se pueda seguir su ciclo de vidas tanto para atrás,
desde su origen, como hacia delante, en la entrega del producto.
• Toda la documentación, códigos y guiones de prueba deberán
apuntar a su fuente de origen para permitir saber en todo
momento el origen, la implementación y las pruebas que se hagan

Trazabilidad a cualquier requerimiento

• Bidireccional: A partir de un requisito se llega al código que lo
implementa y a partir de un determinado código saber el o los
requisitos a los que corresponde.
• Vertical: Garantiza que todos los requerimientos serán diseñados
y que todos los diseños serán codificados y probados.
• Horizontal: Permite detectar si hay conflictos entre
requerimientos, diseño, lógica de codificación y/o casos de
prueba
Práctica SCRUM

• Scrum es una a practica de

desarrollo muy simple, no se basa
en el seguimiento de un plan, sino
en la adaptación continua a las
circunstancias de la evolución del
proyecto.
 Roles
Product
• Product Owner Backlog
• Scrum Team
• ScrumMaster

Reuniones Daily Scrum

• Planificación del 24 horas
Sprint
• Scrum diario Planificación del
• Sprint Review Sprint (coordinación)
• Sprint retrospective Sprint Incremento
Objetivo del 2-4 semanas
Artefactos en el Sprint Review
Sprint
Producto
• Product Backlog
• Sprint Backlog Sprint
Backlog
• Incremento
Sprint
retrospective
 Propietario del Producto:
•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
•Ajusta funcionalidades y
prioridades en cada iteración si
es necesario
•Acepta o rechaza los resultados
del trabajo del equipo
•Financiamiento del proyecto
•Lanzamiento del proyecto
•Representa a la gestión del
proyecto
•Representa a todos los
interesados en el producto final
Scrum Master:
•Responsable de promover los
valores y prácticas de Scrum.
•Se asegura de que el equipo es
completamente funcional y
productivo
•Permite la estrecha cooperación
en todos los roles y funciones
•Garantiza el funcionamiento de
los procesos y metodologías que
se emplean. Formación y
entrenamiento de procesos.
•Remueve impedimentos.
Facilitador.
•Dirección de la empresa, con el
conocimiento de gestión y
desarrollo ágil y facilitando los
recursos necesarios
•Responsables del Departamento
•Responsables del área de
gestión de proyectos
El Equipo:
•Equipo multidisciplinar que
cubre todas las habilidades
necesarias para generar el
resultado
•Se auto-gestiona y auto-
organiza
•Típicamente de 5 a 9 personas
•Los miembros deben ser
preferentemente full-time.
•Solo puede haber cambio de
miembros entre los sprints
•Transforman los requerimientos
en funcionalidad en cada
incremento
 Interdependencias de los Roles
Interesados Product Owner Scrum Master Equipo

>> Asegura que el proyecto cumple objetivos

>> Administra al equipo Auto-organizado

>> Administra el alcance y el presupuesto

>> Administra la comunicación entre involucrados

>> Gestiona riesgos y elimina obstáculos

>> Administra el proceso

>> Gestiona la visión Mejora continua

>> Investigación de mercado. Visión, Voz del Cliente

<< Asegura que el proyecto logra los objetivos

<< Negocia el trabajo con el equipo

<< Gestiona el alcance, cronograma, y presupuesto

<< Gestiona la comunicación con los interesados

>> Visualiza y distribuye información

>> Remueve impedimentos

Confección de Historias de Usuario
1.- Personas:
Usuarios o consumidores finales,
interesados, patrocinadores, equipo de
desarrollo, equipo de soporte.
2.- Historia de usuario: 3.- Criterios de Aceptación:
Como <rol, usuario> : Analista de crédito Definidos por las personas
Quiero <funcionalidad> : aprobar una solicitud de crédito. participantes.
Para <objetivo, valor>: que el comité la evalué.

4.-Contexto:
Necesidad origen, escenarios, de uso de la historia, dominio del negocio, que áreas del negocio usan o se impactan por la historia de usuario,
reglas del negocio que afectan la historia de usuario, alcance de la historia, épica de origen.(No todas las historias provienen de una épica en
particular pero si es así, es bueno conocerla)

5.- Definición de preparado: 6.- Definición de terminado: 7.- Resultado esperado:

¿Qué se debe cumplir para poder Condiciones de terminado especificas de la Solución esperada, valor a ganar. ¿Qué se
construir la historia de usuario? historia de usuario. quiere cumplir con la historia de usuario?

8.- Métricas: 9.- Retroalimentación:

Puntos, esfuerzos, valor, calidad, ganancia, numero de iteraciones, progreso, Nivel o grado de satisfacción de las personas, nivel de
numero de usuarios. felicidad del usuario, impacto generado. ¿Qué hacer para
mejorar?

10.- Importancia: 11.- Estimación: 12.- Categoría:

Desde el punto de vista del negocio. Valoración inicial del equipo del esfuerzo necesario para Categorización básica de la
Definido por el dueño del producto. implementar la historia, comparada con otras historias de historia de usuario
usuario.
INVEST
 El acrónimo INVEST para describir las características de una buena historia:
• Independiente: las historias pueden completarse en cualquier orden.
• Negociable: los detalles de la historia son co-creados por los programadores y los clientes durante el desarrollo.
• Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software.
• Estimable: los programadores pueden encontrar una estimación razonable para construir la historia.
• Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de "días/persona". Se tienen
que poder construir muchas historias en una iteración.
• Testeable: se debe poder escribir pruebas que verifiquen que el software de la historia funcione adecuadamente.
 Una forma habitual de escribir las historias es "Como <rol>.... Quiero <característica>... Para <valor>". La parte del
"Como..." se refiere a la persona que quiere la historia. La parte "Quiero..." describe la funcionalidad de la historia,
y la parte "Para..." describe el motivo por el cual se pide esa funcionalidad.
 • Listado con los requisitos del sistema. Una lista de todos los trabajos
deseados en el proyecto
– Priorizadas
– Documento "vivo"
– Accesible a todos los roles
– Todos pueden contribuir y aportar elementos
– El propietario del producto es su responsable:
Product • Representa los intereses del cliente dentro de la empresa.
• Es el nexo entre el cliente y el equipo.
Backlog • Tiene la visión global del producto buscado.
• Es el encargado de armar y priorizar el Product Backlog (Lista
priorizada de requerimientos).
• Cada tema tiene valor para el usuarios o el cliente (desde el punto de vista
del negocio)
• Repriorizada al comienzo de cada Sprint
• Es dinámico
• Mientras exista un producto, el Product Backlog también existe
Planificación del Sprint

• El equipo selecciona los temas a partir

del Product Backlog que pueden
comprometerse a completar
• Los Sprints duran, idealmente, menos de
un mes.
• Se seleccionan los requerimientos del
Product Backlog que entrarán en el
sprint.
• Se hace un listado de todas las tareas
necesarias para terminar el sprint
backlog, indicando el esfuerzo de cada
una.
• Se asignan responsables a las tareas
• El diseño de Alto Nivel es considerado
Coordinación Planificación del Sprint

• Primera reunión (Las primeras cuatro horas se dedican al Product Owner):

– Se establece la meta del Sprint
– Se identifica la funcionalidad que se va a construir en el Sprint
• Segunda reunión (Las segundas cuatro horas el equipo planea su propio Sprint):
– Se identifican y estiman las tareas para satisfacer
– Se crea un Sprint Backlog
– Las tareas son distribuidas por decisión de los miembros del equipo
– Los miembros del equipo se comprometen a cumplir con la meta del Sprint
• Entradas:
– Backlog del producto actualizado
– Retorno del ultimo Sprint
– Rendimiento del equipo en los Sprints anteriores
• Salida:
– Pila del sprint (Sprint Backlog)
 • Trabajo o tareas determinadas por el equipo
para realizar en un sprint y lograr al final del
mismo un incremento de la funcionalidad.
Pila del sprint • Se recomienda que las tareas reflejadas
tengan una duración comprendida entre las 4
(Sprint y las 16 horas de trabajo.
• Las de mayor duración deben intentar
Backlog) descomponerse en sub-tareas de ese rango de
tiempo.
Estimación de Póquer
• Es una práctica ágil, para conducir las reuniones en las que se estima el
esfuerzo y la duración de tareas. El modelo consta de 8 cartas: ½, 1, 2,
3, 5, 6, 7 e infinito.
• El funcionamiento es muy simple: cada participante dispone de un
juego de cartas, y en la estimación de cada tarea, todos vuelven boca
arriba la combinación que suma el esfuerzo estimado.
• Cuando se considera que éste es mayor de x horas ideales (el tamaño
máximo considerado por el equipo para una tarea), se levanta la carta
“infinito”. Las tareas que exceden el tamaño máximo deben
descomponerse en sub tareas de menor tamaño
• Cada equipo u organización puede utilizar un juego de cartas con las
numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y
el tamaño máximo de tarea que se va a estimar.
Procedimiento
• Cada participante de la reunión tiene un juego de cartas.
• Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente,
moderador o propietario del producto expone la descripción empleando un tiempo máximo.
• Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del
equipo.
• Cada participarte selecciona la carta, o cartas que representan su estimación, y las separa del resto, boca abajo.
• Cuando todos han hecho su selección, se muestran boca arriba.
• Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en sub-tareas
de menor tamaño.
• Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean,
no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen alusiva, para indicar
que se necesita un descanso
Daily Scrum

• Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada. Dura 15 minutos
• Sólo interviene el equipo de desarrollo
• No para la solución de problemas. No es dar un reporte de estado al Scrum Master, se trata de compromisos
delante de pares
• Todo el mundo está invitado
• Sólo los miembros del equipo, Scrum Master y Product Owner, pueden hablar
• Ayuda a evitar otras reuniones innecesarias

• Cada miembro responde a tres preguntas:

• Trabajo realizado desde la reunión anterior,
• Trabajo que se va a realizar hasta la próxima reunión de seguimiento,
• Problemas que se deben solucionar para realizar el trabajo propuesto

• Todo el equipo se reúne y discute lo que les gustaría: Comenzar a hacer, Dejar de hacer, Continuar haciendo
Ejecución del Sprint
• Periodo fijo de tiempo durante el cual el equipo desarrolla un
incremento de funcionalidad (no mas de 30 días)
• No se aceptan cambios a los requerimientos acordados.
• El producto es diseñado, codificado, probado durante el Sprint.
• Solo el Scrum Master puede cancelar el Sprint cuando:
– La tecnología no funciona
– Las circunstancias del negocio cambiaron
– El equipo tuvo interferencias
• Las iteraciones cortas permiten reducir los riesgos
Ejecución del Sprint

• Es el periodo de tiempo durante el que se desarrolla un

incremento de funcionalidad. Constituye el núcleo de Scrum,
que divide de esta forma el desarrollo de un proyecto en un
conjunto de pequeñas “carreras”.
• Durante el sprint no se puede modificar el trabajo que se ha
acordado en el Backlog.
• Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo
lo puede hacer el Scrum Master si decide que no es viable por
alguna de las razones siguientes:
– La tecnología acordada no funciona.
– Las circunstancias del negocio han cambiado.
– El equipo ha tenido interferencias.
• Diariamente se realiza una reunión diaria llamada Daily Scrum, y
al final del Sprint, se realiza una reunión de revisión de Sprint,
llamada Sprint Review
Fin del Sprint: Sprint Review

• Reunión donde se presenta al Product Owner y a los implicados todas las funcionalidades implementadas.
• Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente
– Informal
– Duración de 4 horas. Regla de 2 horas de preparación.
– No usar diapositivas
– Todo el equipo participa
– Se invita a todo el mundo
• El Product Owner trata con los asistentes y con el equipo las posibles modificaciones en la pila de producto.
• Al final de la reunión se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de
cambio y mejora, y su relevancia.
• Después del Sprint Review y antes de la próxima reunión, el ScrumMaster convoca a una Sprint retrospectiva con
el equipo.
 Objetivo:
• Presentar el Product Owner y
demás involucrados del
proyecto el trabajo realizado
(incremento del producto)
durante el Sprint.
Participan:
• Equipo, Scrum Master,
Product Owner, todas las
personas involucradas en el
proyecto.
Reglas: Al finalizar:
• El Equipo no invierte mas de • El Product Owner decide si la
una hora en preparar el funcionalidad presentada
Sprint Review cumple con los objetivos del
• Las funcionalidades no Sprint
finalizadas completamente • Se actualiza y vuelve a
no se presentan priorizar el Product Backlog
• Los miembros del equipo • El Scrum Master anuncia el
presentan las funcionalidades lugar y la fecha de la próxima
• Las demostraciones se revisión del Sprint.
realizan en el equipamiento
de los miembros del equipo
• Al finalizar la reunión se
piden opiniones a los
participantes, los cuales
pueden sugerir cambios y
mejoras.
Sprint Retrospective

• Periódicamente, se echa un vistazo a lo que funciona y lo que no.

• Normalmente 30 a 90 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa: Scrum Master, Product owner, Equipo, Posiblemente clientes y otros
• El Scrum Master hace que el Team revise, su proceso de desarrollo Scrum, para hacerlo más
eficaz y eficiente para el próximo Sprint.
• El Scrum Master no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor
forma de trabajar con Scrum.
• En conjunto, Sprint planning meeting, Daily Scrum, Sprint review, y el Sprint retrospective,
constituyen la inspección empírica y prácticas de la adaptación del Scrum.
 • Demostración de los objetivos alcanzados en cada
sprint
• Asistencia de todos los roles, “Product Owner” e
incluso usuarios
• Sólo el Scrum Master puede abortar un Sprint debido
a una de las siguientes razones:

Incremento • La tecnología seleccionada no funciona o es

incompatible con los objetivos definidos
• Han cambiado las circunstancias de negocio
• El Scrum Team ha tenido inferencias
Fortalezas de SCRUM
Ejemplo del Proceso SCRUM
• Un cliente se pone en contacto con una empresa que fabrica robots.
• El cliente les realiza el pedido.

Quiero un robot que me

sirva de escolta
Ejemplo del Proceso SCRUM
• El Cliente se reúne con el Dueño de Producto, que toma nota de lo que tiene en su
cabeza.

Cliente Dueño de Producto

Ejemplo del Proceso SCRUM
• El Dueño del Producto divide el proyecto en historias que son las que componen la pila
de producto.

Dueño de Producto

Pila de Producto
Ejemplo del Proceso SCRUM
• El Scrum Master es un miembro del equipo que tiene el papel de comunicar y gestionar
las necesidades del Dueño de Producto y la pila de Sprint.
• El Dueño de Producto le entrega la pila de producto para que estimen el costo de
creación del producto.

Dueño de Producto Scrum Manager

Ejemplo del Proceso SCRUM
• El equipo se reune para estimar el costo de cada historia de la pila de producto.
• En este caso utilizan Planning Poker.

Equipo
Ejemplo del Proceso SCRUM
• El cliente, una vez aprobado el presupuesto, reordena la pila de producto para que el
equipo vaya trabajando según la prioridad del cliente.
Menos imporantes

Cliente

Urgentes
Ejemplo del Proceso SCRUM
• El equipo comienza su trabajo desglosando la primera historia de la pila de producto, la
cual subdividen en tareas menores para crear la pila de sprint.
Ejemplo del Proceso SCRUM
• La pila de sprint tiene como utilidad fraccionar el trabajo de un período de 15 días en
tareas mas pequeñas, que tarden como mucho dos días.
Ejemplo del Proceso SCRUM
• Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto, que ha
consultado con el cliente, antes de comenzar el sprint.
Menos imporantes

Dueño de Producto

Urgentes
Ejemplo del Proceso SCRUM
• El equipo comienza el sprint tomando las tareas priorizadas.
• Una vez concluida una se toma la siguiente de la lista.
• Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el
día anterior y cuáles se van a realizar ese día.
Ejemplo del Proceso SCRUM
• Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el resultado del
trabajo realizado.
• El cliente ya tiene el primer contacto con su encargo y además puede volver a priorizar la
pila de producto antes de que comience otro sprint.

Buen trabajo

Dueño de Producto Cliente

Ejemplo del Proceso SCRUM
• El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva, donde se
analiza lo ocurrido durante el sprint.