MTODO GIL SCRUM APLICADO AL DESARROLLO DE UNA PAGINA

WEB DE UNA FLORISTERIA

JEAN CARLOS ALTAMAR ESTRADA

DILAM ALBERTO FREYLE LLAMAS
ANDRS BLANCO

PROFESOR
MARTIN DIAZ
INGENIERO DE SISTEMAS

CORPORACIN UNIVERSITARIA AMERICANA

FACULTAD DE INGENIERAS
TECNICA PROFESIONAL EN PROGRAMACIN DE COMPUTADORES
BARRANQUILLA
2016

INDICE

INTRODUCCIN

------------------------------------------------------------------------------------------------3
PRIMERA PARTE: MARCO TERICO
1. MTODOS GILES---------------------------------------------------------------- 9
1.1.

INTRODUCCIN--------------------------------------------------------------------- 9

1.1.1.
1.1.2.

1.2.

QU ES UNA METODOLOGA GIL?------------------------------------- 10

1.2.1.
1.2.2.
1.2.3.

2.

El dilema del software----------------------------------------------------------------------9

El surgimiento de la agilidad------------------------------------------------------------10
La Alianza gil------------------------------------------------------------------------------11
El Manifiesto gil---------------------------------------------------------------------------12
Metodologas giles vs. tradicionales------------------------------------------------ 16

SCRUM------------------------------------------------------------------------------ 19
2.1.

INTRODUCCIN------------------------------------------------------------------- 19

2.2.

LA ESENCIA DE SCRUM-------------------------------------------------------- 20

2.3.

ELEMENTOS DE SCRUM------------------------------------------------------- 21

2.3.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.

Roles------------------------------------------------------------------------------------------ 22
Poda de requerimientos------------------------------------------------------------------25
Product Backlog----------------------------------------------------------------------------25
Sprint------------------------------------------------------------------------------------------26
Valores----------------------------------------------------------------------------------------35

SEGUNDA PARTE: METODOLOGA

3.

PROCESO DE DESARROLLO----------------------------------------------- 38
3.1.

INTRODUCCIN------------------------------------------------------------------- 38

3.2.

PROCESO ITERATIVO E INCREMENTAL---------------------------------- 38

3.3.

ETAPAS DEL PROCESO DE DESARROLLO------------------------------ 40

3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.

Planificacin---------------------------------------------------------------------------------40
Anlisis----------------------------------------------------------------------------------------40
Diseo-----------------------------------------------------------------------------------------41
Construccin y Prueba------------------------------------------------------------------- 41
Implementacin-----------------------------------------------------------------------------42

3.4.

EDT DEL PROCESO DE DESARROLLO----------------------------------- 43

3.5.

HERRAMIENTAS------------------------------------------------------------------- 44

3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.5.5.
3.5.6.
3.5.7.

Tcnicas de relevamiento--------------------------------------------------------------- 44
Work Breakdown Structure (WBS)---------------------------------------------------- 44
Casos de uso------------------------------------------------------------------------------- 44
Diagrama de actividades-----------------------------------------------------------------45
Diagrama de Entidad Relacin (DER)------------------------------------------------45
ScrumWorks---------------------------------------------------------------------------------46
Burndown chart-----------------------------------------------------------------------------47
3.5.8. Clarion 5.5-----------------------------------------------------------------------------------47

INTRODUCCIN
En la actualidad la tecnologa, marca de una manera trascendental en el
mercado ante los competidores que evolucionan con el entorno, facilitando
el acceso de los productos a los clientes con equipos de cmputos y
soluciones digitales que contribuyen, a la implementacin de estrategias
para el fcil desarrollo de la actividad comercial.

Este Proyecto tiene como meta, implementar una solucin de acuerdo a la

necesidad requerida por las polticas del negocio, saliendo del esquema
tradicional y abordar las limitaciones de interaccin dinmica de los usuarios
y de igual manera

la poca informacin que se tiene de cada producto,

como las ocasiones comunes donde se emplea cada producto, tambin se

considera la informacin econmica detallada por cada servicio requerido
por el usuario.

A raz de este planteo y el corto plazo de implementacin de esta solucin

surge

la inquietud en las metodologas agiles del desarrollo de la pgina

web de la Floristera ABC Ltda.

Se explica a continuacin la manera en la que se ha organizado el Trabajo
Final.
Primera Parte: Marco Terico
Se presenta el contexto en el que surgen las metodologas giles, sus valores,
principios, comparaciones con las metodologas tradicionales y se describe
con detalle Scrum.
Segunda Parte: Metodologa
Se explica el proceso de desarrollo elaborado para complementar Scrum;
etapas definidas y herramientas utilizadas.

PRIMERA PARTE

MARCO TERICO

1. MTODOS GILES

1.1. INTRODUCCIN
1.1.1. El dilema del software
Cualquiera que alguna vez haya sido responsable de conducir un
proyecto de desarrollo de software sabe que no es para nada fcil.
Coordinar y negociar exitosamente con las partes implicadas en el
proyecto desafa al ms experimentado lder.

Y si bien, hoy en da, el software es una parte crtica de todo negocio, an

los proyectos de desarrollo de software sufren de problemas en su gestin
que los pueden llevar directo al fracaso. Los problemas ms frecuentes
son:

No se adaptan a los cambios.

Calidad insuficiente y muy variable.

Proyectos que exceden sus tiempos y costos.

Con base en lo anterior se ha llegado a un acuerdo de lo que significa un

proyecto de software exitoso, en tres dimensiones:
A tiempo.
En presupuesto.
Cumpliendo el alcance definido (incluye adaptabilidad a los
cambios y calidad).

No es novedad que una forma de resolver los problemas de calidad, y

otros, de un producto es mejorando la forma de construir tales productos.
O sea.... mejorando los procesos.

En una actividad humana como es el desarrollo de software, esto es casi

equivalente a mejorar la metodologa que se sigue para construir los
productos.

1.1.2. El surgimiento de la agilidad

Durante el transcurso de los aos 90 el ambiente cambiante y turbulento
era cada vez ms la regla que la excepcin. Por lo tanto surgi la
necesidad de desarrollar metodologas livianas y maniobrables que
pudieran operar en ese ambiente turbulento. Estas metodologas son
conocidas colectivamente hoy en da como metodologas giles.

1.2. QU ES UNA METODOLOGA GIL?

Lo gil se define (por los mismos agilistas) como la habilidad de
responder de forma verstil al cambio para maximizar los beneficios. Las
metodologas giles varan en su forma de responder al cambio, pero en
general comparten las siguientes caractersticas:
Los individuos y sus interacciones son ms importantes que los
procesos y las herramientas.
El software que funciona es ms importante que la documentacin
exhaustiva.

 La colaboracin con el cliente en lugar de la negociacin de

contratos.
La respuesta al cambio en lugar de aferrarse a un plan.

Los valores y principios compartidos por toda la metodologa gil fueron

enunciados en el manifiesto gil, por la alianza gil.

1.2.1. La Alianza gil

En una reunin celebrada en febrero de 2001 en Utha (EEUU), nace el
trmino gil aplicado al desarrollo de software. En esta reunin
participaron un grupo de 17 expertos de la industria del software. Su
objetivo fue esbozar los valores y principios que deban permitir a los
equipos desarrollar software rpidamente y respondiendo a los cambios
que pueden surgir a lo largo del proyecto. Se pretenda ofrecer una
alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se
genera en cada una de las actividades desarrolladas.

Tras esta reunin se cre The Alliance, una organizacin dedicada a

promover los conceptos relacionados con el desarrollo gil de software y
ayudar a las organizaciones para que los adopten. El punto de partida fue
el Manifiesto gil, un documento que resume la filosofa gil.

1.2.2. El Manifiesto gil

El Manifiesto comienza enumerando los principales valores del desarrollo
gil. Se valora:

Al individuo y a las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de xito de
un proyecto de software. Si se sigue un buen proceso de desarrollo, pero
el equipo falla, el xito no est asegurado; sin embargo, si el equipo
funciona, es ms fcil conseguir el objetivo final, aunque no se tenga un
proceso bien definido. As mismo, las herramientas (compiladores,
depuradores, control de versiones) son importantes para mejorar el
rendimiento del equipo, pero el disponer de ms recursos de los
estrictamente necesarios tambin puede afectar negativamente.

Desarrollar software que funciona ms que conseguir una buena

documentacin. Aunque se parte de la base de que el software sin
documentacin es un desastre, la regla a seguir es no producir
documentos a menos que sean necesarios de forma inmediata para tomar
una decisin importante. Estos documentos deben ser cortos y centrarse
en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se
incorpora al equipo de desarrollo, se considera que los dos elementos que
ms le van a servir para ponerse al da son: el propio cdigo y la
interaccin con el equipo.

La colaboracin con el cliente ms que la negociacin de

un contrato. Las caractersticas particulares del desarrollo de
software

hacen que muchos proyectos hayan fracasado por

intentar cumplir plazos

y costes preestablecidos al inicio del mismo, segn los requisitos que el

cliente manifestaba en ese momento. Por ello, se propone que exista una
interaccin constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a lo largo del
proyecto (en los requisitos, la tecnologa, el equipo) determina tambin el
xito o fracaso del mismo. Por lo tanto, la planificacin debe ser flexible
para poder adaptarse a los cambios que puedan surgir. Una buena
estrategia es hacer planificaciones detalladas para unas pocas semanas y
planificaciones mucho ms abiertas para unos pocos meses.

Los valores anteriores inspiran los doce principios del manifiesto. stas
son las caractersticas que diferencian un proceso gil de uno tradicional.
Los dos primeros son generales y resumen gran parte del espritu gil.
I. La prioridad es satisfacer al cliente mediante tempranas y continuas
entregas de software que le aporten un valor. Un proceso es gil si a
las pocas semanas de empezar ya entrega software que funcione
aunque sea rudimentario. El cliente decide si pone en marcha dicho
software con la

funcionalidad que ahora le proporciona o

simplemente lo revisa e informa de posibles cambios a realizar.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que
el cliente tenga una ventaja competitiva. Los cambios en los registros
deben verse como algo positivo. Les va a permitir aprender ms, a la
vez que logran una mayor satisfaccin del cliente. Este principio

implica adems que la estructura del software debe ser flexible para
poder incorporar los cambios sin demasiado coste agregado.

Luego existen una serie de principios que tienen que ver directamente con
el proceso de desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de

tiempo

posible entre entregas. Las entregas al cliente se insiste en que sean

software, no planificaciones, ni documentacin de anlisis o de
diseo.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo
largo del proyecto. El proceso de desarrollo necesita ser guiado por
el cliente, por lo que la interaccin con el equipo es muy frecuente.
V. Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo. La gente es el principal factor de xito, todos los
dems (proceso, entorno, gestin) queda en segundo plano. Si
cualquiera de ellos tiene un efecto negativo sobre los individuos debe
ser cambiado.
VI.El dilogo cara a cara es el mtodo ms eficiente y efectivo para
comunicar informacin dentro de un equipo de desarrollo. Los
miembros de equipo deben hablar entre ellos, ste es el principal
modo de comunicacin. Se pueden crear documentos pero no todo
estar en ellos.

VII.

El software que funciona es la medida principal de progreso. El

estado de un proyecto no viene dado por la documentacin generada

o la fase en la que se encuentre, sino por el cdigo generado y el
funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el
50% de los requisitos ya estn en funcionamiento.
VIII. Los procesos giles promueven un desarrollo sostenible. Los
desarrolladores y usuarios deberan ser capaces de mantener

el

ritmo de desarrollo durante toda la ejecucin del proyecto,

asegurando en todo momento que la calidad es mxima.

Finalmente los ltimos principios estn ms directamente relacionados

con el equipo de desarrollo, en cuanto metas a seguir y organizacin del
mismo.
IX.La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad. Producir cdigo claro y robusto es la clave para avanzar
ms rpidamente en el proyecto.
X. La simplicidad es esencial. Tomar los caminos ms simples que
sean consistentes con los objetivos perseguidos. Si el cdigo
producido es simple y de alta calidad ser ms sencillo adaptarlo a
los cambios que puedan surgir.
XI.Las mejores arquitecturas, requisitos y diseos surgen de los
equipos organizados por si mismos. Todo el equipo es informado de
las responsabilidades y stas recaen sobre todos sus miembros. Es
el propio equipo el que decide la mejor forma de organizarse, de
acuerdo a los objetivos que se persigan.

XII.

En intervalos regulares, el equipo reflexiona respecto a cmo

llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Puesto

que el entorno est cambiando continuamente, el equipo

tambin debe ajustarse al nuevo escenario de forma continua. Puede

cambiar su organizacin, sus reglas, sus convenciones, sus
relaciones, etc., para seguir siendo gil.

Los conceptos subyacentes no son nuevos, aunque toman nueva

importancia a partir del momento que se usan combinados.

1.2.3. Metodologas giles vs. Tradicionales

A continuacin vamos a enumerar las principales diferencias respecto de
las metodologas tradicionales (no giles).

El siguiente cuadro recoge esquemticamente estas diferencias que no se

refieren slo al proceso en s, sino tambin al contexto de equipo y
organizacin que es ms favorable a cada una de estas filosofas de
desarrollo de software.

Metodologas giles

Metodologas

La planificacin del trabajo slo

comprende el ciclo en el que se
est trabajando (normalmente 30
Descubrimiento progresivo de
requisitos, e incorporacin de
cambios en cualquier iteracin del
desarrollo.
Refactorizacin de cdigo como
modelo de trabajo compatible con
el punto anterior.
Comunicacin directa entre los
integrantes del equipo (incluidos
cliente y usuarios) prefiriendo la
Equipos auto-gestionados.

Tradicionales
Trabajo
y gestin guiada por un
plan general del proyecto que
comprende todo su ciclo de
Conocimiento detallado de
los requisitos antes de
comenzar el diseo del
proyecto.
Hacerlo bien a la primera. Evitar
la re-codificacin y el re-trabajo
que supone una prdida de
Comunicacin formal segn el
plan de comunicacin del
proyecto.
Gestin de equipos y
personas centralizada en el
gestor del proyecto.

No existe contrato tradicional o

al menos es bastante flexible.
El cliente es parte del equipo
de desarrollo.
Grupos pequeos (hasta 20
integrantes) y trabajando en el mismo
Pocos artefactos.
Pocos roles.
Menos nfasis en la arquitectura
del software.

Existe un contrato prefijado.

El cliente interacta con el equipo
de desarrollo mediante reuniones.
Grupos grandes y
posiblemente distribuidos.
Ms artefactos.
Ms roles.
La arquitectura del software
es esencial y se expresa
mediante modelos.

Diferencias entre metodologas giles y no giles.

Las metodologas giles estn revolucionando la manera de producir

software, y a la vez generando un amplio debate entre sus adeptos y
quienes por prejuicio no las ven como alternativa a las metodologas
tradicionales.

Aunque los creadores de las metodologas giles han suscrito el

manifiesto gil, y todas ellas coinciden con los principios enunciados
anteriormente, cada una tiene caractersticas propias y hace hincapi en
algunos aspectos ms especficos.

Las metodologas giles ms populares son: XP (Extreme Programming

Programacin Extrema), Cristal y Scrum. Por ser esta ltima la elegida
para desarrollar el presente trabajo mencionamos los tres principales
motivos que nos llevaron a su eleccin.

Sirve para gestionar proyectos de cualquier tipo, no solamente

tecnolgicos.

Deja un vaco en la parte de definiciones del rea de ingeniera lo

que permite una elaboracin propia para completarla.

Tiene escasa documentacin por lo que se piensa que este trabajo

puede resultar en un aporte significativo.

A continuacin, en el prximo captulo, de desarrolla en detalle Scrum.

2. SCRUM

2.1. INTRODUCCIN
Scrum es una metodologa gil de gestin de proyectos cuyo objetivo
primordial es elevar al mximo la productividad de un equipo. Reduce al
mximo la burocracia y actividades no orientadas a producir software que
funcione y produce resultados en periodos muy breves de tiempo. Como
mtodo, Scrum enfatiza valores y prcticas de gestin, sin pronunciarse
sobre requerimientos, prcticas de desarrollo, implementacin y dems
cuestiones tcnicas. Ms bien delega completamente en el equipo la
responsabilidad de decidir la mejor manera de trabajar para ser lo ms
productivos posibles.

La palabra Scrum procede de la terminologa del juego de rugby, donde

designa al acto de preparar el avance del equipo en unidad pasando la
pelota a uno y otro jugador. Igual que el juego, Scrum es adaptable, gil,
auto-organizante y con pocos tiempos muertos.

Scrum fue desarrollado por Jeff Sutherland y elaborado ms formalmente

por Ken Schwaber. Poco despus Sutherland y Schwaber se unieron para
refinar y extender Scrum. Se la ha llegado a conocer como una
herramienta de hiperproductividad. Schwaber se dio cuenta entonces de
que un proceso necesita aceptar el cambio, en lugar de esperar
predictibilidad. Se enfoca en el hecho de que procesos definidos y
repetibles slo funcionan para atacar problemas definidos y repetibles con
gente definida y repetible en ambientes definidos y repetibles. Toma el
cambio como una forma de entregar al final del desarrollo algo ms

cercano a la verdadera necesidad del Cliente. Puede ser aplicado

tericamente a cualquier contexto en donde un grupo de gente necesita
trabajar junta para lograr una meta comn.

Se basa en los principios giles:

Privilegiar el valor de la gente sobre el valor de los procesos.
Entregar software funcional lo ms pronto posible.
Predisposicin y respuesta al cambio.
Fortalecer la comunicacin y la colaboracin.
Comunicacin verbal directa entre los implicados en el proyecto.
Simplicidad; supresin de artefactos innecesarios en la gestin del
proyecto.

2.2. LA ESENCIA DE SCRUM

Ms que una metodologa de desarrollo es para gestionar

proyectos, no contiene definiciones en reas de ingeniera.

Con visin de que el trabajo es efectuado por equipos autoorganizados y auto-dirigidos, logrando motivacin, responsabilidad
y compromiso.

Est basada en un proceso constructivo iterativo e incremental

donde las iteraciones tienen duracin fija.

Contiene definicin de roles, prcticas y productos de trabajo

escritas de forma simple.

Est soportada en un conjunto de valores y principios.

Nueva funcionalidad

Sprint
Backlog

Product Backlog seleccionado

Product Backlog Requisitos priorizados

Visin:
ROI versiones
hitos

El flujo de Scrum

2.3. ELEMENTOS DE SCRUM

Roles
Product Owner
Scrum Master
Team (Equipo)

Poda de requerimientos

Product Backlog

Sprint
Planificacin
Sprint Backlog
Scrum
Estimaciones
Builds continuos
Revisin del Sprint
Reunin retrospectiva

Valores
Foco, comunicacin, respeto y coraje.

2.3.1. Roles
La dimensin del equipo total de Scrum no debera ser superior a veinte
personas. Si hay ms, lo ms recomendable es formar varios equipos. No
hay una tcnica oficial para coordinar equipos mltiples, pero se han
documentado experiencias de hasta 800 miembros, divididos en Scrums
de Scrum, definiendo un equipo central que se encarga de la
coordinacin, las pruebas cruzadas y la rotacin de los miembros.

Scrum tiene una estructura muy simple. Todas las responsabilidades del
proyecto se reparten en 3 roles:

 Product owner (Dueo del producto)

Representa a todos los interesados en el producto final. Sus reas de
responsabilidad son:

Financiacin del proyecto

Requisitos del sistema

Retorno de la inversin del proyecto

Lanzamiento del proyecto

Es el responsable oficial del proyecto, gestin, control y visibilidad de la

lista de acumulacin o lista de retraso del producto (Product Backlog).
Toma las decisiones finales de las tareas asignadas al registro y convierte
sus elementos en rasgos a desarrollar.

Scrum Master (Lder del proyecto)

Responsable del proceso Scrum, de cumplir la meta y resolver los
problemas. As como tambin, de asegurarse que el proyecto se lleve a
cabo de acuerdo con las prcticas, valores y reglas de Scrum y que
progrese segn lo previsto.

Interacta con el cliente y el equipo. Coordina los encuentros diarios, y se

encarga de eliminar eventuales obstculos. Debe ser miembro del equipo
y trabajar a la par.

 Team (Equipo)
Responsable de transformar el Backlog de la iteracin en un incremento
de la funcionalidad del software. Tiene autoridad para reorganizarse y
definir las acciones necesarias o sugerir remocin de impedimentos.

Auto-gestionado

Auto-organizado

Multi-funcional

La dimensin del equipo total de Scrum no debera ser superior a veinte.

El nmero ideal es diez, ms o menos dos. Si hay ms, lo ms
recomendable es formar varios equipos. No hay una tcnica oficial para
coordinar equipos mltiples, pero se han documentado experiencias de
hasta 800 miembros, divididos en Scrums de Scrums, definiendo un
equipo central que se encarga de la coordinacin, las pruebas cruzadas y
la rotacin de los miembros.

Roles: gallinas y cerdos

El nombre de los miembros del equipo y los externos se deriva de una
tpica fbula agilista: un cerdo y una gallina discutan qu nombre ponerle
a un nuevo restaurante; la gallina propuso Jamn y Huevos. No,
gracias, respondi el cerdo, Yo estar comprometido, mientras t slo
implicada.

Scrum diferencia claramente entre estos dos grupos para garantizar que
quienes tienen la responsabilidad tienen tambin la autoridad necesaria

para poder lograr el xito, y que quienes no tienen la responsabilidad, los

observadores externos, no produzcan interferencias innecesarias.
Comprometido en el proyecto

Implicados en el proyecto

Dueo del producto

Marketing

Equipo
Scrum Master

Comercial
Etc.

2.3.2. Poda de requerimientos

La primera actividad es armar una lista exhaustiva de los requerimientos
originales del sistema. Luego se procede a ver qu requerimientos son
realmente necesarios, cules pueden posponerse y cules eliminarse.
Para ello debe identificarse un representante con capacidad de decisin,
priorizar los requerimientos en base a su importancia y acordar cules son
los prioritarios para la fecha de entrega.

La poda de requerimientos es una buena prctica implcita en modelos

giles, se hace lo que el cliente realmente desea, no ms.

2.3.3. Product Backlog

Con los requerimientos priorizados y podados armamos el Backlog de
Producto. Este es una forma de registrar y organizar el trabajo pendiente
para el producto (actividades y requerimientos).

Es un documento dinmico que incorpora constantemente

necesidades del sistema. Por lo tanto, nunca llega a ser una

las
lista

completa y definitiva. Se mantiene durante todo el ciclo de vida (hasta la

retirada del sistema) y es responsabilidad del Product Owner.

2.3.4. Sprint
Scrum est basado en el control emprico de procesos. Se utiliza cuando
la capacidad de prediccin es vaga, la incertidumbre alta o el proceso es
demasiado complejo para ser modelado y definido.

En el enfoque emprico de control de procesos se establecen reglas

simples y se crea una disciplina de inspeccin frecuente para adaptarse
rpidamente a situaciones imprevistas o problemas.

Control:
C
Inspeccin diaria y resolucin de problemas

PROCESO

Entrada:
Salida:
Backlog de producto seleccionado
Nuevo incremento del producto
Proceso:
Sprint con sus prcticas y reglas

Un Sprint es el periodo de tiempo durante el que se desarrolla un

incremento de funcionalidad. Constituye el ncleo de Scrum, que divide
de esta forma el desarrollo de un proyecto en un conjunto de pequeas
carreras.

Duracin mxima del Sprint : 30 das.

Durante el Sprint no se puede modificar el trabajo que se ha

acordado en el Backlog.

Slo es posible cambiar el curso de un Sprint, abortndolo, y slo

lo puede hacer el Scrum Master si decide que no es viable por
alguna de las razones siguientes:
-

La tecnologa acordada no funciona.

Las circunstancias del negocio han cambiado.

El equipo ha tenido interferencias.

 Planificacin
Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que
los objetivos no van a cambiar durante el mismo. De esta manera se
atena el riesgo.

Aspectos a tener en cuenta sobre la planificacin de un Sprint:

Una determinacin general de alcance, frecuentemente basada en

una EDT (Estructura de Divisin del Trabajo).

Estimaciones de esfuerzo de alto nivel realizadas durante la etapa

de concepcin del proyecto.

Esfuerzo dedicado a labores de soporte o de preparacin de los

ambientes requeridos por el proyecto.

Esfuerzo asociados a las reuniones diarias, de planificacin y de

revisin.

Requerimientos

de recursos de infraestructura

o logsticos

(mquinas, redes, licencias, papel, pizarras, etc.).

Habilidades presentes y necesarias en el equipo.

Restricciones asociadas al conocimiento del negocio, la tecnologa

o externas (legales, reglamentarias, estndares, etc.).

Rol del Scrum Master durante la planificacin:

Dirige la planificacin.
Es vnculo entre el equipo y el Product Owner del proyecto.
Registra problemas y riesgos detectados durante la planificacin.
Registra las tareas, asignaciones y estimaciones.
Inicia el Backlog del Sprint.

Sprint Backlog
Trabajo o tareas determinadas por el equipo para realizar en un Sprint.

Tareas a convertir en producto funcional.

Las tareas se estiman en una duracin entre 1 a 20 horas de

trabajo. Las de mayor duracin deben intentar descomponerse en
sub-tareas de ese rango de tiempo.

La estimacin se actualiza da a da.

Scrum diario
Scrum asume que el proceso es complejo y que es necesario
inspeccionarlo frecuentemente, por eso se realiza una reunin diaria de
seguimiento. El encuentro diario impide caer en el dilema sealado por
Fred Brooks: Cmo es que un proyecto puede atrasarse un ao? Un da
a la vez.

El foco de la reunin es determinar el avance en las tareas y detectar

problemas o bloqueos que estn haciendo lento el progreso del equipo o
que eventualmente impidan a un equipo cumplir con la meta del Sprint. La
idea es que ningn problema quede sin resolver o, por lo menos, sin
iniciar alguna accin de respuesta dentro de las 24 horas despus de su
deteccin.

La reunin es adems un espacio definido para que cada miembro del

equipo comunique a los dems el estado de su trabajo y por lo tanto
reafirme el compromiso.

Tips para un buen Scrum diario:

Todos los das en el mismo sitio y a la misma hora. Con una

duracin mxima de 15 minutos.

Se recomienda que sea la primera actividad del da.

Deben acudir todos los miembros del equipo.

Hacer un crculo, permitir que todos vean a todos.

Mantener el foco.

Solo habla una persona a la vez y los dems escuchan. No se

permiten interrupciones, entrar y salir, hablar por telfono, etc.

Slo se habla de: En que trabaj ayer? En que voy a trabajar

hoy? Que problemas impiden mi progreso?

No iniciar discusiones muy largas sobre temas tcnicos o sobre los

problemas, esto hay que registrarlo y manejarlo despus de la
reunin.

Si estn permitidas las preguntas para aclarar el alcance de un

trabajo o de un problema.

Cuando un miembro informa de algo de inters para otros, o

necesita ayuda de otros, estos se renen al terminar la revisin
diaria.

Las gallinas no pueden intervenir ni distraer, y el Scrum Master

puede limitar el nmero de gallinas asistentes si lo considera
oportuno.

Rol del Scrum Master durante el Scrum:

Dirige la reunin y mantiene el foco.
Hace preguntas para aclarar dudas.
Registra (escribe o documenta) los problemas para su resolucin
despus de la reunin.
Se asegura que los miembros cuenten con el ambiente adecuado
para la reunin.

Estimaciones
Las estimaciones se realizan por primera vez en la reunin

de

planificacin al inicio del Sprint. Luego las tareas se re-estiman todos los
das y se registran sus cambios en el Backlog del Sprint; esta actividad
puede ser realizada inmediatamente antes o despus del Scrum diario.

Algunas claves para la estimacin:

Siempre se realizan estimaciones de esfuerzo, no de duracin.

Siempre se estima el esfuerzo total pendiente para terminar

la

tarea, no se estima el esfuerzo consumido.

Se buscan unidades manejables, lo usual es que estn en un

mnimo de 2 horas y un mximo de 20. Si la tarea es muy corta se
trata de juntarla con otras relacionadas. Si la tarea es muy grande
se trata de descomponerla.

Builds continuos y pruebas bsicas

La estrategia que generalmente se utiliza es la de Builds continuos y
smoke test (prueba bsica para la funcionalidad del sistema).
Se itera por estas fases

Se prueba que no se
El programador
Pasa a integracin lo
rompa el build.
libera cdigo.
ms pronto posible (diario al menos).

Procedimiento de Builds continuos

Los programadores desarrollan segn el Backlog del Sprint, y al

finalizar, notifican al integrador.

El integrador toma el cdigo y lo integra con el resto del producto.

Se compila el software y se prueba por arriba el producto, para

verificar que no se haya roto.

Si se encuentran problemas se devuelve al desarrollador.

Se notifica al equipo que hay una nueva versin estable del

cdigo para usar como base.

Revisin del Sprint

El objetivo de la reunin de revisin es presentar el producto o porcin del
producto desarrollada por el equipo a los usuarios. La reunin se utiliza
para detectar inconformidades mayores que se vuelven elementos del
Backlog de Producto y que eventualmente se resuelven en el siguiente
Sprint.

A la reunin asisten el equipo, el Scrum Master, el Product Owner y todas

las personas implicadas en el proyecto (gallinas).

Tips para una buena revisin:

Duracin mxima de la reunin: 4 horas.

Preparar la presentacin, teniendo en cuenta que lo nico que se

presenta es el producto (no Power Point o similares).

Mantener el foco durante la reunin de revisin, el foco es el

producto solamente.

Finalidad: presentar al propietario del producto y a las gallinas las

nuevas funcionalidades implementadas.

Las funcionalidades no implementadas no se presentan.

Registrar todos los comentarios e inconformidades declaradas de

los usuarios sobre el producto para determinar cuales de ellas
formarn parte del Backlog.

Reunin retrospectiva
Scrum involucra el concepto de mejora continua a travs de las reuniones
de retrospeccin. Las reuniones buscan detectar los puntos positivos y
negativos del Sprint para generar propuestas de mejora para futuros
Sprints.

Las reuniones de retrospeccin son el concentrador del aprendizaje

organizacional sobre el Scrum. Los puntos positivos y negativos se
registran y se definen tems de accin para cada uno. Los tems de accin
definidos se toman en cuenta en los siguientes Sprints.

Acuden el equipo y el Scrum Master, y opcionalmente el Product Owner

del Producto.

Tips para una buena retrospeccin:

Todos los miembros del equipo responden a dos preguntas:

-

Qu cosas fueron bien en el ltimo Sprint?

Qu cosas se podran mejorar?

El Scrum Master anota todas las respuestas.

El equipo prioriza las mejoras posibles.

El Scrum Master no proporciona respuestas, sino que ayuda al

equipo a encontrar la mejor forma de trabajar con Scrum.

Las acciones de mejora localizadas que se puedan implementar en

el prximo Sprint deben introducirse en el Backlog como elementos
no funcionales.

2.3.5. Valores
Foco Los individuos y sus interacciones son ms importantes que el
proceso y las herramientas. La gente es el principal factor de xito de un
proyecto de software.

Comunicacin Scrum pone en comunicacin directa y continua a

clientes y desarrolladores. El cliente se integra en el equipo para
establecer prioridades y resolver dudas. De esta forma ve el avance da
a da, y es posible ajustar la agenda y las funcionalidades de forma
consecuente.

Respeto Scrum diferencia claramente entre dos grupos para

garantizar que quienes tienen la responsabilidad tienen tambin la
autoridad necesaria para poder lograr el xito (cerdos), y que quienes no
tienen la responsabilidad, los observadores externos (gallinas), no
produzcan interferencias innecesarias.

Coraje El coraje implica saber tomar decisiones difciles. Reparar un error cuando
se detecta. Mejorar el cdigo siempre que el feedback y las sucesivas iteraciones se
manifiesten susceptibles de mejora.

SEGUNDA PARTE

METODOLOGA

3. PROCESO DE DESARROLLO

3.1. INTRODUCCIN
En este apartado se presenta el proceso de desarrollo elaborado para
complementar la metodologa Scrum ya que esta no contiene definiciones
en cuestiones tcnicas.

Se utiliza un proceso gil iterativo e incremental que respeta las cinco

etapas tradicionales de un proyecto que facilitan su gestin y control; ellas
son:

planificacin,

anlisis,

diseo,

construccin

prueba,

implementacin. Cmo el objetivo final de la metodologa es llegar al xito

del proyecto se definen, en forma clara, los entregables de cada etapa y
el alcance global, reflejando estos puntos en la planificacin de todas las
tareas involucradas.

Se considera que: etapas delimitadas, entregables definidos y tareas

acotadas son claves para el cumplimiento del plan.

3.2. PROCESO ITERATIVO E INCREMENTAL

Este tipo de proceso de desarrollo permite hacer entregas parciales que
se van complementando segn avanza el proyecto. De esta manera se
reducen los riesgos y a la vez el cliente va experimentando los resultados
de su proyecto.

38

Dado que los proyectos de software son largos es comn dividir el trabajo
en mini proyectos. Cada mini proyecto es una iteracin que resulta en un
incremento. Para ser ms efectivas las iteraciones deben ser controladas,
es decir deben ser seleccionadas y llevadas a cabo de una forma
planeada.

Se ha propuesto un proceso iterativo para garantizar la realimentacin de

informacin y de requisitos una vez iniciado el desarrollo, as como la
validacin continua del sistema. Esto permite que cada iteracin
contemple ciclos de desarrollos completos y cortos, y obtener as
rpidamente, una nueva versin con mejoras sobre las versiones
anteriores.

Se ha propuesto un proceso incremental en el sentido de aadir

capacidades y funcionalidades al software de acuerdo con el crecimiento
de las necesidades; con el propsito de obtener el sistema final tras la
realizacin de diferentes ciclos. El final de cada ciclo proporciona adems,
una versin estable del software. Esto permite entregas al cliente de
forma rpida y gil.

Al entregar partes de la aplicacin a tiempo y regularmente, el equipo de

desarrollo tambin gana y establece credibilidad en su entorno y aumenta
su auto-estima. A la vez que este tipo de estrategia se enfoca ms en las
necesidades de los usuarios, instndolos a identificar sus prioridades en
cada etapa del proyecto.

A continuacin detallamos las etapas por las cuales transita nuestro

proceso de desarrollo y la combinacin de herramientas utilizadas en l.

3.3. ETAPAS DEL PROCESO DE DESARROLLO

3.3.1. Planificacin
Objetivo: Es la etapa ms importante de todas, ya que se define el
proyecto propiamente dicho.

Tareas: Relevamiento preliminar de los procesos del negocio, definicin y

secuenciamiento de actividades, definicin del alcance, estimacin de
tiempos, definicin de recursos, anlisis de riesgos, estimacin de costos.

Entregables: Documento de definicin del proyecto o del Sprint.

En esta etapa es importante aclarar que, al comienzo, la planificacin se

realiza en forma general para determinar el alcance, la duracin y el
precio del proyecto, una vez que el cliente decide llevarlo a cabo, las
siguientes planificaciones son a nivel de iteracin, se planifica el Sprint.

3.3.2. Anlisis
Objetivo: Obtener todas las definiciones y especificaciones funcionales
para poder llevar adelante las fases de Diseo y Construccin. Es una
etapa clave ya que el alcance y las caractersticas de la solucin quedan
acordados, lo cual permite mitigar los principales riesgos de un proyecto.

Tareas: Afianzamiento de las definiciones funcionales, definicin de los

requisitos a travs de casos de uso, planificacin de las etapas
posteriores y ajuste de los tiempos preestablecidos.

Entregable: Documento de alcance, casos de uso y sus respectivas

descripciones.

3.3.3. Diseo
Objetivo: Generar el modelo de datos para que la solucin cumpla con
los requerimientos definidos. El diseo generado deber contemplar las
posibles modificaciones futuras, crecimiento de la solucin, mayor carga e
incorporacin de nuevas funcionalidades.

Tareas: Diagrama Entidad Relacin (DER), diseo de las interfaces de

usuario, diseo de las integraciones a realizar. Durante esta etapa
tambin se realizan pruebas para puntos crticos del proyecto.

Entregables: Entre los entregables tpicos de esta etapa se encuentran:

DER, esqueleto del software armado, gua de diseo, diseo de la
infraestructura, y la planificacin ajustada con la evolucin y avances
obtenidos.

3.3.4. Construccin y Prueba

Objetivo: Construir la solucin del Release (Sprint), cumpliendo con las
definiciones

especificaciones

de

los

documentos

de alcance.

Generalmente es la etapa de mayor duracin y con mayor dinmica de

trabajo.

Tareas: Programacin y desarrollo de todos los componentes y

funcionalidades. Implementacin de las estructuras de datos, y sus
procedimientos,

elaboracin

de

documentacin

tcnica

ajustes

funcionales, implementacin de las integraciones y todas las actividades

necesarias para poner en marcha la solucin. En esta etapa se realizarn
las pruebas de usabilidad, funcionalidad y carga de datos.

Entregables: El entregable principal es el incremento de software

funcionando.

3.3.5. Implementacin
Objetivo: Disponer del sistema productivo con sus ambientes de
produccin, metodologa de trabajo y manuales operativos. Se incluye, de
ser necesario, el personal operativo capacitado. Obtencin de nuevas
funciones a agregar o posibles errores a reparar.

Tareas: Puesta en marcha de la aplicacin en el ambiente de produccin,

elaboracin de manuales operativos, y todas las actividades relacionadas
al xito del lanzamiento como la integracin del ambiente de produccin
con terceras partes, etctera.

Entregables: El sistema productivo con sus manuales operativos, de

mantenimiento y de procedimientos. Esquemas de auditoria y seguridad.
Integraciones con terceras partes operativas.

Sistema totalmente

probado.

3.4. EDT DEL PROCESO DE DESARROLLO

Presentamos nuestro proceso de desarrollo a travs de una Estructura de
Divisin del Trabajo para verlo grficamente.

Objetivos
Modelo de negocio

Procesos
Actividades

Planificacin

Estimacin Alcance
Estimacin Tiempo
Especificaciones funcionales

Anlisis

Requerimientos
Ajuste de tiempos

Proceso de
desarrollo

Modelo de datos

Diseo

Interfases
Releases

Construccin y Pruebas

Programar

Integracin y pruebas
Revisin y Retrospeccin

Implementacin

Puesta en
marcha
Carga de datos

3.5. HERRAMIENTAS
3.5.1. Tcnicas de relevamiento
Entrevistas con el cliente y los usuarios; revisin de registros, y
observacin.

3.5.2. Work Breakdown Structure (WBS)

Conocida como Estructura de Descomposicin de Trabajos (EDT). Es un
organigrama que despliega la estructura de un proyecto y muestra su
organizacin por fases y niveles de detalle. Cada nivel de descenso
representa un aumento en el nivel de detalle de las descripciones de las
actividades, sirve de lista de comprobacin, y determina el alcance
general. As como tambin, define los entregables del proyecto. Los
entregables pueden ser etapas o procesos del proyecto (plan del
proyecto, documentacin de diseo, etc.) o partes del producto final
(pantallas, ventanas, documentacin).

Se ir comentando a lo largo de este punto en cuales de las etapas de

desarrollo se aplican las herramientas explicadas. Entonces, tanto el WBS
como las tcnicas de relevamiento mencionadas anteriormente se utilizan
en las dos primeras etapas, o sea para la Planificacin y el Anlisis.

3.5.3. Casos de uso

Son un mtodo prctico para explorar requerimientos. Ayudan a describir
qu es lo que el sistema debe hacer desde el punto de vista del usuario.
Por lo tanto, consideramos que los casos de uso proporcionan un modo
claro y preciso de comunicacin con el cliente.

Descripciones de casos de uso: detallan los casos de uso, en ellas se

explica la forma de interactuar entre el sistema y el usuario.

Tanto los casos de uso como las descripciones de los mismos se utilizan
en la etapa del anlisis para definir los requisitos.

3.5.4. Diagrama de actividades

Sirven fundamentalmente para modelar el flujo de control entre
actividades. La idea es generar una especie de diagrama en el que se
puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, as
como las tareas concurrentes que pueden realizarse a la vez. El diagrama
de actividades sirve para representar el sistema desde otra perspectiva.
Desde un punto de vista conceptual, la actividad es alguna tarea que
debe ser realizada. Por este motivo, en un diagrama de actividades
aparecern acciones y actividades correspondientes a distintas clases;
colaborando todas ellas para conseguir un mismo fin.

Los diagramas de actividad son similares a los diagramas de flujo

procesales, con la diferencia de que todas las actividades estn
claramente asociadas a un caso de uso. Tambin se utilizan en la etapa
del anlisis.

3.5.5. Diagrama de Entidad Relacin (DER)

Un modelo de datos describe de una forma abstracta cmo se
representan los datos, sea en una empresa, en un sistema de informacin
o en un sistema de base de datos.

Los DER son una herramienta para el modelado de datos de un sistema

de informacin. Estos diagramas expresan entidades relevantes y sus
inter-relaciones. Formalmente, son un lenguaje grfico para describir
conceptos. Informalmente, son simples dibujos o grficos que (si se saben
interpretar) describen la informacin que trata un sistema de informacin y
el software que lo automatiza.

Los DER se aplican en la etapa de Diseo.

3.5.6. ScrumWorks
Permite llevar a cabo el seguimiento del proyecto. Es una herramienta de
automatizacin de procesos giles que admite a los equipos autoorganizarse y aumentar la productividad. Esta herramienta, de acceso
libre y fcil de utilizar, es una aplicacin Web que permite compartir la
informacin entre todo el equipo.

Esta herramienta para la administracin del proyecto permite:

Manejar dinmicamente el Backlog de Producto haciendo una

estimacin inicial del esfuerzo de cada requerimiento identificado
hasta el momento.

Definir las tareas y arrastrarlas al Sprint apropiado, donde se irn reestimando diariamente.

Observar un grfico por cada Sprint que nos indica la velocidad con la
que avanza el proyecto.

Estos grficos llamados burndown no slo permiten observar el estado de

avance del proyecto, sino tambin analizar sus comportamientos e ir
aprendiendo para mejorar los Sprints que restan.

3.5.7. Burndown chart

En Scrum se planifica y se mide el esfuerzo restante necesario para desarrollar
el producto. Esta grfica suele utilizarse en lugar de un diagrama de PERT
debido a que el camino crtico en un desarrollo gil cambia diariamente. Esto
hara obsoleto el diagrama de PERT cada da. Es por esto que no es til una
herramienta que modele el camino crtico a partir de actividades.

La solucin es utilizar una tcnica que permita medir la velocidad de desarrollo,

para ello se utiliza el criterio del equipo a partir del cual se calcula diariamente el
camino crtico. Esto permite recalcular el plan y la velocidad en que se realiza el
trabajo. En funcin de esto el equipo puede trabajar para acelerar o desacelerar
el trabajo para cumplir con la fecha de entrega.