Jess Mara Eraso Lerena

Aplicacin para la gestin de proyectos giles con Scrum

Jess Mara Aransay Azofra
Facultad de Ciencias, Estudios Agroalimentarios e Informtica
Grado en Ingeniera Informtica
2012-2013
Ttulo
Autor/es
Director/es
Facultad
Titulacin
Departamento
TRABAJO FIN DE GRADO
Curso Acadmico












Aplicacin para la gestin de proyectos giles con Scrum, trabajo fin de grado
de Jess Mara Eraso Lerena, dirigido por Jess Mara Aransay Azofra (publicado por la Universidad de La Rioja) se
difunde bajo una Licencia Creative Commons Reconocimiento 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.














El autor
Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es

3

Agradecimientos

Gracias a todos vosotros los que siempre estis ah, para lo bueno y para lo malo, por
ayudarme a desconectar, por ensearme vuestra mejor sonrisa, por saber sacar una sonrisa
cuando hace falta, por ensearme las lecciones de la vida que realmente importan.
Gracias todos los que formis parte de esta etapa, todos influs en esta memoria de forma
directa o indirecta.
Gracias a mi tutor, J ess M Aransay, por dirigirme otro proyecto ms y seguir formndome
como Ingeniero.
Y por ultimo Gracias a mis padres y mi hermano que siempre estn ah.

4

Resumen

El objeto de este proyecto surge de la necesidad de gestionar los proyectos durante su
desarrollo. Para ello se analizan en detalle las metodologas giles.

En primer lugar realizamos un anlisis exhaustivo de las metodologas giles, sus ventajas
frente a las metodologas tradicionales y las tcnicas asociadas. Para entrar en detalle se
nombran varias metodologas giles y en concreto se explica el funcionamiento de Scrum.

En segundo lugar y con el objetivo de poner en prctica y afianzar aun ms los conceptos de
las metodologas giles, se detalla la creacin de una aplicacin para la gestin de proyectos
giles utilizando Scrum como metodologa con la que dirigir nuestro proyecto. Para ello se han
utilizado los conceptos y herramientas que nos proporciona Scrum (Historias de usuario,
Sprints, Product Backlog...).

Palabras Clave: Metodologas giles, Scrum, Software de Gestin de proyectos.



5

Abstract

The goal of this project is originated from need to manage projects during the process of their
development. To achieve this goal we analyzed in detail agile methodologies.

First of all we make an analysis of agile methodologies and their advantages over traditional
methodologies, as well as their realated techniques. We explain several agile methodologies,
and more specifically Scrum.

Secondly, and in order to implement and strengthen even more the concepts of agile
methodologies, we detail the creation of an application for agile project management using
Scrum to manage this project. To do this we use the concepts and tools provided by Scrum
(User Stories, Sprints, Product Backlogs ...).


Key words: Agile Methodologies, Scrum, Project Management Sofware

6

ndice
Licencia...................................................................................................................................... 2
Agradecimientos ........................................................................................................................ 3
Resumen ................................................................................................................................... 4
Abstract...................................................................................................................................... 5
ndice ......................................................................................................................................... 6
Introduccin ............................................................................................................................... 8
Metodologa ........................................................................................................................... 8
Definicin de metodologa: .................................................................................................. 8
Metodologas giles ...........................................................................................................10
Extreme Programming: ......................................................................................................12
Desarrollo gil con Scrum: .................................................................................................13
Tiempos y Mtricas ............................................................................................................17
Conclusin .........................................................................................................................19
Kanban ..............................................................................................................................19
Escenario ...........................................................................................................................21
Alcance ..............................................................................................................................22
Product Backlog .................................................................................................................23
Estudio de mercado ...............................................................................................................27
Detalle de las aplicaciones destacadas ..............................................................................27
Aspectos ticos y de seguridad .............................................................................................28
Planificacin y metodologa ...................................................................................................30
Desarrollo .................................................................................................................................34
Historias de Usuario ..............................................................................................................34
Iteracin 0 .............................................................................................................................35
7

Iteracin 1 .............................................................................................................................38
Iteracin 2 .............................................................................................................................43
Iteracin 2B ...........................................................................................................................45
Revisin Product Backlog ......................................................................................................46
Conclusiones ............................................................................................................................49
Bibliografa ................................................................................................................................51
Referencias bibliogrficas: .................................................................................................51
Otras referencias ...............................................................................................................51
Documentacin tcnica ......................................................................................................51


8

Introduccin

Metodologa
Definicin de metodologa:

Una metodologa de desarrollo es un marco de trabajo usado para estructurar, planificar y
controlar un proceso de desarrollo de sistemas software. Todo esto engloba el enfoque de un
proceso de desarrollo de software y un conjunto de herramientas, modelos y tcnicas para
desarrollar software de buena calidad. Definicin de Wikipedia.
Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se
realizan o suceden (alternativa o simultneamente) bajo ciertas circunstancias con un fin
determinado. Definicin de Wikipedia.
Un procedimiento es un conjunto de acciones u operaciones que tienen que realizarse de la
misma forma, para obtener siempre el mismo resultado bajo las mismas circunstancias.
Definicin del blog parasitovirtual.wordpress.com.


Partiendo de estas tres definiciones genricas podemos decir que una metodologa trata de
organizar en la medida de lo posible los procedimientos a realizar durante la ejecucin de los
procesos que conlleva un proyecto. Los procesos de las metodologas tradicionales implican
una planificacin muy detallada resultando muy costoso el trabajo de planificacin, diseo y
documentacin. Esto no era lo que se necesitaba para proyectos pequeos o medianos en los
que el esfuerzo invertido en estas tareas superaba con creces la programacin del sistema
software.

Partimos de que la ingeniera informtica es una ingeniera nueva o muy reciente a diferencia
de la ingenieras industriales que ya han alcanzado su grado de madurez a lo largo de los aos.
Esto ha provocado que en sus inicios se utilizaran metodologas existentes en otras reas para
la gestin de proyectos informticos.

Conforme van aumentando los proyectos informticos en muchos de ellos nos encontramos
con problemas de planificacin. Los objetivos del producto van surgiendo a medida que el
cliente se da cuenta que necesita algo nuevo y el proyecto se ve afectado. Esto hace que
vayan surgiendo nuevas metodologas o metodologas aplicadas en otros campos que dan
buenos resultados en la gestin de proyectos software. Varios de los creadores de estas
nuevas metodologas se renen en el 2001 y crean el manifiesto gil [1] donde consiguen
poner en comn una serie de principios que deberamos tener en cuenta a la hora de gestionar
los proyectos software giles. Con este manifiesto se acua el trmino Metodologas giles.
9

La planificacin tradicional o con enfoque predictivo parte de tareas. Tiene un control
predictivo de las tareas que se van a realizar y la planificacin de dichas tareas en las primeras
fases del proyecto. Esto conlleva el esfuerzo extra de predecir las posibles tareas que puedan
surgir a medio y largo plazo cuando menos informacin del proyecto tenemos. Posteriormente
pasamos a redactar las especificaciones en un documento que entregaremos al cliente y este
deber validar. Si esta validacin no es correcta los requisitos cambiarn durante el progreso
del proyecto y nuestra planificacin habr cambiado lo que conlleva que se alarguen los plazos,
el presupuesto y/o la calidad disminuya. Como consecuencia muchas veces la fase de pruebas
suele quedar en un segundo plano y se ve disminuido el tiempo asignado en la planificacin
para esta fase.

Por el contrario la planificacin gil parte de los objetivos de negocio, es decir, objetivos
necesarios para el cliente una vez se le entrega el software. Se da por supuesto que existen
variables que no controlamos y los objetivos pueden cambiar, por ello se basa en lo emprico,
en lo que tenemos en el momento y lo que vamos realizando. Para ello deber realizarse un
control permanente analizando qu falta por hacer.

En las metodologas giles tambin se redacta documentacin pero a diferencia de las
metodologas en cascada, la documentacin es ms escasa, cobra menos importancia en favor
de obtener producto funcional. Sin embargo una metodologa tradicional simplemente entrega
documentacin de cmo va a ser el producto final.

A pesar de estas diferencias de concepto tan grandes, las metodologas tradicional y gil tienen
caractersticas comunes. Comparten tres conceptos, los objetivos del proyecto, el tiempo y los
costes. Estos trminos forman el Tringulo de hierro ya que se ven relacionados entre s, de
modo que si uno de ellos cambia los dems se ven afectados. Es decir, si tenemos menos
tiempo es necesario reducir los objetivos o aumentar los costes. Si aadimos objetivos
aumentarn los costes y el tiempo. Si el presupuesto es muy limitado, los objetivos se reducirn
y el tiempo aumentar. Si esto no se produce, entonces comprometemos la calidad del
proyecto.

10


Metodologas giles

Principios de las metodologas giles.

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentacin extensiva
Colaboracin con el cliente sobre negociacin contractual
Respuesta ante el cambio sobre seguir un plan

En estos 4 valores se resumen los 12 principios del manifiesto agil. La intencin es detallar las
partes ms prioritarias sobre las que son menos prioritarias cuando tratamos con un proyecto
gil [1]. Hay que proporcionar una motivacin en los individuos y confiarles la ejecucin del
proyecto. Aunque se utilicen herramientas para la gestin del proyecto, el mtodo ms efectivo
y eficiente de comunicacin es el cara a cara.

Es aqu donde nace nuestro proyecto; aunque existe comunicacin en el equipo y la
metodologa se conoce, es necesaria una herramienta software que nos ayude a gestionar los
proyectos y su documentacin. Deber permitir la consulta de estos datos por los miembros de
los equipos y por usuarios externos. Actualmente esto se hace de un modo no controlado
mediante documentos, directorios y correos electrnicos.

Para calcular las horas de los proyectos debemos revisar la documentacin y esto no resulta
fcil. En muchas ocasiones slo se conoce el coste estimado y no el coste real ya que no
tenemos un control del mismo. Adems el hecho de compartir la informacin con el resto de
departamentos hace inmanejable trabajar con las distintas versiones de los documentos y no
tenemos constancia de qu versin dispone cada usuario y se hace necesaria una herramienta
que nos ayude.

La planificacin gil intenta organizar un equipo autogestionado de la forma ms dinmica
posible pero con total control para tomar decisiones. No impone nada de serie. Partimos de
funcionalidades de negocio o historias de usuario que no deben contener especificacin
alguna. Eso no implica que el equipo o un desarrollador en concreto cuando vaya a tomar la
ejecucin de funcionalidad realice la documentacin que para l sea necesaria, teniendo en
cuenta que lo prioritario es que funcione. La documentacin se queda en un segundo plano. Si
es necesaria se har. Por ejemplo, un manual puede ser parte de la entrega de una reunin
peridica. Otro ejemplo puede ser el diseo de la base de datos que genera un ingeniero con
los correspondientes diagramas, pero estos no son el objetivo.

Historia de usuario Es lo mismo que objetivo de negocio? En primer lugar tenemos los
objetivos de negocio, los impone el cliente. Se puede decir que son lo que pretende el cliente
para sacar un beneficio (negocio). El conjunto de objetivos forma la definicin del proyecto. Y
las historias de usuario son los objetivos expresados de tal forma que identifican quin, el qu y
11

porqu puede hacer algo. Ejemplo: "Como cliente del banco, quiero pedir un prstamo para
poder comprar una casa" . Estas historias de usuario generan el Product Backlog. Es el primer
paso a realizar en una metodologa gil [2].

Como hemos comentado antes la planificacin gil tiene en cuenta revisiones peridicas,
siguiendo un ciclo de mejora continua o ciclo de vida iterativo. Para nuestro cliente es ms
sencillo revisar y entender el producto (software) a medida que este va creciendo. Enserselo
cuando ya ha sido acabado supone un mayor esfuerzo y es muy probable que muchas de las
funcionalidades crticas no se correspondan con lo que l necesita.

Cundo utilizar metodologas giles? Hay que tener en cuenta que esto no siempre es
vlido. Es necesario estar dentro de un contexto y ser capaz de adaptar las metodologas a
nuestras necesidades. Tambin depender del tipo de proyectos que realizamos, el escenario
no siempre acompaa para poder utilizar este tipo de metodologas al 100%. La planificacin
tradicional no tiene que desaparecer, simplemente es ms o menos adecuada para segn qu
tipo de proyectos. Puede ser el caso de proyectos en los que tenemos el escenario controlado
y los requisitos del productos son especficos e invariables.


En las metodologas giles podemos encontrar una serie de prcticas o tcnicas habituales a la
hora de afrontar la ejecucin de un proyecto. Por ejemplo, a la hora de hacer reuniones tienen
que ser rpidas y frecuentes, lo suficientemente rpidas (giles) como para no perder el tiempo
pero con una frecuencia suficiente para que los integrantes del equipo estn informados de
todo. Suelen ser reuniones diarias. Cuando se trata de una reunin de planificacin de iteracin
en la que hay una parte del producto para entregar se re-planifica la siguiente iteracin a partir
del feedback obtenido del cliente. El intervalo de tiempo entre entregas se denomina iteracin.
Como se puede deducir en este tipo de reuniones participa el cliente, al que se considera uno
ms del equipo.

A la hora de afrontar el desarrollo del software se puede emplear tcnicas y combinarlas entre
s. Es el caso del pair programming y test driven development. Se pueden aplicar en funcin de
nuestras necesidades y de nuestras posibilidades.

El pair programing consiste en programacin por parejas. Mientras uno programa otro puede
estar realizando la definicin de una clase y viceversa. Se sugiere cambiar los papeles cada
media hora o una hora [6]. Para muchas organizaciones esto puede resultar complicado o
imposible, ya sea por falta de personal, por mentalidad de la organizacin o por las
circunstancias del momento.


Test Driven Development (TDD) pretende conseguir un software de mayor calidad. La calidad
compuesta por los tres vrtices del tringulo de hierro, es uno de los objetivos en las
metodologas giles. Con las numerosas retrospectivas se evita que el producto no sea
probado hasta el ltimo momento y con tcnicas como TDD conseguimos que nuestra
12

programacin, algo artesanal, solo haga lo que tiene que hacer, pasar un test. TDD o la
traduccin al espaol, desarrollo guiado por pruebas, consiste en escribir un test automtico, en
primer lugar hacemos fallar el test, en segundo lugar programamos el cdigo suficiente para
que dicho test funcione. Por ltimo refactorizamos
1
el cdigo para mejorar legibilidad.

Finalmente para gestionar los proyectos las metodologas giles tambin cuentan con mtricas.
Pero no siempre hay que incluir todas, de hecho cuantas ms mtricas se usan, el coste de
recoger e interpretar datos tambin aumenta.

Aunque en general no se definen mtricas giles concretas, existe un objetivo que persiguen
las mtricas giles. Este consiste en que no se pretende medir el trabajo realizado, sino el
trabajo que queda por realizar. En el siguiente apartado veremos las mtricas concretas que se
aplican en una metodologa gil concreta, en este caso Scrum.

Ejemplos de metodologas giles

Algunos ejemplos de metodologas giles conocidas son Extreme Programming y Scrum. Son
dos metodologas adoptadas por la comunidad de desarrolladores con bastante xito. Si bien
tienen diferencias, ambas se rigen por los principios giles que hemos concretado
anteriormente, y por lo tanto tienen puntos en comn. Sin embargo XP se centra ms en las
prcticas de desarrollo y Scrum en la organizacin y gestin [3].

En primer lugar vamos a ver una breve explicacin de Extreme Programming, entraremos en
detalle con Scrum y por ltimo hablaremos de la gestin visual a travs de una herramienta
concreta, Kanban, herramienta que puede ser utilizada por ambas metodologas.


Extreme Programming:
Extreme Programming (XP) se rige sobre la suposicin de que es posible obtener software de
gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asuncin
es que con un poco de planificacin, un poco de codificacin y unas pocas pruebas, se puede
decidir si se est siguiendo un camino acertado o equivocado, evitando tener que echar marcha
atrs demasiado tarde [4].

Esta metodologa entiende que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. En un principio se rega por 4

1
Refactorizacin: tcnica de reestructuracin de cdigo fuente alterando su estructura pero sin cambiar
su comportamiento externo. Fuente Wikipedia.
13

valores principales: Simplicidad, comunicacin, retroalimentacin y coraje. Pero en una
segunda edicin de Extreme Programming Explained
2
fue aadido el quinto, respeto.

Estos valores son aplicados en todos los aspectos que unifican el proyecto. Simplicidad, en la
documentacin, en el desarrollo. Comunicacin, a la hora de desarrollar las tcnicas de
programacin (como test unitarios, vitales en XP). La retroalimentacin necesaria y fcil de
obtener ya que se incluye al cliente como parte del equipo. Coraje para afrontar prcticas que
no son gratificantes, como reescribir cdigo, eliminar funcionalidades que no sirven para nada
despus de un gran esfuerzo y adems enfrentndonos con los problemas o dificultades que
nos podamos encontrar en un momento determinado pero que resolveremos si somos
persistentes. Y por ltimo respeto al trabajo realizado por los distintos miembros del equipo. La
calidad del software es una premisa por la que todos trabajan y para ello tenemos que respetar
al equipo.

Scrum vs XP
Una caracterstica que diferencia XP de Scrum es que los cambios son naturales y aunque en
Scrum tambin se contemplan, Scrum marca la reunin de revisin del sprint como
herramienta/momento en el que se deben solicitar dichos cambios. Sin embargo en XP estos
se pueden hacer en el momento en que se conocen, tenemos total flexibilidad de parar una
funcionalidad a mitad de la iteracin.

Desarrollo gil con Scrum:
Scrum parte de la esencia del desarrollo gil. Se centra en las funcionalidades con ms
prioridad y que pueden ser ejecutadas en un periodo corto de tiempo. Los ciclos de desarrollo,
llamados sprints en Scrum, producen un incremento de funcionalidad terminado y operativo.

El Product Backlog es la lista de requisitos priorizada que representa la visin del cliente
respecto a los objetivos del proyecto. Es un documento en constante evolucin, aunque parte
de unos requisitos inciales, se modifica durante el desarrollo en las reuniones de revisin del
Sprint. Para su elaboracin todo el que est implicado en una tarea puede aportar sugerencias
pero se define un nico responsable, llamado propietario del producto, Product Owner.

Como es un documento que vara a lo largo de las iteraciones no es necesario que est
completado para proceder con la primera iteracin. Basta con una identificacin de los
requisitos que tenemos en esta fase y un detalle de los ms prioritarios, es decir, por cada
requisito tenemos que detallar al menos su valor, coste estimado, una breve descripcin... El
coste estimado y el valor, nos permiten conocer el retorno de inversin y sern utilizadas para
asignar un valor de prioridad a cada historia de usuario.


2
Libro escrito por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Fue uno de los 17 firmantes originales del Manifiesto gil en 2001.
14

A travs del Product Backlog tambin planificamos las iteraciones, agrupando de forma
coherente funcionalidades de modo que no implique un esfuerzo extra completar todos los
objetivos. Con esto acordamos que se entiende por producto completado al final de cada
iteracin, garantizando que el cliente puede probar los resultado de la iteracin sin problemas.
A esto hay que aadir condiciones de satisfaccin por cada objetivo para lo cual se hacen
casos de prueba de aceptacin durante la creacin del propio Product Backlog.

Fuente: Flexibilidad con Scrum


Product Owner, propietario del producto, es la persona conocedora del entorno del cliente y de
la visin del producto. Es el responsable de obtener el mayor valor posible para el cliente o los
usuarios; tambin responsable de la financiacin necesaria del proyecto, de la finalizacin y del
retorno de inversin. Si la comunicacin con el cliente es muy fluida pero el cliente carece de
las habilidades necesarias para formar parte del equipo, puede ser un miembro de nuestra
organizacin el que haga el papel de Product Owner.

Como ya hemos dicho crea y mantiene el Product Backlog. Replanifica el proyecto antes de
cada iteracin en funcin del valor de los requisitos. Adems colabora con el equipo en la
planificacin, revisin y detalle de los objetivos de cada iteracin. A veces es necesario que el
proveedor se ponga en la piel de cliente e interiorice sus necesidades adems de mantener en
todo momento un comunicacin fluida con el cliente final.

Siguiendo la imagen anterior, el inicio de una iteracin viene marcado por la reunin de
planificacin, donde reunido todo el equipo se consensua el trabajo y los objetivos para esa
iteracin concreta. Como resultado obtenemos el Sprint Backlog, lista de tareas a realizar
durante la iteracin. Y el objetivo del sprint, funcionalidad a conseguir en ese sprint.

En Scrum la evolucin de una iteracin se revisa con reuniones de seguimiento diarias, en las
que se rene todo el equipo de desarrollo, comenta el trabajo que ha terminado, el trabajo que
tiene por terminar y los impedimentos que hayan podido surgir. En estas reuniones se trabaja
con el Sprint Backlog, donde actualizamos la lista.
15


El fin de una iteracin o sprint conlleva la revisin del proyecto a travs de otra reunin
(Revisin del Sprint) con todas las personas implicadas y comprometidas en el proyecto.
Durante la reunin se produce la oportunidad de reconducir el proyecto si algo ha cambiado,
plazos, funcionalidades, mercado actual... Como hemos comentado, en una iteracin se
entrega el incremento, que debera ser un producto listo para inspeccionar, evaluar y sacar al
mercado.


Fuente: Flexibilidad con Scrum

Cabe destacar la diferencia entre personas implicadas y comprometidas. Una persona
implicada est relacionada con el proyecto, como puede ser el usuario concreto que har uso
de la aplicacin software. Sin embargo este no realiza tareas para el desarrollo del software.
Una persona comprometida se relaciona y forma parte de la ejecucin del proyecto. Un ejemplo
de esta separacin en el mbito del TFG sera: las personas comprometidas con el proyecto, el
alumno y el director, frente a las personas implicadas, en este caso el tribunal.

Scrum toma la inestabilidad como premisa. No se considera que la definicin detallada del
producto, ni la arquitectura software tengan que estar en una primera fase del proyecto. Como
metodologa gil que es, no ser un desarrollo por fases. Esto hace que al aplicar Scrum para
desarrollo de software la prctica de refactorizacin es de obligado cumplimiento en las tareas
de diseo y codificacin [5]. Es decir, en cada iteracin se van aadiendo las nuevas
funcionalidades y se hace necesario modificar la estructura de las funcionalidades
implementadas para adoptar las nuevas sin modificar el resultado que ya teniamos.

Mientras que en una metodologa predictiva la responsabilidad de las circunstancias no
planificadas las tendr el gestor de proyectos, en Scrum se parte de equipos auto-organizados
con suficiente margen para tomar las decisiones oportunas.

16



Para que todo esto funcione es necesario el Scrum Manager. En Scrum se define un rol para
que se cumpla el funcionamiento de todos los procesos y metodologas que hemos descrito
anteriormente. Tiene que garantizar que se cumplen las siguientes normas:

Todos los involucrados debern seguir y colaborar con las normas definidas por Scrum
en nuestra organizacin. Asegurar la lista de requisitos, preparar y moderar las
reuniones, guiar al equipo en la autogestin.
Proteger al equipo de las interrupciones externas que surgen durante una iteracin. Y
quitar los impedimentos que el equipo pueda tener para llegar al objetivo de la iteracin.


A modo de resumen y antes de seguir con otros conceptos enumeramos los principales
trminos de Scrum que hemos detallado hasta ahora.
Reuniones:
Planificacin del Sprint
Seguimiento del Sprint
Revisin del Sprint

Elementos:
Product Backlog
Sprint Backlog
Incremento

Roles:
El propietario, Product Owner.
Equipo
Scrum Manager



Fuente: Flexibilidad con Scrum


17


Tras este pequeo resumen que nos ayuda a clarificar los conceptos bsicos proseguimos con
las mtricas y los conceptos relacionados que define Scrum.

Tiempos y Mtricas
Los siguientes conceptos surgen del funcionamiento de Scrum. Son necesarios para la
planificacin y la supervisin continua del proyecto. Como resultado obtendremos los grficos
Burn-up y Burn-down de los que hablaremos ms adelante.

Tiempo real: El tiempo efectivo de trabajo. Se mide en horas o das.
Tiempo terico: El tiempo ideal para realizar un trabajo.
Puntos de funcin: Unidad de medida relativa para determinar la cantidad de trabajo
necesaria para construir una funcionalidad del product backlog.
Estimaciones: Clculo del esfuerzo que se prev necesario.
Existen multitud de tcnicas para estimar el coste de las tareas.
Velocidad absoluta: La cantidad de producto construida en un sprint. Se mide con la
misma unidad relativa que las estimaciones.
Velocidad relativa: En este caso no se mide en unidades relativas sino en la unidad de
medida del tiempo de trabajo; horas de trabajo, semana de trabajo real.

En base a estas definiciones se trabaja la planificacin y las constantes revisiones del proyecto.
Generamos una unidad de medida abstracta conocida para todos los miembros del equipo
(puntos de funcin). Ej: coste de desarrollar un login de usuario en PHP. En base a esta unidad
asignaremos el coste de realizar cada historia de usuario entre todos los miembros para que
sea algo consensuado.

Como mtodos de estimacin
3
se pueden utilizar el mtodo de pquer, la sucesin de
Fibonacci... Estos mtodos favorecen la participacin y que nadie se quede sin opinar adems
de resolver los posibles malentendidos en los objetivos. Una vez estimadas las historias de
usuarios el Product Owner se encargar de priorizarlas por valor de negocio. Este orden puede
variar y ser primero el Product Owner quien asigna prioridad a las historias de usuario.

Ahora a partir de nuestra unidad de medida abstracta podemos calcular la velocidad absoluta y
velocidad relativa que vienen a ser la velocidad de producto construido en un sprint y velocidad
de producto construido en una unidad de tiempo de trabajo.

Estas mtricas se pueden representar en los grficos Burn-up y Burn-down, dos grficos que
reflejan la gestin y avance del producto y del sprint correspondientemente. Para conocer la
estimacin de cundo acabaremos tenemos el grfico Burn-down que nos puede ayudar con
esto.


3
Metodos de Estimacion: http://www.proyectosagiles.org/
18

Burn-down chart o grfico de trabajo pendiente que nos permite conocer si acabaremos el
proyecto en la fecha indicada. Muestra la velocidad a la que se van cumpliendo los objetivos.
Existen dos versiones de este grfico, una se centra en ver el trabajo pendiente del proyecto
global y en la segunda se refiere al trabajo del sprint en el que nos encontramos.

En el siguiente grfico observamos el trabajo pendiente en horas de la iteracin en curso.

Fuente: www.proyectosagiles.org



En el caso del grfico Burn-up permite conocer al Product Owner las versiones previstas, las
funcionalidades de cada una, velocidad estimada, fechas previstas, margen de error y
velocidad real.


Fuente: Flexibilidad con Scrum


19

Este grfico se representa con el esfuerzo estimado y los sprints planificados. Conocido el
esfuerzo de cada una de las versiones o funcionalidades nos permite visualizar el momento o
sprint en el que llegamos a nuestro objetivo en funcin de la velocidad a la que avancemos.
Conclusin
Tras esta introduccin a Scrum tenemos claros los conceptos que a partir de este momento
podremos utilizar en nuestro proyecto. Los conceptos sern de aplicacin tanto para la gestin
de nuestro proyecto, como para definir los objetivos del proyecto.

Para finalizar es importante sealar que estas son simples prcticas giles agrupadas en un
nombre (Scrum). Utilizar una de ellas estrictamente no es algo flexible y perdera su esencia.
Se pueden combinar y adaptar prcticas giles de una y otra metodologa en funcin de
nuestro escenario y nuestros requisitos.

Nuestro objetivo es encontrar flexibilidad y esta se consigue conociendo todas nuestras
posibilidades y emplearlas de la forma ms adecuada a las circunstancias de cada proyecto y/o
de cada empresa.

Kanban
Kanban es una herramienta muy utilizada en la gestin gil que no viene asociada a una
metodologa concreta pero que resulta muy til en combinacin con las metodologas giles
como herramienta de gestin visual. En ningn caso se debe entender como una metodologa
en s misma, sino una tcnica para comunicar informacin relativa a los trabajos que
realizamos.

Gestin Visual: Toda la informacin relevante debe estar a la vista. Uno de los primeros
sectores en utilizarla fue el automovilismo en su propio proceso de construccin y
posteriormente se traslad para comunicar las normas de circulacin (Seales de trfico).

Teniendo en cuenta la gestin visual, Kanban se define como sistema de sealizacin para
comunicar informacin relativa y necesaria en la ejecucin o monitorizacin de trabajos. [6]

El hecho de que sea tan visual y fsico hace que sea ptimo para proyectos giles y cada vez
hay ms adaptaciones de proyectos Scrum que adaptndolo a sus necesidades utilizan
Kanban para representar los elementos que forman Scrum. Esto se produce entre otras cosas
gracias a que Kanban no define un formato cerrado de tarjetas o tableros Kanban. Esto no
dara la flexibilidad necesaria para adaptar las tcnicas a las caractersticas de una
organizacin concreta.

Si enmarcamos Kanban dentro de los proyectos giles, se le pueden atribuir caractersticas que
favorecen el cumplimiento de los principios giles. Favorece la comunicacin, la cultura del
equipo y colaboracin. Facilita el control o gestin del proyecto ya que los elementos grficos
reflejan esta informacin en todo momento.
20


Puede ser un elemento a tener en cuenta dentro de aplicaciones informticas mejorando la
comunicacin con los usuarios y en nuestro caso concreto dando a conocer la informacin
global de uno o varios proyectos con una primera consulta visual.


21

Descripcin del producto a desarrollar
Escenario
Vistos los distintos tipos de metodologas que se contemplan, entramos a describir el entorno
del cliente, el modo de trabajo, los equipos de trabajo, la estructura organizativa y el objetivo de
producto para el cliente.

Se trata de una mediana empresa en la que el departamento de Sistemas de la Informacin
est compuesto por dos reas separadas de trabajo, Hardware y Software. En este caso
concreto el departamento est formado por 10 miembros.

La gestin de proyectos se realiza con metodologas giles adaptadas. Esto quiere decir que
no siempre tenemos equipos multidisciplinares como pueden exigir algunas metodologas
inicialmente. No siempre te puedes permitir el pair programing debido a las dimensiones del
departamento. Los integrantes de cada equipo pueden variar en funcin del proyecto/s en
curso. En determinadas fases de un proyecto se puede echar mano de otro compaero, ya sea
del mismo rea o no, es decir hay miembros del equipo que se incorporan para unas tareas
concretas y no durante todo el proyecto.

Solo el departamento IT utilizar la aplicacin para la gestin de proyectos que pretendemos
desarrollar. El resto de departamentos o no necesita esta gestin o ya tiene sus propias
herramientas.

Teniendo en cuenta este tipo de limitaciones y otras muchas que iremos detallando, el principal
objetivo del cliente es poder medir. El propio departamento necesita conocer los costes de
tomar unas u otras decisiones, permitiendo analizar los resultados y mejorar en la toma de
decisiones. Adems otros departamentos como el de administracin necesitan conocer los
costes econmicos de un desarrollo interno, soporte tcnico, deuda tcnica
4
, etc. Es decir,
tenemos el mismo personal para la ejecucin de proyectos, para resolver dudas tcnicas,
resolucin de incidencias, o bugs provenientes de otros desarrollos.

Actualmente no hay una gestin controlada de estas interrupciones y ante estas situaciones es
necesario establecer prioridades y proceder, el equipo es autosuficiente para tomar las
decisiones que considere oportunas. Como consecuencia los proyectos se pueden ver
afectados en alguno de los tres conceptos del tringulo de hierro.

Por parte del departamento de IT y siguiendo con los principios giles, los integrantes del
equipo no necesitan conocer cunto tiempo han empleado en realizar un tarea, sprint, iteracin,
un proyecto...Lo necesario para ellos es conocer cunto falta para llegar al objetivo.


4
La deuda tcnica es un eufemismo tecnolgico que hace referencia a las consecuencias de un
desarrollo apresurado de software o un despliegue descuidado de hardware.
22

El cliente no impone ninguna restriccin del tipo de proyecto a acometer, si tiene que ser una
aplicacin propietaria, una aplicaciones base que podamos adoptar o un servicio SaaS
(Software as a Service).


Al cance
En una primera aproximacin se detectan los objetivos de negocio que detallaremos a
continuacin. Estos vienen determinados por ramas bien diferenciadas. En primer lugar los
objetivos del propio departamento de IT, que necesita de una herramienta para gestionar
proyectos con Scrum y en segundo lugar para departamentos externos que lleven el control de
costes y anlisis de proyectos internos.

La aplicacin gestiona proyectos, usuarios y equipos. Los usuarios con un perfil personal se
agrupan en equipos con un rol determinado. A su vez un equipo tiene asignado un proyecto. Y
los proyectos contienen toda la informacin relacionada: actas, historias de usuarios, contratos,
planificacin, coste real, etc. Aunque no es un requisito propio de la metodologa, es muy til la
posibilidad de tener la informacin asociada al proyecto.

Siguiendo la definicin de Scrum, el cliente forma parte del equipo, pero por ahora no se sabe
si este tiene que poder utilizar la aplicacin o no.

Una vez procesados los objetivos de negocio, tenemos las tareas agrupadas por historias de
usuario. Es necesario que estas tareas sean asignadas a los miembros del equipo. Para que se
pueda asignar una tarea tiene que estar completa, con coste estimado de realizacin. Los
miembros del departamento IT tienen una restriccin de productividad: Les impide tener varias
tareas en ejecucin. A medida que las tareas estn completas, a los usuarios se les van
asignando otras en ejecucin. Adems todo esto debe permitir recoger la duracin real del
proyecto.

En numerosas ocasiones los usuarios interrumpen la ejecucin de una tarea para realizar otra
ms urgente. Es el caso de bugs informticos, nuevas funcionalidades en proyectos anteriores,
que tienen mayor prioridad que el proyecto en curso y es necesario cambiar de tarea.

Los errores o tareas clasificadas con prioridad urgente se gestionan del siguiente modo.
Cuando se decide qu tenemos que hacer, la tarea se asigna a uno de los empleados del Dpto.
y este valorar su alcance, pudiendo llegar a ser un proyecto nuevo o una versin de otro
anterior. Si se trata de un error o algo de menor alcance se decide quin la ejecuta y se
procede. Puede ser necesaria la intervencin de varios compaeros.

Como ya hemos comentado anteriormente, debemos conocer el avance y coste de cada
proyecto, incluso de los que estn en ejecucin, teniendo en cuenta que para el equipo Scrum
lo necesario ser conocer qu falta por hacer.

23

Por ahora tampoco se contempla que la documentacin se gestione de forma interna con
herramientas de colaboracin. Puede ser necesario adjuntar archivos a los proyectos e incluso
solventar los problemas de versin de archivos de un modo transparente. Un ejemplo de
documentacin a aadir pueden ser los manuales de usuario.

Para mostrar la informacin de control se debe tener la posibilidad de exportar en distintos
formatos que nos permitan trabajar con los datos. A travs de los informes tambin podremos
conocer el origen, los costes y toda la informacin relacionada con los trabajos ejecutados por
el equipo.

Respecto a las mtricas que deber permitir, partimos de dos requisitos, uno viene dado por la
gestin de proyectos giles, permitir estimar el coste de los objetivos. Y el segundo requisito,
dado por el cliente, es que debe permitir conocer las horas invertidas en cada tarea y/o el coste
final real de cada tarea. Aunque se tiene claro que el clculo de los costes es un requisito
prioritario, por ahora no existe una decisin unilateral de qu mtrica utilizar.

Podramos utilizar el tiempo en horas pero no para todo el mundo significa lo mismo una hora
de su tiempo. Podemos asignar un coste monetario a una hora de trabajo. O concretar una
hora de trabajo y un usuario especfico. Pero las tareas luego no tienen el mismo valor, los
empleados tienen un coste variable...Entramos en un escenario que no tenemos claro y
tomaremos una decisin durante la marcha del proyecto. Por ahora tomamos la decisin de
que controlamos nicamente el tiempo.


Product Backlog
A continuacin detallamos la primera versin de nuestro Product Backlog. Conforme vayamos
completando las historias de usuarios este podr sufrir modificaciones en cada iteracin. Se
han divido en dos tipos de historias de usuarios, las historias que aportan funcionalidad y valor
al usuario y las historias no funcionales pero que de algn modo aportan valor y hemos
considerado oportuno que aparezcan.




2
4


I
d
e
n
t
i
f
i
c
a
d
o
r

O
b
j
e
t
i
v
o
D
e
s
c
r
i
p
c
i

n
C
o
s
t
e

e
s
t
i
m
a
d
o
C
o
n
d
i
c
i
o
n
e
s

d
e

s
a
t
i
s
f
a
c
c
i

n
V
a
l
o
r

a
p
o
r
t
a
d
o
A
1
D
a
r

a
l
t
a

p
r
o
y
e
c
t
o
3
0
0
Q
u
i
e
r
o

c
r
e
a
r

e
l

p
r
o
y
e
c
t
o

a

t
r
a
v
e
s

d
e

u
n

f
o
r
m
u
l
a
r
i
o
.
1
0
0
0
A
l

c
r
e
a
r

e
l

p
r
o
y
e
c
t
o

m
e

d
e
b
e

p
e
r
m
i
t
i
r

a
s
i
g
n
a
r

m
i
e
m
b
r
o
s

d
e
l

e
q
u
i
p
o
A
2
E
l
i
m
i
n
a
r
/
F
i
n
a
l
i
z
a
r

p
r
o
y
e
c
t
o
s
3
0
0
P
o
d
e
m
o
s

e
l
i
m
i
n
a
r

u
n

p
r
o
y
e
c
t
o

q
u
e

n
o

t
i
e
n
e

a
s
i
g
n
a
d
o
s

m
i
e
m
b
r
o
s

d
e
l

e
q
u
i
p
o

n
i

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o

a
s
o
c
i
a
d
a
s
.
2
0
0
S
i

e
l

p
r
o
y
e
c
t
o

y
a

t
i
e
n
e

i
n
f
o
r
m
a
c
i
o
n

a
s
o
c
i
a
d
a

n
o

s
e

e
l
i
m
i
n
a

c
u
a
n
d
o

e
s

d
a
d
o

d
e

b
a
j
a
S
i

e
l

p
r
o
y
e
c
t
o

t
i
e
n
e

l
a
s

t
a
r
e
a
s

a
s
o
c
i
a
d
a
s

e
n

e
s
t
a
d
o

f
i
n
a
l
i
z
a
d
o

s
e

c
e
r
r
a
r

.
A
3
A
l
t
a

H
i
s
t
o
r
i
a

d
e

U
s
u
a
r
i
o
2
0
0
D
e
b
e
r

s
e
r

a
s
i
g
n
a
d
a

a

u
n

p
r
o
y
e
c
t
o
.
1
0
0
0
D
e
b
e

c
o
n
t
e
n
e
r

u
n

t

t
u
l
o

c
o
r
t
o

i
d
e
n
t
i
f
i
c
a
d
o
r
,

u
n
a

b
r
e
v
e

d
e
s
c
r
i
p
c
i

n
,

e
l

v
a
l
o
r

a
p
o
r
t
a
d
o

p
a
r
a

e
l

c
l
i
e
n
t
e

y

e
l

c
o
s
t
e

e
s
t
i
m
a
d
o
.
A
4
M
o
d
i
f
i
c
a
r

H
i
s
t
o
r
i
a

d
e

U
s
u
a
r
i
o
2
0
0
S
e

p
o
d
r

n

m
o
d
i
f
i
c
a
r

l
o
s

d
a
t
o
s

d
e

a
l
t
a

s
a
l
v
o

e
l

i
d
e
n
t
i
f
i
c
a
d
o
r
.
5
0
0
N
o

s
e

p
o
d
r

m
o
d
i
f
i
c
a
r

l
o
s

d
a
t
o
s

d
e

a
l
t
a

s
i

l
a

h
i
s
t
o
r
i
a

s
e

e
n
c
u
e
n
t
r
a

e
n

e
j
e
c
u
c
i

n
.
A
5
A
c
c
e
s
o

c
l
i
e
n
t
e
,

H
i
s
t
o
r
i
a
s

U
s
u
a
r
i
o
3
0
0
A
l

a
c
c
e
d
e
r

a

u
n
a

h
i
s
t
o
r
i
a

d
e

u
s
u
a
r
i
o

p
u
e
d
e

m
o
d
i
f
i
c
a
r

e
l

v
a
l
o
r

a
p
o
r
t
a
d
o
5
0
0
C
o
n
o
c
e
r

e
l

e
s
t
a
d
o

d
e

l
a
s

h
i
s
t
o
r
i
a
s
,

p
o
r

e
m
p
e
z
a
r
,

e
n

e
j
e
c
u
c
i

n

o

f
i
n
a
l
i
z
a
d
a
.
A
6
C
r
e
a
c
i

n

d
e

t
a
r
e
a
s
4
0
0
P
a
r
a

l
a

c
r
e
a
c
i

n

d
e

u
n
a

t
a
r
e
a

d
e
b
e
m
o
s

i
n
d
i
c
a
r

u
n

n
o
m
b
r
e
,

u
n
a

d
e
s
c
r
i
p
c
i

n

b
r
e
v
e

y

u
n

c
o
s
t
e

e
s
t
i
m
a
d
o
1
0
0
0
D
e
b
e
r

e
s
t
a
r

a
s
i
g
n
a
d
a

a

u
n
a

h
i
s
t
o
r
i
a

d
e

u
s
u
a
r
i
o
.
P
u
e
d
o

a
s
i
g
n
a
r

l
a

t
a
r
e
a

a

u
n

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o


P
r
o
d
u
c
t

B
a
c
k
l
o
g

V
e
r
s
i

n

1

2
5


I
d
e
n
t
i
f
i
c
a
d
o
r

O
b
j
e
t
i
v
o
D
e
s
c
r
i
p
c
i

n
C
o
s
t
e

e
s
t
i
m
a
d
o
C
o
n
d
i
c
i
o
n
e
s

d
e

s
a
t
i
s
f
a
c
c
i

n
V
a
l
o
r

a
p
o
r
t
a
d
o
A
7
P
r
o
c
e
s
a
r

t
a
r
e
a
s
4
0
0
P
u
e
d
o

a
u
t
o
a
s
i
g
n
a
r
m
e

t
a
r
e
a
s

q
u
e

n
o

e
s
t

n

a
s
i
g
n
a
d
a
s

a

o
t
r
o

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o
.
1
0
0
0
P
u
e
d
o

r
e
l
l
e
n
a
r

e
l

c
o
s
t
e

d
e

r
e
a
l

d
e

l
a

t
a
r
e
a
s

a
s
i
g
n
a
d
a
s
.
P
u
e
d
o

m
o
d
i
f
i
c
a
r

e
l

e
s
t
a
d
o

d
e

u
n
a

t
a
r
e
a
:

e
n

e
j
e
c
u
c
i

n
,

p
a
u
s
a
,

t
e
r
m
i
n
a
d
a
.
A
8
A
c
c
e
s
o

D
i
r
e
c
t
o
r
,

P
r
o
y
e
c
t
o
s
3
0
0
A
l

a
c
c
e
d
e
r

a
l

p
r
o
y
e
c
t
o

s
e

l
e

d
a

a
c
c
e
s
o

a

t
o
d
a

l
a

i
n
f
o
r
m
a
c
i

n

d
e

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o

y

t
a
r
e
a
s

q
u
e

e
s
t

n

r
e
l
a
c
i
o
n
a
d
a
s
.
6
0
0
E
x
p
o
r
t
a
r

i
n
f
o
r
m
e
s

c
o
n

l
o
s

d
a
t
o
s

a
c
t
u
a
l
e
s
.
A
9
R
e
p
r
e
s
e
n
t
a
c
i
o
n

v
i
s
u
a
l

d
e

l
o
s

d
a
t
o
s
1
2
0
0
P
u
e
d
o

v
e
r

e
l

G
r

f
i
c
o

B
u
r
n
-
D
o
w
n

e
n

b
a
s
e

a

l
o
s

d
a
t
o
s

d
e

c
a
d
a

p
r
o
y
e
c
t
o
.
5
0
0
P
u
e
d
o

v
e
r

e
l

G
r

f
i
c
o

B
u
r
n
-
U
P

e
n

b
a
s
e

a

l
o
s

d
a
t
o
s

d
e

c
a
d
a

p
r
o
y
e
c
t
o
.
A
1
0
A

a
d
i
r

d
o
c
u
m
e
n
t
a
c
i
o
n

E
x
t
e
r
n
a
2
0
0
P
u
e
d
o

d
e
c
a
r
g
a
r

d
o
c
u
m
e
n
t
o
s

a
d
j
u
n
t
o
s

a

u
n

p
r
o
y
e
c
t
o
.
1
0
0
A
1
1
C
o
n
t
r
o
l

d
e

v
e
r
s
i
o
n
e
s

p
a
r
a

a
r
c
h
i
v
o
s
2
0
0
0
P
u
e
d
o

c
o
n
o
c
e
r

e
l

h
i
s
t
o
r
i
a
l

d
e

u
n

d
o
c
u
m
e
n
t
o

q
u
e

a
n
t
e
r
i
o
r
m
e
n
t
e

h
e

d
e
s
c
a
r
g
a
d
o
.
2
0
0
P
u
e
d
o

c
o
n
o
c
e
r

e
l

h
i
s
t
o
r
i
a
l

d
e

u
n

d
o
c
u
m
e
n
t
o

q
u
e

a
n
t
e
r
i
o
r
m
e
n
t
e

h
e

a
d
j
u
n
t
a
d
o

a
l

p
r
o
y
e
c
t
o
.
A
1
2
R
e
p
r
e
s
e
n
t
a
c
i

n

v
i
s
u
a
l

d
e

l
o
s

e
l
e
m
e
n
t
o
s

S
c
r
u
m

(
K
a
n
b
a
n
)
1
3
0
0
P
u
e
d
o

c
o
n
s
u
l
t
a
r

l
a

i
n
f
o
r
m
a
c
i
o
n

d
e

p
r
o
y
e
c
t
o
s

y

s
u
s

e
l
e
m
e
n
t
o
s

d
e

f
o
r
m
a

v
i
s
u
a
l
.
4
0
0
A
1
3
A
s
i
g
n
a
c
i

n

d
e

p
e
r
m
i
s
o
s

e
n
t
r
e

r
o
l
e
s

d
e

u
s
u
a
r
i
o
1
5
0
0
E
l

a
d
m
i
n
i
s
t
r
a
d
o
r

d
e

l
a

p
l
a
t
a
f
o
r
m
a

p
u
e
d
e

a
s
i
g
n
a
r

p
e
r
m
i
s
o
s

p
a
r
a

u
n
a

f
u
n
c
i
o
n
a
l
i
d
a
d

c
o
n
c
r
e
t
a
1
0
0
A
1
4
W
o
r
k
f
l
o
w

m
e
t
o
d
o
l
o
g

g
i
l

(
S
c
r
u
m
)
1
2
0
0
A
1
5
R
e
u
n
i
o
n
e
s

(
s
c
r
u
m

d
i
a
r
i
o
)
1
0
0
0
A
1
6
S
p
r
i
n
t

B
a
c
k
l
o
g
3
0
0


P
r
o
d
u
c
t

B
a
c
k
l
o
g

V
e
r
s
i

n

1

2
6


I
d
e
n
t
i
f
i
c
a
d
o
r

O
b
j
e
t
i
v
o
D
e
s
c
r
i
p
c
i

n
C
o
s
t
e

e
s
t
i
m
a
d
o
C
o
n
d
i
c
i
o
n
e
s

d
e

s
a
t
i
s
f
a
c
c
i

n
V
a
l
o
r

a
p
o
r
t
a
d
o
B
1
L
o
g
i
n

d
e


u
s
u
a
r
i
o
s
4
0
0
A
l

a
c
c
e
d
e
r

a

u
n
a

f
u
n
c
i
o
n
a
l
i
d
a
d
/
r
u
t
a

s
e

d
e
b
e
r

c
o
m
p
r
o
b
a
r

q
u
e

u
n

u
s
u
a
r
i
o

e
x
i
s
t
e
n
t
e

e
n

l
a

B
D

s
e

h
a

i
d
e
n
t
i
f
i
c
a
d
o

c
o
n

s
u

u
s
u
a
r
i
o

y

p
a
s
s
w
o
r
d
.
1
1
0
0
B
2
C
r
e
a
r

u
s
u
a
r
i
o
s
2
0
0
A
l

c
r
e
a
r

u
n

u
s
u
a
r
i
o

t
i
e
n
e

q
u
e

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

s
u

a
c
c
e
s
o
1
1
0
0
S
i

s
e

t
r
a
t
a

d
e

u
n

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

p
a
r
a

a
s
i
g
n
a
r

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o
S
i

s
e

t
r
a
t
a

d
e

u
n

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

p
a
r
a

a
s
i
g
n
a
r

t
a
r
e
a
s
B
3
D
a
r

d
e

b
a
j
a

u
s
u
a
r
i
o
s
3
0
0
A
l

d
a
r

d
e

b
a
j
a

u
n

u
s
u
a
r
i
o

d
e
j
a

d
e

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

s
u

a
c
c
e
s
o
4
0
0
S
i

e
s

u
n

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o

d
e
j
a
r

d
e

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

p
a
r
a

s
e
r

a
s
i
g
n
a
d
o

c
o
n

t
a
r
e
a
s

u

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o
.
B
4
D
e
f
i
n
i
r

y

c
r
e
a
r

u
n
a

i
n
t
e
r
f
a
z

g
r
a
f
i
c
a
2
0
0
S
e
r

a
p
r
o
b
a
d
a

p
o
r

e
l

c
l
i
e
n
t
e
.

E
n

n
i
n
g

n

c
a
s
o

s
e
r

u
n
a

i
n
t
e
r
f
a
z

r
e
a
l
,

s
i
m
p
l
e
m
e
n
t
e

u
n

b
o
c
e
t
o

d
e

l
a

m
i
s
m
a

p
a
r
a

d
e
f
i
n
i
r

e
s
t
r
u
c
t
u
r
a

y

l
a

o
r
g
a
n
i
z
a
c
i

n

d
e
l

c
o
n
t
e
n
i
d
o
.
2
0
0
B
5
T
D
D

(
T
e
s
t

D
r
i
v
e
n

D
e
v
e
l
o
p
m
e
n
t
)
>
6
0
0
S
u

p
r
o
p
i
o

f
u
n
c
i
o
n
a
m
i
e
n
t
o

e
s

l
a

c
o
n
d
i
c
i

n

d
e

a
c
e
p
t
a
c
i

n
1
1
0
0
B
6
T
e
c
n
o
l
o
g

a

y

H
e
r
r
a
m
i
e
n
t
a
s
8
0
0
L
a
s

c
o
n
c
l
u
s
i
o
n
e
s

f
i
n
a
l
e
s
,

c
o
m
o

r
e
s
u
l
t
a
d
o

d
e

l
o
s

p
r
o
b
l
e
m
a
s

o

d
i
f
i
c
u
l
t
a
d
e
s

q
u
e

h
a
y
a
m
o
s

t
e
n
i
d
o

n
o
s

s
e
r
v
i
r

n

p
a
r
a

c
o
n
o
c
e
r

e
l

g
r
a
d
o

d
e

s
a
t
i
s
f
a
c
c
i

n
.
1
1
0
0
T
o
t
a
l
1
3
0
0
0



P
r
o
d
u
c
t

B
a
c
k
l
o
g

V
e
r
s
i

n

1

27

Estudio de mercado

Antes de pasar a desarrollar el proyecto, se analizar el mercado para ver las soluciones
existentes y ver si es necesario realizar un desarrollo propio, o adaptar alguna aplicacin que
ya exista en el mercado.

Actualmente el desarrollo del software avanza cada vez ms rpido y es posible que si
investigamos a fondo soluciones que ya tenemos en el mercado puedan resultar
completamente funcionales para nuestro cliente y nicamente tengamos que gestionar su
implantacin despus de verificar que los objetivos de nuestro cliente estn cubiertos.

En esta primera fase de investigacin de mercado detectamos las siguientes aplicaciones que
estn relacionadas con alguno de los objetivos del proyecto. A partir de la definicin de
nuestras historias de usuario, se proceder con el anlisis de las mismas para revisar qu
aspectos no son cubiertos y comparar con las prioridades asignadas por nuestro Product
Owner en los objetivos del mismo. Si en algn caso no se cubren las historias de usuarios con
mayor prioridad esta aplicacin ser descartada inmediatamente.

Detalle de las aplicaciones destacadas

Trello.com

Se podra definir como un tablero virtual, nos permite configurar varios tableros, aadir otros
usuarios con los que compartir nuestros tableros y un historial de cambios as como
notificaciones. En definitiva es una pizarra Kanban a la que podemos acceder va web. Al ser
nicamente tableros deja a un lado la parte de gestin de proyectos, historias de usuarios y su
posterior anlisis.

J ira

Bastante ms complejo que el anterior ya que no se trata de un simple aplicacin web. Cuenta
con multitud de plugins que nos permiten aadir funcionalidad adicional en base a nuestros
requisitos, podemos desarrollar nuestros propios plugins e incluso comercializarlos. La mayor
dificultad de esta opcin sera el adecuarnos a una forma concreta de hacer las cosas. Aunque
sea personalizable siempre existe la posibilidad de que el mtodo de trabajo no sea el que
busca el cliente. Respecto al precio por ahora estaramos hablando de 50$ mensuales
permitiendo hasta 15 usuarios, totalmente escalable si crecemos en usuarios.

Esta opcin nos obligara a formarnos en dicha herramienta o contratar alguien con
experiencia, adems de formarnos como usuarios para poder implantar la solucin en nuestro
cliente.
28



Groupcamp.es

Se presenta como una aplicacin web para el trabajo en equipo aadiendo la gestin del
tiempo y los presupuestos. Permite conectarse con otras aplicaciones como Office, Google,
email interno. La falta de plugins o acceso a un API, nos impedira modificar la aplicacin y/o
aadir nuevas funcionalidades especficas. Adems aunque la aplicacin permite la gestin de
proyectos y una amplio abanico de funcionalidades relacionadas no trata una metodologa
concreta como es nuestro caso.

Detalladas las tres aplicaciones que ms nos han interesado durante el anlisis de mercado y
en un principio nos podran ayudar, tras un segundo anlisis ms exhaustivo nos encontramos
una aplicacin que no gestiona proyectos, otra aplicacin que gestiona proyectos sin seguir una
metodologa y una tercera aplicacin, plataforma con plugins y api, muy completa la cual no
conocemos y sera necesaria formacin y/o ayuda externa y que adems podra aadir
complejidad con opciones que nuestro cliente no tiene intencin alguna de utilizar por ahora.



Aspectos ticos y de seguridad

A la hora de llevar a cabo el proyecto deberemos tener presente una serie de aspectos legales,
ticos y de seguridad que pueden influir en los requisitos del mismo.

Desde el punto de vista tico, la aplicacin trata relaciones laborales del grupo de desarrollo
con otros miembros de la empresa del mismo rango o superior.

Aunque la propia empresa no persiga la finalidad de controlar a los empleados, estos pueden
pensar lo contrario. Pueden llegar a dudar de la privacidad ante otros compaeros, etc.
Adems para la empresa puede resultar muy tentador comparar las mtricas de uno u otro
empleado. Esto influye directamente en una de las historias de usuario proyectadas (A7) segn
la cual solo debemos ver nuestro control de tiempos y un coste total del resto de usuarios.

Si durante la ejecucin del proyecto surgen otras cuestiones relacionadas con los aspectos
ticos deberemos tenerlas en cuenta para garantizar a las partes implicadas que se cumplen
estas condiciones y su privacidad est asegurada en la medida de lo posible.

Como toda aplicacin informtica deber tener presente en todo momento la seguridad. Una
vez est concretado el tipo de aplicacin (extranet, intranet, escritorio), se tendrn en cuenta
las medidas de seguridad ms adecuadas. Por ahora se conoce que la aplicacin manejar
datos de empleados, de proyectos internos de la empresa, de clientes y proveedores que
29

debern confiar en la herramienta que les proporciona nuestro cliente. En este punto contamos
con cierta incertidumbre, es decir, lo que para alguien se considera inseguro puede ser una
garanta de seguridad para otro. Aclaramos este punto con el siguiente ejemplo. Una aplicacin
basada en software libre y mantenida por una amplia comunidad de usuarios nos da las
garantas de que un fallo en la seguridad ser notificado y solucionado con bastante premura.
Pero a su vez esto hace que un posible atacante pueda aprovecharlo para conocer nuestras
debilidades antes de ser subsanadas.

Otro aspecto de vital importancia sern los aspecto legales. Estamos realizando una pgina
web con datos personales de clientes, proveedores y empleados, es decir deberemos cumplir
la LOPD. En este caso debemos incluir una referencia de los datos personales que trata la
pgina web (nombre y correo electrnico), explicando el uso que haremos de estos datos. La
LOPD tambin nos obliga a cumplir una serie de polticas de seguridad y registrar nuestro
fichero de datos personales en la AEPD, Agencia Espaola de Proteccin de Datos [7].

Una medida de seguridad a la hora de utilizar un mecanismo de identificacin mediante usuario
y contrasea ser aplicar un mecanismo de cifrado con salt
5
y a su vez un algoritmo de cifrado
concreto que por ahora no se considere inseguro en caso de que alguien acceda al
almacenamiento de nuestras contraseas. El uso de salt criptogrfico aade una dificultad
extra a la hora de intentar crackear un hash almacenado en la base de datos.

En cuanto a la seguridad fsica, se podr dar el caso de que tengamos que elegir un proveedor
u otro si los datos requieren de un hardware especfico para garantizar mayor nivel de
seguridad, contratar un hardware especfico (Ej: firewalls), o incluso instalar la aplicacin en un
servidor propio del cliente de modo que ste tenga el control de los mismos. Por ahora estos
requisitos no se conocen y se plantean durante la ejecucin del proyecto.





5
Salt Criptogrfico: Un salt criptogrfico es un dato que se utiliza durante el proceso de hash para
eliminar la posibilidad de que el resultado pueda buscarse a partir de una lista de pares precalculados de
hash y sus entradas originales. Fuente: php.net.
30


Planificacin y metodologa

En primer lugar detallar que la metodologa a seguir se basa en las metodologas giles que
hemos descrito en este captulo, concretamente Scrum. Siguiendo el guin
6
predefinido para
Trabajos Fin de Grado, describiremos la ejecucin del proyecto con los conceptos definidos por
la metodologa que realmente nos resulten tiles buscando el objetivo principal de las
metodologas giles, no utilizar una metodologa rgida sino adaptarla a nuestras necesidades.

Para afrontar la ejecucin del desarrollo se han identificado los objetivos de negocio en
historias de usuario, asignado un coste aproximado, un valor de negocio y priorizando en
funcin de estos valores. Para estimar el coste no se han utilizado tcnicas especficas como
las mencionadas en la descripcin de la metodologa, debido a que el equipo se compone de
una nica persona y las ventajas que nos ofrecen son fomentar la participacin y evitar los
malentendidos entre los miembros de un equipo. Para dar prioridad hemos tenido en cuenta
que nuestros objetivos de negocio no son los mismos que para un cliente real. En vez de un
beneficio econmico, se busca un beneficio acadmico.

Otro punto a diferenciar entre Scrum y nuestra ejecucin son las reuniones. Aunque se han
celebrado reuniones despus de cada iteracin (reunin de revisin y de preparacin) y se ha
ido revisando avance del sprint durante su ejecucin (reunin diaria), en ambos casos no se
han seguido al pie de la letra las recomendaciones que implica Scrum; es decir, realizar la
reunin de forma automtica, sin tener en cuenta que es la primera tarea del da, juntar
reuniones de revisin con reuniones de preparacin, etc.

Respecto a la planificacin hay que tener en cuenta que hay establecidas las siguientes
limitaciones: 300 horas y entrega a mediados del mes de J unio. Con una dedicacin de 19
horas a la semana en 4 meses cumpliramos la horas estipuladas y dejaramos un pequeo
margen para posibles interrupciones. Dentro de la planificacin de sprints o iteraciones
tenemos en cuenta que disponemos de un tiempo limitado y para obtener un producto con una
funcionalidad aceptable los sprints no deben superar la duracin de 1 semana. A partir de la
duracin de 1 semana por sprint hemos asignado coste estimado en el Product Backlog y la
velocidad media de desarrollo debera ser de 1000 puntos por semana.

6
Guin predefinido por la Facultad de Ciencias, Estudios Agroalimentarios e Informtica de la
Universidad de La Rioja
31


En el grfico anterior se representa la lnea de tiempo planificada. Al comienzo del mismo est
la fase de documentacin, compuesta por la exposicin del problema y documentacin sobre el
tema del proyecto que formar el primer mes. La segunda parte, Anlisis, nos ocupa la primera
mitad del segundo mes, que contina con el desarrollo de la aplicacin durante 2 meses. Y
para finalizar dejamos 2 semanas como mnimo para la redaccin de la memoria final, sacar
conclusiones y finalizar el proyecto.

Ahora para reflejar la correspondiente planificacin haciendo uso de las herramientas que nos
proporciona Scrum vamos a utilizar el grfico Burn-up.


32

El Burn-up anterior nos muestra la comparativa de una estimacin ideal frente a una optimista y
otra pesimista. Para realizar esta comparativa se ha aumentado y disminuido en 300 puntos la
velocidad por semana estimada anteriormente. Adems permite conocer en qu momento de
una u otra estimacin tendremos disponibles las distintas versiones. Para ello se estima que la
primera versin utilizable ser despus de la 2 iteracin en los 4000 puntos (Alpha) y una
segunda versin de prueba ms estable a los 8000 puntos (Beta). Ahora la grfica nos permite
conocer cmo la versin Beta puede acabar retrasndose hasta las 11 o 12 semanas de
duracin. Una vez este grfico empiece a dibujar la lnea de la duracin real nos iremos
haciendo una idea de cul es nuestra velocidad y estimar en cada momento cul ser nuestra
fecha fin para cada versin.


33


Dada la planificacin anterior podemos definir los sprints agrupando historias de usuario segn
su prioridad. La siguiente tabla nos muestra las historias de usuario priorizadas hasta la fecha y
agrupadas por iteraciones hasta la iteracin 2 que forman la versin Alpha. El resto de historias
priorizadas o no sern analizas e incluidas en prximas revisiones del Product Backlog.

N Sprint
Identificador
Objetivo Descripcin
Coste
estimado
Valor
aportado Prioridad
Iteracin 0 B6
Tecnologa y
Herramientas 800 1100 1
800
Iteracin 1 B1 Login de usuarios 400 1100 2
B5 TDD 600 1100 3
B2 Crear usuarios 200 1100 4
A1 Dar alta proyecto 300 1000 5
A2
Eliminar/Finalizar
proyectos 300 200 6
B4
Definir y crear una
interfaz grfica 200 200 7
2000
Iteracin 2 A3
Alta Historia de
Usuario 200 1000 8
A4
Modificar Historia de
Usuario 200 500 9
A6 Creacin de tareas 400 1000 10
A7 Procesar tareas 400 1000 11
1200
Versin Alpha 4000
A8
Acceso Director,
Proyectos 300 600 12
A5
Acceso cliente,
Historias Usuario 300 500 13
A9
Representacin visual
de los datos 1200 500 ?


Destacar cmo en algunos casos no se llega a la planificacin estimada y en otros la
sobrepasamos. Aunque podramos mezclar historias de usuario se ha preferido dejar las
historias de usuario agrupadas siguiendo la prioridad asignada inicialmente. La iteracin 1 tiene
un coste estimado de 2000 puntos y aunque podemos separarla creando otra iteracin se
prefiere dejar estas historias en la misma iteracin puesto que son la toma de contacto con el
framework de acceso a datos y TDD.

34

Desarrollo


En esta seccin vamos a detallar cmo hemos afrontado el proyecto, la descomposicin de las
historias de usuario en tareas, entrando en detalle de las tareas que se consideren oportunas y
detallando la evoluciones, describiendo as la organizacin y metodologa seguidas para el
desarrollo.


Historias de Usuario

En el Product Backlog se han incluido las historias de usuario funcionales que enumeramos
como resultado de los objetivos de negocio y en segundo lugar historias de usuario especiales
que contienen requisitos no funcionales o que se dan por supuesto. Destacar que en el Product
Backlog no se ha tenido en cuenta las primeras fase del TFG, la ejecucin de la memoria,
algunos aspectos de formacin e investigacin en metodologas giles ni la preparacin de la
defensa final.

Durante la creacin del Product Backlog y descomposicin de historias de usuario en tareas,
nos hemos perdido una parte valiosa de la metodologa que es poder ejecutar esta tareas en
equipo, permitiendo contrastar opiniones y detectar posibles errores. Como base para
comenzar estas tareas se han tenido en cuenta algunos consejos, malas prcticas,
consejos...como por ejemplo:

Escribir qu se debe hacer y no cmo se debe hacer.
Las tareas deben seguir los principios INVEST
7
.




7
INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable [8]
35

Iteracin 0

Esta primera iteracin denominada Iteracin 0 recibe este nombre por el hecho de la historia
de usuario (B6) que agrupa. Se ha dudado si incluirla en el Product Backlog. Finalmente
despus de varias reflexiones se cree conveniente que quede reflejado ya que se considera
como un punto igual o ms importante que el resto y el Product Owner o cliente debe ser
consciente de ello.


Backlog Tarea Tipo Descripcin Responsable Estimacin
B6 Tarea 1 Investigacin Brainstorming de
tecnologas/herramient
as
J .M 20%
B6 Tarea 2 Investigacin Brainstorming de
requisitos tcnicos
J .M 20%
B6 Tarea 3 Investigacin Documentarse sobre
las ideas destacadas
J .M 30%
B6 Tarea 4 Investigacin Toma de decisiones J .M 20%
B6 Tarea 5 Investigacin Control de versiones &
Scrum
J .M. 10%

En primer lugar detallar cmo se ha rellenado la columna de estimacin en este y el resto de
sprints backlogs. En este caso y debido al entorno y variabilidad que podemos obtener en las
horas dedicadas en un da se ha decidido incluir un porcentaje de la duracin completa del
Sprint. Dado el tipo de tareas que tratamos en esta iteracin, la duracin real de la misma no
ser muy valiosa para verificar las estimaciones realizadas.

Respecto a esta iteracin cabe destacar la tarea 4, "Toma de decisiones". Partiendo de los
requisitos del cliente, conocemos que deber ser accesible desde varias organizaciones; por
ello podemos concretar que vamos a desarrollar una aplicacin web ya que facilita dicho
requisito. Este tipo de aplicaciones se ven ms expuestas a posibles ataques y la informacin
puede estar expuesta, pero aplicando la medidas oportunas durante la fase de desarrollo se
asume el posible riesgo.

Una vez conocido el tipo de aplicacin las tecnologas a utilizar son ms concretas aunque
seguimos teniendo muchas posibilidades. En este punto y teniendo en cuenta el contexto y los
plazos de ejecucin, la experiencia del equipo ser un punto a tener en cuenta a la hora de
36

elegir la tecnologa. Por ello se cierran las opciones a programar con PHP valorando si
seleccionar un framework conocido o no. Las ltimas opciones a elegir son Silex
8
y
Codeigniter
9
. El primero se trata de un microframework que destaca por su gran velocidad de
desarrollo con multitud de libreras y su gran modularidad para seguir desarrollando
aplicaciones ms complejas. Adems se basa en Symphony
10
, otro framework PHP que ha se
ha ganado un nombre en la comunidad de desarrolladores durante los ltimos aos; sin
embargo su curva de aprendizaje es muy elevada. En este punto y teniendo en cuentas otros
objetivos tomamos la decisin de utilizar Codeigniter con el fin de ahorrar tiempo para
documentacin e investigacin de otros temas, ya que este framework es conocido por el
equipo.

Una vez seleccionado el framework buscamos un ORM
11
que nos facilite la implementacin en
la capa de acceso a datos. En este caso elegimos Datamapper
12
, no se conoce ningn ORM
anteriormente por lo que la decisin est basada en la documentacin encontrada del propio
ORM ya que est pensado nicamente para utilizar con Codeigniter y su instalacin es muy
sencilla. Otros ORM como Doctrine ms conocidos pueden resultar ms complejos
inicialmente.

En segundo lugar y para el almacenamiento de los datos que conectar con el ORM utilizamos
MySQL
13
, simplemente por ser el SGBD ms conocido por el equipo y su facilidad de uso.

Para llevar a cabo la implementacin de las distintas funcionalidades y teniendo en cuenta que
estamos utilizando una metodologa gil vamos a profundizar en el desarrollo guiado por test o
ms conocido como Test Driven Development (TDD). Por ello en esta fase nos hemos
adentrado en su filosofa y cul es el mtodo a seguir sin centrarnos en cmo implementarlo en
PHP. Para ello se ha incluido una historia de usuario especfica en la siguiente iteracin.

Por ltimo detallar que para llevar un control del desarrollo utilizaremos software de control de
versiones, concretamente GIT. El resto de opciones son desconocidas y esta nos permite una
instalacin descentralizada y no requiere configuraciones complejas. Siguiendo el objetivo
principal el flujo de trabajo con GIT vendr dado por la metodologa gil. De este modo con
cada historia de usuario crearemos un rama (branch) a partir de la cual iremos creando otras
ramas por cada tarea dentro de la misma historia y que fusionamos a la rama principal de la
historia una vez est terminada la funcionalidad concreta de la tarea. Posteriormente podemos
eliminar las ramas de las tareas, guardando una referencia a la rama eliminada con una
etiqueta. Este mtodo ser seguido a su vez con la ramas que hacen referencia a las historias
de usuario. Una vez que son aprobadas, pasan a la rama principal de desarrollo
14
.


8
http://silex.sensiolabs.org
9
http://ellislab.com/codeigniter
10
http://symfony.com
11
ORM: Object-Relational mapping [9]
12
http://datamapper.wanwizard.eu/
13
http://www.mysql.com/
14
Se dan por supuestos los trminos y conocimientos propios de los Sistemas de control de versiones.
37

En el siguiente diagrama podemos ver el ciclo de creacin de ramas junto con las etiquetas que
se crean al fusionar una rama en otra y ser eliminadas. Ej: La rama task1 se fusiona con la
rama historia de usuario y creamos una etiqueta #task1 antes de seguir con la siguiente tarea
en la rama task2.




38

Iteracin 1
En esta segunda iteracin (considerada la primera desde el punto de vista de los requisitos del
cliente) vamos a tratar las historias de usuario A1, A2, B1, B3 y B4. Estas historias se
descomponen en el siguiente Sprint Backlog. Como vemos en el tabla, el nmero de tareas
respecto a la iteracin anterior ha aumentado considerablemente. Teniendo en cuenta el
nmero de tareas y que existen temas desconocidos para el encargado de las mismas,
ampliaremos la duracin de esta iteracin a 2 semanas (coincidiendo con el esfuerzo estimado
y planificacin del mismo).


Backlog Tarea Tipo Descripcin Responsable Estimacin
B1 Tarea 1 Anlisis y diseo Modelo de datos J .M 10%
B1 Tarea 2 Implementacin Crear clases MVC J .M 5%
B2 Tarea 3 Implementacin Creacin de
formularios y
mtodos
J .M 5%
B5 Tarea 3 Documentacin TDD y PHP J .M 20%
B5 Tarea 4 Implementacin Creacin de test
unitarios
J .M 10%
A1 Tarea 5 Implementacin Implementar MVC
para proyectos
J .M 10%
B5 Tarea 6 Pruebas Creacin de test
unitarios
J .M 15%
A2 Tarea 7 Implementacin Implementar
funcionalidad
J .M 5%
A2 Tarea 8 Pruebas Creacin de test
unitarios
J .M 10%
B4 Tarea 9 Implementacin Programar la
estructura y diseo
de las vistas
J .M 10%


Descompuestas las tareas de las historias que comprenden esta iteracin vamos a detallar los
aspectos ms importantes a la hora de llevar a cabo la iteracin.

Las historias B1 y B2 son la base para comprender el funcionamiento del ORM seleccionado. A
travs de un ejemplo que implementa un mecanismo de Login y creacin de usuarios creamos
39

nuestros modelos y controladores. Al mencionar modelos y controladores estamos
refirindonos al patrn MVC
15
, a travs del cual estructuramos la aplicacin.

En la siguiente historia de usuario (B5) comenzamos con la bsqueda de la herramientas
necesarias para llevar a cabo los test unitarios de forma ms cmoda. Los test unitarios es la
primera tarea que implica la tcnica TDD. En este caso y debido que es nuestra primera
aproximacin a esta tcnica, partimos de un desarrollo ya realizado sobre el que crearemos los
test unitarios. Como framework principal para test unitarios en PHP tenemos PHPUnit; a la hora
de abordar los tests sobre nuestras clases y mtodos especficos para el framework elegido,
utilizaremos otra librera externa, my-cuinit
16
que nos facilite la creacin de test entre PHPUnit y
CodeIgniter.

Obviando los pasos de instalacin y configuracin nos centraremos en un ejemplo de test
unitario con el fin de clarificar su funcionamiento. En este ejemplo vamos a testear el mtodo
privado encrypt de la clase modelo User.



Dado un nombre de campo (valor del campo $field) y un salt aleatorio guardar en la propiedad
que se corresponde con el valor del campo el contenido de dicha propiedad concatenado con el
salt y encriptado mediante el algoritmo sha512. Si el contenido de la propiedad es vaco no se
hace nada y si no tenemos un salt generamos uno aleatorio y encriptamos.


15
MVC o Modelo Vista Controlador: Patrn de arquitectura de software.
16
Framework para test unitarios con PHPUnit y Codeigniter 2.1.0 Fuente
40


Definido el funcionamiento del mtodo podemos testear las siguientes condiciones:

Si la propiedad a la que referencia el parmetro $field est vaca/empty (no tiene valor)
la propiedad deber seguir vaca.



Si la propiedad salt est vaca al ejecutar el mtodo se crear un salt y almacenar el
valor en la propiedad.



Si la propiedad salt tiene un valor este ser el mismo despus de ejecutar el mtodo.




41

Si la propiedad que pasamos como parmetro tiene valor, despus de ejecutar el
mtodo no ser el mismo.



Tras ejecutar el mtodo el valor almacenado en la propiedad que hace referencia el
valor del campo $field deber ser igual a la concatenacin del salt con el valor de la
propiedad encriptados con el algoritmo sha512.



En este punto hemos creado 5 test unitarios que verifican el correcto funcionamiento del
mtodo encrypt. La finalidad de los test unitarios es testear la nica responsabilidad de un
mtodo, en este caso encriptar la cadena correspondiente cuando se cumplen las condiciones.

Un test est formado por tres partes, que se denominan con las siglas AAA: Arrange, Act,
Assert, es decir, preparar, actuar y afirmar. Esto hace que en muchos test la fase de Arrange
sea la misma y los frameworks nos proporcionan los mecanismos para no tener que reescribir
el mismo estado por cada test. Un ejemplo es el mtodo setUp(), de la clase UserModelTest
que hereda de CUInit_TestCase. Nos permite ejecutar cualquier sentencia con anterioridad e
independencia entre nuestros tests. Respecto a la parte de Act, se refiere a la ejecucin de
nuestro mtodo a implementar. Y por ultimo en la parte de assert, a travs de los mtodos
proporcionados por el framework aseguramos que el resultado de la fase de actuacin es el
esperado.

A la hora de testear un mtodo debemos asegurarnos que estamos testeando una nica
responsabilidad. Por ello los mtodos debern tener una nica responsabilidad y si hay ms
deberemos separar cada responsabilidad en un mtodo nuevo. Hasta este punto hemos estado
42

testeando, validacin de estado. Pero en determinados casos no es posible y es necesario
realizar validacin de iteracin. Un ejemplo de validacin de iteracin es cuando nos
encontramos con elementos que modifican el estado del sistema, como por ejemplo las clases
que acceden a bases de datos.

Los test de validacin tienen como objetivo evaluar la interaccin entre las partes sin que se
llegue a realizar el acceso a la base de datos. Es entonces cuando utilizamos objetos mocks
que nos proporciona el framework. La filosofa de estos mtodos es proporcionar una interfaz
que define todos los mtodos que implementa nuestra clase de acceso a BD, de modo que en
la validacin verificaremos la iteracin de nuestros mtodos con los distintos mtodos que
acceden a la BD pero llamando a los mtodos que define la interfaz del objeto mock (es decir
sin acceder realmente a la BD, simplemente verificando que se efecta la llamada [10]).

Tras esta pequea introduccin a los test unitarios hemos visto un claro ejemplo de test unitario
de estado ejecutado durante esta iteracin junto con otros test de estado. Al continuar con los
test unitarios de la clase User, nos encontramos con el mtodo Login que pasa a utilizar
mtodos de acceso a BD y deberemos testar su iteracin. La complejidad de los test de
iteracin, aadida al desconocimiento de los frameworks de test y la escasa documentacin
encontrada hace que la duracin de la iteracin se vea comprometida y debemos tomar una
decisin. En este punto se decide finalizar la iteracin con las siguientes tareas y poder
entregar el resultado funcional y no testado que tenemos hasta el momento, perdiendo calidad
pero asegurndonos cierto margen de entrega.

Finalizada la iteracin en un pequeo ejercicio de anlisis, revisin del sprint, se decide seguir
adelante con la 2 iteracin dando prioridad a las historias de usuario que componen la
siguiente iteracin frente a la historias de usuario B4.

Como ya hemos adelantado en prrafos anteriores la planificacin de esta iteracin, aun siendo
estimada para dos semanas se ha alargado la duracin de la misma en un 100% debido a la
falta de conocimientos en TDD y la formacin necesaria.

43

Iteracin 2
El resultado de esta iteracin planificada para una sola semana ya debera darnos como
resultado una versin Alpha de la aplicacin sobre la que el cliente ya puede ir viendo el futuro
de la misma y si nos estamos desviando del objetivo final.

Backlog Tarea Tipo Descripcin Responsable Estimacin
A3, A4,
A6, A7
Tarea 1 Anlisis y diseo Modelo de datos J .M 30%
A3 Tarea 2 Implementacin Crear clases,
mtodos MVC
J .M 20%
A4 Tarea 3 Implementacin Creacin de
formularios y
mtodos
J .M 10%
A6 Tarea 4 Implementacin Crear clases y
mtodos MVC Task
J .M 20%
A7 Tarea 5 Implementacin Crear clases y
mtodos MVC Timer
J .M 20%

En esta iteracin empezamos con el anlisis y diseo del modelo de datos que deberemos
ampliar respecto al creado en la iteracin anterior. Estas relaciones afectan tambin a nuestros
objetos de tipo Modelo (clase de tipo modelo siguiendo el patrn MVC, implementado por los
frameworks que hemos seleccionado). En ellas se reflejan todas las relaciones entre entidades
en ambos sentidos y en este caso se han configurado para disponer de los objetos
relacionados automticamente. Es decir, al cargar los datos de un registro en un objeto, en la
misma instruccin estamos cargando los datos de los registros relacionados en la propiedad
correspondiente. Un caso real dentro de nuestra implementacin son los objetos User_story y
Task. Ambos estn relacionados y esto se refleja en la propiedades al definir cada clase. Ahora
al cargar una historia de usuario (User_story) en la misma sentencia estamos cargando los
datos de las tareas (Task) relacionadas en la propiedad task del objeto User_story

Por ahora el modelo de datos es sencillo y el nmero de usuarios est controlado, de modo que
no afectar al rendimiento de la aplicacin de un modo drstico.

En la 2 tarea as como en otras tareas similares, que implementan la funcionalidad necesaria
para enviar datos del usuario a la aplicacin, se ha utilizado validacin de datos en dos
sentidos, es decir, en el lado del cliente y en el del servidor. En el lado del servidor utilizamos la
validacin de HTML5 y en el servidor los mtodos proporcionados por el ORM.

En la reunin de revisin del Sprint nos encontramos con una aplicacin centrada en las
historias de usuario, las tareas y el control de tiempos. Pero se ha perdido el foco de la
44

metodologa, que la propia aplicacin nos invite a seguir los pasos bsicos que conlleva utilizar
Scrum. Esto puede ser causa de una mala identificacin y definicin de las historias de usuario.
Revisaremos los criterios de aceptacin que darn lugar a un iteracin intermedia; antes de
proseguir con las siguientes historias de usuario debemos garantizar que estn finalizadas las
historias ejecutadas hasta el momento.

Criterios de validacin:

Los dos primeros requisitos de la historia A2 (eliminar/finalizar proyectos) se cumplen,
pero en el segundo se puede ser ms especfico. O incluso aadir un nuevo requisito, al
intentar eliminar/dar de baja un proyecto que no est finalizado o con datos deber
mostrar un mensaje de error al usuario. Adems el tercer criterio no se cumple y
tampoco se ha definido en qu consiste la finalizacin de un proyecto.
El primer criterio de la historia A7 (procesar tareas) es errneo. Aunque haya otros
miembros asignados se pueden seguir asignando miembros. Adems en el segundo
criterio debera concretar qu datos son los que se reflejan.
Falta un criterio de aceptacin que verifique el resultado de cambiar el estado de una
tarea.
Los criterios de la tarea B4 (definir y crear una interfaz grfica) no son vlidos. Esto ha
hecho que en la iteracin 1 no se detecten errores y en este momento s. Un criterio
vlido puede ser: La aplicacin deber permitir conocer la situacin del usuario en todo
momento dentro de la plataforma de forma inequvoca y por varios mtodos.

Antes de comenzar con la iteracin de revisin, se ha incluido un grfico Burn-down para
analizar el esfuerzo realizado durante la ejecucin de las primeras iteraciones.



45


En el grfico anterior podemos ver cmo la iteracin 1 tiene un gran descenso de los puntos de
esfuerzo ejecutados. Esto refleja el retraso que tiene la iteracin durante la ejecucin de las
tareas 3, 4 y 6 de dicha iteracin. Una vez eliminado el causante del retraso la velocidad se
recupera e incluso supera la velocidad estimada.

Iteracin 2B
En la reunin de preparacin del Sprint se prepara el Sprint Backlog y se concreta el
funcionamiento de las tareas a ejecutar.

Backlog Tarea Tipo Descripcin Responsable Estimacin
B4 Tarea 1 Implementacin Aplicar las correcciones
visuales en la
estructura de las
pginas.
J .M 15%
A2 Tarea 2 Anlisis y diseo Definir los estados de
un proyecto
J .M 10%
A2, A7 Tarea 3 Diseo Redefinir el modelo de
datos
J .M 10%
A2 Tarea 4 Implementacin Implementar los
estados de un proyecto
J .M 15%
A2 Tarea 5 Implementacin Implementar acciones
automticas segn
estado de un proyecto
J .M 25%
A7 Tarea 6 Implementacin Limitar permisos de
modificacin de tareas
durante su ejecucin
J .M 25%

Se han detallado las tareas resultantes de analizar los criterios de aceptacin correspondiente
a la iteracin 1 y 2 aunque lo correcto hubiera sido revisar los criterios de la iteracin 1 antes de
comenzar con la iteracin, si no son validos no se debera dar por terminada la iteracin y en
consecuencia no debemos empezar una iteracin nueva.

En este punto hemos alcanzado la situacin actual del proyecto. Esta iteracin continuar
cuando terminamos la documentacin del proyecto y el resultado ser reflejado en la aplicacin
resultante al finalizar la iteracin.
46



Revisin Product Backlog

Antes de proseguir con las iteraciones se ha realizado una actualizacin del Product Backlog
con el fin de mejorar los objetivos de negocio y su ejecucin.

Una vez eliminadas las historias de usuarios finalizadas se han reescrito algunas historias de
usuario y sus criterios de validacin. Con el objetivo de centrarnos nicamente en la siguiente
iteracin solo se han dado prioridad objetiva a las 4 siguientes historias. La siguiente iteracin
estar formada por las tareas A8 (acceso director, proyectos), A5 (acceso cliente, historias de
usuario) y B3 (dar de baja usuarios) que juntas hacen un esfuerzo estimado de 900. El hecho
de no llegar a los mil punto se debe que por ahora no tenemos una velocidad estable, en las
anteriores iteraciones no se ha mantenido el ritmo y no se ha llegado a una velocidad de 1000
puntos semana.

En el siguiente Burn-up podemos ver reflejado el cambio de estimacin, planificando a una
velocidad media de 900 puntos por semana y con un margen de error de 250 puntos de
esfuerzo. Debido a que nuestra velocidad real alcanzada ha tenido muchos altibajos como
podemos observar en el grfico Burn-down
17
no sirve base real para calcular la velocidad
media que se acerca a los 700 puntos por semana. Superados los problemas que nos han
frenados estas primeras iteraciones se espera aumentar la velocidad pero teniendo en cuenta
que 1000 puntos por semana era una estimacin optimista.


17
Pgina 44
47

Este grafico Burn-up, actualiza la anterior planificacin
18
realizada a 1000 puntos por semana.
En esta planificacin partimos de las 7 semana de ejecucin habiendo conseguido una
ejecucin de 4000 puntos de esfuerzo.
Replanificando observamos cmo la fecha idea para la versin beta se ha pasado hasta la
mitad de la semana 11, mientras que al principio estaba planificada para la semana 8. Sin
embargo cabe destacar que la iteracin pesimista inicial coincide con la nueva planificacin.
Dicho esto podemos observar como aun tenemos otras dos lneas de planificacin pesimista y
optimista. Puesto que se trata de nuestros inicios en la metodologa no tenemos suficiente
informacin para poder disminuir el margen de error. En este caso se ha reducido en 50 puntos
con el objetivo de acotar la planificacin y ser ms explcitos. Aunque tenemos en cuenta que el
error anterior ha sido importante y tampoco podemos pasarlo por alto.
En la siguiente tabla observamos la actualizacin de historias de usuario y sus criterios de
aceptacin. Puesto que hemos priorizado nicamente las 4 siguientes historias, una vez est
finalizada la iteracin 3, ser necesaria otra actualizacin del Product Backlog y
obligatoriamente priorizar las siguientes historias. De este modo seremos ms conscientes de
los posibles cambios y las necesidades antes de seguir con el desarrollo, y podemos tener en
cuenta los posibles errores o aciertos que hemos ido teniendo a lo largo del proyecto.
Las historias de usuario no ejecutadas son el reflejo del trabajo futuro que puede tener este
proyecto. Funcionalidades como la generacin de grficos automticamente en base al trabajo
ser de gran aporte al proyecto, esto se refleja en el Product Backlog. J unto a esta se han
quedado a la espera otras historias de usuario que aportan el valor de la metodologa a la
aplicacin. Teniendo esto como principal meta, tambin hay que mencionar la necesidad de
crear una aplicacin de calidad y esto implicara documentarse lo necesario para realizar los
test unitarios para testear el funcionamiento de lo que tenemos hasta el momento y continuar el
desarrollo con TDD.


18
Pgina 31
4
8


I
d
e
n
t
i
f
i
c
a
d
o
r

O
b
j
e
t
i
v
o
D
e
s
c
r
i
p
c
i
o
n
C
o
s
t
e

e
s
t
i
m
a
d
o
C
o
n
d
i
c
i
o
n
e
s

d
e

s
a
t
i
s
f
a
c
c
i

n
V
a
l
o
r

a
p
o
r
t
a
d
o
O
b
s
e
r
v
a
c
i
o
n
e
s
P
r
i
o
r
i
d
a
d
A
5
A
c
c
e
s
o

c
l
i
e
n
t
e
,

H
i
s
t
o
r
i
a
s

U
s
u
a
r
i
o
3
0
0
A
l

a
c
c
e
d
e
r

a

u
n
a

h
i
s
t
o
r
i
a

d
e

u
s
u
a
r
i
o

p
u
e
d
e

m
o
d
i
f
i
c
a
r

e
l

v
a
l
o
r

a
p
o
r
t
a
d
o

d
e
b
i
e
n
d
o

m
o
d
i
f
i
c
a
r

a
s
i

l
a

p
r
i
o
r
i
d
a
d

d
e

l
a

m
i
s
m
a
.
5
0
0
1
2
C
o
n
o
c
e
r

e
l

e
s
t
a
d
o

d
e

l
a
s

h
i
s
t
o
r
i
a
s
,

p
o
r

e
m
p
e
z
a
r
,

e
n

e
j
e
c
u
c
i

n

o

f
i
n
a
l
i
z
a
d
a
.
A
8
A
c
c
e
s
o

D
i
r
e
c
t
o
r
,

P
r
o
y
e
c
t
o
s
3
0
0
A
l

a
c
c
e
d
e
r

a
l

p
r
o
y
e
c
t
o

s
e

l
e

d
a

a
c
c
e
s
o

a

t
o
d
a

l
a

i
n
f
o
r
m
a
c
i

n

d
e

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o

y

t
a
r
e
a
s

q
u
e

e
s
t

n

r
e
l
a
c
i
o
n
a
d
a
s
.
6
0
0
1
1
E
x
p
o
r
t
a
r

i
n
f
o
r
m
e
s

c
o
n

l
o
s

d
a
t
o
s

a
c
t
u
a
l
e
s
.
S
e

c
o
n
c
r
e
t
a
r

n

l
o
s

f
o
r
m
a
t
o
s

a
l

p
l
a
n
i
f
i
c
a
r

l
a

i
t
e
r
a
c
i

n
.
A
9
R
e
p
r
e
s
e
n
t
a
c
i
o
n

v
i
s
u
a
l

d
e

l
o
s

d
a
t
o
s
1
2
0
0
P
u
e
d
o

v
e
r

e
l

G
r

f
i
c
o

B
u
r
n
-
D
o
w
n

e
n

b
a
s
e

a

l
o
s

d
a
t
o
s

d
e

c
a
d
a

p
r
o
y
e
c
t
o
.
5
0
0
P
u
e
d
o

v
e
r

e
l

G
r

f
i
c
o

B
u
r
n
-
U
P

e
n

b
a
s
e

a

l
o
s

d
a
t
o
s

d
e

c
a
d
a

p
r
o
y
e
c
t
o
.
A
1
0
A

a
d
i
r

d
o
c
u
m
e
n
t
a
c
i

n

E
x
t
e
r
n
a
2
0
0
P
u
e
d
o

d
e
s
c
a
r
g
a
r

d
o
c
u
m
e
n
t
o
s

a
d
j
u
n
t
o
s

a

u
n

p
r
o
y
e
c
t
o
.
1
0
0
P
u
e
d
o

a

a
d
i
r

d
o
c
u
m
e
n
t
o
s

a
d
j
u
n
t
o
s

a

u
n

p
r
o
y
e
c
t
o
1
0
0
A
1
1
C
o
n
t
r
o
l

d
e

v
e
r
s
i
o
n
e
s

p
a
r
a

a
r
c
h
i
v
o
s
2
0
0
0
P
u
e
d
o

c
o
n
o
c
e
r

e
l

h
i
s
t
o
r
i
a
l

d
e

u
n

d
o
c
u
m
e
n
t
o
,

c
u
a
n
d
o

y

q
u
i
e
n

l
o

h
a

m
o
d
i
f
i
c
a
d
o
.
2
0
0
A
l

s
u
b
i
r

u
n

d
o
c
u
m
e
n
t
o

m
o
d
i
f
i
c
a
d
o

p
o
r

m
i
,

e
l

s
i
s
t
e
m
a

m
e

a
v
i
s
a
r

s
i

h
a
y

u
n
a

n
o
t
i
f
i
c
a
c
i

n

p
o
s
t
e
r
i
o
r

a

m
i

u
l
t
i
m
a

d
e
s
c
a
r
g
a
.
A
1
2
R
e
p
r
e
s
e
n
t
a
c
i
o
n

v
i
s
u
a
l

d
e

l
o
s

e
l
e
m
e
n
t
o
s

S
c
r
u
m

(
K
a
n
b
a
n
)
1
3
0
0
P
u
e
d
o

c
o
n
s
u
l
t
a
r

l
a

i
n
f
o
r
m
a
c
i

n

d
e

p
r
o
y
e
c
t
o
s

y

s
u
s

e
l
e
m
e
n
t
o
s

d
e

f
o
r
m
a

v
i
s
u
a
l
.
4
0
0
A
1
3
A
s
i
g
n
a
c
i

n

d
e

p
e
r
m
i
s
o
s

e
n
t
r
e

r
o
l
e
s

d
e

u
s
u
a
r
i
o
1
5
0
0
E
l

a
d
m
i
n
i
s
t
r
a
d
o
r

d
e

l
a

p
l
a
t
a
f
o
r
m
a

p
u
e
d
e

a
s
i
g
n
a
r

p
e
r
m
i
s
o
s

p
a
r
a

u
n
a

f
u
n
c
i
o
n
a
l
i
d
a
d

c
o
n
c
r
e
t
a
1
0
0
A
1
4
C
o
m
o

u
s
u
a
r
i
o

d
e

l
a

a
p
l
i
c
a
c
i

n

q
u
i
e
r
o

q
u
e

l
a

m
e
t
o
d
o
l
o
g

a

s
e

v
e
a

i
m
p
l

c
i
t
a

e
n

l
a
s

a
c
c
i
o
n
e
s

q
u
e

m
e

o
f
r
e
c
e
.
1
2
0
0
3
0
0
L
a

a
p
l
i
c
a
c
i

n

d
e
b
e

a
y
u
d
a
r

a

s
e
g
u
i
r

l
a

m
e
t
o
d
o
l
o
g
i
a
.

S
e

c
o
n
c
r
e
r

n

m

s

d
e
t
a
l
l
e
s
.
A
1
5
C
o
m
o

s
c
r
u
m

m
a
s
t
e
r

q
u
i
e
r
o

p
o
d
e
r

g
u
a
r
d
a
r

i
n
f
o
r
m
a
c
i

n

r
e
l
a
t
i
v
a

a

l
a
s

r
e
u
n
i
o
n
e
s
.
1
0
0
0
P
e
r
m
i
t
i
r

g
u
a
r
d
a
r

l
a

i
n
f
o
r
m
a
c
i
o
n

r
e
f
e
r
e
n
t
e

a

l
a

r
e
u
n
i
o
n

q
u
e

d
a

c
o
m
i
e
n
z
o

u
n

s
p
r
i
n
t

o

i
t
e
r
a
c
i

n
.


R
e
u
n
i
o
n

d
e

p
l
a
n
i
f
i
c
a
c
i
o
n
3
0
0
P
e
r
m
i
t
i
r

g
u
a
r
d
a
r

l
a

i
n
f
o
r
m
a
c
i
o
n

r
e
f
e
r
e
n
t
e

a

l
a

r
e
u
n
i
o
n

q
u
e

r
e
v
i
s
a

u
n

s
p
r
i
n
t

o

i
t
e
r
a
c
i

n
.


R
e
u
n
i
o
n

d
e

r
e
v
i
s
i

n
.

A
1
6
C
o
m
o

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o

q
u
i
e
r
o

p
o
d
e
r

c
o
n
s
u
l
t
a
r

e
l

s
p
r
i
n
t

b
a
c
k
l
o
g
3
0
0
U
n

u
s
u
a
r
i
o

p
u
e
d
e

c
o
n
s
u
l
t
a
r

l
a
s

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o

q
u
e

c
o
r
r
e
s
p
o
n
d
e
n

c
o
n

l
a

i
t
e
r
a
c
i
o
n

e
n

c
u
r
s
o

d
e
l

p
r
o
y
e
c
t
o
.
3
0
0
1
4
U
n

u
s
u
a
r
i
o

p
u
e
d
e

c
o
n
s
u
l
t
a
r

l
a
s

t
a
r
e
a
s

q
u
e

c
o
r
r
e
s
p
o
n
d
e
n

c
o
n

l
a

i
t
e
r
a
c
i

n

e
n

c
u
r
s
o

d
e
l

p
r
o
y
e
c
t
o
.
O
t
r
a
s

h
i
s
t
o
r
i
a
s
B
3
C
o
m
o

a
d
m
i
n
i
s
t
r
a
d
o
r

d
e

l
a

a
p
l
i
c
a
c
i

n

q
u
i
e
r
o

d
a
r

d
e

b
a
j
a

u
s
u
a
r
i
o
s
3
0
0
A
l

d
a
r

d
e

b
a
j
a

u
n

u
s
u
a
r
i
o

d
e
j
a

d
e

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

s
u

a
c
c
e
s
o
4
0
0
1
3
S
i

e
s

u
n

m
i
e
m
b
r
o

d
e
l

e
q
u
i
p
o

d
e
j
a
r

d
e

e
s
t
a
r

d
i
s
p
o
n
i
b
l
e

p
a
r
a

s
e
r

a
s
i
g
n
a
d
o

c
o
n

t
a
r
e
a
s

u

h
i
s
t
o
r
i
a
s

d
e

u
s
u
a
r
i
o
.
T
o
t
a
l
9
6
0
0

P
r
o
d
u
c
t

B
a
c
k
l
o
g

V
e
r
s
i

n

2
49

Conclusiones


En esta ltima seccin de la memoria, vamos a detallar las conclusiones que hemos obtenido
de la ejecucin del TFG.

El objetivo marcado era crear una aplicacin para la gestin gil de proyectos dirigidos
utilizando Scrum. Para ello nos hemos adentrado en el mundo de las tecnologas giles
concretando el funcionamiento de Scrum que para entenderlo y poder reflejarlo mejor se ha
utilizado como metodologa para dirigir y ejecutar nuestro proyecto.

Es cierto la aplicacin se ha quedado en una versin Alpha, que no refleja al 100% nuestro
objetivo final por las dificultades encontradas durante la ejecucin del proyecto. Por otro lado
hemos obtenido una formacin y visin de las metodologas giles entendiendo los valores que
defiende y sus indicaciones, gracias a la puesta en marcha de las mismas en un proyecto real.

Estas dificultades han venido dadas por la necesidad de documentacin previa en la
metodologas y las reas que se abren dentro de un proyecto gil, entre ellas el desarrollo
guiado por test, TDD. Entendidos los principios y las ventajas de esta "tcnica" de desarrollo
apenas hemos podido poner en marcha y ver las ventajas en nuestro propio proyecto. Los test
que hemos podido poner en prctica nos garantizan que nuestra programacin testada ser de
mayor calidad y en caso de existir un error podremos excluir esa parte como la causa del
mismo.

El hecho de utilizar metodologas giles no implica la falta de un mtodo, sino que simplemente
se rigen por unos principios ms flexibles y orientados a la situacin real de algunos proyectos
que estn expuestos a un cambio constante y/que en su fase inicial no estn definidos ni se
conocen las posibles dificultades que podemos encontrarnos. Adems de esto, en todo
momento se tiene en cuenta la calidad de lo que hacemos y entiende que estamos realizando
un trabajo artesanal que puede tener errores. Por ello incluye como tcnica de desarrollo TDD.

Respecto a Scrum y los pasos que nos indica son la base para una ejecucin gil, si no
tenemos experiencia en la direccin de proyectos son el mejor punto de partida que
posteriormente podremos adaptar a nuestro entorno y experiencia. La herramientas que nos
proporciona pueden resultar un poco abstractas y complejas. En particular la descomposicin
de los objetivos en historias de usuario totalmente independientes y con un lenguaje coloquial,
compartido por el Product Owner y el equipo. La descomposicin de las historias en tareas
independientes nos ayuda a organizar el trabajo en equipo y aunque no ha sido aplicable en
nuestro entorno, la descomposicin en tareas ha resultado un aspecto bastante abstracto.
Viniendo de las metodologas tradicionales en las que no se hace referencia a estos conceptos,
50

es complicado descomponer las funcionalidades en tareas totalmente independientes sin una
experiencia previa, de modo que nos hemos basado en la documentacin previa a partir de la
cual tomar nuestras decisiones.

Un ejemplo puede ser la creacin del modelo de datos. En nuestro Product Backlog no hay una
historia de usuario que refleje la creacin del modelo de datos. En un principio hemos llevado al
extremo la independencia de las historias y en cada una se define el modelo de datos para las
funcionalidades que indica. En la segunda iteracin se decide crear un modelo de datos que
refleje todas las historias de usuario de la iteracin. Finamente despus de esta experiencia
empezaramos un proyecto con una historia de usuario para el modelo de datos general. En
ella deberamos identificar las entidades y relacionarlas entre s. Esto se complementara con
una tarea especfica que identifique las propiedades de las entidades implicadas en la iteracin
que estamos ejecutando.

Otra caracterstica de Scrum y que inicialmente hemos dejado de lado son las reuniones. Al no
ser un proyecto en equipo, o el equipo estar compuesto por un solo miembro y un director tutor,
que ha compartido el rol de Product Owner con el alumno, las reuniones sin el tutor no tenan
lugar como tales. Por ello en la segunda iteracin se concreta la reunin de revisin en la que
s se han revisado los criterios expuestos en el Product Backlog y posteriormente se han
tomado las medidas oportunas para cumplir los criterios. Las revisiones de sprint sirven de
utilidad para conocer el estado del proyecto da a da. En nuestro caso se reflejan an ms sus
ventajas puesto que la dedicacin en este proyecto no es 100% da a da y se hace ms
necesaria una revisin y planificacin de lo que hemos hecho y lo que nos queda por hacer.
Para terminar destacar que la experiencia ha sido satisfactoria, sacando en claro muchos
aspectos de las metodologas agiles y el porqu plantearse utilizarlas al inicio de un proyecto.
En este caso debido a la naturaleza de nuestro proyecto, dirigir proyectos giles, y al
desconocimiento de rea que aborda, era de vital importancia conocer desde nuestro punto de
vista la metodologa. Esto ha propiciado que la planificacin no sea lo ms acertada y nos
hayamos desviado, no llegando al esfuerzo estimado medio que inicialmente se planific. Aun
as, s que estamos dentro del margen definido en aquella primera planificacin, haciendo as
que seamos conscientes de las complicaciones que pueden surgir durante la ejecucin del
proyecto. Esto nos da un claro ejemplo de lo importantes y tiles que resultan los elementos
que nos ofrecen Scrum.

51

Bibliografa

Referencias bibliogrficas:

1. http://agilemanifesto.org
2. http://www.proyectosagiles.org/
3. Scrum y XP desde las trincheras. Autor: Henrik Kniberg
4. Flexibilidad con Scrum. Autor: J uan Palacio
Principios de diseo e implantacin de campos de Scrum
5. http://www.navegapolis.net
6. Gestin visual: Kanban
Apuntes Curso ScrumManager
7. http://www.bonillaware.com/
8. jmbeas.es
9. Wikipedia
10. Diseo gil con TDD: Carlos Bl J urado y Colaboradores

Otras referencias

javiergarzas.com
queridointernet.wordpress.com
devnettips.blogspot.com.es
www.genbetadev.com

Documentacin tcnica
http://ellislab.com/codeigniter
http://datamapper.wanwizard.eu/
http://www.mysql.com/
http://git-scm.com/book/en/
http://www.php.net