Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Comparativa Metodologias Agiles
Comparativa Metodologias Agiles
E. U. de Informtica (SEGOVIA)
Grado en Ingeniera Informtica de Servicios y
Aplicaciones
Tabla de contenidos
Captulo 1: Introduccin ............................................................................................ 7
Motivacin .............................................................................................................. 11
Objetivos del proyecto ............................................................................................. 12
Captulo 2: Metodologas giles y caractersticas .................................................... 13
Manifiesto gil ....................................................................................................... 17
Scrum ...................................................................................................................... 19
Actividades de la metodologa Scrum .................................................................. 20
Roles ................................................................................................................... 24
Herramientas ....................................................................................................... 27
XP (eXtreme Programming) .................................................................................... 30
Fases .................................................................................................................... 31
Reglas de XP ....................................................................................................... 32
Diseo ................................................................................................................. 34
Implementacin ................................................................................................... 35
Pruebas ................................................................................................................ 38
Valores en XP ...................................................................................................... 39
Roles ................................................................................................................... 39
Kanban .................................................................................................................... 42
Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo ............ 43
Determinar el lmite del trabajo en curso (Work In Progress) ............................... 43
Medir el tiempo en completar una tarea (Lead time) ............................................. 44
Roles ................................................................................................................... 44
Scrumban ................................................................................................................ 44
De Scrum ............................................................................................................. 45
De Kanban ........................................................................................................... 45
Captulo 3: Mtodo comparativo.............................................................................. 47
Orientacin de la organizacin ................................................................................ 52
Primer formulario: Orientacin tradicional vs orientacin gil ............................. 52
Segundo Formulario: Cumplimiento principios giles .......................................... 53
Eleccin de una metodologa gil ............................................................................ 55
Tercer Formulario: Eleccin de una metodologa gil .......................................... 59
3
Conclusiones ........................................................................................................... 67
Captulo 4: Caso Prctico ......................................................................................... 69
Velocidad inicial del equipo .................................................................................... 73
Reunin de planificacin ......................................................................................... 73
Historias de usuario ................................................................................................. 76
Reuniones diarias .................................................................................................... 83
Demostracin ........................................................................................................ 107
Reunin retrospectiva ............................................................................................ 107
Captulo 5: Planificacin ........................................................................................ 109
Backlog ................................................................................................................. 113
Primera iteracin ................................................................................................... 115
Segunda iteracin .................................................................................................. 118
Tercera iteracin.................................................................................................... 120
Cuarta iteracin ..................................................................................................... 122
Quinta iteracin ..................................................................................................... 125
Diagrama de Gantt ................................................................................................ 127
Captulo 6: Valoracin econmica ......................................................................... 131
Recursos Humanos ................................................................................................ 135
Estimacin de la duracin de las actividades ...................................................... 135
Costes unitarios.................................................................................................. 135
Equipo y tiempo en el proyecto .......................................................................... 135
Estimacin de horas del proyecto ....................................................................... 138
Estimacin econmica del proyecto ................................................................... 138
Recursos materiales ............................................................................................... 142
Hardware y Software ......................................................................................... 142
Comunicaciones................................................................................................. 142
Costo del proyecto................................................................................................. 143
Herramientas Empleadas ....................................................................................... 143
Captulo 7: Conclusiones ........................................................................................ 145
Captulo 8: Futuras lneas de trabajo .................................................................... 149
Captulo 9: Glosario de Trminos .......................................................................... 153
Captulo 10: Bibliografa ........................................................................................ 159
Captulo 11: Referencias ......................................................................................... 163
4
Captulo 1:
Introduccin
Contenido
Captulo 1: Introduccin ............................................................................................ 7
Motivacin .............................................................................................................. 11
Objetivos del proyecto ............................................................................................. 12
10
Introduccin
Motivacin
La idea surge por el inters personal en la ingeniera del software, en concreto,
por el desarrollo de software aplicando metodologas giles, ya que he visto que
mejoran la calidad del trabajo realizado en muchos aspectos, ayudan a ofrecer un buen
producto, adems de tener contento al cliente y por supuesto, que el equipo trabaje
cmodo. Despus de comenzar a trabajar con SCRUM en mi empresa, hubo un periodo
de documentacin para conocer esta metodologa y a la vez conocer, con menos
profundidad, otras metodologas giles. A partir de este momento he visto la necesidad
de elaborar una clasificacin / comparativa que me diese unos criterios para saber qu
metodologa gil se adapta mejor a un contexto de trabajo.
Las metodologas de desarrollo de software son decisivas en el xito o fracaso de
un proyecto. En general las metodologas ponen en prctica una serie de procesos
comunes, que son buenas prcticas para lograr los objetivos de negocio, costes,
funcionalidad, sencillez, etc. La eleccin de una metodologa inadecuada o su mala
aplicacin pueden conducir a que el proyecto no llegue a su fin.
Hasta hace muy poco, se venan utilizando las llamadas metodologas
tradicionales, donde los procesos son prcticamente secuenciales, estn cargados de
documentacin lo que los hace poco flexibles frente al cambio.
Hoy en da, con un escenario en el que los requisitos cambian habitualmente es
donde surge la necesidad de conocimiento sobre las metodologas giles, ms ligeras y
verstiles. En este proyecto hay un objetivo de divulgacin de las metodologas giles
ms importantes, as como saber en qu contexto encajan y las reglas bsicas del juego.
Varios criterios han hecho elegir esta temtica como eje para el Trabajo Fin de
Grado. Entre ellos el contacto reciente en mi trabajo, su importancia y las futuras
aplicaciones en la vida laboral.
11
12
Captulo 2:
Metodologas
giles y
caractersticas
13
14
Contenido
Captulo 2: Metodologas giles y caractersticas .................................................... 13
Manifiesto gil ....................................................................................................... 17
Scrum ...................................................................................................................... 19
Actividades de la metodologa Scrum .................................................................. 20
Roles ................................................................................................................... 24
Herramientas ....................................................................................................... 27
XP (eXtreme Programming) .................................................................................... 30
Fases .................................................................................................................... 31
Reglas de XP ....................................................................................................... 32
Diseo ................................................................................................................. 34
Implementacin ................................................................................................... 35
Pruebas ................................................................................................................ 38
Valores en XP ...................................................................................................... 39
Roles ................................................................................................................... 39
Kanban .................................................................................................................... 42
Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo ............ 43
Determinar el lmite del trabajo en curso (Work In Progress) ............................... 43
Medir el tiempo en completar una tarea (Lead time) ............................................. 44
Roles ................................................................................................................... 44
Scrumban ................................................................................................................ 44
De Scrum ............................................................................................................. 45
De Kanban ........................................................................................................... 45
15
16
17
A la hora de elaborar el manifiesto gil se han tenido en cuenta los siguientes puntos,
dndole ms valor a la primera parte que a la segunda:
Qu es Scrum?
Qu es XP (eXtreme Programming)?
Kanban?
Scrumban?
18
Scrum
En Scrum un proyecto se ejecuta en bloques temporales (iteraciones-sprints) de un mes
natural (pueden ser de dos o tres semanas, si as se necesita). Cada iteracin tiene que
proporcionar un resultado completo, un incremento de producto que sea susceptible de
ser entregado con el mnimo esfuerzo cuando el cliente lo solicite.
19
Planificacin de la iteracin
La planificacin de las tareas a realizar en la iteracin se divide en dos partes:
Primera parte de la reunin. Se realiza en un tiempo mximo 4 horas:
Define las tareas necesarias para poder completar cada requisito, creando la lista de
tareas de la iteracin.
Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se asigna a las tareas que puede realizar.
20
Beneficios
Potenciacin responsable de organizar el trabajo por parte del equipo, que es quien
mejor conoce como realizarlo.
Define las tareas necesarias para poder completar cada requisito, creando la lista de
tareas de la iteracin.
Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea.
Una estimacin conjunta es ms fiable, dado que tiene en cuenta los diferentes
conocimientos, experiencia y habilidades de los integrantes del equipo.
Ejecucin de la iteracin (sprint)
Recomendaciones
Para poder completar el mximo de requisitos en la iteracin, se debe minimizar el
nmero de requisitos en que el equipo trabaja simultneamente completando primero
los que den ms valor al cliente. Esta forma de trabajar, que se ve facilitada por la
propia estructura de la lista de tareas de la iteracin, permite tener ms capacidad de
reaccin frente a cambios o situaciones inesperadas.
Restricciones
El hecho de no poder cambiar los requisitos de la iteracin una vez iniciada facilita
que el cliente cumpla con su responsabilidad de conocer qu es lo ms prioritario a
desarrollar, antes de iniciar la iteracin.
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del
equipo no se relajen ni se extiendan en ms detalles de los necesarios.
Realizar las reuniones de colaboracin entre miembros del equipo justo despus de
la de sincronizacin.
22
Beneficios
El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos
que proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que
necesita y tomar mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los requisitos que solicit el
cliente y ver en qu puntos hay que mejorar la comunicacin entre ambos.
El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va
obteniendo. No est meses trabajando sin poder exhibir su obra.
23
Para realizar esta tarea, el cliente colabora con el equipo y obtiene de l la estimacin de
costes de desarrollo para completar cada requisito. El equipo ajusta el factor de
complejidad, el coste para completar los requisitos y su velocidad de desarrollo en
funcin de la experiencia adquirida hasta ese momento en el proyecto.
Hay que notar que el equipo sigue trabajando con los requisitos de la iteracin en curso,
(que de hecho eran los ms prioritarios al iniciar la iteracin). No es posible cambiar los
requisitos que se desarrollan durante la iteracin. En la reunin de planificacin de la
iteracin el cliente presentar la nueva lista de requisitos para que sea desarrollada.
Beneficios
De manera sistemtica, iteracin a iteracin, se obtienen los siguientes beneficios:
El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y
posibles desviaciones:
Roles
Cuando se aplica la metodologa Scrum se determinan las responsabilidades siguientes:
24
25
Velar que todos los participantes del proyecto sigan las reglas y proceso de Scrum,
encajndolas en la cultura de la organizacin, y guiar la colaboracin del equipo con
el cliente de manera que las sinergias sean mximas. Esto implica:
Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo
de cada iteracin (proporcionar un resultado til al cliente de la manera ms
efectiva) y poder finalizar el proyecto con xito. Estos obstculos se identifican de
manera sistemtica en las reuniones diarias de sincronizacin del equipo y en las
reuniones de retrospectiva.
Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la
iteracin (introduccin de nuevos requisitos, "secuestro" no previsto de un miembro
del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el
compromiso que adquiri sobre los requisitos que completara en la iteracin..
Asegurar que los requisitos se desarrollan con calidad.
Ensear al equipo a auto gestionarse. No da respuestas, si no que gua al equipo con
preguntas para que descubra por s mismo una solucin.
Equipo (Team)
Grupo de personas que de manera conjunta desarrollan el producto del proyecto.
Comparten la responsabilidad del trabajo que realizan (as como de su calidad) en cada
iteracin y en el proyecto. El tamao del equipo est entre 5 y 9 personas. Por debajo de
5 personas cualquier imprevisto o interrupcin sobre un miembro del equipo
compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que
se va a entregar al cliente al finalizar la iteracin. Por encima de 9 personas, la
comunicacin y colaboracin entre todos los miembros se hace ms difcil y se forman
subgrupos.
Es un equipo auto gestionado, que realiza de manera conjunta las siguientes actividades:
El equipo es multidisciplinar:
Los miembros del equipo tienen las habilidades necesarias para poder identificar y
ejecutar todas las tareas que permiten proporcionar al cliente los requisitos
comprometidos en la iteracin.
Tienen que depender lo mnimo de personas externas al equipo, de manera que el
compromiso que adquieren en cada iteracin no se ponga en peligro.
Se crea una sinergia que permite que el resultado sea ms rico al nutrirse de las
diferentes experiencias, conocimientos y habilidades de todos. Colaboracin
creativa.
Los miembros del equipo deben dedicarse al proyecto a tiempo completo para evitar
daar su productividad por cambios de tareas en diferentes proyectos, para evitar
interrupciones externas y as poder mantener el compromiso que adquieren en cada
iteracin.
Todos los miembros del equipo trabajan en la misma localizacin fsica, para poder
maximizar la comunicacin entre ellos mediante conversaciones cara a cara, diagramas
en pizarras, etc. De esta manera se minimizan otros canales de comunicacin menos
eficientes, que hacen que las tareas se transformen en un pasa pelota o que hacen
perder el tiempo en el establecimiento de la comunicacin
El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mnimo
posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones
interpersonales, engranarse y establecer su organizacin del trabajo.
Herramientas
Entre las herramientas que son necesarias en la aplicacin de Scrum se encuentran:
27
Contiene los requisitos de alto nivel del producto o proyecto. Para cada requisito se
indica el valor que aporta al cliente y el coste estimado de completarlo. La lista est
priorizada balanceando el valor que cada requisito aporta al negocio frente al coste
estimado que tiene su desarrollo.
En la lista se indican las posibles iteraciones y las entregas esperadas por el cliente
(los puntos en los cuales desea que se le entreguen los requisitos completados hasta
ese momento), en funcin de la velocidad de desarrollo del (los) equipo(s) que
trabajar(n) en el proyecto.
La lista tambin tiene que considerar los riesgos del proyecto e incluir los requisitos
o tareas necesarios para mitigarlos.
Antes de iniciar la primera iteracin, el cliente debe tener definida la meta del producto
o proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni
que todos los requisitos estn detallados al mismo nivel. Basta con que estn
identificados y con suficiente detalle los requisitos ms prioritarios con los que el
equipo empezar a trabajar. Los requisitos de iteraciones futuras pueden ser mucho ms
amplios y generales. La incertidumbre y complejidad propia de un proyecto hacen
conveniente no detallar todos los requisitos hasta que su desarrollo est prximo. De
esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos
prioritarios) est repartido en el perodo de ejecucin del proyecto. Esto produce varias
ventajas:
Se evita caer en parlisis de anlisis al inicio del proyecto, de manera que se puede
iniciar antes el desarrollo y el cliente puede empezar a obtener resultados tiles.
Se evita analizar en detalle requisitos no prioritarios que podran cambiar durante el
transcurso del proyecto, dado que se conocer mejor cul ha de ser el resultado a
conseguir, o bien porque podran ser reemplazados por otros.
Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar
los requisitos restantes.
para ser entregado al cliente al finalizar cada iteracin, de manera que no haya tareas
pendientes que puedan impedir utilizar los resultados del proyecto lo antes posible. De
este modo, el cliente podr tomar decisiones correctas cuando al final de cada iteracin
el equipo le haga una demostracin de los requisitos completados (por ejemplo, solicitar
una entrega del producto).
Cuando el cliente solicita una entrega de los requisitos completados hasta ese momento,
el equipo puede necesitar aadir una iteracin de entrega, ms corta que las iteraciones
habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el
momento de la entrega final.
Lista de tareas de la iteracin (Sprint Backlog)
Lista de tareas que el equipo elabora como plan para completar los requisitos
seleccionados para la iteracin y que se compromete a demostrar al cliente al finalizar la
iteracin, en forma de incremento de producto preparado para ser entregado.
Esta lista permite ver las tareas donde el equipo est teniendo problemas y no avanza,
con lo que le permite tomar decisiones al respecto.
La lista contiene las tareas, el esfuerzo pendiente para finalizarlas y la auto-asignacin
que han hecho los miembros del equipo.
El progreso de la iteracin y su velocidad con respecto a tareas u horas pendientes se
muestra mediante un grfico de trabajo pendiente (grfica burndown).
Grficos de trabajo pendiente (Burndown)
Un grfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se
est completando los requisitos. Permite extrapolar si el Equipo podr completar el
trabajo en el tiempo estimado.
Es una grfica que en un simple vistazo muestra la evolucin del equipo respecto a los
requisitos del usuario y muestra cuando se espera terminar:
29
Este tipo de grfico permite realizar diversas simulaciones: ver cmo se aplazan las
fechas de entrega si se le aaden requisitos, ver cmo se avanzan si se le quitan
requisitos o se aade otro equipo, etc.
XP (eXtreme Programming)
Tpicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones
30
Fases
Fase de exploracin
Es la fase en la que se define el alcance general del proyecto. En esta fase, el cliente
define lo que necesita mediante la redaccin de sencillas historias de usuario. Los
programadores estimas los tiempos de desarrollo en base a esta informacin. Debe
quedar claro que las estimaciones realizadas en esta fase son primarias (ya que estn
basadas en datos de muy alto nivel), y podran variar cuando se analicen en ms detalle
en cada iteracin.
Esta fase dura tpicamente un par de semanas, y el resultado es una visin general del
sistema, y un plazo total estimado.
Fase de planificacin
La planificacin es una fase corta, en la que el cliente, los gerentes y el grupo
desarrolladores acuerdan el orden en que debern implementarse las historias
usuario, y, asociadas a stas, las entregas. Tpicamente esta fase consiste en una
varias reuniones grupales de planificacin. El resultado de esta fase es un Plan
Entregas que se detallar en la seccin Reglas y Practicas.
31
de
de
o
de
Fase de iteraciones
Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades son
desarrolladas en esta fase, generando al final de cada una un entregable funcional que
implementa las historias de usuario asignadas a la iteracin. Como las historias de
usuario no tienen suficiente detalle como para permitir su anlisis y desarrollo, al
principio de cada iteracin se realizan las tareas necesarias de anlisis, recabando con el
cliente todos los datos que sean necesarios. El cliente, por lo tanto, tambin debe
participar activamente durante esta fase del ciclo.
Las iteraciones son tambin utilizadas para medir el progreso del proyecto. Una
iteracin terminada sin errores es una medida clara de avance.
Fase de puesta en produccin
Si bien al final de cada iteracin se entregan mdulos funcionales y sin errores,
puede ser deseable por parte del cliente no poner el sistema en produccin hasta tanto
no se tenga la funcionalidad completa.
En esta fase no se realizan ms desarrollos funcionales, pero pueden ser
necesarias tareas de ajuste.
Reglas de XP
Planificacin
La metodologa XP plantea la planificacin como un dialogo continuo entre las
partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los
coordinadores o gerentes. El proyecto comienza recopilando Historias de usuarios, las
que sustituyen a los tradicionales casos de uso. Una vez obtenidas las historias de
usuarios, los programadores evalan rpidamente el tiempo de desarrollo de cada una.
Si alguna de ellas tiene riesgos que no establecer con certeza la complejidad del
desarrollo, se realizan pequeos programas de prueba (spikes), para reducir estos
riesgos. Una vez realizadas estas estimaciones, se organiza una reunin de planificacin,
con los diversos actores del proyecto (cliente, desarrolladores, gerentes), a los efectos de
establecer un plan o cronograma de entregas (Release Plan) en los que todos estn de
acuerdo. Una vez acordado este cronograma, comienza una fase de iteraciones, en
dnde en cada una de ellas se desarrolla, prueba e instala unas pocas historias de
usuarios.
Los planes en XP se diferencian de las metodologas tradicionales en tres aspectos:
32
33
Plan de iteraciones
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas
en un ciclo de iteracin, de acuerdo al orden preestablecido.
Al comienzo de cada ciclo, se realiza una reunin de planificacin de la iteracin. Cada
historia de usuario se traduce en tareas especficas de programacin. Asimismo, para
cada historia de usuario se establecen las pruebas de aceptacin. Estas pruebas se
realizan al final del ciclo en el que se desarrollan, pero tambin al final de cada uno de
los ciclos siguientes, para verificar que subsiguientes iteraciones no han afectado a las
anteriores.
Las pruebas de aceptacin que hayan fallado en el ciclo anterior son analizadas para
evaluar su correccin, as como para prever que no vuelvan a ocurrir.
Reuniones diarias de seguimiento
El objetivo de tener reuniones diarias es mantener la comunicacin entre el equipo, y
compartir problemas y soluciones. En la mayora de estas reuniones, gran parte de los
participantes simplemente escuchan, sin tener mucho que aportar. Para no quitar tiempo
innecesario del equipo, se sugiere realizar estas reuniones en crculo y de pie.
Diseo
La metodologa XP hace especial nfasis en los diseos simples y claros. Los conceptos
ms importantes de diseo en esta metodologa son los siguientes:
Simplicidad
Un diseo simple se implementa ms rpidamente que uno complejo. Por ello XP
propone implementar el diseo ms simple posible que funcione. Se sugiere nunca
adelantar la implementacin de funcionalidades que no correspondan a la iteracin en la
que se est trabajando.
Caractersticas fundamentales del cdigo: Testeable, legible, comprensible y explicable.
Metforas
Una metfora es algo que todos entienden, sin necesidad de mayores explicaciones.
La metodologa XP sugiere utilizar este concepto como una manera sencilla de explicar
el propsito del proyecto, y guiar la estructura y arquitectura del mismo. Por ejemplo,
34
puede ser una gua para la nomenclatura de los mtodos y las clases utilizadas en el
diseo del cdigo. Tener nombres claros, que no requieran de mayores explicaciones,
redunda en un ahorro de tiempo.
Es muy importante que el cliente y el grupo de desarrolladores estn de acuerdo y
compartan esta metfora, para que puedan dialogar en un mismo idioma. Una buena
metfora debe ser fcil de comprender para el cliente y a su vez debe tener suficiente
contenido como para que sirva de gua a la arquitectura del proyecto.
Solucin spike
Una solucin spike, es una solucin muy simple para plantear posible soluciones, de
manera, que solamente se aborda el problema en concreto y se asla de otro tipo de
preocupaciones.
Refactorizacin
La recodificacin consiste en escribir nuevamente parte del cdigo de un programa, sin
cambiar su funcionalidad, a los efectos de hacerlo ms simple, conciso y/o entendible.
Muchas veces, al terminar de escribir un cdigo de programa, pensamos que, si lo
comenzramos de nuevo, lo hubiramos hecho en forma diferente, ms clara y
eficientemente.. Las metodologas de XP sugieren recodificar cada vez que sea
necesario. Si bien, puede parecer una prdida de tiempo innecesaria en el plazo
inmediato, los resultados de sta prctica tienen sus frutos en las siguientes iteraciones,
cuando sea necesario ampliar o cambiar la funcionalidad. La filosofa que se persigue
es, como ya se mencion, tratar de mantener el cdigo ms simple posible que
implemente la funcionalidad deseada.
Implementacin
Cliente disponible
Uno de los requisitos de XP es tener al cliente disponible. No solo para ayudar al equipo
de desarrollo, sino para ser parte del mismo. Todas las fases de XP requieren
comunicacin con el cliente.
Las historias de usuario son escritas por el cliente con la ayuda de los desarrolladores,
adems de establecer la prioridad de las mismas. Su presencia asegura que los
desarrollos cubren toda la funcionalidad descrita.
35
El proyecto termina con ms personas que conocen los detallas de cada parte del
cdigo.
Las personas aprenden a trabajar juntas, generando mejor dinmica de grupo y
haciendo que la informacin fluya rpidamente.
Las personas disfrutan ms de su trabajo.
Integracin secuencial
Pruebas
Pruebas Unitarias
Las pruebas unitarias son una de las piedras angulares de XP. Todos los mdulos deben
de pasar las pruebas unitarias antes de ser liberados o publicados. Por otra parte, como
se mencion anteriormente, las pruebas deben ser definidas antes de realizar el cdigo
(Test-driven programming). Que todo cdigo liberado pase correctamente las pruebas
unitarias es lo que habilita que funcione la propiedad colectiva del cdigo. En este
sentido, el sistema y el conjunto de pruebas debe ser guardado junto con el cdigo, para
que pueda ser utilizado por otros desarrolladores, en caso de tener que corregir, cambiar
o recodificar parte del mismo.
38
Valores en XP
Simplicidad: Hacer exactamente lo que se ha pedido, no ms.
Comunicacin: La comunicacin entre los componentes del equipo XP es fundamental.
Dado que la documentacin es escasa, el dilogo frontal, cara a cara, entre
desarrolladores, gerentes y el cliente es el medio bsico de comunicacin. Una buena
comunicacin tiene que estar presente durante todo el proyecto.
Retroalimentacin: Siempre tener en cuenta la valoracin del cliente una vez que se
hace una entrega e intentar mejorar haciendo cambios en el proceso si es necesario.
Coraje: Se trata que el equipo asuma la responsabilidad de su trabajo, tanto si es un
xito como un fracaso, adems de ser emprendedor a la hora de implementar cambios
en la aplicacin (refactorizaciones).
Roles
Cliente
El cliente es el responsable de conducir el proyecto. Define el proyecto y sus objetivos.
Cuanto ms preciso es su trabajo y cuanto mayor sea su involucracin, mayores sern
las oportunidades de xito.
Toma decisiones de negocio y debe entender los cambios del mismo a largo del tiempo:
identificando si una historia tiene el mismo valor ahora que cuando se identific, si se
puede retrasar o simplificar, adems de tener en consideracin las implicaciones
39
Responsabilidades
Programador
Una vez que se han comprendido las historias de usuario, el XP adjudica a los
programadores la responsabilidad de tomar decisiones tcnicas. Los desarrolladores
estiman el tiempo que les va a tomar cada historia. Transforma las historias de usuario a
cdigo. Deben responder a preguntas como:
Cmo implementamos esta funcionalidad?
Cunto nos va a llevar?
Cules son los riesgos?
Derechos
Responsabilidades
41
Para medir la velocidad del equipo, el encargado de seguimiento pregunta uno por uno a
los desarrolladores cuntas tareas ha completado. El mejor procedimiento es
preguntrselo en persona, en un ambiente informal y distendido. La sinceridad es
fundamental por parte de los desarrolladores, y el encargado de seguimiento no debe
entrar en valoraciones.
Esta mtrica ayuda a controlar el flujo del proyecto en posteriores iteraciones.
Entrenador (Coach)
No es un rol cubierto en todos los equipos de XP. Su papel es guiar y orientar al equipo,
especialmente cuando un equipo comienza a trabajar siguiendo la metodologa XP. Esto
se debe a que no es fcil aplicar XP de forma consistente. Aunque son prcticas de
sentido comn, se necesita un tiempo para interiorizarlas. Tambin hay situaciones
especiales en las que se requiere la sabidura de un especialista en XP para aplicar sus
normas frente a un obstculo en el proyecto.
El objetivo de un entrenador es que el equipo comprenda las directrices de XP. No se
trata de que sean solamente lecciones tericas, si no que se trata de dar ejemplo y
propone ideas para mejorar.
Gestor (Big Boss)
Es el gerente del proyecto, debe tener una idea general del proyecto y estar
familiarizado con su estado. El cliente puede asumir este papel.
Kanban
Su objetivo es gestionar de manera general como se van completando tareas, pero en los
ltimos aos se ha utilizado en la gestin de proyectos de desarrollo software.
Las principales reglas de Kanban son las siguientes:
1. Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo.
2. Determinar el lmite del trabajo en curso (WIP - Work In Progress).
3. Medir el tiempo en completar una tarea (Lead time).
42
pequeo, simple o complejo, hay una cantidad de trabajo ptima que se puede realizar
sin sacrificar eficiencia, por ejemplo, puede ser que realizar diez tareas a la vez nos
lleve una semana, pero hacer dos cosas a la vez nos lleve slo unas horas, lo que nos
permite hacer quince tareas en la semana.
En Kanban se debe definir cuantas tareas como mximo puede realizarse en cada fase
del ciclo de trabajo (ejemplo, como mximo 4 tareas en desarrollo, como mximo 1 en
pruebas, etc.), a ese nmero de tareas se le llama lmite del work in progress. A esto
se aade otra idea tan razonable como que para empezar con una nueva tarea alguna
otra tarea previa debe haber finalizado.
Por ejemplo, en la anterior figura de ejemplo el nmero lmite del work in progress
para las pruebas es 1.
Roles
La metodologa Kanban no prescribe roles. Tener un papel asignado y las tareas
asociadas a dicho papel crean una identidad en el individuo. Por lo tanto, pedir que
adopten un nuevo papel o un nuevo puesto de trabajo puede ser entendido como un
ataque a su identidad. Habra una resistencia al cambio. Kanban trata de evitar esa
resistencia emocional, entiende que la ausencia de papeles es una ventaja para el equipo.
Scrumban
Scrumban es una metodologa derivada de los mtodos de desarrollo Scrum y Kanban.
44
De Scrum
De Kanban
Flujo visual
Hacer lo que sea necesario, cuando sea necesario y solo la cantidad necesaria.
Limitar la cantidad de trabajo (WIP)
Optimizacin del proceso.
Scrum vs Scrumban:
Normas
Pizarra / Herramientas
Reuniones
Iteraciones
Estimaciones
Esquipo
Roles
WIP (Work In Progress)
Cambios
Impedimentos
Scrum
Pizarra
Backlogs
Grfica burn-down
Reunin diaria
Planificacin
Retrospectiva
S, Sprints
S
Multidisciplinar
Product Owner
Scrum Master
Equipo
Controlado por el
contenido del Sprint
Scrumban
Pizarra
Reunin diaria
No, flujo continuo
No
Puede ser especializado
Equipo + otros
historia. Por ello, resulta ms beneficioso adoptar flujo de trabajo continuo propio del
modelo Kanban.
Aunque hay diferencias entre ambos mtodos, por ejemplo, las reglas de Kanban son
muchas menos que las de Scrum, Kanban no define iteraciones (Sprints), Kanban limita
explcitamente las tareas que se pueden realizar por fase (con el lmite del work in
progress), mientras que Scrum lo hace de manera indirecta por medio del sprint
planning, etc.
46
Captulo 3: Mtodo
comparativo
47
48
Contenido
Captulo 3: Mtodo comparativo.............................................................................. 47
Orientacin de la organizacin ................................................................................ 52
Primer formulario: Orientacin tradicional vs orientacin gil ............................. 52
Segundo Formulario: Cumplimiento principios giles .......................................... 53
Eleccin de una metodologa gil ............................................................................ 55
Tercer Formulario: Eleccin de una metodologa gil .......................................... 59
Conclusiones ........................................................................................................... 67
49
50
Mtodo comparativo
El propsito de este apartado es responder a preguntas como:
Qu diferencia hay entre Srum y Kanban?
Dnde se complementan?
Hay conflictos potenciales?
En definitiva, este apartado trata de ser un comparador de herramientas, no se trata de
juzgar cul es mejor o cul es peor.
Cuchillo o tenedor qu herramienta es mejor?
Pues depende del contexto, para comer las albndigas el tenedor probablemente sea
mejor, para cortar setas el cuchillo y para comer filete lo mejor ser utilizar ambos de
manera conjunta.
Para la seleccin e implantacin de una metodologa existe una importante labor de
documentacin previa y, a partir de ah, escoger alguna de las metodologas vistas para
aplicar en el da a da de nuestro trabajo.
En este caso, se ha dado la vuelta al proceso, de manera que conociendo el marco de
trabajo lleguemos a una metodologa de trabajo apropiada.
Se ha elaborado un cuestionario que consta de dos partes, una inicial para conocer la
orientacin de la organizacin: gil o tradicional y una segunda parte que permite
conocer la metodologa gil que mejor se adapta al marco de trabajo de una
organizacin.
51
Orientacin de la organizacin
En esta fase se extraer el enfoque de la organizacin, bien un enfoque tradicional o un
enfoque gil. Si la empresa sigue en un porcentaje alto de implantacin de las
directrices de las metodologas giles, se podra pasar a la segunda parte del formulario,
mientras que si en esta primera fase se detecta que la cultura de trabajo es ms cercana a
una metodologa tradicional, sera necesario conocer y adquirir las prcticas de una
metodologa gil.
ORIENTACIN GIL
ORIENTACIN TRADICIONAL
VALOR
IMPORTANCIA VALOR
IMPORTANCIA
Individuo y las
El proceso y las
herramientas
y1
interacciones del equipo x1
Conseguir una
Desarrollar software
buena
que funciona
x2
documentacin
y2
Colaboracin con el
Negociacin
cliente
x3
contractual
y3
Seguimiento de un
Respuesta al cambio
x4
plan
y4
Tabla 3-1: Orientacin tradicional vs orientacin gil
Siendo x1, x2, x3 y x4 los valores asignados a cada valor con enfoque gil, e y1, y2, y3 e
y4 los valores asignados a cada valor con enfoque tradicional.
52
Caso Prctico
ORIENTACIN GIL
VALOR
IMPORTANCIA
Individuo y las
interacciones del equipo
3
Desarrollar software que
funciona
3
Colaboracin con el
cliente
2
Respuesta al cambio
3
MEDIA
2,75
ORIENTACIN TRADICIONAL
VALOR
IMPORTANCIA
El proceso y las
herramientas
2
Conseguir una buena
documentacin
2
Negociacin
contractual
2
Seguimiento de un plan
2
2
En este caso, se demuestra que se sobrevalora lo indicado por los valores del manifiesto
gil.
1
2
3
4
53
5
6
7
8
9
10
11
12
Total
Tabla 3-3: Cumplimiento principios giles
1
2
3
4
5
6
Prioridad
2
2
2
2
3
3
3
7 El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los
promotores, los desarrolladores y usuarios deberan ser capaces
8 de mantener una paz constante
3
La atencin continua a la calidad tcnica y al buen diseo mejora
9 la agilidad.
3
10 La simplicidad es esencial.
3
Las mejores arquitecturas, requisitos y diseos surgen de los
11 equipos organizados por s mismos.
2
En intervalos regulares, el equipo reflexiona respecto a cmo
12 llegar a ser ms efectivo, y segn esto ajusta su comportamiento. 2
Total
30
Tabla 3-4: Ejemplo cumplimiento principios giles
55
USO
Refleja por qu utilizar metodologas giles. Los atributos de esta vista tratan de evaluar
todos los beneficios de que el equipo de desarrollo y el cliente obtienen utilizando este
tipo de metodologas: incremento de la productividad, calidad y satisfaccin.
Las metodologas giles integran los cambios en el proceso de desarrollo, aportan reglas
y directrices para trabajar en proyectos con requisitos cambiantes manteniendo fechas
de entrega, Las metodologas giles aportan flexibilidad.
Los atributos de este punto de vista son:
CAPACIDAD DE AGILIDAD
Representa cul es la parte gil de la metodologa. Los atributos de esta vista
representan todos los aspectos del concepto de agilidad y su evaluacin refleja que
aspectos estn incluidos en una metodologa.
56
Indicadores de cambio.
Colaboracin.
Los requisitos funcionales pueden cambiar.
Los recursos humanos pueden cambiar.
Integracin de los cambios.
Nivel de intercambio de conocimientos (baja, alta).
De peso ligero.
Requisito no funcional puede cambiar.
Centrado en las personas.
Reactividad (al comienzo del proyecto, cada etapa, cada iteracin).
Refactoring poltico.
Iteraciones cortas.
Pruebas de poltica.
Plan de trabajo se puede cambiar.
APLICABILIDAD
El objetivo de esta vista es mostrar el impacto de los aspectos ambientales en el mtodo.
Representa cuando el entorno es favorable para la aplicacin de metodologas giles.
Este aspecto se describe por atributos, cada uno correspondiente a una caracterstica del
entorno.
57
PROCESOS Y PRODUCTOS
La vista de los procesos y productos representa cmo se caracteriza la metodologa. Los
atributos caracterizarn a los procesos giles por dos dimensiones y listarn los
productos de las actividades del proceso.
El proceso se compone de dos dimensiones. La primera dimensin son las actividades
de desarrollo de software cubiertas por las metodologas giles. La segunda representa
el nivel de abstraccin de sus directrices y reglas. Estas dos dimensiones se evalan con
atributos de esta vista.
Los atributos de los procesos y los productos son:
Nivel de abstraccin de las normas y directrices:
Gestin de proyectos
Descripcin de procesos
Normas y orientaciones concretas sobre las actividades y productos
Modelos de diseo
Comentario del cdigo fuente
Ejecutable
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Informes de calidad
Documentacin de usuario
Premisa
Respeto de las fechas de entrega
Cumplimiento de los requisitos
Respeto al nivel de calidad
Satisfaccin del usuario final
Entornos turbulentos
Favorable al Off shoring
Aumento de la productividad
Respuesta
CAPACIDAD DE AGILIDAD
Verdadero (V) o Falso (F) en cada una de las premisas.
1
2
3
4
5
6
7
8
Premisa
Iteraciones cortas
Colaboracin
Centrado en las personas
Refactoring poltico
Prueba poltico
Integracin de los cambios
De peso ligero
Los requisitos funcionales pueden cambiar
59
Respues
ta
APLICACIN
Verdadero (V) o Falso (F) en cada una de las premisas.
Premisa
Tamao del proyecto (PEQUEO, GRANDE)
La complejidad del proyecto (BAJA, ALTA)
Los riesgos del proyecto (BAJO, ALTO)
El tamao del equipo (PEQUEO, GRANDE)
El grado de interaccin con el cliente (BAJA, ALTA)
Grado de interaccin con los usuarios finales (BAJA, ALTA)
Grado de interaccin entre los miembros del equipo (BAJA, ALTA)
Grado de integracin de la novedad (BAJA, ALTA)
La organizacin del equipo (AUTO-ORGANIZACIN,
9 ORGANIZACIN JERRQUICA)
Respuesta
1
2
3
4
5
6
7
8
PROCESOS Y PRODUCTOS
Verdadero (V) o Falso (F) en cada una de las premisas.
Nivel de abstraccin de las normas y directrices:
Premisa
1 Gestin de proyectos
2 Descripcin de procesos
3 Normas y orientaciones concretas sobre las actividades y productos
Respuesta
Premisa
Puesta en marcha del proyecto
Definicin de requisitos
Modelado
Cdigo
Respuesta
60
5
6
7
8
9
10
Pruebas unitarias
Pruebas de integracin
Prueba del sistema
Prueba de aceptacin
Control de calidad
Sistema de uso
Tabla 3-9: Valoracin actividades cubiertas por el mtodo gil
Premisa
Modelos de diseo
Comentario del cdigo fuente
Ejecutable
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Informes de calidad
Documentacin de usuario
Respuesta
Los datos extrados de este formulario se compararn con clasificacin de las diferentes
metodologas que se muestra a continuacin.
METODOLOGAS GILES
ORIENTADA
AL
DESARROLLO
DE
SOFTWARE
USO
Cumplimiento de los
requisitos
Por qu
utilizar un
mtodo gil?
CAPACIDAD DE
AGILIDAD
SCRUM
KANBAN
SCRUMBAN
FALSO
VERDADERO
FALSO
FALSO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
FALSO
FALSO
FALSO
FALSO
FALSO
VERDADERO
FALSO
FALSO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
FALSO
VERDADERO
FALSO
VERDADERO
Aumento de la
productividad
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Iteraciones cortas
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Colaboracin
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Refactoring poltico
VERDADERO
FALSO
FALSO
FALSO
parte de
agilidad
incluida en el
mtodo?
XP
Entornos turbulentos
Cul es la
61
Prueba poltico
VERDADERO
VERDADERO
FALSO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
De peso ligero
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
FALSO
FALSO
VERDADERO
VERDADERO
VERDADERO
FALSO
VERDADERO
VERDADERO
VERDADERO
FALSO
VERDADERO
VERDADERO
VERDADERO
FALSO
FALSO
FALSO
ITERACIN
ITERACIN
ITERACIN
ITERACIN
ALTO
BAJO
BAJO
BAJO
PEQUEO
GRANDE /
PEQUEO
PEQUEO
GRANDE /
PEQUEO
La complejidad del
proyecto (BAJA, ALTA)
BAJA
ALTA
BAJA
ALTA
BAJO
ALTO
BAJO
ALTO
PEQUEO
PEQUEO
PEQUEO
PEQUEO
ALTA
ALTA
BAJO
BAJA
BAJO
ALTA
BAJO
BAJA
ALTA
ALTA
BAJA
ALTA
Grado de integracin de la
novedad (BAJA, ALTA)
ALTA
ALTA
BAJA
ALTA
AUTOORGANIZACIN
AUTOORGANIZACIN
AUTOORGANIZACIN
AUTOORGANIZACIN
Los requisitos no
funcionales pueden
cambiar
PROCESOS Y PRODUCTOS
APLICABILIDAD
Intercambio de
conocimientos (BAJO,
ALTO)
Cundo un
ambiente es
favorable para
Grado de interaccin con
usar este
los usuarios finales (BAJA,
mtodo?
ALTA)
62
FALSO
VERDADERO
FALSO
FALSO
FALSO
FALSO
Puesta en marcha
del proyecto
Definicin de
requisitos
FALSO
FALSO
FALSO
FALSO
VERDADERO
VERDADERO
FALSO
VERDADERO
Modelado
VERDADERO
VERDADERO
FALSO
FALSO
Cdigo
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Pruebas unitarias
Pruebas de
integracin
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
FALSO
FALSO
FALSO
FALSO
Control de calidad
FALSO
FALSO
FALSO
FALSO
Sistema de uso
FALSO
FALSO
FALSO
FALSO
FALSO
VERDADERO
FALSO
VERDADERO
Comentario del
cdigo fuente
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Ejecutable
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Pruebas unitarias
Pruebas de
integracin
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
Pruebas de sistema
Pruebas de
aceptacin
VERDADERO
FALSO
VERDADERO
VERDADERO
FALSO
FALSO
FALSO
FALSO
Informes de calidad
Documentacin de
usuario
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
Premisa
Respeto de las fechas de entrega
Cumplimiento de los requisitos
Respeto al nivel de calidad
Satisfaccin del usuario final
Entornos turbulentos
Favorable al Off shoring
Aumento de la productividad
Respuesta
V
V
V
V
V
F
V
63
CAPACIDAD DE AGILIDAD
1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
1
3
1
4
Premisa
Iteraciones cortas
Colaboracin
Centrado en las personas
Refactoring poltico
Prueba poltico
Integracin de los cambios
De peso ligero
Los requisitos funcionales pueden cambiar
Los requisitos no funcionales pueden cambiar
Respuesta
V
V
V
F
V
V
V
V
V
V
ITERACIN
BAJO
APLICACIN
Premisa
Tamao del proyecto (PEQUEO, GRANDE)
La complejidad del proyecto (BAJA, ALTA)
Los riesgos del proyecto (BAJO, ALTO)
El tamao del equipo (PEQUEO, GRANDE)
El grado de interaccin con el cliente (BAJA, ALTA)
Grado de interaccin con los usuarios finales (BAJA, ALTA)
Grado de interaccin entre los miembros del equipo (BAJA,
7 ALTA)
8 Grado de integracin de la novedad (BAJA, ALTA)
La organizacin del equipo (AUTO-ORGANIZACIN,
9 ORGANIZACIN JERRQUICA)
1
2
3
4
5
6
PROCESOS Y PRODUCTOS
Verdadero (V) o Falso (F) en cada una de las premisas.
Nivel de abstraccin de las normas y directrices:
64
Respuesta
PEQUEO
BAJA
BAJO
PEQUEO
ALTA
ALTA
ALTA
ALTA
JERRQUICA
Premisa
1 Gestin de proyectos
2 Descripcin de procesos
3 Normas y orientaciones concretas sobre las actividades y productos
Respuesta
V
V
F
Premisa
Puesta en marcha del proyecto
Definicin de requisitos
Modelado
Cdigo
Pruebas unitarias
Pruebas de integracin
Prueba del sistema
Prueba de aceptacin
Control de calidad
Sistema de uso
Respuesta
V
V
F
V
V
V
V
V
V
V
Tabla 3-16: Ejemplo valoracin de las actividades cubiertas por la metodologa gil
Premisa
Modelos de diseo
Comentario del cdigo fuente
Ejecutable
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Informes de calidad
Documentacin de usuario
Respuesta
F
V
V
V
V
V
V
V
V
En los casos en los que la respuesta de la organizacin coincida con el valor asociado a
la metodologa se sumar 1, en caso contrario 0.
65
METODOLOGAS GILES
APLICABILIDAD
CAPACIDAD DE AGILIDAD
USO
ORIENTADA AL
DESARROLLO
DE SOFTWARE
ORIENTADA A LA GESTIN DE
PROYECTOS
XP
SCRUM
KANBAN
SCRUMBAN
Entornos turbulentos
Aumento de la productividad
Iteraciones cortas
Colaboracin
Refactoring poltico
Prueba poltico
De peso ligero
Reactividad
Intercambio de conocimientos
Grado de integracin de la
novedad
66
Descripcin de procesos
Normas y orientaciones
concretas sobre las actividades y
productos
PROCESOS Y PRODUCTOS
Definicin de requisitos
Modelado
Cdigo
Pruebas unitarias
Pruebas de integracin
Prueba de aceptacin
Control de calidad
Sistema de uso
Ejecutable
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Informes de calidad
Documentacin de usuario
32
32
TOTAL:
34
Tabla 3-18: Metodologa gil adecuada para el ejemplo
33
En los resultados se observa que XP y SCRUMBAN son los que han obtenido ms
puntuacin. Podran aplicar una u otra, incluso XP para la fase de desarrollo y SCRUM
para la gestin de los proyectos de la organizacin.
Conclusiones
Usar las herramientas adecuadas ayuda a triunfar, pero no garantiza el xito. Es fcil
confundir el xito/fracaso del proyecto, con el xito/fracaso de la herramienta.
Del mismo modo, el hecho de no aplicar todas y cada una de las recomendaciones de la
herramienta no conduce al fracaso. No es requisito indispensable para el xito.
67
No limitar las herramientas que utilizamos, las herramientas (Scrum, Kanban, XP) se
pueden combinar, por ejemplo, muchos equipos de Kanban hacen reuniones diarias (que
es una prctica de Scrum). Hay que usar lo que funcione en cada equipo.
68
Captulo 4: Caso
Prctico
69
70
Contenido
Captulo 4: Caso Prctico ......................................................................................... 69
Velocidad inicial del equipo .................................................................................... 73
Reunin de planificacin ......................................................................................... 73
Historias de usuario ................................................................................................. 76
Reuniones diarias .................................................................................................... 83
Demostracin ........................................................................................................ 107
Reunin retrospectiva ............................................................................................ 107
71
72
Caso prctico
En este captulo se muestra un caso prctico de una iteracin (Sprint) de Scrum
para resolver una seria de tareas para un proyecto Web. El objetivo es tener una toma de
contacto con una aplicacin prctica de las metodologas giles y no solo terica. A lo
largo del captulo se han ido documentando el da a da de la iteracin.
Desarrollador 1
Desarrollador 2
Desarrollador 3
Desarrollador 4
Desarrollador 5
Disponibilidad
100%
100%
100%
100%
50%
TOTAL
Tabla 4-1: Velocidad del equipo
Reunin de planificacin
Backlog de historias de usuario presentado por el cliente:
73
Prior
Proyecto
Nombre
Notas
Gestin Incidencias
Gestin Incidencias
Gestin Incidencias
Crear front-end para subir Nueva opcin en el men y nueva ventana para que el usuario
Excel con incidencias.
descargue la plantilla Excel y una vez cubierta la enve al sistema.
LDAP
Cmo probarlo
Comprobar que una vez que
el usuario sube un Excel con
incidencias, se procesan y se
crean registros de incidencias
en la web.
LDAP
Configuracin de perfiles
LDAP
Informes
Aadir un nuevo
concepto de comisin en
los informes
74
Durante la reunin de planificacin se trat una a una y con la prioridad establecida por
el cliente las historias de usuario para el siguiente Sprint.
Utilizando para la estimacin la serie de Fibonacci (1/2, 1, 2, 3, 5, 6, 7, ,
).
Historias de usuario
Backlog Item #7
Proyecto: Informes
Prioridad
Como probarlo
Una vez calculada la comisin por portabilidad, comprobar
que se acumula en la columna de "Comisin Portabilidad".
Estimacin
7
11
Backlog Item #6
Proyecto: LDAP
Notas
Se requiere implantar LDAP en el acceso a la Web de
Comisiones.
Prioridad
Como probarlo
Estimacin
6
3
77
Backlog Item #5
Proyecto: LDAP
Configuracin de perfiles
Notas
Es necesario tener dos perfiles diferentes a la hora de acceder a
la Web:
Los perfiles a configurar son:
- Administrador.
- No administrador.
Como probarlo
Prioridad
5
Estimacin
2
Tareas asociadas a esta historia de usuario:
78
Backlog Item #4
Proyecto: LDAP
Prioridad
79
4
Estimacin
Backlog Item #3
Proyecto: Gestin Incidencias
Prioridad
Como probarlo
Comprobar gua de estilo del cliente.
Test de accesibilidad.
Estimacin
3
6
80
Backlog Item #2
Proyecto: Gestin Incidencias
Prioridad
Como probarlo
Estimacin
2
4
Crear tabla de BBDD como repositorio de los archivos Excel con incidencias de los
usuarios.
Crear Manager para el acceso a la nueva tabla.
Recoger el archivo Excel de la vista y almacenarlo.
81
Backlog Item #1
Proyecto: Gestin Incidencias
Prioridad
Como probarlo
Comprobar que una vez que el usuario sube un Excel con
incidencias, se procesan y se crean registros de incidencias en
la web.
Estimacin
82
1
9
Reuniones diarias
Estado de la grfica
La lnea gris marca el progreso ideal del Sprint, se pinta para tener una referencia de la
consecucin de trabajo a lo largo del Sprint, siempre que la lnea de progreso vaya por
83
debajo de la lnea gris, el ritmo es mejor del esperado, cuando est por encima, el
equipo es ms lento de lo planificado.
El primer da del Sprint la grfica est limpia, an no ha habido progreso en las tereas.
Da 1:
Preguntas que tiene que responder cada uno de los desarrolladores: Qu has hecho
ayer? Qu voy a hacer hoy? Algn impedimento?
Desarrollador 1: Ha estado trabajando en la tarea: Crear modelo para el concepto de
PORTABILIDAD. Durante el da de hoy continuar con esta tarea. No ha encontrado
ningn impedimento y estima que an le quedan 4 puntos de trabajo, por tanto, ha
avanzado un punto de trabajo.
Desarrollador 2: Ha estado trabajando en la tarea: Procedimiento SQL que genere
informe. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Estima que le quedan 2 puntos de trabajo en esta tarea.
Desarrollador 3: Ha estado trabajando en la tarea: FRONT-END: Nueva columna en
los informes. Comisin Portabilidad y ya est terminada, por tanto, actualiza el ticket
de la tarea a la columna Hecho!. Coge la siguiente tarea disponible en el tabln:
Configurar perfil: administrador.
Desarrollador 4: Ha estado trabajando en la tarea: BACK-END: Recuperar comisin
de BBDD. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Estima que le quedan 1 puntos de trabajo en esta tarea.
84
85
Da 2:
Desarrollador 1: Ha estado trabajando en la tarea: Crear modelo para el concepto de
PORTABILIDAD. Durante el da de hoy continuar con esta tarea. No ha encontrado
ningn impedimento y estima que an le quedan 3 puntos de trabajo, por tanto, ha
avanzado un punto de trabajo.
Desarrollador 2: Ha estado trabajando en la tarea: Procedimiento SQL que genere
informe. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Estima que le quedan 1.5 puntos de trabajo en esta tarea.
Desarrollador 3: Ha estado trabajando en la tarea: Configurar perfil: administrador
en el entorno de Desarrollo. Mientras no se instalen los servidores en los entornos de
Pruebas y Produccin no puede seguir trabajando, por tanto, deja su tarea en la
columna: Pendiente y coge la tarea de: Instalar LDAP en: Pruebas y Produccin.
Desarrollador 4: Ha estado trabajando en la tarea: BACK-END: Recuperar comisin
de BBDD. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Mantiene la estimacin de la tarea.
Desarrollador 5: El desarrollador 5 (su disponibilidad al Sprint es del 50%) no ha
podido trabajar en la tarea de: Configurar perfil: Administrador, y durante la jornada
de hoy tampoco podr dedicarle tiempo, por tanto, mantiene la estimacin de la tarea.
86
87
Da 3:
Desarrollador 1: Ha estado trabajando en la tarea: Crear modelo para el concepto de
PORTABILIDAD. Durante el da de hoy continuar con esta tarea. No ha encontrado
ningn impedimento y estima que an le quedan 2.5 puntos de trabajo.
Desarrollador 2: Ha estado trabajando en la tarea: Procedimiento SQL que genere
informe. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Estima que an le quedan 1.5 puntos de trabajo en esta tarea.
Desarrollador 3: Ha finalizado la tarea: Instalar LDAP en: Desarrollo, Pruebas y
Produccin y la coloca en la columna Hecho!. Para continuar hoy se coge la tarea:
Configurar perfil: Administrador.
Desarrollador 4: Ha estado trabajando en la tarea: BACK-END: Recuperar comisin
de BBDD. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Reestima la tarea en 0.5 puntos de trabajo.
Desarrollador 5: El desarrollador 5 (su disponibilidad al Sprint es del 50%) no ha
trabajado en las tareas de Sprint.
88
Da 4:
Desarrollador 1: Ha estado trabajando en la tarea: Crear modelo para el concepto de
PORTABILIDAD. Durante el da de hoy continuar con esta tarea. No ha encontrado
ningn impedimento y estima que an le quedan 1 puntos de trabajo.
Desarrollador 2: Ha estado trabajando en la tarea: Procedimiento SQL que genere
informe. Durante el da de hoy continuar con esta tarea. No hay encontrado ningn
impedimento. Estima que an le quedan 0.5 puntos de trabajo en esta tarea.
Desarrollador 3: Ha finalizado la tarea: Configurar perfil: Administrador y la coloca
en la columna Hecho!. Para continuar hoy se coge la tarea: Configurar perfil: no
Administrador (limitado).
Desarrollador 4: Ha terminado la tarea: BACK-END: Recuperar comisin de
BBDD. Se coge una nueva tarea: Perfil administrador: opcin para simular
distribuidor.
Desarrollador 5: El desarrollador 5 (su disponibilidad al Sprint es del 50%) no ha
trabajado en las tareas de Sprint.
89
90
Da 5:
Desarrollador 1: Fin de la tarea: Crear modelo para el concepto de
PORTABILIDAD, se mueve a la columna Hecho!. Se asigna la siguiente tarea
disponible en el tablero: Perfil no administrador: Que no se vea la opcin de simular
distribuidor.
Desarrollador 2: Fin de la tarea: Procedimiento SQL que genere informe, se mueve a
la columna Hecho!. Se asigna la siguiente tarea disponible en el tablero:
Incidencias / Subir fichero Excel.
Desarrollador 3: Ha trabajado en la tarea: Perfil administrador: opcin para simular
distribuidor reestima que an le quedan 1.5 puntos de trabajo. Hoy se mantendr
trabajando en esta tarea.
Desarrollador 4: Ha finalizado la tarea: Configurar perfil: no Administrador
(limitado) que pone en la columna Hecho!. Coge la siguiente tarea disponible en el
tablero: Definir plantilla Excel.
Desarrollador 5: Coge la tarea: Descargar plantilla Excel.
91
92
Da 6:
Desarrollador 1: Ha trabajado en la tarea: Perfil no administrador: Que no se vea la
opcin de simular distribuidor. Reestima la tarea en 1 punto de trabajo.
Desarrollador 2: Ha trabajado en la tarea: Incidencias / Subir fichero Excel.
Reestima la tarea en 2.5 puntos de trabajo.
Desarrollador 3: Ha trabajado en la tarea: Perfil administrador: opcin para simular
distribuidor reestima que an le quedan 0.5 puntos de trabajo. Hoy se mantendr
trabajando en esta tarea.
Desarrollador 4: Ha finalizado la tarea: Definir plantilla Excel que pone en la
columna Hecho!. Coge la siguiente tarea disponible en el tablero: Tabla en BBDD.
Desarrollador 5: Ha trabajado en la tarea: Descargar plantilla Excel. Reestima que
an le queda 1 punto de trabajo.
93
94
Da 7:
Desarrollador 1: Ha trabajado en la tarea: Perfil no administrador: Que no se vea la
opcin de simular distribuidor. Mantiene la estimacin en 1 punto de trabajo.
Desarrollador 2: Ha trabajado en la tarea: Incidencias / Subir fichero Excel.
Reestima la tarea en 1.5 de trabajo.
Desarrollador 3: Ha finalizado la tarea: Perfil administrador: opcin para simular
distribuidor. Se coge la siguiente tarea disponible en el tablero: Manager para el
acceso a la nueva tabla.
Desarrollador 4: Ha trabajado en la tarea: Tabla en BBDD. Reestima que an le
queda 1 punto de trabajo.
Desarrollador 5: Ha finalizado la tarea: Descargar plantilla Excel. Se coge la
siguiente tarea disponible en el tablero:Recoger el archivo que sube el usuario y
almacenarlo.
95
Da 8:
Desarrollador 1: Ha finalizado la tarea: Perfil no administrador: Que no se vea la
opcin de simular distribuidor. Coge la siguiente tarea disponible en el tablero:Script
Perl para la creacin de incidencias.
Desarrollador 2: Ha trabajado en la tarea: Incidencias: Subir fichero Excel. Reestima
la tarea en 0.5 puntos de trabajo.
Desarrollador 3: Ha trabajado en la tarea: Manager para el acceso a la nueva tabla.
Reestima la tarea en 1 punto de trabajo.
Desarrollador 4: Ha finalizado la tarea: Tabla en BBDD. Coge la siguiente tarea
disponible en el tablero:Crear incidencias e insertarlas en BBDD.
Desarrollador 5: Ha finalizado la tarea en la que estaba trabajando: Recoger el
archivo que sube el usuario y almacenarlo. Coge la siguiente tarea disponible en el
tablero:Aadir validaciones al script.
96
97
Da 9:
Desarrollador 1: Se mantiene trabajando en la tarea:Script Perl para creacin de
incidencias. Mantiene la estimacin de 3 puntos de trabajo.
Desarrollador 2: Se mantiene trabajando en la tarea:Incidencias / Subir fichero
Excel. Mantiene la estimacin de 0.5 puntos de trabajo.
Desarrollador 3: Se mantiene trabajando en la tarea:Manager para el acceso a la
nueva tabla. Mantiene la estimacin de 1 puntos de trabajo.
Desarrollador 4: Ha trabajo en la tarea: Crear incidencias e insertarlas en BBDD.
Como la tarea que tiene el Desarrollador 1 an no est terminada, considera que hay
dependencias entre ambas y aumenta en un punto el tiempo estimado para su tarea.
Desarrollador 5: Ha trabajo en la tarea: Aadir validaciones al Script. Tarea tambin
dependiente de la tarea del desarrollador 1, por tanto aumenta en medio punto la
estimacin para su tarea.
98
99
Da 10:
Da de reuniones ajenas al Sprint, ningn desarrollador avanza en el trabajo asignado,
por tanto no se avanza en los puntos del Sprint.
Estado actualizado de la grfica:
No se ha avanzado en el trabajo: Tenemos que marcar el punto de hoy de la grfica en
12 puntos de trabajo restantes.
100
Da 11:
Desarrollador 1: Ha avanzado en la tarea: Script Perl para la creacin de incidencias,
la reestima en 2 puntos y contina trabajando en ella.
Desarrollador 2: Ha finalizado la tarea: Incidencias / Subir fichero Excel y la coloca
en la columna: Hecho!. Coge la siguiente tarea disponible en el tablero:.
Desarrollador 3: Contina trabajando en la tarea: Manager para el acceso a la nueva
tabla y mantiene la estimacin en 1 punto de trabajo.
Desarrollador 4: Ha estado trabajando en la tarea: Crear incidencias e insertarlas en
BBDD, mantiene la estimacin en 4 puntos de trabajo.
Desarrollador 5: Al estar bloqueado no ha trabajado en la tarea. Mantiene la estimacin
de 3.5 puntos de trabajo. Durante el da de hoy no trabajar en las tareas del Sprint.
101
Da 12:
Desarrollador 1: Ha finalizado la tarea: Script Perl para la creacin de incidencias,
como no hay tareas nuevas se junta con otro compaero para finalizar tareas a las que
todava le quedan varios puntos por terminar. Se une al desarrollador 5.
Desarrollador 2: Se mantiene trabajando la tarea: Programar contab. Y mantiene la
estimacin de 1 punto.
Desarrollador 3: Ha finalizado la tarea en la que estaba trabajando: Manager para el
acceso a la nueva tabla, por tanto, la deja ya en la columna de: Hecho!. Como no
quedan tareas nuevas en la que trabajar, se une al trabajo de algn compaero de trabajo
al que an le queden muchos puntos por hacer. Se une al desarrollador 4.
Desarrollador 4: Se mantiene trabajando en la tarea: Crear incidencias e insertarlas en
BBDD, ya se ha finalizado la tarea: Script Perl para creacin de incidencias y ya no
est bloqueado por tanto tendr que recuperar el retraso que haya podido acumular en el
bloqueo. El desarrollador 3 se une para trabajar en esta misma tarea.
Desarrollador 5: Se mantiene trabajando en la tarea: Aadir validaciones al script, ya
se ha finalizado la tarea: Script Perl para creacin de incidencias y ya no est
bloqueado por tanto tendr que recuperar el retraso que haya podido acumular en el
bloqueo. El desarrollador 1 se une para trabajar en esta misma tarea.
102
103
Da 13:
Desarrollador 1 y desarrollador 5: Continan trabajando en la tarea: Crear
incidencias e insertarlas en BBDD.
Desarrollador 2: Finaliza la tarea que estaba realizando: Programar crontab.
Comienza la preparacin de la demo.
Desarrollador 3 y desarrollador 4: Continan trabajando en la tarea: Aadir
validaciones al script.
104
Da 14:
Desarrollador 1 y desarrollador 5: Continan trabajando en la tarea: Crear
incidencias e insertarlas en BBDD, estiman 2.5 puntos de trabajo.
Desarrollador 2: Preparacin de la demo.
Desarrollador 3 y desarrollador 4: Continan trabajando en la tarea: Aadir
validaciones al script. Estiman 2.5 puntos de trabajo.
105
Da 15:
Desarrollador 1 y desarrollador 5: Finalizan la tarea: Crear incidencias e insertarlas
en BBDD, se mueve a la columna Hecho!. Se unen a la preparacin de la demo.
Desarrollador 2: Preparacin de la demo.
Desarrollador 3 y desarrollador 4: Han trabajado en la tarea: Aadir validaciones al
script, pero no han terminado, estiman que quedan 0.5 puntos de trabajo.
106
Demostracin
Una vez preparado el guin para la reunin, se convoca al cliente a una reunin en la
que ha visto las nuevas funcionalidades que se han aadido al aplicativo.
Reunin retrospectiva
Una vez finalizado el Sprint se realiza la reunin retrospectiva, el objetivo de la reunin
es reflexionar para mejorar el proceso: como est trabajando el equipo junto, prcticas o
herramientas que se estn utilizando.
Esta reunin est restringida a los miembros del equipo.
Las conclusiones se encuentran resumidas a continuacin:
107
Positivo
Mejorable
Soluciones
Mejora tareas QA
Estimaciones
cumplidas
Requisitos claros
para el equipo
Preparacin Demo
Gua de Tests para
los usuarios
Mejorar
comunicacin (QAEquipo de
desarrollo)
Mejorar la toma de
requisitos durante el Sprint
para el siguiente Sprint
No se ha llegado a la fecha
del Sprint
Entornos / servicios
preparados
Retraso de la demo para
mostrar toda la
funcionalidad
Ideas
Crear el guin de la demo
como otro documento del
sprint
Conocer infraestructura
Aportar/plantear posibles
desarrollos que puedan
interesar a negocio
Captulo 5:
Planificacin
110
Contenido
Captulo 5: Planificacin ........................................................................................ 109
Backlog ................................................................................................................. 113
Primera iteracin ................................................................................................... 115
Segunda iteracin .................................................................................................. 118
Tercera iteracin.................................................................................................... 120
Cuarta iteracin ..................................................................................................... 122
Quinta iteracin ..................................................................................................... 125
Diagrama de Gantt ................................................................................................ 127
111
112
Planificacin
A la hora de desarrollar este Trabajo Fin de Grado se ha seguido la metodologa Scrum.
Se ha considerado oportuno trabajar con iteraciones de dos semanas de duracin y se
aplicar un factor de correccin de: 0,8
Backlog
113
ID
Imp
Proyecto
PFG - Gua
comparativa de
metodologas giles
PFG - Gua
comparativa de
metodologas giles
Nombre
Seleccionar
metodologas giles a
estudiar
Documentar cada una
de las metodologas
giles
Notas
Cmo probarlo
PFG - Gua
comparativa de
metodologas giles
N/A
PFG - Gua
comparativa de
metodologas giles
Comparativa de las
metodologas giles
Comprobar cul es la
recomendacin de la Gua
elaborada para diferentes
escenarios de trabajo
conocidos e integrados en
las metodologas giles. Si
la respuesta coincide con la
metodologa que se est
tilizando la gua puede ser
fiable.
PFG - Gua
comparativa de
metodologas giles
N/A
PFG - Gua
comparativa de
metodologas giles
Maquetacin de la
memoria
Primera iteracin
Backlog Item #1
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
N/A
Estimacin
4
2
Backlog Item #2
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
N/A
Estimacin
3
2
Backlog Item #3
Proyecto: PFG - Gua comparativa de metodologas giles
Documentar teora XP
Notas
Elaborar una documentacin sobre XP que permita conocer
los aspectos ms importantes.
Prioridad
Como probarlo
N/A
Estimacin
2
2
Backlog Item #4
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
N/A
Estimacin
1
2
116
Divisin de la Historia de
Usuario
Documentar teora Scrum
Documentar teora XP
Documentar teora Kanban
Documentar teora Scrumban
Estimacin
2
2
2
2
8 ptos
Historia de Usuario
Seleccionar metodologas giles a estudiar
Documentar teora Scrum
Documentar teora XP
Documentar teora Kanban
Total:
Tabla 5-3: Historias de usuario de la primera iteracin
117
Estimacin
2
2
2
2
8 ptos
Segunda iteracin
Backlog Item #5
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
N/A
Estimacin
3
2
Backlog Item #6
Proyecto: PFG - Gua comparativa de metodologas giles
Establecer criterios de
comparacin
Notas
Crear una lista de criterios de comparacin entre las
diferentes metodologas de estudio.
Prioridad
Como probarlo
N/A
Estimacin
2
4
118
Backlog Item #7
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
Comprobar que hay suficientes detalles para distinguir con
claridad si una organizacin es tradicional / gil.
Estimacin
1
2
Total:
Estimacin
2
2
3
3
1
8 ptos
119
Historia de Usuario
Documentar teora Scrumban
Criterios de comparacin
Base terica para orientacin de la organizacin
Total:
Estimacin
2
4
2
8 ptos
Tercera iteracin
Backlog Item #8
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
Comprobar que se han cubierto las cuatro metodologas.
Comprobar que se ha elaborado una lista unificada de
rasgos de las cuatros metodologas giles.
Estimacin
120
3
2
Backlog Item #9
Proyecto: PFG - Gua comparativa de metodologas giles
Prioridad
Como probarlo
Comprobar que son claros, precisos, comprensibles.
Estimacin
2
3
Comparativa: Interpretacin
Notas
Interpretacin del vaciado de los cuestionarios.
Prioridad
Como probarlo
Indicar si la interpretacin del vaciado de los cuestionarios
es clara y comprensible.
Estimacin
121
1
3
Estimacin
2
3
3
8 ptos
Cuarta iteracin
Comparativa: Ejemplo
Notas
Cumplimentar formularios e interpretar los resultados
obtenidos.
Prioridad
Como probarlo
N/A
Estimacin
3
1
122
Prioridad
Como probarlo
N/A
Estimacin
2
4
Prioridad
Como probarlo
N/A
Estimacin
1
3
123
Divisin de la Historia de
Usuario
Caso Prctico: Planificacin y
tareas
Caso Prctico: Desarrollo
Caso Prctico: Demostracin
Caso Prctico: Retrospectiva
Total:
Estimacin
4
3
2
1
10 ptos
Estimacin
1
4
3
8 ptos
124
Quinta iteracin
Prioridad
Como probarlo
Comprobar que en el guin de la demostracin aparecen
todas las nuevas funcionalidades.
Estimacin
3
2
Prioridad
Como probarlo
N/A
Estimacin
2
1
125
Maquetacin de la memoria
Notas
Maquetacin de la memoria del PFG segn los estndares
definidos por la EUISG.
Prioridad
Como probarlo
Verificar que los estndares de los PFG se han aplicado a la
memoria
Estimacin
1
3
Historia de Usuario
Caso Prctico: Demostracin
Caso Prctico: Retrospectiva
Maquetacin de la memoria
Total:
Estimacin
2
1
3
6 ptos
126
Diagrama de Gantt
Diagrama de Gantt del proyecto completo. Se reflejan las cinco iteraciones de Scrum
que ha tomado la ejecucin del TFC: Gua Comparativa de Metodologas giles.
127
129
130
Captulo 6:
Valoracin
econmica
131
132
Contenido
Captulo 6: Valoracin econmica ......................................................................... 131
Recursos Humanos ................................................................................................ 135
Estimacin de la duracin de las actividades ...................................................... 135
Costes unitarios.................................................................................................. 135
Equipo y tiempo en el proyecto .......................................................................... 135
Estimacin de horas del proyecto ....................................................................... 138
Estimacin econmica del proyecto ................................................................... 138
Recursos materiales ............................................................................................... 142
Hardware y Software ......................................................................................... 142
Comunicaciones................................................................................................. 142
Costo del proyecto................................................................................................. 143
Herramientas Empleadas ....................................................................................... 143
133
134
Valoracin econmica
Detalle de los costes del proyecto. stos se basan en dos aspectos: los recursos humanos
y los recursos materiales.
Recursos Humanos
En el proyecto sern necesarios un coordinador de proyecto y un desarrollador /
investigador.
Costes unitarios
Tabla precio / hora ser la siguiente para cada miembro del equipo
Proyecto
PFG - Gua comparativa de metodologas giles
PFG - Gua comparativa de metodologas giles
Persona Equipo
Coordinador proyecto
desarrollador
Precio Hora
40 / hora
15 / hora
135
Diagrama de Gantt agrupado por el nombre del recurso para ver cmo estn distribuidas
las horas de trabajo del coordinador y del desarrollador a lo largo del proyecto.
136
137
Mes
Coordinador
Desarrollador
Total
Junio
40 h
160 h
Julio
44 h
176 h
Agosto
12 h
48 h
480 h
Junio
40 h
1.600
160 h
2.400
Julio
44 h
1.760
176 h
2.640
Total
Tabla 6-3: Coste mensual del proyecto
138
Agosto
12 h
480
48 h
720
9600
Primera iteracin
Segunda iteracin
139
Tercera iteracin
Cuarta iteracin
140
Quinta iteracin
Coste total
141
Tanto en el desglose mensual como en el desglose por iteracin el coste total del
proyecto en recursos humanos es de: 9.600 .
Recursos materiales
Componentes del presupuesto del proyecto que forman parte de la inversin inicial:
Hardware y Software
Recurso HW / SW
TOSHIBA Satellite
Windows XP
Professional
Microsoft-Office 2010
Adobe Acrobat
Professional
Microsoft Paint
OpenProj
Consumibles
Total
Coste
% Coste aplicado
Adquisicin
proyecto
700
Coste
Proyecto
20%
140
170
150
20%
20%
34
30
300
Integrado
Open-source
50
20%
0%
0%
20%
60
0
0
10
274
Comunicaciones
Recurso
Conexin
internet
Total
Coste
Unitario
Duracin
Meses
% Coste aplicado
proyecto
Coste
Proyecto
20
20%
12
12
142
Coste Proyecto
9.600
286
9.886
Tabla 6-6: Costo total del proyecto
Herramientas Empleadas
Herramientas empleadas para el desarrollo del proyecto:
Hardware
-
Software
-
143
144
Captulo 7:
Conclusiones
145
146
Conclusiones
Para concluir este proyecto solo queda anotar algunas reflexiones sobre la
realizacin de la gua comparativa de metodologas giles, en este proyecto se ha
intentado dar una visin global sobre el mundo gil, adems de mostrar los
principios de las metodologas giles ms utilizadas. Se muestra como,
compartiendo el mismo origen y los mismos principios, cada una de las
metodologas giles estudiada tiene sus particularidades que hacen que se adapte
mejor a un mbito de trabajo u otro. Se ha creado una herramienta que permite
conocer a una organizacin cul es la metodologa que mejor se adapta a modo de
trabajo. Adems se ha documentado un caso prctico de Scrum para comprender
mejor como funciona en el da a da.
Las organizaciones tendrn un acceso rpido y clasificado de las metodologas
estudiadas. Adems, tener una herramienta que ayuda a elegir una metodologa gil
entre varias creo que ser muy importante para organizaciones que estn intentando
instaurar una metodologa gil, partiendo de una organizacin tradicionalista, la
herramienta permite clasificar a una organizacin dentro del mundo gil. La
organizacin se ahorra una gran cantidad de tiempo investigando las diferentes
opciones, centrando sus esfuerzos en aplicar una metodologa concreta y
aumentando la probabilidad de xito.
Se ha tratado de hacer un proyecto el objetivo claro de facilitar la vida a
organizaciones interesadas en las metodologas giles, proporcionndoles una
herramienta que les ayude a la toma de decisiones, que adems tendrn una
referencia terica de cada metodologa y una referencia prctica que les sirva de
apoyo a la hora de comenzar a trabajar de manera gil.
Como reflexin final creo que el proyecto en si es muy interesante y completo, da a
conocer la esencia del mundo gil, as como su impacto en las empresas, evitando
situaciones de riesgo en los proyectos gracias a su adaptacin a los cambios. Es
importante tener en cuenta cmo la eleccin de una mala metodologa de gestin de
proyecto puede provocar un impacto negativo en el proyecto y a su vez en el cliente
que ha solicitado el proyecto. Por otro lado, como es posible aplicar conjuntamente
otra metodologa gil centrada en la mejora del desarrollo de software, creado
productos de calidad. Me ha mostrado como es posible que un equipo trabaje
cmodo y sea productivo y a la vez al cliente est satisfecho.
147
148
Captulo 8: Futuras
lneas de trabajo
149
150
151
152
Captulo 9:
Glosario de
Trminos
153
154
Glosario de Trminos
Agilismo: Trmino que se usa en lugar del trmino anglosajn Agile. Se pueden
utilizar los trminos desarrollo gil de software, metodologa gil agilidad.
Grfica burndown: Grfica que muestra la velocidad a la que se estn completando los
requisitos del sprint.
Manifiesto gil: Recoge los principios en los que se basan todas las metodologas
giles.
155
QA: Del anglosajn Quality Assurance, son las tareas, previas a la entrega al cliente,
que se llevan a cabo para asegurar la calidad del producto software.
Scrum daily meeting: Reunin diaria de Scrum en la que participan todos los
miembros del equipo y comentan el progreso del trabajo y posibles bloqueos que hayan
surgido en el trabajo.
Sprint o iteracin: Ritmo de los ciclos de Scrum. Est delimitado por la reunin de
planificacin del sprint y la reunin retrospectiva.
Sprint backlog: Lista priorizada con los requisitos seleccionados para un Sprint.
156
157
158
Captulo 10:
Bibliografa
159
160
Bibliografa
The Agile Samurai: How Agile Masters Deliver Great Software, Jonathan Rasmusson
SCRUM and XP from the Trenches (Enterprise Software Development), Henrik Kniberg
Do Better SCRUM, artculo escrito por Certified Scrum Coach and Trainer Peter
Hundermark
161
162
Captulo 11:
Referencias
163
164
Referencias
http://www.eumed.net/libros/2009c/584/indice.htm
http://agilemanifesto.org/
http://www.scrumalliance.org
http://www.programacionextrema.org/
http://www.extremeprogramming.org/rules.html
http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
http://www.willydev.net/descargas/masyxp.pdf
http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
http://ceur-ws.org/Vol-341/paper9.pdf
http://www.scrumninja.com/scrum-software
165
166
167
168
ndice de Tablas
Tabla 2-1: Scrum vs Scrumban................................................................................... 45
Tabla 3-1: Orientacin tradicional vs orientacin gil .................................................. 52
Tabla 3-2: Resultado orientacin tradicional vs orientacin gil .................................. 53
Tabla 3-3: Cumplimiento principios giles ................................................................... 54
Tabla 3-4: Ejemplo cumplimiento principios giles ...................................................... 55
Tabla 3-5: Valoracin del Uso ..................................................................................... 59
Tabla 3-6: Valoracin de la Capacidad de agilidad ..................................................... 60
Tabla 3-7: Valoracin de la Aplicacin ........................................................................ 60
Tabla 3-8: Valoracin normas y directrices giles ....................................................... 60
Tabla 3-9: Valoracin actividades cubiertas por el mtodo gil ................................... 61
Tabla 3-10: Valoracin de los productos de las actividades de la metodologa gil .... 61
Tabla 3-11: Clasificacin de metodologas giles ....................................................... 63
Tabla 3-12: Ejemplo valoracin del Uso ...................................................................... 63
Tabla 3-13: Ejemplo valoracin de la Capacidad de agilidad ...................................... 64
Tabla 3-14: Ejemplo valoracin de la Aplicacin ......................................................... 64
Tabla 3-15: Ejemplo valoracin de las normas y directrices de la metodologa gil .... 65
Tabla 3-16: Ejemplo valoracin de las actividades cubiertas por la metodologa gil .. 65
Tabla 3-17: Ejemplo valoracin de los productos de las actividades de la metodologa
gil .............................................................................................................................. 65
Tabla 3-18: Metodologa gil adecuada para el ejemplo ............................................. 67
Tabla 4-1: Velocidad del equipo .................................................................................. 73
Tabla 4-2: Reunin retrospectiva .............................................................................. 108
Tabla 5-1: Backlog de la Guia comparativa de metodologas giles ......................... 114
Tabla 5-2: Divisin de la tarea Documentar cada metodologa gil en subtareas ..... 117
Tabla 5-3: Historias de usuario de la primera iteracin ............................................. 117
Tabla 5-4: Divisin de la tarea Comparativa de metodologas giles ........................ 119
Tabla 5-5: Historias de usuario de la segunda iteracin ............................................ 120
Tabla 5-6: Historias de usuario de la tercera iteracin .............................................. 122
Tabla 5-7: Divisin de la tarea Caso Prctico Scrum en subtareas ........................... 124
Tabla 5-8: Historias de usuario de la cuarta iteracin................................................ 124
Tabla 5-9: Historias de usuario de la quinta iteracin ................................................ 126
Tabla 6-1: Precio / hora para cada miembro del equipo ............................................ 135
Tabla 6-2: Horas del proyecto ................................................................................... 138
Tabla 6-3: Coste mensual del proyecto ..................................................................... 138
Tabla 6-4: Costo Hardware y Software ..................................................................... 142
Tabla 6-5: Costo Comunicaciones ............................................................................ 142
Tabla 6-6: Costo total del proyecto ........................................................................... 143
169
170
171
172
ndice de figuras
Ilustracin 2-1: Ciclo de Scrum - Sprint ....................................................................... 19
Ilustracin 2-2: Actividades del proceso de Scrum ...................................................... 20
Ilustracin 2-3: Grfica burndown ............................................................................... 30
Ilustracin 2-4: Ciclos XP ............................................................................................ 31
Ilustracin 2-5: Integracin Secuencial - XP................................................................ 37
Ilustracin 2-6: Proyecto XP........................................................................................ 39
Ilustracin 2-7: Muro Kanban ...................................................................................... 43
Ilustracin 3-1: Qu herramienta es mejor? .............................................................. 51
Ilustracin 3-2: Cuatro vistas de las metodologas giles (Iacovelli) ............................ 56
Ilustracin 4-1: Caso Prctico Tareas de Backlog tem 7 .......................................... 76
Ilustracin 4-2: Caso Prctico Tareas de Backlog tem 6 .......................................... 77
Ilustracin 4-3: Caso Prctico Tareas de Backlog tem 5 .......................................... 78
Ilustracin 4-4: Caso Prctico Tareas de Backlog tem 4 .......................................... 79
Ilustracin 4-5: Caso Prctico Tareas de Backlog tem 3 .......................................... 80
Ilustracin 4-6: Caso Prctico Tareas de Backlog tem 2 .......................................... 81
Ilustracin 4-7: Caso Prctico Tareas de Backlog tem 1 .......................................... 82
Ilustracin 4-8: Caso Prctico - Tabln al inicio del Sprint ........................................... 83
Ilustracin 4-9: Caso Prctico - Burndown al inicio del sprint ...................................... 84
Ilustracin 4-10: Caso Prctico - Tabln primer da del Sprint..................................... 85
Ilustracin 4-11: Caso Prctico - Burndown primer da del Sprint ............................... 86
Ilustracin 4-12: Caso Prctico - Tabln segundo da del Sprint ................................. 87
Ilustracin 4-13: Caso Prctico - Burndown segundo da del Sprint ............................ 87
Ilustracin 4-14: Caso Prctico - Tabln tercer da del Sprint...................................... 88
Ilustracin 4-15: Caso Prctico - Burndown tercer da del Sprint ................................ 89
Ilustracin 4-16: Caso Prctico - Tabln cuarto da del Sprint ..................................... 90
Ilustracin 4-17: Caso Prctico - Burndown cuarto da del Sprint ................................ 90
Ilustracin 4-18: Caso Prctico - Tabln quinto da del Sprint ..................................... 92
Ilustracin 4-19: Caso Prctico - Burndown quinto da del Sprint ................................ 93
Ilustracin 4-20: Caso Prctico - Tabln sexto da del Sprint ...................................... 94
Ilustracin 4-21: Caso Prctico - Burndown sexto da del Sprint ................................. 94
Ilustracin 4-22: Caso Prctico - Tabln sptimo da del Sprint .................................. 95
Ilustracin 4-23: Prctico - Burndown sptimo da del Sprint ...................................... 96
Ilustracin 4-24: Caso Prctico - Tabln octavo da del Sprint .................................... 97
Ilustracin 4-25: Caso Prctico - Burndown octavo da del Sprint ............................... 98
Ilustracin 4-26: Caso Prctico - Tabln noveno da del Sprint ................................... 99
Ilustracin 4-27: Caso Prctico - Burndown noveno da del Sprint ............................ 100
Ilustracin 4-28: Prctico - Burndown dcimo da del Sprint ..................................... 100
Ilustracin 4-29: Caso Prctico - Tabln undcimo da del Sprint ............................. 101
Ilustracin 4-30: Caso Prctico - Burndown undcimo da del Sprint ........................ 102
Ilustracin 4-31: Caso Prctico - Tabln decimosegundo da del Sprint .................... 103
Ilustracin 4-32: Caso Prctico - Burndown decimosegundo da del Sprint............... 103
Ilustracin 4-33: Caso Prctico - Tabln decimotercer da del Sprint ........................ 104
Ilustracin 4-34: Caso Prctico - Burndown decimotercer da del Sprint ................... 104
Ilustracin 4-35: Caso Prctico - Tabln decimocuarto da del Sprint ....................... 105
Ilustracin 4-36: Caso Prctico - Burndown decimocuarto da del Sprint .................. 105
173
174