Documentos de Académico
Documentos de Profesional
Documentos de Cultura
NCLEO DE ANZOTEGUI
COORDINACIN DE POSTGRADO
MAESTRA EN INFORMTICA GERENCIAL
ASIGNATURA: GERENCIA ESTRATGICA DE PROYECTOS
METODOLOGA SCRUM
FACILITADOR:
Prof. Andrs Martnez
PARTICIPANTES:
Mara Santamara
Angel Espinoza
Abraham Morales
NDICE GENERAL
0
1. Introduccin
______________________________________________________________2 1.1
Principales caractersticas
________________________________________________ 2 1.2 Principales
elementos de la metodologa____________________________________ 2 1.3
Esquema general _______________________________________________________
3
2. Herramientas y Practicas
____________________________________________________5 2.1 Product
Backlog List ___________________________________________________5 2.2
Sprints _______________________________________________________________ 5
2.3 Reunin diaria de sincronizacin del equipo (Scrum Daily
Meeting)_____________6
2.4 Demostracin de los requisitos completados (Sprint
Review)____________________7
2.5 Retrospectiva (Sprint
Retrospective)________________________________________8
3. 2.3 Burn down Chart
_______________________________________________________ 6 2.4 Sprint
Backlog_________________________________________________________ 7 2.5
Stabilization Sprints _____________________________________________________
7 2.6 Scrum of Scrums o
MetaScrum____________________________________________ 7
4. El Proceso
________________________________________________________________8 3.1
Pregame Phase ________________________________________________________
9 3.2 Development
Phase____________________________________________________10
5. Roles y
Responsabilidades__________________________________________________11
4.1 Scrum Master
_________________________________________________________11 4.2 Product
Owner ________________________________________________________11 4.3
Scrum Team__________________________________________________________11
4.4 Customer
____________________________________________________________11 4.5
Management _________________________________________________________11
6. Visin General del
Modelo_________________________________________________12
7. Conclusion__________________________________________________________17
8. Bibliografas
_____________________________________________________________13
1. INTRODUCCION
Scrum es una metodologa de desarrollo muy simple, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en la adaptacin
continua a las circunstancias de la evolucin del proyecto. Scrum es una
metodologa gil, y como tal: Es un modo de desarrollo de carcter adaptable
ms que predictivo. Orientado a las personas ms que a los procesos. Emplea
la estructura de desarrollo gil: incremental basada en iteraciones y revisiones.
Se comienza con la visin general del producto, especificando y dando
detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo
y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de
30 das).
Cada uno de estos periodos de desarrollo es una iteracin que finaliza con la
produccin de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su
evolucin a travs de reuniones breves diarias en las que todo el equipo revisa
el trabajo realizado el da anterior y el previsto para el da siguiente.
El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por
ser muy adaptable.
1.1
Principales caractersticas
Equipos autodirigidos
Utiliza reglas para crear un entorno gil de administracin de proyectos
No prescribe prcticas especficas de ingeniera
Los requerimientos se capturan como tems de la lista Product Backlog
El producto se construye en una serie de Sprints de un mes de duracin
1.2
Herramientas
Product Backlog
Sprint Backlog
Prcticas
Sprints
Sprint Planning Meeting
Daily Meetings
Sprint Review Meeting
Design Review Meeting
Stabilization Sprints
Meta Scrums
Roles y responsabilidades
1.3
Esquema general
2. HERRAMIENTAS Y PRACTICAS
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de eso, especifica
prcticas y herramientas de gerencia que se aplican en sus distintas fases para
evitar el caos originado por la complejidad e imposibilidad de realizar
predicciones.
2.1
2.2
Sprints
pueden colaborar y adaptar sus trabajos para que den el mximo valor y
no realizar tareas que no proporcionan ningn beneficio al resto del
equipo.
Cul es su ritmo de trabajo. Se hace visible si de manera continua un
miembro del equipo est realizando tareas por debajo del rendimiento
esperado. Se evita que una persona seale con el dedo a otra, dado que
la reunin de sincronizacin pone a todos los miembros del equipo en la
misma situacin de tener que explicar en qu tareas estn trabajando.
Cules son los criterios que est utilizando para realizar sus tareas, de
manera que estn alineados con los objetivos comunes del equipo.
Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver
cmo trabajan los otros segn sus especialidades y experiencias.
Conocer el estado de la iteracin, ver si es posible completar los requisitos a
que se comprometi el equipo, en vista de las desviaciones y de las tareas
pendientes.
Restricciones
La reunin diaria de estado y sincronizacin del equipo no es para resolver
problemas, los problemas se resuelven despus de la reunin.
No a todos los miembros del equipo les interesan todos los detalles de
cada tema.
En la reunin los miembros del equipo programan reuniones entre ellos
donde colaborar sincronizando tareas, ayudando a resolver problemas,
etc.
No puede haber una persona explicando su estado mientras otras "se
han apartado" de la reunin para comentar un tema particular. Si
apareciese alguna conversacin de inters comn (que debe ser rpida),
debe poder ser escuchada por todo el equipo sin distraer el principal
objetivo de que todos conozcan en qu estn trabajando los dems. Si
la mini conversacin no es del inters de todos, debe hacerse despus
de la reunin.
El equipo debe contar con unos criterios consensuados sobre el proceso de
ejecucin de las de tareas
El proceso de ejecucin de las tareas debe estar consensuado para
evitar que cada reunin sea una exposicin de discrepancias entre los
miembros del equipo.
Recomendaciones
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del
equipo no se relajen ni se extiendan en ms detalles de los necesarios.
9
El cliente puede ver de manera objetiva cmo han sido desarrollados los
requisitos que proporcion, ver si se cumplen sus expectativas, entender
ms qu es lo que necesita y tomar mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los requisitos que
solicit el cliente y ver en qu puntos hay que mejorar la comunicacin entre
ambos.
El equipo se siente ms satisfecho cuando puede ir mostrando los resultados
que va obteniendo. No est meses trabajando sin poder exhibir su obra.
Restricciones
Restricciones
2.6
11
2.7
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los tems de la
Product Backlog List que van a ser implementados en el siguiente Sprint.
Los tems son seleccionados por el Scrum Team, el Scrum Master y el Product
Owner en la Sprint Planning Meeting a partir de la priorizacin de los tems y
los objetivos que se marcaron para ese Sprint. A partir de los objetivos a
cumplir durante el Sprint el Scrum Team determina que tareas debe
desempear para cumplir el objetivo. De esto surge el Sprint Backlog. Es
importante destacar que es el equipo quien se organiza para alcanzar el
objetivo. El Manager no asigna tareas a los individuos y tampoco toma
decisiones por el equipo. El equipo puede agregar nuevas tareas o remover
tareas innecesarias en cualquier momento si lo considera necesario para
cumplir el objetivo. Pero el Sprint Backlog solo puede ser modificado por el
equipo. Las estimaciones se actualizan cada vez que aparece nueva
informacin.
2.8
Stabilization Sprints
12
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo est
metodologa ha sido aplicada en proyectos que involucran ms de 600
personas. Esto ha sido llevado a cabo dividiendo a los accionistas en equipos
de pequeos de hasta 10 personas aproximadamente. Y definiendo
jerrquicamente personas que pertenecen a dos equipos, es decir, adems de
su rol especfico dentro de un equipo tienen el rol de enlace en un equipo
superior.
3 EL PROCESO
Scrum consta de tres fases: Pregame, Development y Postgame.
Planning
Consiste en la definicin del sistema que ser construido. Para esto se crea la
lista Product Backlog a partir del conocimiento que actualmente se tiene del
sistema. En ella se expresan los requerimientos priorizados y a partir de ella se
estima el esfuerzo requerido. La Product Backlog List es actualizada
constantemente con tems nuevos y ms detallados, con estimaciones ms
precisas y cambios en la prioridad de los tems.
Pregame Phase
Descripcin
14
Responsabl
es
Requerid
a/
Opcional
Product Owner
Requerida
Priorizar la Product
Backlog List
Effort Estimation
elementos
Esta actividad se basa en considerar que
elementos tienen ms o menos influencia en
el xito del proyecto en un momento dado;
considerando que los elementos con mayor
prioridad se realizan primero.
Es un proceso iterativo que rene toda la
informacin que haya acerca un elemento
para tener un mayor nivel de precisin en la
estimacin.
Siempre se mide el esfuerzo que falta para
cumplir con el / los objetivos tanto a nivel de
la lista Product Backlog como para el Sprint
Backlog (lo que resta).
En esta instancia se comunica el diseo a los
interesados para revisar el cumplimiento de
los tems especificados en el Product Backlog
Product Owner
Requerida
Product Owner
Requerida
Scrum Team
Requerida
3.7
Development Phase
Nombre de la tarea
Descripcin
Responsables
Qu hiciste ayer?
Qu hars hoy?
15
Requerida/
Opcional
Scrum Master
Customer, User
Management
Product Owner
Scrum Team
Requerida
Scrum Team
Scrum Master
Product Owner
Scrum Team
Requerida
Customers
Management
Product Owner
otros
interesados
Requerida
4 ROLES Y RESPONSABILIDADES
4.6
Scrum Master
Product Owner
Scrum Team
Es el equipo del proyecto que tiene la autoridad para decidir como organizarse
para cumplir con los objetivos de un Sprint. Sus tareas son: Effort Estimation
(Estimar Esfuerzo), crear el Sprint Backlog, revisar la Product Backlog List y
sugerir obstculos que deban ser removidos para cumplir con los items que
aparecen.
Tpicamente es un equipo de entre 5 y 10 personas cada una especializada en
algn elemento que conforma los objetivos a cumplir, por ejemplo:
Programadores, Diseadores de Interfaz de usuario, etc. La dedicacin de los
miembros del equipo debera ser full-time con algunas excepciones. La
membresa solo puede cambiar entre sprints (no durante).
4.9
Customer
17
18
5 VISIN GENERAL
19
Conclusin
Scrum se basa en el desarrollo incremental de los requisitos del proyecto
en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta
de dos semanas, si as se necesita). La priorizacin de los requisitos por
20
7 BIBLIOGRAFIA
MountainGoatSoftware
http://www.mountaingoatsoftware.com/scrum/index.php
22