PDF de programación - SCRUM development process

SCRUM development process



Ing. Natalia G. Caso

Universidad Tecnol(cid:243)gica Nacional
Facultad Regional Buenos Aires

Septiembre 2004

[email protected]





1. INTRODUCCI(cid:211)N

Las metodolog(cid:237)as tradicionales para el
desarrollo de software imponen un
proceso definido. Sin embargo, un gran
nœmero de procesos de desarrollo no
estÆn completamente definidos, aunque
se los trata como si lo estuvieran.
SCRUM proporciona una metodolog(cid:237)a
que trata a estos procesos como una
caja negra controlada aplicando
mecanismos
su
control.

apropiados

para

2. DEFINICI(cid:211)N

SCRUM es una metodolog(cid:237)a para
gesti(cid:243)n, mejora y mantenimiento de un
sistema nuevo o existente.
SCRUM se concentra en como los
miembros del equipo deber(cid:237)an
funcionar a fin de producir un sistema
flexible en un entorno que cambia
constantemente.

Permite a los equipos de desarrollo
adaptarse dentro de un ambiente
complejo utilizando procesos
imprecisos.

El origen de la palabra SCRUM
procede del rugby: acto de preparar el
avance del equipo en unidad pasando
la pelota a uno y otro jugador. Igual
que el juego, SCRUM es adaptativo,
Ægil, auto-organizante y con pocos
tiempos muertos.

3. CARACTER˝STICAS

















PÆgina 1 de 9

 Emp(cid:237)rico

Iterativo
 Flexible
 Equipos auto-organizativos

Los requerimientos se capturan como
(cid:237)tems en un listado (product backlog)

SCRUM considera que el proceso del
desarrollo de software involucra muchas
variables de entorno y tØcnicas tales como:
requerimientos, tiempo, recursos, costo,
competencia, calidad y tecnolog(cid:237)a. Es
probable que todas ellas cambien durante
el proceso.





El entregable se determina durante el
proyecto basÆndose en el entorno.

SCRUM utiliza tØcnicas de orientaci(cid:243)n a
objetos para la construcci(cid:243)n de los
entregables.

Los proyectos SCRUM pueden estimarse
empleando el mØtodo de function points.
Sin embargo, la estimaci(cid:243)n sirve solo
para el comienzo, debido a que el tiempo
y el costo son determinados
dinÆmicamente en respuesta a factores del
entorno.

4. ORIGEN

SCRUM fue desarrollada por Ken
Schwaber (Advanced Development
Methods), Jeff Sutherland y Mike Beedle.

Como metodolog(cid:237)a Ægil espec(cid:237)ficamente
referida a ingenier(cid:237)a de software, SCRUM
fue aplicado por Jeff Sutherland y
elaborado mÆs formalmente por Ken

Schwaber. Poco despuØs Sutherland y
Schwaber se unieron para refinar y
extender SCRUM.


En SCRUM se aplicaron principios de



procesos de control industrial, junto
con experiencias metodol(cid:243)gicas de
Microsoft, Borland y Hewlett-Packard.
Schwaber, en particular, hab(cid:237)a
trabajado con cient(cid:237)ficos de Du Pont
para comprender mejor los procesos
definidos de antemano, y notaron que a
pesar que CMM se concentraba en
hacer que los procesos de desarrollo se
tornaran repetibles, definidos y
predecibles, muchos de ellos eran
formalmente impredecibles e
irrepetibles porque cuando se estÆ
planificando no hay primeros
principios aplicables, los procesos
reciØn comienzan a ser
comprendidos y son complejos por
naturaleza. Schwaber se dio cuenta
entonces de que un proceso necesita
aceptar el cambio, en lugar de
esperar predictibilidad.



5. DIFERENCIA CON OTRAS

METODOLOG˝AS


Comparaci(cid:243)n con el mØtodo iterativo:

SCRUM asume que todos los
requerimientos no se conocen en
profundidad y que el camino mÆs
rÆpido para explorarlos e
implementarlos serÆ descubierto
emp(cid:237)ricamente durante el proceso de
desarrollo.

Comparaci(cid:243)n con metodolog(cid:237)as
(cid:147)Waterfall(cid:148) y espiral:

Las metodolog(cid:237)as (cid:147)Waterfall(cid:148) y
(cid:147)Espiral(cid:148) establecen el contexto y la
definici(cid:243)n de los entregables al
comienzo del proyecto. En cambio,
SCRUM y las metodolog(cid:237)as iterativas
inicialmente plantean el contexto y una









definici(cid:243)n global de entregables y luego
el entregable irÆ evolucionando durante
el proyecto en base al entorno. SCRUM
confirma que la definici(cid:243)n de los procesos
de desarrollo no estÆn completamente
definidos y utiliza mecanismos de control
para mejorar la flexibilidad.

Comparaci(cid:243)n con CMM:

Los procesos de CMM tales como testing
e inspecciones pueden ser utilizados en
proyectos que utilizan SCRUM, pero la
diferencia radica en que los mismos se
utilizarÆn (cid:147)on demand(cid:148); si el equipo
siente que no se necesitan, no se utilizan.

6. PROCESO SCRUM

El proceso de SCRUM se divide en 3
grandes etapas:



Inicio
DEFINIDO

Desarrollo
EMP˝RICO

Cierre
DEFINIDO



Fig. 1 (cid:150)Etapas de SCRUM

SCRUM trata la fase de desarrollo como
una caja negra que requiere controles
externos. Los controles se ponen en cada
iteraci(cid:243)n de la fase de desarrollo para
evitar el caos y a su vez maximizar la
flexibilidad.

El proyecto estÆ abierto al entorno
hasta la fase de cierre. El entregable
puede ser cambiado en cualquier momento
durante las fases de inicio y desarrollo del
proyecto.

Inicio (Pregame)

Esta etapa estÆ conformada por dos
subetapas:


 Planeamiento: Consiste en

establecer la visi(cid:243)n, el presupuesto,
forma de financiamiento y el
backlog del producto. En esta fase

PÆgina 2 de 9

se selecciona que funcionalidad
es la mÆs apropiada para
desarrollo inmediato. TambiØn
se establece el equipo de
trabajo, se evalœan las
herramientas de desarrollo y se
define la fecha de entrega (es
una fecha aproximada).

 Arquitectura:

Esta fase consiste en la
conceptualizaci(cid:243)n y anÆlisis. Si
el proyecto se trata de la mejora
de un nuevo sistema, s(cid:243)lo se
realiza un anÆlisis limitado.
Se realiza un diseæo de alto
nivel para actualizar los
modelos del dominio y reflejar
el contexto del nuevo sistema y
los requerimientos y las
modificaciones necesarias de la
arquitectura del sistema. Los
diseæadores y arquitectos
dividen el proyecto en paquetes
basÆndose en los (cid:237)tems del
backlog. En la jerga de
SCRUM se llaman (cid:147)paquetes(cid:148)
a los objetos o componentes
que necesitan cambiarse en
cada iteraci(cid:243)n.



Desarrollo (Game)

En esta etapa se realiza el desarrollo
propiamente dicho. TambiØn se la
conoce como (cid:147)Ingenier(cid:237)a concurrente(cid:148).
La misma se divide en iteraciones que
proveen como resultado
funcionalidades incrementales al fin de
cada una de ellas. Dichas iteraciones se
llaman sprints.

Un sprint es el proceso de adaptaci(cid:243)n a
las variables que cambian con el
entorno.

Un sprint dura aproximadamente entre
una semana y 30 d(cid:237)as. Cada sprint
incluye las fases tradicionales del
desarrollo de software:

requerimientos, anÆlisis, diseæo, desarrollo
y entrega.

Los riesgos son evaluados continuamente
y se establecen mecanismos de control
adecuados.

Durante un sprint no se utilizan
diagramas de gantt para seguimiento de
tareas (estos parten del supuesto que las
tareas de un proyecto se pueden identificar
y ordenar), debido a que el desarrollo es
semi-ca(cid:243)tico y cambiante como para que
se le aplique un proceso definido.

Durante un sprint no se pueden
cambiar los miembros del equipo
scrum. Tampoco pueden introducirse
cambios durante un sprint (si surge
algun cambio se incluirÆ en el backlog del
producto, pero no en el del sprint).

El scrum master mantiene el sprint
backlog. Actualiza las tareas finalizadas y
para las que no lo estÆn, el tiempo que el
equipo piensa que tomarÆ para terminarlas.

En cada sprint se realizan las siguientes
actividades:


 Planeamiento

Consiste en una reuni(cid:243)n de
planeamiento. (cid:201)sta comprende dos
fases. La primera consiste en
decidir los objetivos y la
funcionalidad a incluir en el
sprint. La segunda consiste en
establecer como Østa funcionalidad
se implementa durante el sprint.

El product owner establece
prioridades entre los (cid:237)tems del
product backlog y el equipo scrum
determina cuales son las tareas que
pueden completar durante el sprint
partiendo de las que tienen mÆs
prioridad.

Se realizan estimaciones de los
(cid:237)tems del product backlog, pero

PÆgina 3 de 9

estas estimaciones solo sirven
para asignar items al sprint.
Durante el sprint el equipo
volverÆ a estimar los (cid:237)tems
del sprint backlog.

Para cada sprint se establecerÆn
que funcionalidades del product
backlog definido inicialmente
se van a implementar. Ese
conjunto de funcionalidades
conformarÆn el (cid:147)sprint
backlog(cid:148).


 Desarrollo

Consiste en definir los cambios
para la implementaci(cid:243)n de los
requerimientos del backlog en
los paquetes, abrir dichos
paquetes: realizar anÆlisis,
diseæo, desarrollo,
implementaci(cid:243)n, testeo y
documentaci(cid:243)n de los cambios.


 Envoltura (Wrap)

Consiste en cerrar los paquetes:
creaci(cid:243)n de una versi(cid:243)n
ejecutable de los cambios y
establecer como Østa
implementa los requerimientos
del backlog.


 Revisi(cid:243)n

Consiste en realizar una
reuni(cid:243)n de revisi(cid:243)n para
presentar el trabajo y resoluci(cid:243)n
de problemas emergentes. Se
revisan los riesgos y se definen
las respuestas apropiadas.






 Ajuste

Consiste en consolidar la
informaci(cid:243)n recolectada de la
revisi(cid:243)n en los paquetes afectados,
esto incluye nuevas propiedades y
nuevo look & feel.


Reuniones Scrum:

Durante un sprint, todos los d(cid:237)as se
realizan reuniones llamadas (cid:147)SCRUM(cid:148).
El objetivo de las mismas es quitar los
impedimentos que le surgen a los
miembros del equipo scrum.

Cada una de ellas dura aproximad