Guía de Definición de Proyectos 2022

Lectura Recomendada
Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman, The Essence of Software
Engineering: The SEMAT Kernel. Disponible en:

https://www.ivarjacobson.com/publications/articles/essence-software-engineering-semat-kernel-published-
acmqueue
NOTA: Es suficiente con entender los alphas mencionados en la Figura 1 del artículo.

Product Name
Definir un nombre para el proyecto, el cual también será el nombre del producto que se construya. Piense
en un nombre corto, sin complicaciones de escritura, llamativo e informativo, y ojalá pegajoso.

Brief Description
Dar un breve resumen ejecutivo del proyecto que se propone llevar a cabo. Para redactarlo, piense en
qué le diría a la persona que aprobará los recursos económicos necesarios para desarrollarlo, pero que
espera que usted lo convenza de hacerlo.

Opportunity Alpha
Explicar por qué es deseable desarrollar el sistema que se propone. Qué oportunidad de negocio se está
atendiendo o qué problemática real se está resolviendo con el sistema. Con esta explicación usted
debería poder convencer a cualquier audiencia conocedora del dominio de la aplicación. Mencione aquí
aplicaciones ya existentes que compitan con su propuesta y argumente por qué razones su aplicación
sería bien recibida por los interesados.

Stakeholders Alpha
Hacer una lista de personas, grupos de personas, o entidades que podrían ser afectadas o estarían
interesadas en el desarrollo del sistema. De cada stakeholder, describa las razones por las cuales estaría
interesado en, o afectado por, el sistema que se va a desarrollar.

Requirements Alpha
En esta sección se describen las necesidades generales que el sistema cubriría. No importa aquí si el
proyecto las implementará todas o no (recuerden que los proyectos ágiles usualmente no tienen
predefinido un alcance preciso). La descripción de estas funcionalidades mayores puede ser general y de
granularidad gruesa, inicialmente. Sin embargo, para poder realizar un Sprint Planning se debe disponer
de un conjunto de User Stories que describen actividades del usuario con un nivel de granularidad fina.

Una User Story describe una actividad concreta que un usuario quiere hacer con nuestro sistema. Debe
estar redactada en el lenguaje del usuario y del dominio de aplicación (evite términos técnicos que no
entenderían los usuarios). En contraposición, los términos epic y theme se usan para funcionalidades
gruesas. Es decir, se refieren a bloques grandes de funcionalidad en el sistema pretendido.

El formato más simple para una historias de usuario es el siguiente:

Título: Pagos online

Descripción: como cliente quiero pagar en línea la factura mensual, de tal manera que no
tendré que imprimir recibos, ni ir al banco, ni manejar efectivo. Además, podré usar diversos
medios de pago: PayPal, PSE o tarjeta de crédito.
Tamaño: 8
Prioridad: 2

El título sirve para referirse a la historia de usuario de manera rápida y precisa, por lo que debe ser corto y
descriptivo. La descripción debe explicar a alto nivel lo que a un futuro usuario le gustaría hacer con el
sistema, una vez esta historia esté implementada. Además, debe especificar cuál es el beneficio para ese
usuario (business value). El tamaño es una medida de qué tan grande o compleja de implementar es esa
historia con respecto a las demás historias de usuario especificadas (es un tamaño relativo). Use la
secuencia de Fibonacci, teniendo en cuenta que a las historias más pequeñas se les asignaría tamaños
entre 1 y 5. Si es una historia aún muy gruesa y difícil de estimar (Epic), le debería asignar 13, 21, 100, o
infinito, para reflejar la incertidumbre que aún se tiene acerca de su tamaño y la necesidad de dividirla en
historias más simples. La prioridad es un número entero, entre 1 y 5, donde 1 significa que la historia es
de vital importancia para el cliente, y 5 es la menor importancia posible en la escala.
NOTA IMPORTANTE:
● Los tamaños y las prioridades los pueden dejar en blanco por ahora
● La priorización y la planificación del release se harán posteriormente

Team Alpha
Crear una tabla que resuma la información de los integrantes, con las siguientes columnas: (i) nombre, (ii)
horas/semana de dedicación al proyecto, (iii) rol dentro del proyecto, (iv) habilidades como desarrollador
(experiencia previa, lenguajes y ambientes de desarrollo que maneja, etc.), (v) descripción breve de las
características del computador que usará para trabajar durante el proyecto (marca, Ram, disco, velocidad
del procesador, sistema operativo, etc). Deben llegar a acuerdos muy claros sobre la dedicación en
horas/semana de cada uno de los integrantes.
Way of Working Alpha
Incluir descripciones breves de los siguientes aspectos:

A. Cada uno de los valores y principios ágiles que guiarán el desarrollo del proyecto. Suponemos que
ustedes adoptan el Manifiesto Ágil, así que no es necesario referirse a esos principios y valores.
Solo deben describir valores y/o principios adicionales de Scrum o propios del equipo.
B. Herramientas de desarrollo de software a usar. Incluyan las ya previstas como Spring Boot y
Git/GitHub.
C. Herramientas de comunicación, administración y tracking a usar. Para la administración se sugiere
Jira.
D. Periodicidad y tipo de reuniones que realizarán (especificar días y horario de reunión). Las
reuniones de planificación de iteración y retrospectiva, ya están propuestas en el Programa del
curso. Entonces, aquí se recomienda pensar en al menos una reunión adicional a mitad de
iteración que reemplace al Daily Scrum.

Entregable
Subir a Moodle un archivo X.pdf, donde X es el nombre de su proyecto. Las secciones de este
documento son las ya mencionadas arriba.