Prototipo para Scrum Desarrollado en Mono

UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA EN COMPUTACIÓN
Prototipo para Scrum Desarrollado
en Mono
Pedro Antonio Bustos Estay
2010
La presente Memoria de Titulación ha sido aprobada con la siguiente calificación:
Pedro Antonio Bustos Estay
Memoria :
Exámen de Tı́tulo :
Nota Final :
MSc. Eduardo Peña Jaramillo
Director Departamento
de Ingenierı́a en Computación
13 de julio de 2010
UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA EN COMPUTACIÓN
Prototipo para Scrum Desarrollado en
Mono
Trabajo de titulación presentado en
conformidad a los requisitos para
obtener el tı́tulo de Ingeniero en Computación e Informática.
Profesor Guı́a: Sr. José Canumán
Chacón.
Pedro Antonio Bustos Estay
2010
Resumen
En el presente documento se encuentran variados análisis acerca del desarrollo del Prototipo para Scrum Desarrollado en Mono, que van desde el detalle de la base de datos hasta
las bases sobre las cuales comenzó el estudio, lo cual está abarcado en el marco teórico con
explicaciones en detalle de lo que se trata todo este trabajo de tı́tulo en términos generales.
También hay imagenes de la implementación del prototipo junto con los digramas de casos
de uso y de colaboración para ver y analizar desde un enfoque de ingenierı́a de software a
través de herramientas UML. El documento deja en claro los problemas que se encontraron
en la implementación y los trabajos futuros que se dejaron fuera de este trabajo de Tı́tulo por diversos motivos; se explica detalladamente la base de datos en la sección anexos y
para finalizar las conclusiones señalarán los puntos altos y bajos a través de opiniones y
observaciones de este trabajo de tı́tulo.
Índice general
I.
Introducción
1
1.1. Objetivo general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3. Descripción de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
II. Marco Teórico
4
2.1. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2. Pila de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3. Una planificación 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. Actualización de tareas . . . . . . . . . . . . . . . . . . . . . . . . . .
16
i
2.3.6. ¿Cómo funciona el diagrama Burndown? . . . . . . . . . . . . . . . .
16
2.3.7. El encargado de pruebas . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4. Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.5. Umbrales de aceptación 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. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2. Diagramas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3. Dificultades en la implementación . . . . . . . . . . . . . . . . . . . . . . . .
40
IV. Conclusiones
41
ii
Trabajos Futuros
43
Anexos
46
A. Tablas de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referencias y Bibliografı́a
47
51
iii
Índice 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. Estimación de historias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.14. Estimación de velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
iv
3.1. Menú 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. Creación de una aplicación didáctica básica en sistema Sugar . . . . . . . . .
43
v
Índice 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
51
Capı́tulo I
Introducción
2
Trabajar en grupos puede ser muy complicado en muchos ámbitos, ya que surgen muchas
dudas en relación a los objetivos individuales y grupales o los recursos con que se contará,
la división de tareas de forma equitativa para que nadie se sienta perjudicado puede ser el
mayor de los dolores de cabeza, especialmente para quien está a cargo de evaluar y hacer
que éstos grupos rindan de forma eficiente. Para asistir a éstas personas se creó un marco
de trabajo llamado Scrum, el cual pareciera ser ágil para desarrollo, no sólo 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, además de optimizar los recursos
con los que cuentan quienes desarrollen ideas con éste marco de trabajo.
Aún no sabemos a ciencia cierta en el medio en que se desenvuelve Scrum, ni la forma
en que las personas se relacionan con éste 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 prácticas y roles que puede tomarse como
punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Además Scrum es un framework o conjunto de herramientas, para la gestión y desarrollo
de tareas utilizado mayormente por personas ligadas a la informática. Está basado en un
proceso iterativo e incremental utilizado comúnmente en entornos de desarrollo de software.
Al parecer en la práctica, para muchos equipos de desarrollo, ante las dificultades para
utilizar metodologı́as tradicionales, se llegó a la resignación de prescindir del “buen hacer” de
la ingenierı́a del software con el objetivo de ajustarse a restricciones. Ante esta situación, las
metodologı́as ágiles aparecen como una posible respuesta para llenar este vacı́o metodológico.
Por estar especialmente orientadas para proyectos pequeños, las metodologı́as ágiles constituyen una solución a medida, con una elevada simplificación, que a pesar de ello no renuncia
a las prácticas esenciales para asegurar la calidad del producto[1].
1.1.
Objetivo general del proyecto
Crear un prototipo que sirva para gestionar a través de Scrum cualquier tipo de trabajo
en equipos.
3
1.2.
Objetivos especı́ficos
Utilizar el proyecto impulsado por Novell Mono a través de su interfaz Monodevelop y
programar la aplicación con el lenguaje C#
Implementar el gestor de Scrum como un prototipo
Poner a prueba este prototipo para un trabajo
Promover la utilización de Mono y su interfaz Monodevelop
1.3.
Descripción de la memoria
Capı́tulo I: Abarca la introducción al documento, una breve presentación de lo que se
verá con el correr de las hojas.
Capı́tulo II: Muestra todos los enfoques teóricos que se requirieron durante el desarrollo de
este trabajo de Tı́tulo.
Capı́tulo III: Es el desarrollo del prototipo, se analiza la implementación del prototipo.
Capı́tulo IV: Se analizará el prototipo entregando conclusiones.
Capı́tulo II
Marco Teórico
5
2.1.
Scrum
Scrum no tiene relación 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 ámbito que deseen desenvolver sus energias, ya sea en
algun proyecto muy importante o para la ayuda de actividades cotidianas. Scrum no dice
qué 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 válida, la
cual sea deseable de imitar, esto es muy importante porque Scrum lo hacen las experiencias.
La ejecución correcta de Scrum se está convirtiendo en un factor cada vez más importante para los equipos que buscan inversión 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: ¿cuándo terminarán el producto?, en
otras palabras se está preguntando si conocen la velocidad de sus equipos. Actualmente se
tiene dificultad para responder esta pregunta. Las oportunidades de inversión en el futuro requerirán que los equipos de desarrollo comprendan el concepto de su velocidad de producción
de software o de cualquier tipo de producto.
Los equipos de trabajo deben conocer los principios de Scrum. ¿Cómo se crea y se estima
una pila de producto?, ¿Cómo se gestiona un gráfico de Burndown y se calcula la velocidad
del equipo?
¿Por qué es esto tan importante? Si los equipos no conocen su velocidad, el Dueño de
producto no puede crear una hoja de ruta del producto con fechas de lanzamiento creı́bles.
Sin fechas de lanzamiento fiables, la compañias podrı́an fracasar y los inversores perder su
dinero.
Scrum requiere que los equipos completen algún tipo de producto potencialmente liberable
al final de cada iteración. Estas iteraciones están diseñadas para ser cortas y de duración
fija. Este enfoque en entregar código 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 código 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 también son conscientes de que la mejor manera de encontrar dichos errores es dejar de
pensar en el software a un nivel teórico de análisis y diseño, y sumergirse en él, ensuciarse
las manos y comenzar a construir el producto.
No hay y nunca habrá una lista de “mejores prácticas” en Scrum, porque el contexto
de cada equipo y proyecto impera sobre cualquier otra consideración. En lugar de mejores
prácticas, lo que se necesita conocer son mejores prácticas 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 cómo se desglosa y cómo se trabaja Scrum,
para esto se analiza a continuación la pila de producto y el plan de Sprint.
2.2.
Pila de producto
La pila de producto es el corazón de Scrum. Es donde empieza todo. La Pila de producto
es, básicamente, 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 explicará más adelante.
Los datos que contiene una historia son:
ID – un identificador único, simplemente un número auto-incremental. Esto nos permite
no perder la pista a las historias cuando se cambia su nombre.
Nombre – una descripción 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,
Dueño del producto comprenda aproximadamente de qué estamos hablando, y suficientemente clara como para distinguirla de las otras historias.
Importancia – el ratio de importancia que el Dueño de producto da a esta historia. Por
ejemplo, 10 o 150. Más alto = más importante.
Estimación inicial – la valoración 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 número óptimo de personas para esta historia (ni muchos ni pocos,
tı́picamente 2) y si se encerraran en una habitación con cantidad de comida, y trabajasen sin distracciones, ¿en cuántos dı́as saldrı́as con una implementación terminada,
demostrable, testeada y liberable?”. Si la respuesta es “con 3 personas encerrados en
una habitación nos llevarı́a 4 dı́as”, entonces la estimación inicial son 12 puntos. Lo
importante no es que las estimaciones absolutas sean correctas (es decir, que una historia 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).
Cómo probarlo – una descripción a alto nivel de cómo se demostrará esta historia en
la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación 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 descripción puede
usarse como pseudo-código para un test de aceptación.
Notas – cualquier otra información, clarificación, referencia a otras fuentes de información, 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 Dueño 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 estimación.
2.3.
Una planificación de Sprint
La planificación de Sprint es una reunión crı́tica, probablemente la más importante de
Scrum. Una planificación de Sprint mal ejecutada puede arruinar por completo todo el Sprint.
El propósito de la planificación de Sprint es proporcionar al equipo suficiente información
como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y
para ofrecer al Dueño de producto suficiente confianza como para permitı́rselo.
A continuación 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 dedicación, 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 más a menos importantes las historias y sus
tareas.
10
2.3.1.
Dividiendo las historias en tareas
¿Cuál es la diferencia entre historias y tareas? Una pregunta muy válida. La diferencia
es muy simple, las tareas son divisiones de una historia. Las historias son entregables de
los que el Dueño de producto se preocupa, pero no se preocupa de las tareas ya que son
creadas por quienes las trabajarán para ası́ ir dividiendo en pequeñas metas. Las tareas son
no-entregables, o aspectos de los que el Dueño de producto no se preocupa.
La figura 2.3 muestra un ejemplo de división de una historia llamada gestión de usuarios,
en dos post-its amarillos que representan tareas llamadas añadir/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) aún 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 están 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 completamente, entonces podemos escoger otra y repetir los pasos.
2.3.3.
Informar los Sprints
Es importante mantener a toda la compañia informada sobre lo que está ocurriendo.
De otra forma, la gente se quejarı́a constantemente o, incluso peor, podrian hacer falsas
presunciones sobre lo que está 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, sólo
se muestran cosas generales con el fin de informar y no se entran en detalles técnicos 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 continuación 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 chequeada en el repositorio de código fuente, testeada, refactorizada, etcétera). La herramienta de
migración (segunda historia) está 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 útil para recordar 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.
Actualización de tareas
El tablón de tareas se actualiza durante los Scrum diarios. Conforme cada persona describe
lo que hizo el dı́a anterior y lo que hará hoy, mueve los post-it en el tablón 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 estimación.
2.3.6.
¿Cómo 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 estimó 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
planificación, es decir, que a este paso se completarı́a todo al final del Sprint.
2.3.7.
El encargado de pruebas
Además de ser sólo 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 él dice que
está 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 más 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 relación 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 cómo se puede mejorar en el futuro.
2.5.
2.5.1.
Umbrales de aceptación y planes de entrega
Importancias
Además de la Pila de producto habitual, el Dueño de producto define una lista de umbrales
de aceptación, que son una simple clasificación de qué significan los niveles de importancia
de la Pila de producto en términos del contrato.
He aquı́ un ejemplo de umbrales de aceptación:
Todos los elementos con importancia >=100 deben estar incluidos en la versión 1.0
19
Todos los elementos de importancia entre 50 y 99 deberı́an estar incluidos en la versión
1.0, pero se podrı́a pasar sin ellos si se les incluyese en otra entrega poco después.
Los elementos con importancias entre 25 y 49 son requisitos, pero se pueden incluir en
una versión 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 código de colores
basado en las reglas anteriores:
Figura 2.12: Importancia de historias
Rojo = debe incluirse en la versión 1.0 (plátano - pera)
Amarillo = deberı́a incluirse en la versión 1.0 (pasa - cebolla)
20
Verde = puede hacerse más tarde (uva - melocotón)
Ası́ que si lo entregamos todo desde plátano 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 planificación de entregas el Dueño de producto necesita estimaciones,
al menos para todas las historias incluidas en el contrato. Al igual que en la planificación
de Sprint, se trata de un esfuerzo cooperativo entre el Dueño de producto y el equipo. El
equipo estima, el Dueño de producto describe los elementos y responde a las preguntas. Una
estimación de tiempos es valiosa si resulta ser casi correcta, menos valiosa si resulta que falla
por, digamos, un 30 % y completamente inútil si no tiene ninguna conexión con la realidad.
Todo esto no ha sido más 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 cómo podrı́an acabar las estimaciones (en puntos
de historia):
21
Figura 2.13: Estimación de historias
2.5.3.
Estimar la velocidad
Esto significa que debemos decidir nuestro factor de dedicación. El factor de dedicación
significa, básicamente, “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 dedicación del equipo es del 50 % (lo cual es
bastante bajo). Y digamos que la duración del Sprint es de 3 semanas (15 dı́as) y el tamaño
del equipo es 6 personas. Ası́ que cada Sprint tendrı́a 90 dı́as-hombre ideales, pero sólo 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: Estimación 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 prometió al cliente? depende enteramente
de la naturaleza del contrato. Usualmente se añade un buffer o colchón 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 adaptará ella sola al plan, ası́ que se debe hacer al revés. Después 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 próximos Sprints y se actualiza
el plan de entregas. Si esto es una situación problemática, puede que el Dueño de producto
empiece a negociar con el cliente o se dedique a averiguar cómo se puede reducir el alcance sin
romper el contrato. O quizás él y el equipo encuentren una forma de aumentar la velocidad
eliminando algún impedimento severo que se haya identificado durante el Sprint. El Dueño
de producto podrı́a llamar al cliente y decirle “hola, vamos un poco retrasados respecto a
la planificación, pero creo que podrı́amos cumplir con la fecha de entrega si eliminásemos
la funcionalidad “comecocos embebido” que nos llevarı́a un montón de tiempo construir.
Podrı́amos añadirla en la siguiente entrega, 3 semanas después de la primera versión, si ası́ lo
quieres”. Quizás no sean buenas noticias para el cliente, pero al menos se está siendo honesto
y se le está dando al cliente opciones muy pronto: “podemos entregar las funcionalidades más
importantes en fecha o entregarlo todo pero tarde”. Normalmente no suele ser una decisión
muy difı́cil[2].
2.6.
Herramientas utilizadas
Ya explicado anteriormente lo más 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 cómo se hará, para esto es necesario describir las más importantes herramientas que fueron investigadas y que se utilizaron en este trabajo de tı́tulo, para aquello se
comenzará de lo más general a lo más especı́fico describiendo en términos amplios Microsoft
.Net, Mono, MonoDevelop y el lenguaje C#.
24
2.6.1.
Microsoft .NET
.NET es un framework de Microsoft que hace un énfasis en la transparencia de redes, con
independencia de plataforma de hardware y que permita un rápido 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 rápida
y económica, a la vez que segura y robusta, de desarrollar aplicaciones (o como la misma
plataforma las denomina, soluciones) permitiendo una integración más rápida y ágil entre
empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo
de dispositivo[9].
2.6.2.
Mono
Mono es el nombre de un proyecto de código abierto iniciado por Ximian y actualmente
impulsado por Novell (tras la adquisición de Ximian) para crear un grupo de herramientas
libres, basadas en GNU/Linux y compatibles con .NET[11].
Mono posee importantes componentes útiles para desarrollar software:
Una máquina virtual de infraestructura de lenguaje común (CLI) que contiene un
cargador de clases, un compilador en tiempo de ejecución (JIT), y unas rutinas de
recolección 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 versión para mono de Visual Basic),
Java y Python.
25
El CLR y el Sistema de tipos común (CTS) permite que la aplicación 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 manipulación
algebraica en C#, ésta 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 único, 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 rápido de aplicaciones libre oficial de GNOME diseñado principalmente para C# y otros lenguajes de la plataforma .NET. Las principales caracterı́sticas
son:
Finalización de código automática: Intenta completar tipos, métodos y nombres de campos
que están siendo escritos. Se intentará obtener información de la clase de manera automática de los archivos del código fuente y de las librerias que son referenciadas en el
proyecto abierto.
Ayuda integrada: La documentación de .NET y de GTK# está integrada dentro de MonoDevelop para su fácil acceso.
Respaldo a los proyectos: MonoDevelop te guı́a en los proyectos que vas a comenzar ya sea
una aplicación de consola, Gnome# o una aplicación 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 versión 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 también mantenido
por la comunidad FreeBSD[10].
2.6.4.
El lenguaje C#
C# o C Sharp, es un lenguaje orientado a objetos con énfasis 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
(orientación a objetos, gestión automática de memoria, etc.) a la vez que proporciona un
gran rendimiento.
En junio de 2000, Microsoft liberó la especificación de un nuevo lenguaje llamado C#. A
esto le siguió rápidamente la primera versión de prueba del entorno de desarrollo estándar
(SDK) .NET, que incluı́a un compilador de C#. El nuevo lenguaje estaba diseñado 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 más importantes caracterı́sticas de C# son:
Orientación a objetos: Como todo lenguaje de programación de propósito general actual, 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 más puro en tanto que no
admite ni funciones ni variables globales sino que todo el código 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 código. C# soporta todas las caracterı́sticas propias del paradigma
de programación orientada a objetos: encapsulación, herencia y polimorfismo.
Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios
en .NET. Por ejemplo:
El código 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 tamaño de los tipos de datos básicos es fijo e independiente del compilador, sistema
operativo o máquina para quienes se compile (no como en C++), lo que facilita la
portabilidad del código.
No se incluyen elementos poco útiles de lenguajes como C++ tales como macros, herencia múltiple o la necesidad de un operador diferente del punto (.).
Eficiente: En principio, en C# todo el código 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 través de punteros. Para ello
basta marcar regiones de código como inseguras (modificador unsafe) y podrán 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 través del concepto de atributos, la posibilidad de añadir a los metadatos del módulo resultante de la compilación de cualquier fuente
información adicional a la generada por el compilador que luego podrá ser consultada en
tiempo ejecución a través de la librerı́a de reflexión de .NET . Esto, que más 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 implementación del prototipo, se empiezan a asimilar resultados y análisis, es decir, todos
los términos que se encuentran en el marco teórico toman una forma tangible con muestras
del software o prototipo
Implementación, diagramas UML y problemas en la implementación son las tres secciones
en las cuales se verán en profundidad los análisis del prototipo con herramientas de diseño
UML y figuras de la implementación, esto quiere decir que se mostrará varias imágenes del
prototipo en funcionamiento, todas y cada una con su explicación pertinente. Finalmente se
mencionará los trabajos futuros que se basan en lo que no se pudo implementar por problemas
que se explicarán y fundamentarán.
30
3.1.
Implementación
Figura 3.1: Menú principal
La Figura 3.1 muestra el menú 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 botón en lo más alto que marca las opciones con las que se cuenta, al marcar una
columna no se puede trabajar en las otras. En la Figura está marcada la opción 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 menú es en donde se deberı́a ingresar una historia que pertenezca al Sprint
’B’. En el segundo menú 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 códigos, los cuales son
automáticamente asignados a cada miembro por la base de datos. Al querer eliminar un
miembro se debe verificar antes el código del miembro en esta lista ya que será 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 confirmación o negación de la petición de eliminar un proyecto,
cabe destacar que el combobox de Proyectos señala cual proyecto se desea eliminar y se
confirma luego en la nueva ventana, para este caso el proyecto que se desea eliminar es ’bbb’.
También se advierte que se eliminarán 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 estimación, importancia y descripción. El estado está por defecto ya que siempre tiene el
mismo valor inicial. Para ver esta ventana se debe presionar el botón 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 información para una tarea, se le da un nombre,
estimación y descripción. Además se escoge un estado y una historia a la cual pertenece.
Para ingresar una tarea se debe presionar el botón tarea en la columna Ingresar, se debe
tener al menos una historia ingresada, sino se mostrará un aviso.
35
Figura 3.6: Ver retrospectiva
En la retrospectiva se ven los datos almacenados en la base de datos cuando esta se creó,
no se puede editar el contenido. Para acceder a ver la ventana que se muestra en la Figura
3.6 presione el botón 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 botón abre una nueva ventana en la cual
puedo asociar o desasociar miembros, el segundo botón presenta la opción Eliminar la tarea.
Para Editar una tarea se debe marcar la opción tarea en la columna Editar del segundo
menú.
3.2.
Diagramas UML
En ingenierı́a del software, un caso de uso es una técnica para la captura de requisitos
potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo 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 técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario
37
final[6].
Un diagrama de colaboración es esencialmente un diagrama que muestra interacciones
organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas
de comunicación muestran explı́citamente las relaciones de los roles[7].
Esta sección de diagramas UML sirve para que a través de éstos se entienda desde
una nueva perspectiva el prototipo, se mostrarán figuras que muestran variados diagramas
de colaboración que son representativos de todo la aplicación. 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 análisis de algunos diagramas de colaboración 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 través del prototipo, y
el diagrama de colaboración 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 código 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 código 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 código identificador del Sprint y
luego obtener de la base de datos los campos que se necesitan ver.
40
3.3.
Dificultades en la implementación
Monodevelop aún no es una herramienta globalizada en comparación 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 carácter
investigativo y se describı́a como promover la utilización de Monodevelop.
En búsqueda de mayor información a falta de tutoriales, los foros oficiales de Mono y Monodevelop no son de gran ayuda ya que no están actualizados, lo cual se presenta como una
nueva barrera para adquirir más conocimientos. Y sumado a todo lo anterior la comunidad
Mono no respondió ninguno de los correos enviados por mı́ ni por el profesor guı́a de este
trabajo de Tı́tulo.
No es ningún misterio que Microsoft siempre tiene más documentación acerca de la utilización de sus herramientas que cualquier software libre, pero Monodevelop aún pareciera no
tener gente encargada de la documentación y de promover y mostrar las bondades de su sistema más allá de ser software libre, lo que termina perjudicándolo, ya que los programadores
corren el riesgo de enfrentarse a una duda y no tener donde solucionarla. Esto último es
el caso en este trabajo de Tı́tulo, ya que no existieron respuestas ni fuentes para encontrar
solución al problema de generar gráficos en GTK# ni poder implementar Drag & Drop.
Capı́tulo IV
Conclusiones
42
Una vez terminada esta investigación acerca de Scrum la primera apreciación es que
aún cuando Scrum es un marco de trabajo que permite ciertas libertades a la hora de su
utilización, lo que lo diferencia principalmente de una metodologı́a de trabajo, Scrum es
mucho más fuerte cuando se combina con las buenas prácticas 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 más protagonismo. Siendo una de las más 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 también crecerá Monodevelop que es la herramienta que se utilizó en el desarrollo del
prototipo, pero aún falta un crecimiento cualitativo en el ámbito de los accesos a la forma
de uso de esta herramienta, lo cual fue mencionado antes porque obligó a dejar trabajos
futuros. Aún ası́ no cabe dudas que Monodevelop crece rápidamente, un ejemplo en base a
experiencia es el hecho de que cuando se comenzó a trabajar en este proyecto no existı́a ni
se vislumbraba una versión para Windows, lo cual ya existe y se utilizó satisfactoriamente.
Siempre es sano y recomendable investigar, y este trabajo de tı́tulo me entregó 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 aún con cosas a favor y en contra de las herramientas de desarrollo de este
trabajo de tı́tulo, satisfactoriamente puedo llegar a la conclusión que vale la pena investigar
acerca de plataformas como éstas de software libre, para ası́ dar una nueva opción 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
logró; para posteriormente ponerlo a prueba en un trabajo cualquiera; lo que se realizó siguiendo los pasos del trabajo de tı́tulo llamado “Creación de una aplicación didáctica básica
43
en sistema Sugar” de Gustavo Roblero el cual mostrará su desarrollo a continuación a través
de un gráfico Burndown.
Burndown
100
IDEAL
TESIS
80
TRABAJO
60
40
20
0
0
5
10
15
20
25
30
35
40
FECHA
Figura 4.1: Creación de una aplicación didáctica básica en sistema Sugar
El gráfico de la Figura 4.1 muestra el desarrollo de un Sprint que tiene una duración 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 finalización 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 éste se localizaron problemas que
impidieron implementar el gráfico Burndown Figura 2.10 y Drag & Drop de una forma
similar a la acción que se muestra en las Figuras 2.4, 2.5 y 2.6. Para detalles de los problemas
mencionados ver la sección 3.3 Dificultades en la implementación.
Además de todo lo anterior también se deja planteada la idea de hacer alguna relación
entre casos de uso y pasar de historias a tareas, es decir, ¿cómo se podrı́an asociar los casos
de uso con el marco de trabajo Scrum?. Esto último es una duda planteada por el Dr.
Carlos Arias, profesor del Departamento de Ingenierı́a en Computación de la Universidad de
Magallanes.
Anexos
47
A. Tablas de la base de datos
hist descrip : Esta tabla describe las historias.
Campo
Tipo
Descripción
id hist
int
Es el identificador de la historia
descripcion
text
Es una descripción de la historia
Cuadro 1: hist descrip
hist estado : En esta tabla están los posibles estados de las historias.
Campo
Tipo
id estado hist
int
nom estado hist
char
Descripción
Es el identificador del estado en que se encuentra la historia
Es el nombre que recibe el estado
Cuadro 2: hist estado
hist estimacion : Esta tabla almacena la estimación inicial de cada historia.
Campo
Tipo
Descripción
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 dueño a cada historia.
Campo
Tipo
Descripción
id hist
int
Es el identificador de la historia
import historia
int
Es la importancia que le da el dueño del producto a la historia
Cuadro 4: hist importancia
48
historia : Esta tabla almacena las historias.
Campo
Tipo
Descripción
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
id miembro
int
nombre
char
Descripción
Es el identificador de los integrantes
Es el nombre de un integrante
Cuadro 6: miembros
proyectos : Esta tabla almacena los Proyectos.
Campo
Tipo
id proyecto
int
nom proyecto
char
scrum master
int
Descripción
Es el identificador de los Proyectos
Son los nombres de los Proyectos
Es el identificador del encargado del Proyecto
Cuadro 7: proyectos
retrospectiva : Tabla que almacena las Restrospectivas de cada Sprint, con el fin de mejorarlos.
49
Campo
Tipo
Descripción
id sprints
int
mejorable
text
Son las cosas que se pueden mejorar
mejoras
text
Lo que se mejoró
bien
text
Lo que está bien hecho
Es el identificador del Sprint al que pertenece la retrospectiva
Cuadro 8: retrospectiva
scrum : Tabla que almacena comentarios de cada reunión de Scrum diario.
Campo
Tipo
Descripción
id sprints
int
fecha
date
Es la fecha en que se realiza la reunión
comentario
text
Guarda alguna breve idea u observación del Scrum diario
Es el identificador del Sprint al que pertenece el Scrum diario
Cuadro 9: scrum
sprints : Esta tabla guarda la información de los Sprints que se realizan durante un Proyecto.
Campo
Tipo
Descripción
id sprints
int
nombre
char
id proyecto
int
fecha demo
date
Es la fecha en que se liberará 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 identificador del Sprint
Nombre del Sprint
Es el identificador de los Proyectos
Es el código 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
Descripción
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 descripción de cada tarea.
Campo
Tipo
Descripción
id tarea
int
Es el identificador de las tareas
descripcion
text
Es una descripción de la tarea
Cuadro 12: tarea descrip
tarea estado : Esta tabla almacena los posibles estados de las tareas.
Campo
Tipo
id estado tarea
int
nom estado tarea
char
Descripción
Es el identificador del estado en que se encuentra la tarea
Es el nombre que recibe el estado
Cuadro 13: tarea estado
tarea estimacion : Esta tabla guarda la estimación inicial de la tarea, la suma del tiempo
de tareas debe ser inferior o igual a la historia a la cual pertenecen.
Campo
Tipo
Descripción
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 modificó la estimación 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 dedicación que tienen a ésta.
Campo
Tipo
Descripción
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 Guzmán.
Metodologias ágiles.
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] José Antonio González Seco.
Introducción 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 colaboración. 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