¿Cuándo se ¿Quién

Concepto ¿Qué se hace?

hace? interviene?
Procesos de software Al Un conjunto de Todo el
comie actividades para equipo de
nzo desarrollar un Desarrollo
sistema de software, y el
en las cuales ScrumMas
intervienen: mano de ter.
obra, materiales, Personalm
energía, ente
equipamiento, también
métodos es
recomend
able la
participaci
ón del
Product
Owner. En
el caso de
que se
requiere
la
participaci
ón de
stakehold
ers o
gerentes,
estos
también
podrán
ser
convocado
s
Proceso unificado rational Describe las
buenas
prácticas de
ingeniería de
software que
se
recomiendan
para su uso en
 el desarrollo
de sistemas
Planeación del bosquejo y diseño Al Se establecen Scrum
arquitectónico. comie los objetivos Master y
nzo generales del deben
proyecto y el asistir el
diseño de la propietari
arquitectura o del
de software, producto
define el y el
backlog y los equipo
criterios de completo,
aceptación y a la que
también
pueden
asistir
otros
implicados
en el
proyecto.
Planificación sprint Luego Revisión de lo Scrum
de sucedido Master
definir durante el (moderad
el Sprint. or) e
backlog Reunión en la integrante
y que el equipo s del
prioriza analiza equipo
rlo se aspectos
define operativos de
el la forma de
Sprint trabajo y crea
un plan de
mejoras para
aplicar en el
próximo
sprint
Daily Recome Se le Scrum
ndable pregunta al Master
mente equipo ¿Qué (moderad
todos hice ayer? or) e
los días. ¿Qué voy a integrante
hacer hoy? s del
 ¿Qué equipo
impedimento
s tengo?
Sprint demo Al final Testing Equipo y
de cada los
Sprint Stakehold
ers revisan
el
resultado
del Sprint.
Cuando
decimos
“resultado
”
hablamos
de
“producto
utilizable”
y
“potencial
mente e
entregable
”
Retrospectiva Al final Equipo y los Todo el
de la Stakeholders equipo de
revisión revisan el Desarrollo
de cada resultado del y el
Sprint Sprint. ScrumMas
demo Cuando ter.
decimos Personalm
“resultado” ente
hablamos de también
“producto es
utilizable” y recomend
“potencialme able la
nte e participaci
entregable” ón del
Product
Owner. En
el caso de
que se
requiere
la
 participaci
ón de
stakehold
ers o
gerentes,
estos
también
podrán ser
convocado
s

 Al comienzo.

 Se establecen los objetivos generales del proyecto y el diseño de la arquitectura de

software, define el backlog y los criterios de aceptación.

 Product Owner.

 Casos de prueba.

 Testing.

 Luego de definir el backlog y priorizarlo se define el Sprint.

 Se toman como base las prioridades y necesidades de negocio del cliente, y se determinan
cuáles y cómo van a ser las funcionalidades que se incorporarán al producto en el siguiente
sprint.

 Scrum Master y deben asistir el propietario del producto y el equipo completo, y a la que
también pueden asistir otros implicados en el proyecto.

 Recomendablemente todos los días.

 Se le pregunta al equipo ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Qué impedimentos
tengo?

 Scrum Master (moderador) e integrantes del equipo.

 Al final de cada Sprint.

 Análisis e inspección del incremento generado y adaptación de la pila del producto si
resulta necesario.

 Equipo y los Stakeholders revisan el resultado del Sprint. Cuando decimos “resultado”
hablamos de “producto utilizable” y “potencialmente e entregable”.

 Al final de la revisión de cada Sprint demo.

 Revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos

operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo
sprint.

 Todo el equipo de Desarrollo y el ScrumMaster. Personalmente también es

recomendable la participación del Product Owner. En el caso de que se requiere la
participación de stakeholders o gerentes, estos también podrán ser convocados.

 Un conjunto de actividades para desarrollar un sistema de software, en las cuales

intervienen: mano de obra, materiales, energía, equipamiento, métodos.

 Describe las buenas prácticas de ingeniería de software que se recomiendan para su uso
en el desarrollo de sistemas.