Embed Size (px)
Citation preview
UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA EN COMPUTACION
Prototipo para Scrum Desarrollado
en Mono
Pedro Antonio Bustos Estay
2010
La presente Memoria de Titulacion ha sido aprobada con la siguiente calificacion:
Pedro Antonio Bustos Estay
Memoria :
Examen de Tıtulo :
Nota Final :
MSc. Eduardo Pena Jaramillo
Director Departamento
de Ingenierıa en Computacion
13 de julio de 2010
UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA EN COMPUTACION
Prototipo para Scrum Desarrollado en
Mono
Trabajo de titulacion presentado en
conformidad a los requisitos para
obtener el tıtulo de Ingeniero en Com-
putacion e Informatica.
Profesor Guıa: Sr. Jose Canuman
Chacon.
Pedro Antonio Bustos Estay
2010
Resumen
En el presente documento se encuentran variados analisis acerca del desarrollo del Pro-
totipo para Scrum Desarrollado en Mono, que van desde el detalle de la base de datos hasta
las bases sobre las cuales comenzo el estudio, lo cual esta abarcado en el marco teorico con
explicaciones en detalle de lo que se trata todo este trabajo de tıtulo en terminos generales.
Tambien hay imagenes de la implementacion del prototipo junto con los digramas de casos
de uso y de colaboracion para ver y analizar desde un enfoque de ingenierıa de software a
traves de herramientas UML. El documento deja en claro los problemas que se encontraron
en la implementacion y los trabajos futuros que se dejaron fuera de este trabajo de Tıtu-
lo por diversos motivos; se explica detalladamente la base de datos en la seccion anexos y
para finalizar las conclusiones senalaran los puntos altos y bajos a traves de opiniones y
observaciones de este trabajo de tıtulo.
Indice general
I. Introduccion 1
1.1. Objetivo general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Descripcion de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
II. Marco Teorico 4
2.1. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Pila de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Una planificacion de Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Dividiendo las historias en tareas . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Trabajando las historias . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Informar los Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Tabla de Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.5. Actualizacion de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . 16
i
2.3.6. ¿Como funciona el diagrama Burndown? . . . . . . . . . . . . . . . . 16
2.3.7. El encargado de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Umbrales de aceptacion y planes de entrega . . . . . . . . . . . . . . . . . . 18
2.5.1. Importancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2. Estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.3. Estimar la velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.4. Adaptar el plan de entregas a la realidad . . . . . . . . . . . . . . . . 23
2.6. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1. Microsoft .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.2. Mono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.3. Monodevelop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.4. El lenguaje C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.5. Caracterısticas de C# . . . . . . . . . . . . . . . . . . . . . . . . . . 26
III. Desarrollo 28
3.1. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Diagramas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3. Dificultades en la implementacion . . . . . . . . . . . . . . . . . . . . . . . . 40
IV. Conclusiones 41
ii
Trabajos Futuros 43
Anexos 46
A. Tablas de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Referencias y Bibliografıa 51
iii
Indice de figuras
2.1. Pila de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Prioridad de historias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Historias y tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Historia pendiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Historia en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Historia terminada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Informe Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8. Tabla de Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9. Tabla Sprint avanzado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11. Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.12. Importancia de historias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.13. Estimacion de historias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.14. Estimacion de velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iv
3.1. Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Listado de miembros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Eliminar proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4. Ingresar historias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5. Ingresar tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6. Ver retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7. Editar tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9. Ingresar miembros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10. Eliminar sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.11. Editar tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.12. Ver retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1. Creacion de una aplicacion didactica basica en sistema Sugar . . . . . . . . . 43
v
Indice de cuadros
1. hist descrip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2. hist estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3. hist estimacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4. hist importancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5. historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6. miembros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7. proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8. retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9. scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
12. tarea descrip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13. tarea estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
14. tarea estimacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
vi
15. tarea miembros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
vii
Capıtulo I
Introduccion
2
Trabajar en grupos puede ser muy complicado en muchos ambitos, ya que surgen muchas
dudas en relacion a los objetivos individuales y grupales o los recursos con que se contara,
la division de tareas de forma equitativa para que nadie se sienta perjudicado puede ser el
mayor de los dolores de cabeza, especialmente para quien esta a cargo de evaluar y hacer
que estos grupos rindan de forma eficiente. Para asistir a estas personas se creo un marco
de trabajo llamado Scrum, el cual pareciera ser agil para desarrollo, no solo de proyectos de
software sino que de cualquier tipo de proyectos. La ventaja es que permite valorar o medir el
rendimiento de las personas y mantener claros los objetivos, ademas de optimizar los recursos
con los que cuentan quienes desarrollen ideas con este marco de trabajo.
Aun no sabemos a ciencia cierta en el medio en que se desenvuelve Scrum, ni la forma
en que las personas se relacionan con este y entre sı cuando lo utilizan como sistema base de
trabajo y medidor de productividad. Entonces para iniciarnos en esto diremos que Scrum es
un modelo de referencia, que define un conjunto de practicas y roles que puede tomarse como
punto de partida para definir el proceso de desarrollo que se ejecutara durante un proyecto.
Ademas Scrum es un framework o conjunto de herramientas, para la gestion y desarrollo
de tareas utilizado mayormente por personas ligadas a la informatica. Esta basado en un
proceso iterativo e incremental utilizado comunmente en entornos de desarrollo de software.
Al parecer en la practica, para muchos equipos de desarrollo, ante las dificultades para
utilizar metodologıas tradicionales, se llego a la resignacion de prescindir del “buen hacer” de
la ingenierıa del software con el objetivo de ajustarse a restricciones. Ante esta situacion, las
metodologıas agiles aparecen como una posible respuesta para llenar este vacıo metodologico.
Por estar especialmente orientadas para proyectos pequenos, las metodologıas agiles consti-
tuyen una solucion a medida, con una elevada simplificacion, que a pesar de ello no renuncia
a las practicas esenciales para asegurar la calidad del producto[1].
1.1. Objetivo general del proyecto
Crear un prototipo que sirva para gestionar a traves de Scrum cualquier tipo de trabajo
en equipos.
3
1.2. Objetivos especıficos
Utilizar el proyecto impulsado por Novell Mono a traves de su interfaz Monodevelop y
programar la aplicacion con el lenguaje C#
Implementar el gestor de Scrum como un prototipo
Poner a prueba este prototipo para un trabajo
Promover la utilizacion de Mono y su interfaz Monodevelop
1.3. Descripcion de la memoria
Capıtulo I: Abarca la introduccion al documento, una breve presentacion de lo que se
vera con el correr de las hojas.
Capıtulo II: Muestra todos los enfoques teoricos que se requirieron durante el desarrollo de
este trabajo de Tıtulo.
Capıtulo III: Es el desarrollo del prototipo, se analiza la implementacion del prototipo.
Capıtulo IV: Se analizara el prototipo entregando conclusiones.
Capıtulo II
Marco Teorico
5
2.1. Scrum
Scrum no tiene relacion directa con algo computacional, no es un software o un algoritmo,
tampoco es una base de datos, Scrum es un marco de trabajo que en simples palabras ayuda
a grupos y/o personas en cualquier ambito que deseen desenvolver sus energias, ya sea en
algun proyecto muy importante o para la ayuda de actividades cotidianas. Scrum no dice
que se debe hacer, ya que no es una receta, Scrum lo crean a su medida quienes lo usan,
lo ajustan a sus necesidades, pero sı deben tomar en cuenta previas utilizaciones de otras
personas que digan haber optimizado sus recursos, esto para tener una experiencia valida, la
cual sea deseable de imitar, esto es muy importante porque Scrum lo hacen las experiencias.
La ejecucion correcta de Scrum se esta convirtiendo en un factor cada vez mas impor-
tante para los equipos que buscan inversion de capital, pero antes de invertir siempre hay que
preguntarse muchas cosas, y una de las preguntas de mayor relevancia que se hace cuando se
consulta al encargado del desarrollo de un proyecto es: ¿cuando terminaran el producto?, en
otras palabras se esta preguntando si conocen la velocidad de sus equipos. Actualmente se
tiene dificultad para responder esta pregunta. Las oportunidades de inversion en el futuro re-
queriran que los equipos de desarrollo comprendan el concepto de su velocidad de produccion
de software o de cualquier tipo de producto.
Los equipos de trabajo deben conocer los principios de Scrum. ¿Como se crea y se estima
una pila de producto?, ¿Como se gestiona un grafico de Burndown y se calcula la velocidad
del equipo?
¿Por que es esto tan importante? Si los equipos no conocen su velocidad, el Dueno de
producto no puede crear una hoja de ruta del producto con fechas de lanzamiento creıbles.
Sin fechas de lanzamiento fiables, la companias podrıan fracasar y los inversores perder su
dinero.
Scrum requiere que los equipos completen algun tipo de producto potencialmente liberable
al final de cada iteracion. Estas iteraciones estan disenadas para ser cortas y de duracion
fija. Este enfoque en entregar codigo funcional cada poco tiempo significa que los equipos
Scrum no tienen tiempo para teorias. No se persigue dibujar el modelo UML perfecto en
6
una herramienta CASE, escribir el documento de requisitos perfecto o escribir codigo que se
adapte a todos los cambios futuros imaginables. En vez de eso, los equipos Scrum se enfocan
en que las cosas se hagan. Estos equipos aceptan que puede que se equivoquen por el camino,
pero tambien son conscientes de que la mejor manera de encontrar dichos errores es dejar de
pensar en el software a un nivel teorico de analisis y diseno, y sumergirse en el, ensuciarse
las manos y comenzar a construir el producto.
No hay y nunca habra una lista de “mejores practicas” en Scrum, porque el contexto
de cada equipo y proyecto impera sobre cualquier otra consideracion. En lugar de mejores
practicas, lo que se necesita conocer son mejores practicas y el contexto en que fueron exitosas.
En palabras de Ken Schwaber, “Scrum no es una metodologıa, es un marco de trabajo. Eso
quiere decir que Scrum no te va a decir exactamente lo que se debe hacer, es un proceso de
aprendizaje continuo”[4].
Tan importante como lo anterior es saber como se desglosa y como se trabaja Scrum,
para esto se analiza a continuacion la pila de producto y el plan de Sprint.
2.2. Pila de producto
La pila de producto es el corazon de Scrum. Es donde empieza todo. La Pila de producto
es, basicamente, una lista priorizada de requisitos, a los cuales llamaremos historias, es decir,
1 requisito = 1 historia. En simples palabras las historias son las cosas que el cliente quiere,
descritas usando la terminologıa del cliente. A varias historias juntas pertenecientes a un
Sprint se les llama elementos de pila del Sprint, siendo un Sprint un proceso iterativo el cual
se explicara mas adelante.
Los datos que contiene una historia son:
ID – un identificador unico, simplemente un numero auto-incremental. Esto nos permite
no perder la pista a las historias cuando se cambia su nombre.
Nombre – una descripcion corta de la historia. Por ejemplo, “Ver tu historial de transac-
7
ciones”. Suficientemente claro como para que el cliente, al cual comenzaremos a llamar,
Dueno del producto comprenda aproximadamente de que estamos hablando, y suficien-
temente clara como para distinguirla de las otras historias.
Importancia – el ratio de importancia que el Dueno de producto da a esta historia. Por
ejemplo, 10 o 150. Mas alto = mas importante.
Estimacion inicial – la valoracion inicial del equipo acerca de cuanto trabajo es necesario
para implementar la historia, comparada con otras historias. La unidad son “puntos
de historia” y usualmente corresponde a “dıas-persona ideales”. Se pregunta al equipo:
“si tuvieras el numero optimo de personas para esta historia (ni muchos ni pocos,
tıpicamente 2) y si se encerraran en una habitacion con cantidad de comida, y traba-
jasen sin distracciones, ¿en cuantos dıas saldrıas con una implementacion terminada,
demostrable, testeada y liberable?”. Si la respuesta es “con 3 personas encerrados en
una habitacion nos llevarıa 4 dıas”, entonces la estimacion inicial son 12 puntos. Lo
importante no es que las estimaciones absolutas sean correctas (es decir, que una his-
toria de 2 puntos deba durar 2 dıas), lo importante es que las estimaciones relativas
sean correctas (es decir, que una historia de 2 puntos deberıa durar la mitad que una
historia de 4 puntos).
Como probarlo – una descripcion a alto nivel de como se demostrara esta historia en
la Demo al final del Sprint. Se trata, esencialmente, de una simple especificacion de un
test: “Haz esto, entonces haz lo otro, y entonces deberıa ocurrir aquello”. Si se practica
TDD (Test-Driven Development, desarrollo orientado a test) esta descripcion puede
usarse como pseudo-codigo para un test de aceptacion.
Notas – cualquier otra informacion, clarificacion, referencia a otras fuentes de informa-
cion, etc. Normalmente muy breve.
8
Figura 2.1: Pila de producto
Estos seis campos son los importantes Sprint tras Sprint. Esta tabla es un documento
que muchos usuarios pueden editar. Oficialmente, el Dueno de producto es el propietario del
documento, pero es mejor no dejar al resto de usuarios fuera. Muchas veces un desarrollador
necesita abrir el documento para clarificar algo o cambiar una estimacion.
2.3. Una planificacion de Sprint
La planificacion de Sprint es una reunion crıtica, probablemente la mas importante de
Scrum. Una planificacion de Sprint mal ejecutada puede arruinar por completo todo el Sprint.
El proposito de la planificacion de Sprint es proporcionar al equipo suficiente informacion
como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y
para ofrecer al Dueno de producto suficiente confianza como para permitırselo.
A continuacion se muestran los campos recomendables con los que debe contar un Sprint:
9
Una meta de Sprint.
Una lista de miembros (y su nivel de dedicacion, si no es del 100%)
Una Pila de Sprint (lista de historias incluidas en el Sprint)
Una fecha concreta para la Demo del Sprint.
Un lugar y momento definidos para el Scrum Diario.
Figura 2.2: Prioridad de historias
En la Figura 2.2 se muestran ordenadas de mas a menos importantes las historias y sus
tareas.
10
2.3.1. Dividiendo las historias en tareas
¿Cual es la diferencia entre historias y tareas? Una pregunta muy valida. La diferencia
es muy simple, las tareas son divisiones de una historia. Las historias son entregables de
los que el Dueno de producto se preocupa, pero no se preocupa de las tareas ya que son
creadas por quienes las trabajaran para ası ir dividiendo en pequenas metas. Las tareas son
no-entregables, o aspectos de los que el Dueno de producto no se preocupa.
La figura 2.3 muestra un ejemplo de division de una historia llamada gestion de usuarios,
en dos post-its amarillos que representan tareas llamadas anadir/modificar usuario y buscar
usuario:
Figura 2.3: Historias y tareas
2.3.2. Trabajando las historias
Figura 2.4: Historia pendiente
11
En la Figura 2.4 vemos como una historia (papel o post-it blanco) y sus tareas (papel o
post-it amarillo) aun no han comenzado a trabajarse por el equipo. Las columnas marcan el
estado en que se encuentran.
Figura 2.5: Historia en curso
El trabajo ya ha comenzado, debemos notar que algunas tareas ya estan siendo analizadas
por miembros del equipo, y esta imagen ya puede verse reflejado luego del primer Scrum.
12
Figura 2.6: Historia terminada
Posteriormente y luego de mucho trabajo vemos como la historia ha sido terminada com-
pletamente, entonces podemos escoger otra y repetir los pasos.
2.3.3. Informar los Sprints
Es importante mantener a toda la compania informada sobre lo que esta ocurriendo.
De otra forma, la gente se quejarıa constantemente o, incluso peor, podrian hacer falsas
presunciones sobre lo que esta ocurriendo. Entonces se puede usar algo como esto:
13
Figura 2.7: Informe Sprint
La Figura 2.7 muestra el detalle de un equipo trabajando en un Sprint, se indican fechas,
quienes trabajan, quien es el encargado, las historias y el objetivo que tiene este Sprint, solo
se muestran cosas generales con el fin de informar y no se entran en detalles tecnicos como
podrıan ser las tareas.
14
2.3.4. Tabla de Sprint
Sirve para tener un orden en cada Sprint. Entre otras cosas nos muestra el avance de cada
historia perteneciente a un Sprint y sus tareas. Como se muestra a continuacion en la Figura
2.8.
Figura 2.8: Tabla de Sprint
Y luego de unos cuantos dias:
15
Figura 2.9: Tabla Sprint avanzado
Como puede observarse, se ha completado la historia “Deposit” (es decir, ha sido chequea-
da en el repositorio de codigo fuente, testeada, refactorizada, etcetera). La herramienta de
migracion (segunda historia) esta parcialmente completada. La tercera historia (“backoffice
login”) ha comenzado, y la cuarta (“backoffice user admin”) no ha empezado aun. Se tiene
tres elementos no planificados, como puede verse abajo a la derecha. Esto es util para recor-
dar cuando se haga retrospectiva del Sprint. Aquı se tiene un ejemplo de una Pila de Sprint
real casi al final de un Sprint. Se vuelve bastante liosa conforme el Sprint progresa, pero no
pasa nada, ya que tiene una vida muy corta. En cada nuevo Sprint, se crea una limpia, fresca
y nueva Pila de Sprint.
16
2.3.5. Actualizacion de tareas
El tablon de tareas se actualiza durante los Scrum diarios. Conforme cada persona describe
lo que hizo el dıa anterior y lo que hara hoy, mueve los post-it en el tablon y describe los
elementos no planificados, pone un post-it nuevo para cada uno de ellos. Y actualiza sus
estimaciones en el post-it correspondiente y tacha la anterior estimacion.
2.3.6. ¿Como funciona el diagrama Burndown?
Figura 2.10: Burndown
El diagrama de la Figura 2.10 muestra que:
En el primer dıa del Sprint, 1 de agosto, el equipo estimo que habıan aproximadamente
70 puntos de historia en los que trabajar. Esta era, consecuentemente, la velocidad
estimada para todo el Sprint.
17
El 16 de agosto el equipo estima que quedan aproximadamente 15 puntos de historia
por hacer. La lınea de puntos muestra que se esta incluso algo avanzados respecto a la
planificacion, es decir, que a este paso se completarıa todo al final del Sprint.
2.3.7. El encargado de pruebas
Ademas de ser solo un miembro del equipo, el encargado de pruebas tiene una labor
importante. Es el que da el visto bueno. Nada se considera terminado hasta que el dice que
esta terminado.
2.4. Retrospectiva
Consiste en ver cuales son las fortalezas y debilidades de un trabajo, para el caso de Scrum
esto se debe realizar al finalizar cada Sprint. Lo mas importante de las retrospectivas es
asegurarse de que tienen lugar. Sin las retrospectivas puede que los equipos sigan cometiendo
los mismos errores una y otra vez. En el siguiente ejemplo se muestra como se genera una
tabla en donde se ponen historias y/o tareas en cada columna, con el fin de que quienes
tienen alguna relacion con el Sprint interpreten visualmente lo que se ha hecho bien o mal.
18
Figura 2.11: Retrospectiva
Bien: si se hiciera el Sprint otra vez, se volverıa a hacer estas cosas igual.
Mejorable: si se hiciera otra vez el Sprint, se harıa estas cosas de forma diferente.
Mejoras: ideas concretas sobre como se puede mejorar en el futuro.
2.5. Umbrales de aceptacion y planes de entrega
2.5.1. Importancias
Ademas de la Pila de producto habitual, el Dueno de producto define una lista de umbrales
de aceptacion, que son una simple clasificacion de que significan los niveles de importancia
de la Pila de producto en terminos del contrato.
He aquı un ejemplo de umbrales de aceptacion:
Todos los elementos con importancia >=100 deben estar incluidos en la version 1.0
19
Todos los elementos de importancia entre 50 y 99 deberıan estar incluidos en la version
1.0, pero se podrıa pasar sin ellos si se les incluyese en otra entrega poco despues.
Los elementos con importancias entre 25 y 49 son requisitos, pero se pueden incluir en
una version 1.1.
Los elementos con importancia <25 son puramente especulativos y puede que ni siquiera
hagan falta.
Y he aquı en la Figura 2.12 un ejemplo de Pila de producto con un codigo de colores
basado en las reglas anteriores:
Figura 2.12: Importancia de historias
Rojo = debe incluirse en la version 1.0 (platano - pera)
Amarillo = deberıa incluirse en la version 1.0 (pasa - cebolla)
20
Verde = puede hacerse mas tarde (uva - melocoton)
Ası que si lo entregamos todo desde platano a cebolla en la fecha lımite, estamos a salvo.
Si el tiempo se nos acaba, podrıamos salir adelante abandonando pasa, cacahuete, donut o
cebolla. Cualquier cosa por debajo de cebolla es un plus.
2.5.2. Estimaciones
Para poder hacer la planificacion de entregas el Dueno de producto necesita estimaciones,
al menos para todas las historias incluidas en el contrato. Al igual que en la planificacion
de Sprint, se trata de un esfuerzo cooperativo entre el Dueno de producto y el equipo. El
equipo estima, el Dueno de producto describe los elementos y responde a las preguntas. Una
estimacion de tiempos es valiosa si resulta ser casi correcta, menos valiosa si resulta que falla
por, digamos, un 30% y completamente inutil si no tiene ninguna conexion con la realidad.
Todo esto no ha sido mas que una forma complicada de decir:
Hay que dejar que el equipo haga las estimaciones.
No hay que dejar que le dediquen demasiado tiempo.
Se debe asegurar de que entiendan que se trata de estimaciones, no compromisos.
He aquı en la Figura 2.13 un ejemplo de como podrıan acabar las estimaciones (en puntos
de historia):
21
Figura 2.13: Estimacion de historias
2.5.3. Estimar la velocidad
Esto significa que debemos decidir nuestro factor de dedicacion. El factor de dedicacion
significa, basicamente, “cuanto del tiempo del equipo se emplea en las historias a las que
se ha comprometido”. Nunca es el 100%, ya que el equipo gasta tiempo en elementos no
planificados, haciendo cambios de contexto, ayudando a otros equipos, chequeando el correo,
arreglando sus computadores rotos, discutiendo de polıtica en la cocina, etc.
Digamos que se determina que el factor de dedicacion del equipo es del 50% (lo cual es
bastante bajo). Y digamos que la duracion del Sprint es de 3 semanas (15 dıas) y el tamano
del equipo es 6 personas. Ası que cada Sprint tendrıa 90 dıas-hombre ideales, pero solo se
puede pretender producir el equivalente a 45 dıas-hombre ideales (debido al factor del 50%).
En la Figura 2.14 vemos como queda que la velocidad estimada sea de 45 puntos de historia.
22
Figura 2.14: Estimacion de velocidad
Cada Sprint incluye tantas historias como sea posible sin exceder la velocidad estimada
de 45. Ası, se puede ver que probablemente se necesite 3 Sprints para finalizar todos los
“debe” y los “deberıa”. 3 Sprints = 9 semanas de calendario = 2 meses. Ası que esa es la
fecha de entrega. Ahora bien, ¿es la fecha que se prometio al cliente? depende enteramente
de la naturaleza del contrato. Usualmente se anade un buffer o colchon significativo para
protegerse contra las malas estimaciones, problemas inesperados, etc. Ası que en este caso
se podrıa acordar fijar la fecha de entrega dentro de 3 meses, ası se da un mes de “reserva”.
Lo bonito es que se puede mostrar algo usable al cliente cada tres semanas e invitarle a
introducir cambios en los requisitos conforme se avanza (dependiendo por supuesto de lo que
permita el contrato).
23
2.5.4. Adaptar el plan de entregas a la realidad
La realidad no se adaptara ella sola al plan, ası que se debe hacer al reves. Despues de
cada Sprint se comprueba la velocidad real de dicho Sprint. Si la velocidad real ha sido muy
diferente de la estimada, se revisa la velocidad estimada para proximos Sprints y se actualiza
el plan de entregas. Si esto es una situacion problematica, puede que el Dueno de producto
empiece a negociar con el cliente o se dedique a averiguar como se puede reducir el alcance sin
romper el contrato. O quizas el y el equipo encuentren una forma de aumentar la velocidad
eliminando algun impedimento severo que se haya identificado durante el Sprint. El Dueno
de producto podrıa llamar al cliente y decirle “hola, vamos un poco retrasados respecto a
la planificacion, pero creo que podrıamos cumplir con la fecha de entrega si eliminasemos
la funcionalidad “comecocos embebido” que nos llevarıa un monton de tiempo construir.
Podrıamos anadirla en la siguiente entrega, 3 semanas despues de la primera version, si ası lo
quieres”. Quizas no sean buenas noticias para el cliente, pero al menos se esta siendo honesto
y se le esta dando al cliente opciones muy pronto: “podemos entregar las funcionalidades mas
importantes en fecha o entregarlo todo pero tarde”. Normalmente no suele ser una decision
muy difıcil[2].
2.6. Herramientas utilizadas
Ya explicado anteriormente lo mas trascendente de Scrum, entonces ya es hora de poner
en claro lo que se desea realizar que para este trabajo de tıtulo, que es desarrollar un gestor
de scrum y con como se hara, para esto es necesario describir las mas importantes herra-
mientas que fueron investigadas y que se utilizaron en este trabajo de tıtulo, para aquello se
comenzara de lo mas general a lo mas especıfico describiendo en terminos amplios Microsoft
.Net, Mono, MonoDevelop y el lenguaje C#.
24
2.6.1. Microsoft .NET
.NET es un framework de Microsoft que hace un enfasis en la transparencia de redes, con
independencia de plataforma de hardware y que permita un rapido desarrollo de aplicaciones.
Basado en ella, la empresa intenta desarrollar una estrategia horizontal que integre todos sus
productos, desde el sistema operativo hasta las herramientas de mercado.
.NET podrıa considerarse una respuesta de Microsoft al creciente mercado de los negocios
en entornos Web, como competencia a la plataforma Java de Sun Microsystems y a los diversos
framework de desarrollo web basados en PHP. Su propuesta es ofrecer una manera rapida
y economica, a la vez que segura y robusta, de desarrollar aplicaciones (o como la misma
plataforma las denomina, soluciones) permitiendo una integracion mas rapida y agil entre
empresas y un acceso mas simple y universal a todo tipo de informacion desde cualquier tipo
de dispositivo[9].
2.6.2. Mono
Mono es el nombre de un proyecto de codigo abierto iniciado por Ximian y actualmente
impulsado por Novell (tras la adquisicion de Ximian) para crear un grupo de herramientas
libres, basadas en GNU/Linux y compatibles con .NET[11].
Mono posee importantes componentes utiles para desarrollar software:
Una maquina virtual de infraestructura de lenguaje comun (CLI) que contiene un
cargador de clases, un compilador en tiempo de ejecucion (JIT), y unas rutinas de
recoleccion de memoria.
Una biblioteca de clases que puede funcionar en cualquier lenguaje que funcione en el
CLR (Common Language Runtime).
Un compilador para el lenguaje C#, MonoBasic (la version para mono de Visual Basic),
Java y Python.
25
El CLR y el Sistema de tipos comun (CTS) permite que la aplicacion y las bibliotecas
sean escritas en una amplia variedad de lenguajes diferentes que compilen para byte
code.
Esto significa que si, por ejemplo, se define una clase que realice una manipulacion
algebraica en C#, esta pueda ser reutilizada en cualquier lenguaje compatible con
CLI. Puede crear una clase en C#, una subclase en C++ e instanciar esa clase en un
programa en Eiffel.
Un sistema de objetos unico, sistema de hilos, bibliotecas de clases y sistema recolector
de memoria pueden ser compartidos por todos estos lenguajes.
Es un proyecto independiente de la plataforma. Actualmente Mono funciona en
GNU/Linux, FreeBSD, UNIX, Mac OS X, Solaris y plataformas Windows.
2.6.3. Monodevelop
MonoDevelop es el editor rapido de aplicaciones libre oficial de GNOME disenado princi-
palmente para C# y otros lenguajes de la plataforma .NET. Las principales caracterısticas
son:
Finalizacion de codigo automatica: Intenta completar tipos, metodos y nombres de campos
que estan siendo escritos. Se intentara obtener informacion de la clase de manera au-
tomatica de los archivos del codigo fuente y de las librerias que son referenciadas en el
proyecto abierto.
Ayuda integrada: La documentacion de .NET y de GTK# esta integrada dentro de Mono-
Develop para su facil acceso.
Respaldo a los proyectos: MonoDevelop te guıa en los proyectos que vas a comenzar ya sea
una aplicacion de consola, Gnome# o una aplicacion con Gtk#.
Extensiones y complementos: MonoDevelop posee un potente motor de extensiones, el cual
junto con el API modular y un completo puntos extendibles, te permite crear tus propias
26
herramientas de desarrollo. MonoDevelop incluye un panel de control para instalar tus
extensiones y complementos desde repositorios online[3].
Desde la version 2.2 MonoDevelop ya dispone de un instalador para Windows y MacOS
Ofreciendo ası un completo soporte multiplataforma. MonoDevelop se distribuye juntamente
con Mono para Mac OS X funcionando ambos de manera nativa (sin requerir otro software
adicional). MonoDevelop es empaquetado para Solaris sobre SPARC y x86 pero es mantenido
por grupos de la comunidad OpenSolaris. Finalmente, MonoDevelop es tambien mantenido
por la comunidad FreeBSD[10].
2.6.4. El lenguaje C#
C# o C Sharp, es un lenguaje orientado a objetos con enfasis en Internet se basa en las
lecciones aprendidas de los lenguajes C, C++, Java y Visual Basic. Por ello se trata de un
lenguaje que combina todas las cualidades que se pueden esperar de un lenguaje moderno
(orientacion a objetos, gestion automatica de memoria, etc.) a la vez que proporciona un
gran rendimiento.
En junio de 2000, Microsoft libero la especificacion de un nuevo lenguaje llamado C#. A
esto le siguio rapidamente la primera version de prueba del entorno de desarrollo estandar
(SDK) .NET, que incluıa un compilador de C#. El nuevo lenguaje estaba disenado por Anders
Hejlsberg (creador de Turbo Pascal y arquitecto de Delphi), Scott Wiltamuth y Peter Golde.
Entonces describieron el lenguaje como ”...simple, moderno, orientado a objetos, seguro y
con una fuerte herencia de C/C++”[8].
2.6.5. Caracterısticas de C#
Algunas de las mas importantes caracterısticas de C# son:
Orientacion a objetos: Como todo lenguaje de programacion de proposito general actu-
al, C# es un lenguaje orientado a objetos. Una diferencia del enfoque orientado a objetos
27
respecto al de otros lenguajes como C++ es que el de C# es mas puro en tanto que no
admite ni funciones ni variables globales sino que todo el codigo y datos han de definirse
dentro de definiciones de tipos de datos, lo que reduce problemas por conflictos de nombres y
facilita la legibilidad del codigo. C# soporta todas las caracterısticas propias del paradigma
de programacion orientada a objetos: encapsulacion, herencia y polimorfismo.
Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios
en .NET. Por ejemplo:
El codigo escrito en C# es autocontenido, lo que significa que no necesita de ficheros
adicionales al propio fuente tales como ficheros de cabecera o ficheros IDL
El tamano de los tipos de datos basicos es fijo e independiente del compilador, sistema
operativo o maquina para quienes se compile (no como en C++), lo que facilita la
portabilidad del codigo.
No se incluyen elementos poco utiles de lenguajes como C++ tales como macros, heren-
cia multiple o la necesidad de un operador diferente del punto (.).
Eficiente: En principio, en C# todo el codigo incluye numerosas restricciones para asegurar
su seguridad y no permite el uso de punteros. Sin embargo, y a diferencia de Java, en C#
es posible saltarse dichas restricciones manipulando objetos a traves de punteros. Para ello
basta marcar regiones de codigo como inseguras (modificador unsafe) y podran usarse en
ellas punteros de forma similar a como se hace en C++, lo que puede resultar vital para
situaciones donde se necesite una eficiencia y velocidad procesamiento muy grandes.
Extensibilidad de modificadores: C# ofrece, a traves del concepto de atributos, la posibil-
idad de anadir a los metadatos del modulo resultante de la compilacion de cualquier fuente
informacion adicional a la generada por el compilador que luego podra ser consultada en
tiempo ejecucion a traves de la librerıa de reflexion de .NET . Esto, que mas bien es una
caracterıstica propia de la plataforma .NET y no de C#, puede usarse como un mecanismo
para definir nuevos modificadores[5].
Capıtulo III
Desarrollo
29
En este capıtulo se abordan todas las variables que se vieron mientras se trabajaba en
la implementacion del prototipo, se empiezan a asimilar resultados y analisis, es decir, todos
los terminos que se encuentran en el marco teorico toman una forma tangible con muestras
del software o prototipo
Implementacion, diagramas UML y problemas en la implementacion son las tres secciones
en las cuales se veran en profundidad los analisis del prototipo con herramientas de diseno
UML y figuras de la implementacion, esto quiere decir que se mostrara varias imagenes del
prototipo en funcionamiento, todas y cada una con su explicacion pertinente. Finalmente se
mencionara los trabajos futuros que se basan en lo que no se pudo implementar por problemas
que se explicaran y fundamentaran.
30
3.1. Implementacion
Figura 3.1: Menu principal
La Figura 3.1 muestra el menu principal del programa en donde se ven una serie de
botones divididos en dos grupos. El primer grupo es el superior, se divide en tres columnas
con un boton en lo mas alto que marca las opciones con las que se cuenta, al marcar una
columna no se puede trabajar en las otras. En la Figura esta marcada la opcion Proyectos y
se ven los botones de Ingresar, Eliminar y el combobox en el cual se selecciona el Proyecto
31
en el que se desea trabajar.
El segundo grupo trabaja sobre las opciones seleccionadas en los combobox de Proyectos
y Sprints, para este ejemplo serıa Proyecto: ’BBB’, Sprint: ’B’, entonces por ejemplo en el
segundo grupo o menu es en donde se deberıa ingresar una historia que pertenezca al Sprint
’B’. En el segundo menu especificamente se trabaja sobre las retrospectivas, Scrum diarios,
historias y tareas. Para esto siempre se debe tener seleccionado un Sprint.
Figura 3.2: Listado de miembros
La Figura 3.2 muestra el listado de miembros que se encuentran ingresados a la base
de datos, en la imagen se ven los nombres de las personas y sus codigos, los cuales son
automaticamente asignados a cada miembro por la base de datos. Al querer eliminar un
miembro se debe verificar antes el codigo del miembro en esta lista ya que sera pedido. Para
ver esta ventana se debe presionar los botones Miembros y luego Lista.
32
Figura 3.3: Eliminar proyectos
La Figura 3.3 muestra la confirmacion o negacion de la peticion de eliminar un proyecto,
cabe destacar que el combobox de Proyectos senala cual proyecto se desea eliminar y se
confirma luego en la nueva ventana, para este caso el proyecto que se desea eliminar es ’bbb’.
Tambien se advierte que se eliminaran los derivados: historias, tareas, etc. para que ası no
quede basura en la base de datos.
33
Figura 3.4: Ingresar historias
La Figura 3.4 muestra como llenar los datos para ingresar historias, se ingresa un nombre,
la estimacion, importancia y descripcion. El estado esta por defecto ya que siempre tiene el
mismo valor inicial. Para ver esta ventana se debe presionar el boton historia en la columna
Ingresar, se debe tener escogido un Sprint para poder ingresar una historia.
34
Figura 3.5: Ingresar tarea
En la Figura 3.5 vemos como se ingresa informacion para una tarea, se le da un nombre,
estimacion y descripcion. Ademas se escoge un estado y una historia a la cual pertenece.
Para ingresar una tarea se debe presionar el boton tarea en la columna Ingresar, se debe
tener al menos una historia ingresada, sino se mostrara un aviso.
35
Figura 3.6: Ver retrospectiva
En la retrospectiva se ven los datos almacenados en la base de datos cuando esta se creo,
no se puede editar el contenido. Para acceder a ver la ventana que se muestra en la Figura
3.6 presione el boton retrospectiva en la columna Ver.
36
Figura 3.7: Editar tarea
En la Figura 3.7 se pueden modificar datos de la tarea cuando fue ingresada. Aparecen
dos botones; el primero de ellos es Miembros; este boton abre una nueva ventana en la cual
puedo asociar o desasociar miembros, el segundo boton presenta la opcion Eliminar la tarea.
Para Editar una tarea se debe marcar la opcion tarea en la columna Editar del segundo
menu.
3.2. Diagramas UML
En ingenierıa del software, un caso de uso es una tecnica para la captura de requisitos
potenciales de un nuevo sistema o una actualizacion de software. Cada caso de uso propor-
ciona uno o mas escenarios que indican como deberıa interactuar el sistema con el usuario o
con otro sistema para conseguir un objetivo especıfico. Normalmente, en los casos de usos se
evita el empleo de jergas tecnicas, prefiriendo en su lugar un lenguaje mas cercano al usuario
37
final[6].
Un diagrama de colaboracion es esencialmente un diagrama que muestra interacciones
organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas
de comunicacion muestran explıcitamente las relaciones de los roles[7].
Esta seccion de diagramas UML sirve para que a traves de estos se entienda desde
una nueva perspectiva el prototipo, se mostraran figuras que muestran variados diagramas
de colaboracion que son representativos de todo la aplicacion. La totalidad de acciones
que puede realizar el Scrum Master se ven en la Figura 3.8 que corresponde a los casos de
uso. Se presenta el analisis de algunos diagramas de colaboracion que dicho ya antes son
representativos ya que tienen gran porcentaje de similitud con el resto de los diagramas.
Figura 3.8: Casos de uso
38
En la Figura 3.8 vemos los casos de uso del prototipo, se exponen todas las posibilidades o
funcionalidades que tiene el Scrum Master para hacer alguna actividad dentro del prototipo.
Figura 3.9: Ingresar miembros
Para ingresar miembros a la base de datos se debe hacer a traves del prototipo, y
el diagrama de colaboracion muestra que lo primero es obtener los miembros para luego
almacenarlos.
Figura 3.10: Eliminar sprint
Para poder eliminar un Sprint lo primero es obtener el codigo identificador del Sprint,
luego se procede a eliminar todas las dependencias del Sprint y el Sprint en sı mismo.
39
Figura 3.11: Editar tarea
Para poder editar una tarea se debe conseguir el codigo identificador del Sprint, luego
el de la historia, con eso ya se encuentra la tarea y se puede modificar. El paso final es
sobreescribir la base de datos.
Figura 3.12: Ver retrospectiva
Para poder ver una retrospectiva se debe conseguir el codigo identificador del Sprint y
luego obtener de la base de datos los campos que se necesitan ver.
40
3.3. Dificultades en la implementacion
Monodevelop aun no es una herramienta globalizada en comparacion con Visual Studio,
su sımil de Microsoft, lo que deriva en menor cantidad de consumidores de Monodevelop y
por tanto en pocos manuales, tutoriales, etc. Esto era un tanto predecible, pero cabe volver
a mencionar que uno de los objetivos especıficos de este trabajo de Tıtulo era de caracter
investigativo y se describıa como promover la utilizacion de Monodevelop.
En busqueda de mayor informacion a falta de tutoriales, los foros oficiales de Mono y Mo-
nodevelop no son de gran ayuda ya que no estan actualizados, lo cual se presenta como una
nueva barrera para adquirir mas conocimientos. Y sumado a todo lo anterior la comunidad
Mono no respondio ninguno de los correos enviados por mı ni por el profesor guıa de este
trabajo de Tıtulo.
No es ningun misterio que Microsoft siempre tiene mas documentacion acerca de la uti-
lizacion de sus herramientas que cualquier software libre, pero Monodevelop aun pareciera no
tener gente encargada de la documentacion y de promover y mostrar las bondades de su sis-
tema mas alla de ser software libre, lo que termina perjudicandolo, ya que los programadores
corren el riesgo de enfrentarse a una duda y no tener donde solucionarla. Esto ultimo es
el caso en este trabajo de Tıtulo, ya que no existieron respuestas ni fuentes para encontrar
solucion al problema de generar graficos en GTK# ni poder implementar Drag & Drop.
Capıtulo IV
Conclusiones
42
Una vez terminada esta investigacion acerca de Scrum la primera apreciacion es que
aun cuando Scrum es un marco de trabajo que permite ciertas libertades a la hora de su
utilizacion, lo que lo diferencia principalmente de una metodologıa de trabajo, Scrum es
mucho mas fuerte cuando se combina con las buenas practicas propias del dominio del tipo
de proyecto en el que se lleva a cabo en Scrum, esto quiere decir que hay ciertas cosas que
se pueden acomodar a un grupo de trabajo pero otras que no.
El auge de la plataforma .NET ha servido para que Mono cobre cada vez mas pro-
tagonismo. Siendo una de las mas trascendentes razones para que esto suceda el hecho de
que atrae a desarrolladores de la plataforma de Microsoft que ven como sus aplicaciones
pueden ser ejecutadas en sistemas operativos que no son de este fabricante. Y si crece
Mono tambien crecera Monodevelop que es la herramienta que se utilizo en el desarrollo del
prototipo, pero aun falta un crecimiento cualitativo en el ambito de los accesos a la forma
de uso de esta herramienta, lo cual fue mencionado antes porque obligo a dejar trabajos
futuros. Aun ası no cabe dudas que Monodevelop crece rapidamente, un ejemplo en base a
experiencia es el hecho de que cuando se comenzo a trabajar en este proyecto no existıa ni
se vislumbraba una version para Windows, lo cual ya existe y se utilizo satisfactoriamente.
Siempre es sano y recomendable investigar, y este trabajo de tıtulo me entrego la
oportunidad de hacer este ejercicio, ya que tiene un enfoque investigativo con el fin de
promover herramientas como por ejemplo Mono y Monodevelop, que no son utilizadas por
la comunidad estudiantil de la Universidad de Magallanes en sus asignaturas, a partir de
esta premisa, y aun con cosas a favor y en contra de las herramientas de desarrollo de este
trabajo de tıtulo, satisfactoriamente puedo llegar a la conclusion que vale la pena investigar
acerca de plataformas como estas de software libre, para ası dar una nueva opcion a los
estudiantes de nuestra carrera y a la Universidad de Magallanes de contar con software que
permite ahorrar en pagos de licencias.
Otro de los objetivos fue implementar el prototipo de gestor de Scrum, lo cual se
logro; para posteriormente ponerlo a prueba en un trabajo cualquiera; lo que se realizo si-
guiendo los pasos del trabajo de tıtulo llamado “Creacion de una aplicacion didactica basica
43
en sistema Sugar” de Gustavo Roblero el cual mostrara su desarrollo a continuacion a traves
de un grafico Burndown.
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40
TR
AB
AJO
FECHA
Burndown
IDEALTESIS
Figura 4.1: Creacion de una aplicacion didactica basica en sistema Sugar
El grafico de la Figura 4.1 muestra el desarrollo de un Sprint que tiene una duracion de
40 dias de trabajo y 100 puntos en la suma de sus historias. No se alcanza a mostrar los
resultados finales ya que las fechas de la entrega de este trabajo de tıtulo no coincide con las
fecha 11 de julio que entrega Gustavo Roblero como finalizacion de proyecto. Para finalizar
la Figura 4.1 es ilustrada con el fin de demostrar que se hizo un seguimiento y se puso a
prueba el prototipo, tal como lo pedıan los objetivos especıficos.
Trabajos Futuros
45
Como trabajos futuros quedaron algunos puntos que inicialmente estaban contemplados
en el prototipo, ya que al avanzar en el desarrollo de este se localizaron problemas que
impidieron implementar el grafico Burndown Figura 2.10 y Drag & Drop de una forma
similar a la accion que se muestra en las Figuras 2.4, 2.5 y 2.6. Para detalles de los problemas
mencionados ver la seccion 3.3 Dificultades en la implementacion.
Ademas de todo lo anterior tambien se deja planteada la idea de hacer alguna relacion
entre casos de uso y pasar de historias a tareas, es decir, ¿como se podrıan asociar los casos
de uso con el marco de trabajo Scrum?. Esto ultimo es una duda planteada por el Dr.
Carlos Arias, profesor del Departamento de Ingenierıa en Computacion de la Universidad de
Magallanes.
Anexos
47
A. Tablas de la base de datos
hist descrip : Esta tabla describe las historias.
Campo Tipo Descripcion
id hist int Es el identificador de la historia
descripcion text Es una descripcion de la historia
Cuadro 1: hist descrip
hist estado : En esta tabla estan los posibles estados de las historias.
Campo Tipo Descripcion
id estado hist int Es el identificador del estado en que se encuentra la historia
nom estado hist char Es el nombre que recibe el estado
Cuadro 2: hist estado
hist estimacion : Esta tabla almacena la estimacion inicial de cada historia.
Campo Tipo Descripcion
id hist int Es el identificador de la historia
estimacion int Es cuanto trabajo es necesario para implementar la historia, son
puntos de historia y equivale a dıas-persona
Cuadro 3: hist estimacion
hist importancia : Esta tabla almacena la importancia que le da el dueno a cada historia.
Campo Tipo Descripcion
id hist int Es el identificador de la historia
import historia int Es la importancia que le da el dueno del producto a la historia
Cuadro 4: hist importancia
48
historia : Esta tabla almacena las historias.
Campo Tipo Descripcion
id hist int Es el identificador de la historia
id estado hist int Es el identificador del estado en que se encuentra la historia
id sprints int Es el identificador del Sprint al que pertenece la historia
nom historia char Es el nombre de la historia
Cuadro 5: historia
miembros : Esta tabla almacena a los integrantes que trabajan en los Proyectos.
Campo Tipo Descripcion
id miembro int Es el identificador de los integrantes
nombre char Es el nombre de un integrante
Cuadro 6: miembros
proyectos : Esta tabla almacena los Proyectos.
Campo Tipo Descripcion
id proyecto int Es el identificador de los Proyectos
nom proyecto char Son los nombres de los Proyectos
scrum master int Es el identificador del encargado del Proyecto
Cuadro 7: proyectos
retrospectiva : Tabla que almacena las Restrospectivas de cada Sprint, con el fin de mejo-
rarlos.
49
Campo Tipo Descripcion
id sprints int Es el identificador del Sprint al que pertenece la retrospectiva
mejorable text Son las cosas que se pueden mejorar
mejoras text Lo que se mejoro
bien text Lo que esta bien hecho
Cuadro 8: retrospectiva
scrum : Tabla que almacena comentarios de cada reunion de Scrum diario.
Campo Tipo Descripcion
id sprints int Es el identificador del Sprint al que pertenece el Scrum diario
fecha date Es la fecha en que se realiza la reunion
comentario text Guarda alguna breve idea u observacion del Scrum diario
Cuadro 9: scrum
sprints : Esta tabla guarda la informacion de los Sprints que se realizan durante un Proyecto.
Campo Tipo Descripcion
id sprints int Es el identificador del Sprint
nombre char Nombre del Sprint
id proyecto int Es el identificador de los Proyectos
fecha demo date Es la fecha en que se liberara la demo del Sprint
fecha inicio date Es la fecha en que se inicia el Sprint
fecha termino date Es la fecha en que se acaba el Sprint
hora scrum time Es el horario de las reuniones de Scrum diario
meta char Lo que se desea lograr en el Sprint
tester int Es el codigo del miembro encargado de hacer las pruebas
Cuadro 10: sprints
tarea : Esta tabla almacena las tareas, que son divisiones de las historias.
50
Campo Tipo Descripcion
id tarea int Es el identificador de las tareas
id hist int Es el identificador de la historia.
id estado tarea int Es el identificador del estado en que se encuentra la tarea
nom tarea char Es el nombre que recibe la tarea
Cuadro 11: tarea
tarea descrip : Esta tabla contiene la descripcion de cada tarea.
Campo Tipo Descripcion
id tarea int Es el identificador de las tareas
descripcion text Es una descripcion de la tarea
Cuadro 12: tarea descrip
tarea estado : Esta tabla almacena los posibles estados de las tareas.
Campo Tipo Descripcion
id estado tarea int Es el identificador del estado en que se encuentra la tarea
nom estado tarea char Es el nombre que recibe el estado
Cuadro 13: tarea estado
tarea estimacion : Esta tabla guarda la estimacion inicial de la tarea, la suma del tiempo
de tareas debe ser inferior o igual a la historia a la cual pertenecen.
Campo Tipo Descripcion
id tarea int Es el Es el identificador de las tareas
estimacion int Es cuanto trabajo es necesario para implementar la tarea, son
puntos de historia y equivale a dıas-persona
fecha date Es la fecha en que se modifico la estimacion de la tarea
Cuadro 14: tarea estimacion
51
tarea miembros : Esta tabla almacena a los integrantes que trabajan en una tarea especıfica
y la dedicacion que tienen a esta.
Campo Tipo Descripcion
id tarea int Es el identificador de las tareas
id miembro int Es el identificador de los integrantes
Cuadro 15: tarea miembros
Referencias y Bibliografıa
Bibliografıa
[1] Oscar Guzman. Metodologias agiles. http://sites.google.com/site/oeguzman/
introduccion.
[2] Henrik Kniberg. Scrum y xp desde las trincheras, 2007.
[3] Mono-hispano. Monodevelop. http://www.mono-hispano.org/wiki/Monodevelop.
[4] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004.
[5] Jose Antonio Gonzalez Seco. Introduccion a c#. http://www.devjoker.com/
contenidos/C/125/Introduccion-a-C.aspx.
[6] Wikipedia. Caso de uso. http://es.wikipedia.org/wiki/Caso_de_uso.
[7] Wikipedia. Diagrama de colaboracion. http://es.wikipedia.org/wiki/Diagrama_
de_colaboraci%C3%B3n.
[8] Wikipedia. El lenguaje c sharp. http://es.wikibooks.org/wiki/C_sharp_NET.
[9] Wikipedia. Microsoft .net. http://es.wikipedia.org/wiki/Microsoft_.NET.
[10] Wikipedia. Monodevelop. http://es.wikipedia.org/wiki/MonoDevelop.
[11] Wikipedia. Proyecto mono. http://es.wikipedia.org/wiki/Proyecto_Mono.
53
