Entrega de avance Unidad 3 – Mayra Palacios
ALCANCE
01 Preparación de Alcance de Mayra Palacios 23/11/2018
Proyecto
02 Revisión de Alcance y Aprobación Julian Barmat 27/11/2018
NOMBRE DEL PROYECTO
Boda de Juan y Sofía
CÓDIGO DEL PAQUETE DE NOMBRE DEL PAQUETE DE TRABAJO (PDT):
TRABAJO (PDT): SEGÚN EL
SEGÚN EL WBS
WBS
OBJETIVO DEL PAQUETE DE El presente PDT se elabora para poder darle
TRABAJO: un seguimiento y monitoreo programado a la
PARA QUE SE ELABORA EL planificación y ejecución del proyecto
PDT. denominado “Boda de Juan y Sofía”
DESCRIPCIÓN DEL Se planificará y ejecutará la boda de Juan y
PAQUETE DE TRABAJO: Sofía, todo la organización de su boda civil y
QUÉ CONTIENE, EN QUÉ religiosa, y las recepciones (fiestas) de
ambas.
CONSISTE, CÓMO ES,
DIMENSIONES, COTAS, ETC. También se negociará el paquete de luna de
miel y boletos aéreos.
DESCRIPCIÓN DEL TRABAJO - Diseñar y elaborar invitaciones
A REALIZAR (ACTIVIDADES):
- Selección de ropa para ambos novios para
CÓMO SE VA A ELABORAR todos los eventos
EL PDT.
- Lunch de la ceremonia civil
- Fiesta del civil
- Ceremonia religiosa
- Lunch o comida de la fiesta religiosa
- Fiesta de la religiosa
Participa: Juan y Sofía
Aprueba: Julian Barmat
Da información: Mayra Palacios
FECHAS PROGRAMADAS: Inicio: 12/11/2018 Elaboración del Acta de
Constitución
CUÁNDO SE VA A ELABORAR
EL PDT. PDT: 26/11/2018
Fin: Octubre/2019
CRITERIOS DE Stakeholder que acepta: Julian Barmat
ACEPTACIÓN: Evaluación de planificación, monitoreo y
QUIÉN, Y CÓMO SE DARÁ ejecución.
POR VALIDO Y ACEPTADO EL
PDT.
Requisitos que deben cumplirse: a Conformidad
de los novios
Forma en que se aceptará: Firma de ambos
novios
RIESGOS: EVENTOS CUYA - Fecha de ceremonia religiosa
OCURRENCIA IMPACTARÁ
- Disponibilidad en local
LOS OBJETIVOS DEL
ALCANCE, TIEMPO, COSTO, - Clima
O CALIDAD, DEL PDT.
DEPENDENCIAS: QUÉ Antes del pdt: el acta de constitución del
PRECEDENTE Y proyecto
SUBSECUENTE TIENE EL
PDT.
Después del pdt: backlog que puede ser
mensual o bimensual
Se elegirá trabajar con el Método Iteractivo e incremental, porque se puede gestionar las
expectativas del cliente (requisitos desarrollados, velocidad de desarrollo, calidad) de
manera regular, puede tomar decisiones en cada iteración. Esto es especialmente interesante
cuando:
El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo conforme va viendo cuales
son los resultados del proyecto.
El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya
realizados) por:
Cambios en las condiciones del mercado (por un cambio de necesidades, por un nuevo
producto que ha lanzado la competencia, urgencias).
La reacción y aceptación del mercado respecto al uso de los primeros resultados del
proyecto.
Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto
manteniendo como mínimo los resultados alcanzados hasta ese momento.
El equipo necesita saber si lo que ha entendido es lo que el cliente espera.
El cliente puede comenzar el proyecto con requisitos de alto nivel, quizás no del todo completos, de
manera que se vayan refinando en sucesivas iteraciones. Sólo es necesario conocer con más detalle
los requisitos de las primeras iteraciones, los que más valor aportan. No es necesario realizar una
recolección completa y detallada de todos los requisitos antes de empezar el desarrollo del
proyecto.
El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones.
El cliente como máximo puede perder los recursos dedicados a una iteración, no los de todo el
proyecto.
La finalización de cada iteración es el lugar natural donde el equipo puede decidir cómo mejorar su
proceso de trabajo, en función de la experiencia obtenida. Con esta información ya es
posible planificar los cambios necesarios para aumentar la productividad y calidad desde las
primeras iteraciones. Ver Retrospectiva.
Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si
sufinalización es viable en la fecha prevista. El cliente puede decidir repriorizar los requisitos del
proyecto, añadir nuevos equipos, cancelarlo, etc.
Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteración el equipo tiene
que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes
estos riesgos, es posible iniciar su mitigación de manera anticipada.
Permite gestionar la complejidad del proyecto.
Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones.
Dado que cada iteración debe dar como resultado requisitos terminados, se minimiza el número de
errores que se producen en el desarrollo y se aumentar la calidad.
