Ingeniera de Requerimientos y
metodologas giles. SCRUM
Ing. Alice Rambo
Indice
Planificacin de la jornada
Introduccin a las metodologas agiles
Requerimientos
Procesos
Relato de un caso de aplicacin
Presentacin de un video
Instancia de trabajo grupal. Actividad 1
Receso
Planteo de la Actividad 2
Devolucin Final
Historia
Depende del tipo de proyecto
proyecto con valor para el usuario mas que para seguir
una planificacin, es cuando los requisitos o ambientes
soncambiantes, ejemplo mercado cambiante el cambio es
algo necesario, adaptarse es mas importante que predecir
el proyecto.
Scrum empez en el ao 94 lleva ya 15 aos
Manifiesto gil ao 2001
Cuatro puntos aplicaciones sw o cualquier tipo de proyecto
con cambios
1. individuos e interacciones mas importante que procesos y
herramientas. ejemplo en comidas rpidas es mas importante
el proceso que el personal, la gente se cambia y el proceso se
mantiene en un restaurante de cocina especifica es mas
importante la gente y el producto tiene requerimientos mas
especficos.
2. software que funciona mas importante que documentacin
exhaustiva
3. colaboracin con el cliente sobre negociacin de contratos
4. responder ante el cambio sobre seguimiento de un plan va a
haber cambio, el cambio es bueno y se debe vivir con ello
Principios y valores agiles
prioridad mayor satisfaccin del cliente haciendo entregas
continua de software valioso para l
los cambios son bienvenidos siempre
la medida principal del progreso es el software
funcionando
el gestor es un facilitador no un controlador
equipos auto-organizados y multidisciplinarios
inspeccionar y adaptar
mejora continua
respeto, claridad y comunicacin
ritmo sostenible
la arquitectura y diseo emergen
Introduccin Metodologas giles
Cuando urge presentar un producto de software, se recurren
a metodologas de desarrollo que hacen hincapi en el
resultado, en detrimento de por ejemplo la documentacin.
Los ciclos de desarrollo son realmente cortos, de bajo costo e
implementacin inmediata.
Scrum es una metodologa gil, se aplica al desarrollo de
software cuando su utilizacin lo amerita. Su implementacin
es realizada por un grupo pequeo de profesionales, no ms
de 8.
El equipo responde a una estructura, con un Coordinador
General, y los dems integrantes entre los cuales se encuentra
el mismo cliente y el usuario final, interactan con un alto nivel
de comunicacin.
Se definen acciones en base a metas especficas dadas por la
visin del Cliente y/o Usuario Final.
Introduccin Qu es SCRUM ?
Requerimientos de Scrum
Los requisitos del sistema a nivel formal se definen al
inicio del proyecto, siendo el product backlog el
documento que evoluciona durante todo el desarrollo.
Los requisitos del sistema los desarrolla un equipo
especializado en ingeniera de requisitos a travs del
proceso de elicitacin con el cliente. En Scrum la visin
del cliente es conocida por todo el equipo y el product
backlog se realiza y evoluciona de forma contnua con
aportes de todo el equipo.
La pila de producto
La pila de producto es el corazn de Scrum. Es donde empieza todo. La Pila de Producto es, bsicamente,
una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere,
descritas usando la terminologa del cliente. Llamamos a esto historias, o a veces simplemente elementos de
la Pila.
Ciclo de Vida del Sprint
Procesos Planificacin del Sprint.
Exposicin de prioridades.
Resolucin de dudas.
Objetivo del Sprint.
Estimacin del esfuerzo
para cada requisito.
PP: Propietario del Producto.
SM: Scrum Master. Product Backlog / Pila del Producto
E: Miembro del Equipo.
Velocidad
determina cual es el numero de cosas o el esfuerzo que puede realizar el
equipo durante esas semanas
no es el jefe del proyecto, es el equipo el que estima
el equipo evala la velocidad de acuerdo a sus capacidades.
cuantas historias de usuario, cuanto trabajo puedo llevar a cabo
Depende del numero de personas en el equipo, experiencia aptitudes y
habilidades, de la historia del equipo
como se mide: en horas, en historia de usuarios, en actividades
la estimacin mejora al avanzar el proyecto y el conocimiento del producto
se puede tener un sprint cero de prueba para aprender a estimar y
preparar al equipo, pero los tres primeros sprint sirven para estimar
realmente velocidad real del equipo de acuerdo a sus capacidades.
incorporar personas por lo general atrasa el proyecto.
estimacin mtodo de las cartas
Burn-Down-Chart
cuanto hicimos, cuanto nos falta
lneas que se cruzan
el sprint burn down chart que son las tareas realizadas y las faltantes
si las pendientes se vuelven mesetas representan problemas
otra grafica es la que se actualiza al final de cada sprint y es la grafica de la
pila de productos que debera ir bajando (salvo que se incorporen tareas)
pongo la historia, la descompongo en tareas y las tareas se pasan de
pendientes a realizadas
cuando hay tareas transversales como requisitos no funcionales u
organizacionales, generalmente se incorporan criterios en cada historia que
generan tareas dentro de cada historia (tambin puede crearse una historia
ficticia)
Burn-Down-Chart
Procesos Reunin diaria y Revisin
Reunin diaria.
Revisin del trabajo,
resolucin de trabas.
Presentacin del
incremento,
sugerencias, anuncio
del prximo sprint.
Planificacin del prximo Sprint
Pila del Sprint Sprint
PP: Propietario del Producto.
SM: Scrum Master.
E: Miembro del Equipo. Reunin Diaria
I: Stakeholders Incremento del Producto
Ciclo de Vida del Sprint
Planificacin del Sprint
El Propietario del Producto prioriza
el Product Backlog y lo presenta al
equipo.
El trabajo es seleccionado de la
parte superior de la pila de
prioridad.
El Equipo selecciona aquello que
podr cumplir durante el sprint.
El PP podr redefinir el Product
Backlog.
El equipo recibe informacin
detallada de distintas fuentes.
Los elementos seleccionados se
desglosan en tareas a cumplirse
en el sprint.
Reunin diaria del Equipo
El Equipo se rene diariamente, no
ms de 15 minutos.
Sincronizan el progreso del trabajo,
se informan las trabas con las que
podran encontrarse.
Se previenen la duplicacin de
esfuerzos.
Alimenta la dinmica del equipo y
su espritu. Mejora la productividad
ante la presin de informar
diariamente de los progresos.
Los objetivos claros y la direccin
son compartidas por todo el
equipo.
Se responden bsicamente a: Qu
hice, que har y que problemas
puedo tener con lo que voy a
hacer.
Incremento del producto
Al final de cada Sprint, el equipo
debera emitir un incremento de la
calidad del Producto.
Este incremento es lo que se le
muestra a las partes interesadas,
usuarios finales para su
aprobacin.
En esta etapa el equipo debe
encontrar posibles errores en el
cdigo, cuyas modificaciones
podrn formar parte de sucesivos
Sprint.
El versionado se produce cuando
el PP aprueba el incremento.
Revisin del Sprint
La revisin del Sprint, provee la
posibilidad de dar cuenta de los
avances del proyecto al finalizar el
Sprint.
Durante la revisin, el Equipo
presenta las funcionalidades,
responde preguntas a las partes
interesadas acerca de estas
explicaciones, y toma de nota de
los cambios sugeridos.
El PP analiza con las partes
interesadas y los miembros del
Equipo potenciales cambios al
Product Backlog.
Se identifican nuevas
funcionalidades que se incorporan
al product backlog y lo prioriza el
dueo del producto
Retrospectiva del Sprint
Es una reunin propuesta por el
Scrum Master con el Equipo.
Se analizan las conclusiones del
Sprint, en la que se determina que
cambios podras realizarse. En
esta etapa se discute cmo
realizar estos cambios en prximos
Sprint.
Esta etapa permite al Equipo
evolucionar contnuamente durante
la vida de un proyecto. Es un
proceso de colaboracin entre el
PP, el Scrum Master y el Equipo.
Los miembros del Equipo
identifican qu ha ido bien y qu
puede mejorarse.
Update del Product Backlog
El Product Backlog es un
documento dinmico, vivo.
Su contenido puede cambiar
durante la vida del Proyecto, por
distintas cuestiones, por ejemplo
debido a mejoras detectadas por
las partes interesadas y el PP.
La gestin del Product Backlog lo
hace el PP durante todo el
Proyecto.
Etapa en la cual se producen
acomodamientos en la pila del
Product Backlog. Se disparan
ajustes en las prioridades, a tener
en cuenta en los futuros Sprint.
Problemas del Sprint
problemas en el sprint planning
ausencia del dueo el producto o poca colaboracin del
mismo, o no da las prioridades correctamente
Se debe poder responder al cambio.
el scrum master o el dueo del producto puede
cuestionar las estimaciones del equipo.
el scrum master quiere indicar quien debe hacer las
tareas o cuando se deben cumplir, el equipo debe
autogestionarse solo
el dueo del producto no tiene en cuenta la velocidad del
equipo.
direccin y control vs equipos autorganizados
Muchas gracias !!!
Bibliografa
Agile Project Manegement with Scrum. Ken Scwaber. Microsoft Press.
Agile Software Development with Scrum. Ken Scwaber. Prentice Hall 2002
SoManifiesto de desarrollo gil. [Link]
Experiencia-Implantacion-CMMI-DEV-v1-2-metodologias-agiles-y-software-libre. Jos Manuel Navarro.
Kybele Consulting y Universidad Rey Juan Carlos.
Actas de 1a Conferencia Agile-Spain CAS 2010. Agustn Yage Panadero. Juan Garbajosa Sopea. Jnnifer
Prez Benedi . Pedro Pablo Alarcn Cavero.
IMPLANTACIN DE LAS NORMAS ISO/IEC 15504 E ISO/IEC 12207 CON MTODOS GILES Y SCRUM
M Carmen Garca, Emanuel Irrazabal y Javier Garzs
SCRUM Y XP DESDE LAS TRINCHERAS. Cmo hacemos Scrum. Henrik Kniberg. Prlogos de Jeff
Sutherland y Mike Cohn.
Flexibilidad con Scrum - Jorge Serrano
ScrumManager . Manual. Juan Palacio.
Explicando Scrum a mi abuela - Jorge Serrano - MVP Visual Developer
[Link] Ultima visita: 2008/10/15
[Link] . Ultima visita: 15/11/2008
[Link] ultima visita: 03/12/2008
[Link] behind the Agile [Link] ultima visita: 15/11/2008
[Link] for Agile Software [Link] ultima visita 15/11/2008
