Unidad 2 - Capitulo 5 - Entrega Del Proyecto (Delivery) - V2.0

Posgrado en Gestión de Proyectos (PGP)
Entrega del Proyecto, Planificación y Gestión

del Presupuesto
Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
p. 2
Módulo 2 - Unidad 5
Gestión del Alcance

p. 3
Presentación:
El Módulo 2 introduce a los participantes las dificultades y complejidad de gestión de las
restricciones.
En esta sexta unidad del curso se continúa el desarrollo de los conceptos y prácticas que refieren a
gestionar qué se entrega en el proyecto, un producto, un servicio, un resultado: en definitiva, el
Alcance. En particular se avanza con mayor foco sobre metodologías y marcos de trabajo Ágiles.

p. 4
Objetivos:
Que los participantes:
 Comprendan como se debe Gestionar con profesionalismo el Alcance del Proyecto

 Entiendan el ciclo de vida de los requisitos
 Se familiaricen con las prácticas tanto predictivas como ágiles en lo que refiere a la Gestión
del Alcance

p. 5
Bloques temáticos:
1. Supuestos y Limitaciones
2. Gestión por Entregables
3. Línea Base del alcance (continuación)
4. El Alcance en Metodologías Ágiles
5. MMF y MVP (Ágiles)
6. Gestión del Alcance para dar Valor al Negocio
7. BackLog de Producto (Ágiles)
8. Historias de Usuario (Ágiles)

p. 6
Consignas para el aprendizaje colaborativo

En esta Unidad los participantes se encontrarán con diferentes tipos de actividades que, en el
marco de los fundamentos del MEC*, los referenciarán a tres comunidades de aprendizaje, que
pondremos en funcionamiento en esta instancia de formación, a los efectos de aprovecharlas
pedagógicamente:
● Los foros proactivos asociados a cada una de las unidades.

● La Web 2.0.
● Los contextos de desempeño de los participantes.
Es importante que todos los participantes realicen algunas de las actividades sugeridas y
compartan en los foros los resultados obtenidos.
Además, también se propondrán reflexiones, notas especiales y vinculaciones a bibliografía y sitios

web.
El carácter constructivista y colaborativo del MEC nos exige que todas las actividades realizadas
por los participantes sean compartidas en los foros.
* El MEC es el modelo de E-learning colaborativo de nuestro Centro.

p. 7
Tomen nota:
Las actividades son opcionales y pueden realizarse en forma individual, pero siempre es deseable
que se las realice en equipo, con la finalidad de estimular y favorecer el trabajo colaborativo y el
aprendizaje entre pares. Tenga en cuenta que, si bien las actividades son opcionales, su realización
es de vital importancia para el logro de los objetivos de aprendizaje de esta instancia de
formación. Si su tiempo no le permite realizar todas las actividades, por lo menos realice alguna,
es fundamental que lo haga. Si cada uno de los participantes realiza alguna, el foro, que es una
instancia clave en este tipo de cursos, tendrá una actividad muy enriquecedora.
Asimismo, también tengan en cuenta cuando trabajen en la Web, que en ella hay de todo, cosas
excelentes, muy buenas, buenas, regulares, malas y muy malas. Por eso, es necesario aplicar filtros
críticos para que las investigaciones y búsquedas se encaminen a la excelencia. Si tienen dudas con
alguno de los datos recolectados, no dejen de consultar al profesor-tutor. También aprovechen en
el foro proactivo las opiniones de sus compañeros de curso y colegas.

p. 8
1. Supuestos y Limitaciones
Es claro que por su naturaleza y complejidad todos los proyectos se conciben y desarrollan sobre
la base de un grupo de hipótesis, escenarios o supuestos que incluyen restricciones o limitaciones.
Este es un punto que resulta esencial dado que es un trabajo típicamente proactivo que se debe
realizar sobre los Supuestos y las Restricciones, una buena gestión de ellos protege al proyecto de
cambios fuera de control, discusiones sobre el alcance o dudas sobre el objetivo del proyecto,
entre otros casos.
Revisemos, entonces, las definiciones:
Supuesto: La palabra proviene en su etimología del latín de “supponere” que implica “dar
por sentado”. Un supuesto es un elemento o punto una aseveración que es tenido por
certero, aun cuando no haya sido probado. Los supuestos son premisas en las que se basan
los Gerentes de Proyecto y el Equipo para “poder avanzar”.
Este último comentario es fundacional dado que sin el empleo de supuestos deberíamos
esperar a tener confirmación y certeza de cada uno de los mencionados puntos, algo que
claramente no es viable en el contexto de la ejecución de un proyecto y también es
especialmente válido en los trabajos iniciales de definición del objetivo del proyecto
(Alcance “preliminar” o Alcance en el período anterior a la ejecución, en el “Pre Proyecto”).
Un ejemplo de un supuesto es “Se asume que el Proveedor XXX podrá entregar el trabajo
YYY antes de la fecha ZZZ”, o también “Se asume que el comienzo de la ejecución del
equipo proyecto será el día XXX”.
Otro punto importante en cuanto a los supuestos, es que una vez que estamos ejecutando
el proyecto no debiese tener más supuestos. A lo largo de la planificación debiese ir
confirmando los mismos, para lo cual, voy a tener algunos que se confirman como hechos,
o que son todo lo contrario y pasan a ser limitaciones, o bien que no lo pueden confirmar
(como por ejemplo la entrega certera del proveedor) a partir de lo cual eso debo
gestionarlo como un riesgo ya que en ninguna metodología existe la Gestión de Supuestos,
sino la gestión de riesgos.
Los supuestos y Limitaciones están en gran medida fuera de control del

Gerente de Proyecto

p. 9
Limitación: La palabra proviene en su etimología del latín de “limitatio” que es la acción y

efecto de limitar o limitarse. El verbo limitar refiere entonces a poner “límites” o
separaciones por ejemplo entre territorios (y he aquí la analogía, por ejemplo, con el
territorio del Proyecto).
Las limitaciones también son llamadas Restricciones y si bien en la Gestión de Proyectos se
menciona a las restricciones en una asociación con la “triple restricción” de Alcance,
Tiempos y Costos, en realidad una restricción es cualquier elemento, o situación que
implica una reducción o limitación en la gestión de proyectos. Por ejemplo, el contar con
un equipo de trabajo demasiado “junior” para ejecutar el proyecto es una restricción y por
lo tanto establece un límite en la gestión y en consecuencia decimos que el gerente de
proyecto cuenta con un proyecto que tiene limitaciones, es decir, no cuenta con un
conjunto infinito de opciones para Gestionar, por ejemplo, el Alcance, sino que debe actuar
dentro de sus posibilidades.
En oportunidades se menciona también al término “Asunción” dado que referencia al acto y

resultado de asumir, que implica aceptar una responsabilidad, comenzar a ejercer una función o
un cargo.
En definitiva, cuando se definen los entregables y el alcance de un proyecto es clave listar los
supuestos en los que se basa todo. Es ideal contar con un apartado que mencione por ejemplo
aquellas situaciones o elementos que se “asumen” como válidas, obviamente la recomendación
aquí es contar con una aprobación formal del sponsor y principales interesados.
Es clave listar los supuestos en los que se basan los entregables. Es

ideal contar con un apartado que mencione por ejemplo aquellas situaciones o
elementos que se “asumen” como válidas, la recomendación es contar con una
aprobación formal del sponsor y principales interesados.

p. 10
2. Gestión por Entregables
Un entregable es el fruto “tangible” (aunque sea virtualmente) de un trabajo. Por ejemplo, un
informe, un reporte, una presentación sobre alternativas para la definición de roles en el equipo,
la construcción de un muro lateral entre ambientes en una construcción, una minuta de reunión,
un diseño plasmado en una página web, una pieza mecánica terminada, una capacitación
finalizada, etc.
Existe una gestión que ganó popularidad en las prácticas de Gestión de Proyectos y que es la
Gestión por Entregables.
Esencialmente se establecen los siguientes criterios:
1. Toda actividad, tarea, trabajo que se realice debe concluir en un “Entregable”. Por ejemplo,
no es posible hacer una reunión de proyecto que no implique una minuta de reunión o una
actualización de un chart de trabajo, que es el entregable de esa reunión
2. La gestión en su totalidad se enfoca exclusivamente en cuál es el resultado del trabajo, en
ese sentido, por ejemplo, no se planifican tareas, sino que se planifica directamente sobre
el entregable
3. Se genera y gestiona una lista de entregables más que una lista de tareas o actividades
La gestión por Entregables implica que toda actividad, tarea, trabajo

que se realice debe concluir en un “Entregable”. Por ejemplo, no es posible hacer una
reunión de proyecto que no implique una minuta de reunión
En un enfoque con estas características las conversaciones en el equipo y con el Gerente de

Proyecto siempre se enfocan siempre en resultados concretos. Con frecuencia, y también que, por
supuesto depende en gran medida del contexto, la gestión por entregables requiere una gestión
del cambio en los equipos, en su manera de interactuar en reuniones, en su forma de pensar sobre
las actividades, etc.
Por otra parte, el trabajo se piensa más en términos de una una PBS que de una EDT.

p. 11
La PBS (del idioma inglés Product Breakdown Structure) es la Estructura de Descomposición o
Desglose del Producto.
La PBS es una descomposición jerárquica de todos los entregables (resultados tangibles) que se
deben crear en un proyecto partiendo de lo que, en el marco de trabajo de PRINCE2®1, se llama el
Producto del Proyecto. El producto es el resultado esperado del proyecto, desde el punto de vista
del cliente o usuario final. Para desarrollar el PBS debemos responder preguntas del estilo: ¿Qué
es exactamente el objetivo final? ¿Cuál es resultado del proyecto? ¿Cómo debería verse? ¿Cuáles
son las partes que integran al producto?
En definitiva, la PBS es la visión de conjunto del producto (y sus partes) creado por el proyecto.
Ejemplo “visual”de una PBS:
1 Prince2® proviene del acrónimo en inglés PRojects IN Controlled Environments (PRINCE), es decir,
convertir a los proyectos, que manejan una carga importante de variabilidad y de incertidumbre, en entornos
controlados. Más que un conjunto de buenas prácticas, PRINCE2 propone un marco de trabajo de gestión
de proyectos similar al propuesto por el PMI®
p. 12
3. Línea Base del alcance (continuación)
La línea de base o línea basal es la primera medición de todos los indicadores contemplados en un
primer instante CERO y también es una “fotografía” de un momento en el proyecto, por ejemplo,
es una “congelación” de resguardo de la documentación en el estado en que estuviera en ese
determinado instante.
La línea base tiene como objetivo el permitir conocer el valor de los indicadores y saber cómo se
encontraba el proyecto al momento de iniciarse acciones posteriores, es decir, establece un
“punto de partida”.
La línea de base suele tener un carácter cuantitativo (porque queremos en la medida de lo posible
“medir” para comparar luego). Se puede recurrir tanto a fuentes primarias (producidas ad-hoc
para la Línea Base) como a secundarias (por ejemplo: los documentos de preproyecto, estudios
previos, etc.).
Dentro del ciclo de vida del proyecto, es muy recomendable que la línea base se realice al inicio
del Proyecto dado que, a posteriori, no se contará con datos que permitan establecer
comparaciones posteriores e indagar sobre cambios ocurridos conforme el proyecto se ejecute.
Es posible realizar una Línea Base de Alcance, una de Presupuesto o Costos, una de Planificación o
Cronograma, etc. También se puede optar por realizar una Línea Base de “todo” el proyecto
teniendo en cuenta las distintas variables, por ejemplo, Alcance, Equipo, Calidad, Costos.
Queda claro que en entornos ágiles el establecimiento y seguimiento sobre una Línea Base del
Alcance no es requerido y puede que no otorgue ningún valor, debido a la naturaleza de este tipo
de gestión

p. 13
4. El alcance en Metodologías Ágiles
La Gestión de Proyectos en General es enormemente distinta cuando se emplean metodologías o
marcos de trabajo ágiles.
Recordemos que la gestión ágil tiene como meta entregar un producto o un incremento de
producto con el mayor valor posible para el cliente en un tiempo dado (time-boxed). Se realizan
entregas incrementales para reducir el riesgo y la incertidumbre.
Ahora bien, ¿Cómo Impacta la Gestión del Alcance? La respuesta es “de muchas formas”, desde la
mentalidad de trabajo hasta “nuevos” conceptos como MMF.
La idea general de “Agile” es definir pequeños incrementos de funcionalidad, pequeños productos

o agregar cualidades a estos, por lo cual existe una relación más estrecha entre una PBS y Agile
que entre una EDT y Agile.
Si bien las metodologías ágiles introducen actividades, procesos y técnicas, el enfoque ágil
requiere de un cambio de paradigma para adoptar esta nueva mentalidad ágil además de seguir
un mero proceso. Esta mentalidad ágil se refleja en el manifiesto ágil, los principios Lean, los
valores de XP, y los pilares de Scrum, entre otros. El concepto de “Escenarios Simples y
Complejos” visto en el capítulo de Estimaciones, es clave para entender la problemática y desde
esa mirada pensar nuevas soluciones.

p. 14
5. MMF y MVP (Ágiles)
MMF
Según James Shore2 “Un Minimum Marketable Feature (MMF) es el conjunto más pequeño
posible de funcionalidades que de por si aporta valor al negocio. Se podría entregar el
producto con un único MMF y sin embargo ver algún beneficio para el negocio.”
Minimum (Mínimo)
Si una división del MMF resultará en un conjunto de funcionalidades

demasiado pequeño – por ejemplo, para ser comercializado a clientes – no
se debería hacer.
Para orientar esta decisión, un buen criterio es definir si este conjunto de

funcionalidades ameritaría contar con su propio ítem en un email comercial
describiendo las funcionalidades de una nueva versión del producto.
Dicho de otra forma, un MMF tiene una atomicidad o una esencia que no se
puede dividir desde el punto de vista del negocio.
Marketable (Comercializable)
El carácter de comercializable se refiere a la entrega a un cliente del

conjunto de funcionalidades. Conceptualmente involucra una transacción
comercial directa o indirecta, donde uno o varios clientes “compran” esta
entrega.
El concepto se puede extender a entregas sin transacción comercial, pero

con una disponibilización del conjunto de funcionalidades para su uso en un
ambiente productivo o de mercado.
En consecuencia, el MMF es comercializable si aporta algún valor concreto a

sus clientes o usuarios.
Feature (Conjunto de Funcionalidades, ergo “Alcance”)
2Autor de muchas publicaciones y artículos sobre marcos de trabajo ágiles, en particular “The Art of Agile
Development
p. 15
El “feature” (funcionalidad) es un comportamiento del producto “que
perciben” sus interesados, por ejemplo, para los usuarios.
Como mencionamos previamente, es el “QUÉ” se puede hacer con un

producto (que es el Alcance). En este sentido, se distingue del “CÓMO” se
resuelve técnicamente (que es la ejecución del proyecto).
Es importante hacer esta distinción, en particular en las metodologías ágiles,

donde los MMFs siempre son vistos desde el punto de vista de sus usuarios
finales.
Un Minimum Marketable Feature (MMF) es el conjunto más pequeño

posible de funcionalidades que de por si aporta valor al negocio
MVP
El MVP (Minimum Viable Product) es la "Versión Mínima de un Producto", características

mínimas y estrictamente necesarias para que el producto se pueda considerar entregado y
“eventualmente” salir al mercado, de tal manera que nos permite obtener feedback con
celeridad del comportamiento de un producto. En general MVP tiene solamente las
funcionalidades que permiten que el producto sea lanzado sólo a un segmento del total de
los potenciales usuarios, tales como a los "early adopters".
El concepto de MVP es similar al concepto de MMF, solo que el MVP es “un producto
entero” mientras que, como su nombre lo indica, el MMF podría ser solo una funcionalidad
específica.
El Objetivo del MVP es (desde el punto de vista del negocio) testear hipótesis sobre la
visión del producto e incorporar tempranamente retroalimentación para futuras versiones
del mismo producto o para una evolución hacia otros productos.

p. 16
El concepto de MVP es similar al concepto de MMF, solo que el MVP es

un producto completo, entero.
MVP representado junto con una comparación entre la definición del alcance completa de
metodologías tradicionales en comparación con metodologías ágiles:
Las agiles deben cumplir con la premisa de generar un producto en forma iterativa e
incrementar, en periodos cortos (para su industria). En cada iteración deben generar un
producto que se potencialmente entregable al cliente.
En el ejemplo, el producto a generar es un vehículo de transporte. Transporte de una

persona es el propósito.
En “Not like this..” no salvo la última entrega en el resto no generan un vehículo.

p. 17
En “Like This!” en cada entrega cumple con la funcionalidad de movilidad. En la 1 difícil de
usar, 2 facil pero lento, 3 más rápido pero con sin motor, 4 con motor sin capacidad de
carga de equipaje, 5 con capacidad de carga. Cada iteración de más valor a los clientes. Un
ejemplo cotidiano que hoy hay son edificios que se construye la estructura y luego se van
construyendo y entregando por pisos.
En un escenario de mucha incertidumbre, pensar que se definirá la solución de

una única vez y para siempre, es el más certero error de estrategia.

p. 18
6. DoR y DoD (Definición de Listo y de Hecho)
El llamado Definition of Ready en los textos originales, indica el criterio de inicio para
definir un trabajo, una tarea y podemos estar hablando de un impedimento técnico, así
como también de una especificación. Esto suele acordarse con el equipo de construcción
(delivery, entrega del proyecto) para saber si las definiciones del trabajo son lo
suficientemente buenas para empezar.
Definición de Hecho (Done)
La definición de hecho (DoD - Definition of Done) es un acuerdo realizado por el equipo de

proyecto para validar cuando un trabajo, una labor, puede considerarse completada,
evitando cuestionamientos posteriores y pudiendo planificar claramente sobre qué estará
“hecho” y cuáles son las actividades y entregables finalizados 100%.
Es importante destacar que esto no hace referencia solo a la funcionalidad entregada en si

misma sino también a la calidad e ítems asociados requeridos para terminarlo; puede verse
como una lista de actividades que completamos por defecto (por ejemplo en desarrollo de
SW podría incluir Codificación, Prueba unitaria, Generación de Casos de prueba,
actualización de documentos, etc.). Estas actividades deben entenderse como de valor
para los entregables (descartando toda actividad que no lo hace).
Esta definición no debe ser tomada a la ligera por el equipo, ya que es la manera en que el
equipo considera puede garantizar calidad en su trabajo.
7. Gestión del Alcance para dar Valor al Negocio

Si bien claramente el proveer valor al Negocio no es una potestad de las metodologías y
marcos de trabajo ágiles, en “Agile” este enfoque es sanamente obsesivo.

p. 19
El valor es la calidad que hace deseable algo. De acuerdo a la Teoría del Valor de David
Morris3, el valor puede tener que ver con obligaciones (lo que se espera que alguien
entregue), con el precio (lo que alguien pagaría por tenerlo) y con la satisfacción (como
alguien se siente al respecto), y se debería considerar tanto desde el punto de vista del que
entrega como desde el punto de vista del que recibe (David Morris)
Podemos tipificar las organizaciones en tres tipos, según su objetivo director:
• Organizaciones Comerciales: buscan retornar un dividendo a sus accionistas

y un crecimiento de su capital en el largo plazo.
• Organizaciones Gubernamentales: buscan cumplir con sus obligaciones

estatúales.
• Organizaciones Caritativas: buscan avanzar hacía sus objetivos

fundacionales (como por ejemplo educar gente desfavorecida, proveer comida a
niños, etc.)
Obviamente esta tipificación es una simplificación, y seguramente en algunas

organizaciones se podrán combinar estos tipos y eventualmente aparecer otros objetivos
directores.
Teniendo en cuenta esta tipificación, podemos destacar la siguiente definición:
El Valor de Negocio es lo que contribuye al objetivo director de una organización, por

ejemplo: aumentar o retener ingresos, mejorar servicios, reducir o eliminar costos, cumplir
con regulaciones, lograr objetivos de marketing, hacer crecer sus empleados, etc. (David
Morris)
En las principales metodologías ágiles se busca asignar un Valor de Negocio a los features a
desarrollar, que represente los beneficios correspondientes para la organización, de
acuerdo a sus objetivos director.
3La teoría del valor de David Morris NO refiere a la clásica Teoría del valor-trabajo (TVT) que considera que
el valor de un bien o servicio está determinado por la cantidad de trabajo necesario para producirlo, en lugar
de por la utilidad que le encuentre el propietario.
p. 20
Cuantificación del Valor de Negocio: “Como regla general, si los beneficios nos
son cuantificados, se puede asumir que no existen.” Tom De Marco y Timothy Lister

p. 21
8. BackLog de Producto (Ágiles)
El Backlog de Producto es una lista única, publica y dinámica que recopila una secuencia
priorizada de requisitos para el producto. Algunos de estos requisitos tienen una estimación de
alto nivel de esfuerzo o complejidad. Se suele decir que el Backlog de Producto representa el
"Qué" esperado del producto, sin preocuparse por el "Como" (una vez más, es el “Alcance”)
A continuación, se explican algunos conceptos claves respecto al Backlog de Producto:
• Lista publica y única
El Backlog de Producto es un artefacto que permite aportar visibilidad y transparencia

sobre el trabajo del equipo de proyecto. Dado que es el lugar donde se registran los
requisitos en los cuales está trabajando el equipo y también la priorización de los requisitos
a trabajar posteriormente, es importante que cada persona involucrada o interesada en el
producto pueda conocer este detalle, de tal forma que no haya ambigüedad sobre que está
haciendo y que no está haciendo el equipo en términos de requisitos (alcance). En caso
contrario es a veces muy difícil para un único equipo poder satisfacer prioridades que
llegan de sectores distintos al mismo tiempo.
• Dinamismo
El Backlog de Producto es un elemento dinámico que siempre está en evolución. El

enfoque ágil permite ir descubriendo las características deseadas del producto que se está
construyendo. Los requisitos del producto suelen ir cambiando en el tiempo, por distintas
razones como por ejemplo cambios legales a tener en cuenta, cambios en el negocio del
cliente, cambios tecnológicos que aparecen, mejor entendimiento de las problemáticas,
feedback de los usuarios, ideas de mejoras que surgen con el uso del producto, etc. Este
modelo de gestión del alcance es diametralmente opuesto a la gestión tradicional en
donde se hace especial énfasis en evitar cambios al alcance estipulado
Por estas razones el Backlog de Producto es un artefacto abierto donde se pueden agregar
ítems en cualquier momento, potencialmente por cualquier persona bajo la supervisión de
un Dueño de Producto / Gerente de Proyecto
• Priorización

p. 22
Los ítems del Backlog de Producto deben en general tener una secuencia única de
priorización, evitando que haya varios ítems con la misma prioridad (siempre se busca que
uno tenga mayor prioridad que el otro). En la metodología Ágil Scrum se persigue lograr
una priorización desde la perspectiva del valor que puede aportar el ítem o la funcionalidad
para el negocio una vez que se implemente. Existen distintas formas de cuantificar este
valor para el negocio, considerando por ejemplo algunos de los siguientes criterios:
• Beneficios medibles (por ejemplo, en dinero) de implementar una funcionalidad
• Penalidades de no implementar una funcionalidad en un momento dado o costo

de posponerla
• Riesgos en la implementación de la funcionalidad
• Coherencia con la estrategia de negocios de la organización
• Valor diferencial respecto a productos de la competencia
• Estimaciones de cada ítem
Cada ítem del Backlog de Producto suele contar con una estimación aproximada de
esfuerzo o complejidad para desarrollar la funcionalidad correspondiente por completo.
Estas estimaciones suelen actualizarse periódicamente. Son opcionales para los ítems
menos priorizados de la lista, con un alto grado de incertidumbre para ítems con baja
prioridad, pero más precisas para los ítems más priorizados. Se trata de dedicarle esfuerzo
a las estimaciones para los ítems que más probablemente se desarrollen en un futuro
cercano. De esta forma no se invierte esfuerzo en estimaciones de ítems que en el futuro
podrían no desarrollarse y también a veces permite estimar con un mayor contexto, un
mayor conocimiento de los usuarios, del negocio o del ítem.
• Granularidad
Los ítems del Backlog de Producto pueden tener distintas granularidades (tamaños de la
estimación), no necesariamente tienen que tener tamaños similares. Por ejemplo, se
pueden encontrar ítems como "Contar con un módulo de Contabilidad" o "Agregar un filtro
p. 23
de Tipo de Producto al Reporte de Ventas". Para los ítems de baja granularidad, se suele
usar el formato de Historias de Usuario como formato de especificación de requisitos. Los
ítems de mayor granularidad suelen llamarse temas o Épicas.
Sin un norte claro, no se sabrá cuál es el próximo paso, o si el paso anterior fue
correcto.

p. 24
9. Historias de Usuario (Ágiles)
Una Historia de Usuario es en definitiva una porción del Alcance, es una forma de escribir un
ítem del Backlog de Producto que se enfoca en la necesidad de los involucrados de entender
como la funcionalidad se va a usar. Al concentrarse en el objetivo funcional del ítem, la Historia
de Usuario permite al equipo entender la perspectiva del usuario antes de elegir una forma de
implementarlo.
Una Historia de Usuario se escribe de la forma siguiente:
Como [Rol de usuario de la funcionalidad],
Quiero [una funcionalidad]
Para [beneficio]
Por ejemplo:
Como Pasajero,
Quiero Comprar un pasaje
Para llegar a un destino particular en una fecha y hora indicada
Las Historias de usuarios identifican conversaciones que deberían darse entre el cliente y el
equipo para definir las funcionalidades. Son relatos que hablan de una necesidad “Para”, de un
tipo de persona o rol “Como” y de qué hacer para satisfacerlo “que”. Permiten en cierta forma
posponer los detalles para más adelante, refiriéndose a problemas más que soluciones. Son
naturalmente un formato adecuado para los ítems de un Backlog de Producto.
En mi experiencia, desde que surge una "idea de mejora" se tiene claro el beneficio, el "para que" se pide, el
"valor" que genera al negocio. Cuando la idea llega a la etapa de construcción esto suele esfumarse, o
p. 25
nublarse y llega el "que" o el "como" hacerlo, limitando la capacidad de pensar del desarrollador. Este no
puede evaluar si el "que" y el "como" siguen siendo solución, u otras posibilidades de mejora. Una de las
herramientas para mantener el "Para Que", "El Propósito" vivo son las historias o relatos de usuario.
Criterios de Terminado (Done)
Para todos los ítems del Backlog de Producto, se suelen identificar un criterio por el cual se
considera terminado. Por ejemplo, se consideran terminado cuando pasaron el control de
calidad. Esto criterio es propio de cada industria, o grupo de productos a desarrollar.
Criterios de Aceptación
Para cada ítem del Backlog de Producto, se suelen identificar los principales criterios de
aceptación o tests de aceptación de alto nivel a ejecutar para considerar cumplido el
requisito. Estos son criterios individuales de cada ítem de backlog.

p. 26
A continuación, se muestra un ejemplo de un Backlog de Producto en formato de planilla:
Prioridad Ítem Estimación Estado Criterios de Aceptación
1 Como usuario registrado, quiero 3 En curso  Probar una compra simple, realizar la
poder comprar acciones para compra
ganar o mantener mi capital  Probar con acciones de tipo A, B y C, realizar
la compra
 Probar con usuario sin saldo, rechazar todas
las compras
 Probar con usuario no registrado, rechazar
todas las compras
2 Como usuario no registrado, 5 Terminado  Probar con rango de fecha valido que
quiero poder buscar eventos de muestre los eventos.
mercado para ver si me  Rango invalido, indique que no hay
interesan algunos resultados
 Probar con múltiples eventos un mismo día,
muestra los eventos.
3 Como usuario registrado, quiero 3 Pendiente  Probar con empresas sin ficha detallada,
recibir información detallada de devolver los datos de las empresas
una empresa elegida para  Probar con empresa con ficha detallada,
estudiar su perfil financiero devolver los datos de las empresas
 Probar con usuario no registrado, no dar
ningún dato
4 Como inquilino, quiero tener 8 Pendiente  Probar con 1 televisor, funcione
televisión por cable para ver  Probar con múltiples televisores, que solo se
cuando quiera toda la vea en uno.
programación de la empresa de  Probar utilizar internet, que no funcione.
cable
etc.
Criterios de Listo (Ready)
Es un acuerdo entre el Dueño de producto y el equipo de desarrollo, para cada ítem de

backlog, en el que se especifica que es lo necesario para que este se pueda empezar a
construir. Suele ser un checklist, con todo los necesario previo a empezar. En algunos casos
sin estos no se puede estimar el esfuerzo de construcción.
Ejemplo Checklist:
1. Definir arquitectura

p. 27
2. Definir mecanismo de seguridad
3. Obtener materiales
4. Definir el template de calidad
Unión de las Historias de Usuario con la EDT
Si se desea emplear una EDT al mismo tiempo que una descomposición en Historias de
Usuario, el PMI® sugiere en la 6ta edición del PMBoK lo siguiente : “Si se utiliza un enfoque ágil, las
épicas se pueden descomponer en historias de usuarios. La EDT/WBS se puede estructurar como
un esquema, como un organigrama, o mediante otro método que represente un desglose
jerárquico”

p. 28
Bibliografía utilizada y sugerida

· The Agile PMO - Leading the Effective, Value Driven, Project Management Office (The
Leadership Series) by Michael Nir (Feb 27, 2013) Sold by: Amazon Digital Services, Inc;
Language: English; ASIN: B00BMP8518
· Organizational Project Management Maturity Model, (Opm3r) Knowledge Foundation:

Knowledge Foundation by Project Management Institute (Dec 31, 2008) Publisher: Project
Management Institute ISBN-10: 1933890541
· A Guide to the Project Management Body of Knowledge: PMBOK(R) Guide, Publisher: Project
Management Institute; 7 edition (2021) Language: English ISBN-10: 1628256648
· Agile Practice Guide, Publisher: Project Management Institute; 1st edition (October 1, 2017)
Language: English ISBN-10: 1628251999

p. 29
Lo que vimos:
 Entrega del Proyecto
Lo que viene:
 Planificación del Proyecto


Unidad 2 - Capitulo 5 - Entrega Del Proyecto (Delivery) - V2.0

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 2 - Capitulo 5 - Entrega Del Proyecto (Delivery) - V2.0

Cargado por

Copyright:

Formatos disponibles

Posgrado en Gestión de Proyectos (PGP)

Entrega del Proyecto, Planificación y Gestión

Centro de e-Learning SCEU UTN - BA.

Gestión del Alcance

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

 Comprendan como se debe Gestionar con profesionalismo el Alcance del Proyecto

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

Consignas para el aprendizaje colaborativo

● Los foros proactivos asociados a cada una de las unidades.

Además, también se propondrán reflexiones, notas especiales y vinculaciones a bibliografía y sitios

* El MEC es el modelo de E-learning colaborativo de nuestro Centro.

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

Revisemos, entonces, las definiciones:

Los supuestos y Limitaciones están en gran medida fuera de control del

Centro de e-Learning SCEU UTN - BA.

Limitación: La palabra proviene en su etimología del latín de “limitatio” que es la acción y

En oportunidades se menciona también al término “Asunción” dado que referencia al acto y

Es clave listar los supuestos en los que se basan los entregables. Es

Centro de e-Learning SCEU UTN - BA.

Esencialmente se establecen los siguientes criterios:

La gestión por Entregables implica que toda actividad, tarea, trabajo

En un enfoque con estas características las conversaciones en el equipo y con el Gerente de

Centro de e-Learning SCEU UTN - BA.

Ejemplo “visual”de una PBS:

Centro de e-Learning SCEU UTN - BA.

La idea general de “Agile” es definir pequeños incrementos de funcionalidad, pequeños productos

Centro de e-Learning SCEU UTN - BA.

Si una división del MMF resultará en un conjunto de funcionalidades

Para orientar esta decisión, un buen criterio es definir si este conjunto de

El carácter de comercializable se refiere a la entrega a un cliente del

El concepto se puede extender a entregas sin transacción comercial, pero

En consecuencia, el MMF es comercializable si aporta algún valor concreto a

Feature (Conjunto de Funcionalidades, ergo “Alcance”)

Como mencionamos previamente, es el “QUÉ” se puede hacer con un

Es importante hacer esta distinción, en particular en las metodologías ágiles,

Un Minimum Marketable Feature (MMF) es el conjunto más pequeño

El MVP (Minimum Viable Product) es la "Versión Mínima de un Producto", características

Centro de e-Learning SCEU UTN - BA.

El concepto de MVP es similar al concepto de MMF, solo que el MVP es

En el ejemplo, el producto a generar es un vehículo de transporte. Transporte de una

En “Not like this..” no salvo la última entrega en el resto no generan un vehículo.

Centro de e-Learning SCEU UTN - BA.

En un escenario de mucha incertidumbre, pensar que se definirá la solución de

Centro de e-Learning SCEU UTN - BA.

Definición de Hecho (Done)

La definición de hecho (DoD - Definition of Done) es un acuerdo realizado por el equipo de

Es importante destacar que esto no hace referencia solo a la funcionalidad entregada en si

7. Gestión del Alcance para dar Valor al Negocio

Centro de e-Learning SCEU UTN - BA.

Podemos tipificar las organizaciones en tres tipos, según su objetivo director:

• Organizaciones Comerciales: buscan retornar un dividendo a sus accionistas

• Organizaciones Gubernamentales: buscan cumplir con sus obligaciones

• Organizaciones Caritativas: buscan avanzar hacía sus objetivos

Obviamente esta tipificación es una simplificación, y seguramente en algunas

Teniendo en cuenta esta tipificación, podemos destacar la siguiente definición:

El Valor de Negocio es lo que contribuye al objetivo director de una organización, por

Centro de e-Learning SCEU UTN - BA.

A continuación, se explican algunos conceptos claves respecto al Backlog de Producto:

• Lista publica y única

El Backlog de Producto es un artefacto que permite aportar visibilidad y transparencia

El Backlog de Producto es un elemento dinámico que siempre está en evolución. El