Gia Comparativa de Metologias Agiles

Universidad de Valladolid
E. U. de Informtica (SEGOVIA) Grado en Ingeniera Informtica de Servicios y Aplicaciones
Gua Comparativa de Metodologas giles
Alumno: Mara Jos Prez Prez
Tutor: Francisco J. Gonzlez Cabrera
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 12: ndice de Tablas ................................................................................. 167 Captulo 13: ndice de Figuras ............................................................................... 171
Captulo 1: Introduccin
Mara Jos Prez Prez Grado en Ingeniera Informtica de Servicios y Aplicaciones
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
Objetivos del proyecto

Seleccionar la metodologas giles que van a formar parte del estudio. Entender y documentar las caractersticas fundamentales de cada una de ellas. Seleccionar los criterios de comparacin. Elaborar la comparativa de las metodologas giles anteriormente estudiadas. Presentacin de un caso prctico utilizando SCRUM. Es muy importante escoger una buena metodologa para tener xito en el proyecto, lo que implica muchas ms cosas que sacar un producto tiempo, supone que el cliente est satisfecho y que el equipo trabaje cmodo. Actualmente, las metodologas giles estn en auge dentro del desarrollo software. Dentro de la diversidad de metodologas giles, se trata de elaborar una comparativa que sirva para tener unos criterios y escoger una metodologa gil u otra en funcin del marco en el que se vaya a implantar.
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
Metodologas giles y caractersticas

Manifiesto gil
La Alianza gil elabor un conjunto de doce principios comunes a las metodologas giles de desarrollo que se enuncian a continuacin: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos giles se doblegan al cambio como ventaja competitiva para el cliente. 3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. 4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a travs del proyecto. 5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldo que necesitan y procurndoles confianza para que realicen la tarea. 6. La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin cara a cara. 7. El software que funciona es la principal medida del progreso. 8. Los procesos giles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. 9. La atencin continua a la excelencia tcnica enaltece la agilidad. 10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se autoorganizan. 12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su conducta en consecuencia.
La utilizacin de todas las buenas prcticas enumeradas en el manifiesto gil no implica ser gil, sin embargo, el hecho de incumplir una de ellas te transforma en no gil.
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:
1. Se valora a los individuos y las interacciones sobre los procesos y las herramientas. 2. Se valoras las aplicaciones que funcionan sobre la documentacin exhaustiva. 3. Se valora la colaboracin del cliente sobre las negociaciones contractuales. 4. Se valora la respuesta al cambio sobre el seguimiento de un plan.
A continuacin se van a presentar las metodologas giles de desarrollo ms exitosas. El propsito de este apartado es responder a las siguientes preguntas:
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.
Ilustracin 2-1: Ciclo de Scrum - Sprint
El Sprint es el ritmo de los ciclos de Scrum. Est delimitado por la reunin de planificacin del sprint y la reunin retrospectiva. Una vez que se fija la duracin del sprint es inamovible. La mayora de los equipos eligen dos, tres o cuatro semanas de duracin. Diariamente durante el sprint, el equipo realiza una reunin de seguimiento muy breve. Al final del sprint se entrega el producto al cliente en el que se incluye un incremento de la funcionalidad que tenia al inicio del sprint. El proceso parte de la lista de requisitos priorizada del producto, que acta como plan del proyecto. En esta lista el cliente ha priorizado los requisitos balanceando el valor que le aportan respecto a su coste y han sido divididos en iteraciones y entregas.
19
Actividades de la metodologa Scrum

Las actividades que se llevan se plantea realizar en la metodologa Scrum son las siguientes:
Ilustracin 2-2: Actividades del proceso de Scrum
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: El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteracin (de manera que ayude a tomar decisiones durante su ejecucin) y propone los requisitos ms prioritarios a desarrollar en ella. El equipo examina la lista, pregunta al cliente las dudas que le surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.
Segunda parte de la reunin. Se realiza en un tiempo mximo 4 horas. El equipo planifica la iteracin, dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cmo 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. 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.
Potenciacin del compromiso de cada miembro con el equipo: Es el equipo quien asume la responsabilidad de completar en la iteracin los requisitos que selecciona. Es cada una de las personas la que se responsabiliza de realizar las tareas a las que se asigna.
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) En Scrum un proyecto se ejecuta en iteraciones de un mes natural (pueden ser de dos 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. Cada da el equipo realiza una reunin de sincronizacin, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, as cmo comunicar cuales son los impedimentos con que se encuentra. El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstculos que el equipo no puede resolver por s mismo. Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
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 No se puede cambiar los requisitos de la iteracin en curso. 21
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.
Terminacin anormal de la iteracin Slo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminacin anormal de la iteracin. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteracin para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido. En ese caso, se dar por finalizada la iteracin y se dar inicio a otra mediante una reunin de planificacin de la iteracin. Reunin diaria de sincronizacin del equipo (Scrum daily meeting) El objetivo de esta reunin es facilitar la transferencia de informacin y la colaboracin entre los miembros del equipo para aumentar su productividad. Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para al finalizar la reunin poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de planificacin de la iteracin). Cada miembro del equipo debe responder las siguientes preguntas en un intervalo de tiempo de cmo mximo 15 minutos: Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena planeado? Cul fue el problema? Qu voy a hacer a partir de este momento? Qu impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteracin y en el proyecto?
Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, as como con el grfico de horas pendientes en la iteracin. Se actualiza la grfica burndown con el trabajo realizado. Recomendaciones 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
Demostracin de requisitos completados (Sprint Demonstration) Reunin informal donde el equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo, haciendo un recorrido por ellos lo ms real y cercano posible al objetivo que se pretende cubrir. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto. Se realiza en un tiempo mximo 4 horas.
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.
Retrospectiva (Sprint Retrospective) El equipo analiza cmo ha sido su manera de trabajar durante la iteracin, qu cosas han funcionado bien, cules hay que mejorar, qu cosas quiere probar hacer en la siguiente iteracin, qu se ha aprendido y cules son los problemas que podran impedirle progresar adecuadamente, con el objetivo de mejorar de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados que el propio equipo no pueda resolver por s mismo. Se realiza en un tiempo mximo 3 horas. Beneficios Incrementa la productividad y el aprendizaje del equipo de manera sistemtica, iteracin a iteracin, con resultados a corto plazo.
Replanificacin del proyecto Durante el transcurso de una iteracin, el cliente va trabajando en la lista de requisitos priorizada del producto o proyecto, aadiendo requisitos, modificndolos,
23
eliminndolos, repriorizndolos, cambiando el contenido de iteraciones y definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades. Los cambios en la lista de requisitos pueden ser debidos a: Modificaciones que el cliente solicita tras la demostracin que el equipo realiza al final de cada iteracin sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto. Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc.). Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
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: Replanificar el proyecto para obtener un nuevo calendario de entregas que cumpla con sus necesidades actuales. Incorporar nuevos recursos. Cancelar el proyecto con los requisitos completados hasta el momento plenamente operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo. El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de ltima hora.
Roles
Cuando se aplica la metodologa Scrum se determinan las responsabilidades siguientes:
24
No hay un jefe de proyecto. Las responsabilidades del tradicional jefe de proyecto se distribuyen a los siguientes roles de un equipo Scrum: El cliente o Product Owner Scrum master o facilitador Resto del equipo
Cliente (Product Owner) Las responsabilidades del Cliente (que puede ser interno o externo a la organizacin) son: Ser el representante de todas las personas interesadas en los resultados del proyecto (internas o externas a la organizacin, promotores del proyecto y usuarios finales) y actuar como interlocutor nico ante el equipo, con autoridad para tomar decisiones. Definir los objetivos del producto o proyecto. Dirigir los resultados del proyecto. Es el propietario de la planificacin del proyecto: crea y mantiene la lista priorizada con los requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que aportar cada. Divide la lista de requisitos estableciendo un calendario de entregas. Antes de iniciar cada iteracin replanifica el proyecto en funcin de los requisitos que aportan ms valor en ese momento, de los requisitos completados en la iteracin anterior y del contexto del proyecto en ese momento (demandas del mercado, movimientos de la competencia, etc.). Participar en la reunin de planificacin de iteracin, proponiendo los requisitos ms prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se compromete a hacer. Estar disponible durante el curso de la iteracin para responder a las preguntas que puedan aparecer. No cambiar los requisitos que se estn desarrollando en una iteracin, una vez est iniciada. Participar en la reunin de demostracin de la iteracin, revisando los requisitos completados.
Facilitador (Scrum Master) Lidera al equipo llevando a cabo las siguientes responsabilidades:
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: Asegurar que la lista de requisitos priorizada est preparada antes de la siguiente iteracin. Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y consigan sus objetivos.
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: Seleccionar los requisitos que se compromete a completar en una iteracin, de forma que estn preparados para ser entregados al cliente. En la lista de requisitos priorizados del producto, estimar la complejidad de cada uno de ellos. En la reunin de planificacin de la iteracin decide cmo va a realizar su trabajo: Seleccionar los requisitos que pueden completar en cada iteracin, realizando al cliente las preguntas necesarias. 26
Identificar todas las tareas necesarias para completar cada requisito. Estimar el esfuerzo necesario para realizar cada tarea. Cada miembro del equipo se asigna a las tareas. Durante la iteracin, trabajar de manera conjunta para conseguir los objetivos de la iteracin. Cada especialista lidera el trabajo en su rea y el resto colaboran si es necesario para poder completar un requisito. Al finalizar la iteracin: Demostrar al cliente los requisitos completados en cada iteracin. Hacer una retrospectiva final de cada iteracin para mejorar de forma continua su manera de trabajar. 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
Lista de requisitos priorizada (Product Backlog) La lista de requisitos priorizada representa las expectativas del cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador (Scrum Master) y del equipo, quien proporciona el coste estimado de completar cada requisito). Al reflejar las expectativas del cliente, esta lista permite involucrarle en la direccin de los resultados del producto o proyecto. 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.
En el caso del desarrollo de un producto, la lista va evolucionando durante toda la vida del producto. En el caso de un proyecto, conforme ste avance irn apareciendo los requisitos menos prioritarios que falten. El cliente y el equipo tienen que acordar la definicin de completado de los requisitos, qu ser lo que el equipo habr realizado para considerar que el producto est preparado 28
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: Cuanto trabajo ha sido hecho Cuanto trabajo queda por hacer Velocidad del equipo Fecha fin esperada
29
Ilustracin 2-3: Grfica burndown
En el eje Y cantidad de trabajo pendiente de terminar En el eje X tiempo (iteraciones)
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
Ilustracin 2-4: Ciclos XP
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. de de o de
31
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
Simplicidad del plan. No se espera que un plan requiera de un gur con complicados sistemas de gerenciamiento de proyectos. Los planes son realizados por las mismas personas que realizarn el trabajo. Los planes no son predicciones del futuro, sino simplemente la mejor estimacin de cmo saldrn las cosas. Los planes son tiles, pero necesitan ser cambiados cuando las circunstancias lo requieren. De otra manera, se termina en situaciones en las que el plan y la realidad no coinciden, y en estos casos, el plan es totalmente intil.
Los conceptos bsicos de esta planificacin son los siguientes: Historias de usuario Las Historias de usuarios sustituyen a los documentos de especificacin funcional, y a los casos de uso. Estas historias son escritas por el cliente, en su propio lenguaje, como descripciones cortas de lo que el sistema debe realizar. La diferencia ms importante entre estas historias y los tradicionales documentos de especificacin funcional se encuentra en el nivel de detalle requerido. Las historias de usuario deben tener el detalle mnimo como para que los programadores puedan realizar una estimacin poco riesgosa del tiempo que llevar su desarrollo. Cuando llegue el momento de la implementacin, los desarrolladores dialogarn directamente con el cliente para obtener todos los detalles necesarios. Las historias de usuarios deben poder ser programadas en un tiempo entre una y tres semanas. Si la estimacin es superior a tres semanas, debe ser dividida en dos o ms historias. Si es menos de una semana, se debe combinar con otra historia. Plan de entregas (Release Plan) El cronograma de entregas establece qu historias de usuario sern agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma ser el resultado de una reunin entre todos los actores del proyecto (cliente, desarrolladores, gerentes, etc.). XP denomina a esta reunin Juego de planeamiento (Planning game), pero puede denominarse de la manera que sea ms apropiada al tipo de empresa y cliente (por ejemplo, Reunin de planeamiento, Planning meeting o Planning workshop). Tpicamente el cliente ordenar y agrupar segn sus prioridades las historias de usuario. El cronograma de entregas se realiza en base a las estimaciones de tiempos de desarrollo realizadas por los desarrolladores. Despus de algunas iteraciones es recomendable realizar nuevamente una reunin con los actores del proyecto, para evaluar nuevamente el plan de entregas y ajustarlo si es necesario.
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
Durante la reunin de planificacin el cliente negocia las historias que se incluirn en la prxima entrega, as como su duracin. El cliente es imprescindible a la hora de realizar pruebas funcionales, en caso de error l ser el encargado de decidir si el cdigo puede pasar a produccin o no. Estndares de codificacin Todos los programadores deben escribir y documentar el cdigo en la misma manera. El cdigo debe seguir los estndares de codificacin. Las normas de codificacin ayudan a mantener el cdigo legible y fcil de mantener y refactorizar. Implementacin dirigida por las Pruebas Unitarias En las metodologas tradicionales, la fase de pruebas, incluyendo la definicin de los tests, se realizada al final del proyecto, o al final del desarrollo de cada mdulo. La metodologa XP propone un modelo inverso, en el que, lo primero que se escriben los test que el sistema debe pasar. Luego, el desarrollo debe ser el mnimo necesario para pasar las pruebas previamente definidas. Las pruebas a las que se refiere esta prctica, son las pruebas unitarias, realizados por los desarrolladores. La definicin de estos test al comienzo, condiciona y dirige el desarrollo. Programacin en parejas XP promueve que todo el cdigo sea escrito en parejas trabajando en el mismo ordenador. La programacin en parejas incrementa la calidad del cdigo sin impactar en la fecha de entrega. En contra de lo que parece, dos personas que trabajan en un mismo equipo aadirn la misma funcionalidad que dos personas trabajando por separado, excepto que el cdigo ser de mucha mayor calidad. Adicionalmente, la programacin en pares tiene las siguientes ventajas: La mayora de los errores se descubren en el momento en que se codifican, ya que el cdigo es permanentemente revisado por dos personas. La cantidad de defectos encontrados en las pruebas es estadsticamente menor. Los diseos son mejores y el cdigo ms corto. El equipo resuelve problemas en forma ms rpida. Las personas aprenden significativamente ms, acerca del sistema y acerca de desarrollo de software. 36
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
Todos los desarrolladores necesitan trabajar siempre con la ltima versin. Realizar cambios o mejoras sobre versiones antiguas causan graves problemas, y retrasan al proyecto. Es por eso que XP promueve publicar lo antes posible las nuevas versiones, aunque no sean las ltimas, siempre que estn libres de errores. Idealmente, todos los das deben existir nuevas versiones publicadas. Para evitar errores, solo una pareja de desarrolladores puede integrar su cdigo a la vez.
Ilustracin 2-5: Integracin Secuencial - XP
Propiedad colectiva del cdigo La propiedad colectiva anima a todos los miembros del equipo a aportar nuevas ideas. Cualquier desarrollador puede cambiar lneas de cdigo para aadir funcionalidad, solucionar errores, mejorar el diseo o refactorizar el cdigo. Cuando una persona realiza un desarrollo tiene que subir al repositorio el cdigo ms sus pruebas unitarias funcionando al 100%, de manera, que otra persona que se lo descargue puede confiar en que tiene un cdigo que funciona y desarrollar a partir del mismo. En la prctica, la propiedad colectiva es ms fiable que poner una sola persona se encarga de vigilar segmentos especficos de cdigo. Sobre todo porque una persona 37
puede dejar el proyecto en cualquier momento, de esta manera, el conocimiento est repartido. Ritmo constante La metodologa XP indica que debe llevarse un ritmo sostenido de trabajo. Anteriormente, sta prctica se denominaba Semana de 40 horas. Sin embargo, lo importante no es si se trabajan, 35, 40 o 42 horas por semana. El concepto que se desea establecer con esta prctica es el de planificar el trabajo de manera de mantener un ritmo constante y razonable, sin sobrecargar al equipo. Cuando un proyecto se retrasa, trabajar tiempo extra puede ser ms perjudicial que beneficioso. El trabajo extra desmotiva inmediatamente al grupo e impacta en la calidad del producto. En la medida de lo posible, se debera renegociar el plan de entregas realizando una nueva reunin de planificacin con el cliente, los desarrolladores y los gerentes. Adicionalmente, agregar ms desarrolladores en proyectos ya avanzados no siempre resuelve el problema.
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
Ilustracin 2-6: Proyecto XP
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
tcnicas detectadas por los desarrolladores: es mejor cambiar el orden de la planificacin de las historias de usuarios por sugerencia de los desarrolladores. Debe responder a preguntas como: Qu debera hacer esta nueva caracterstica? Colaborando con los desarrolladores. Escribiendo las historias de usuario (requisitos), aclarando los detalles adems de planificarlas. Cmo sabremos cuando est lista? Creando bateras de tests de aceptacin del producto, verificando que las nuevas caractersticas estn completas. Cunto podemos gastar?, Cundo comenzamos a trabajar sobre ella? Participando en la reunin de planificacin de las historias de usuario para la siguiente iteracin.
El cliente representa el usuario final y a los intereses econmicos de la empresa. Su objetivo es maximizar su inversin. Derechos Maximizar la inversin, escogiendo las historias de usuario para cada iteracin. Cambiar el alcance del proyecto para hacer frente a los cambios en la planificacin, aadiendo o eliminando tareas de la iteracin si las estimaciones demuestran ser incorrectas. Determinar que funcionalidades sern las siguientes en implementarse. Medir el progreso del proyecto en cualquier momento, lanzando las pruebas de aceptacin. Detener el proyecto en cualquier momento sin perder la inversin realizada, manteniendo en produccin un producto estable y continuar planificando otras funcionalidades ms importantes.
Responsabilidades Confiar en las decisiones tcnicas de los desarrolladores. Analizar los riesgos correctamente, Seleccionar las historias que aportan ms valor para cada iteracin. Definir las historias de usuario de forma precisa, permitiendo a los desarrolladores realizar estimaciones precisas. Participar en el equipo, dando directrices y feedback tan pronto y preciso como sea posible. 40
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 Estimacin de su propio trabajo, teniendo autoridad para tomar decisiones tcnicas. Delimitar el trabajo responsabilizndose de aquellas tareas que van a ser capaces de llevar a cabo. Implementar la funcionalidad que cubre las necesidades del cliente. No tomar decisiones de negocio.
Responsabilidades Seguir las directrices del equipo. Desarrollar las funcionalidades realmente necesarias. Comunicacin fluida con el cliente.
Encargado de Pruebas (Tester) El encargado de pruebas ayuda al cliente a definir y escribir las pruebas de aceptacin de las historias de usuario. Este rol en un equipo XP tambin es responsable realizar test peridicamente y informar de los resultados al equipo. A medida que el volumen de pruebas aumenta, el encargado de pruebas necesitar una herramienta para crear y mantener la batera de pruebas, ejecutarlas y obtener los resultados ms rpidamente. Encargado de Seguimiento (Tracker) Hace el seguimiento de acuerdo a la planificacin. La mtrica ms importante para XP es la velocidad del equipo, que se define como el tiempo ideal estimado para las tareas frente al tiempo real dedicado. Esta mtrica ayuda a determinar si el proyecto est dentro del tiempo de la iteracin.
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
Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo

Kanban se base en el desarrollo incremental, dividiendo el trabajo en partes. Una de las principales aportaciones es que utiliza tcnicas visuales para ver la situacin de cada tarea, y que se representa en pizarras llenas de post-it. El trabajo se divide en partes, normalmente cada una de esas partes se escribe en un post-it y se pega en una pizarra. Los post-it suelen tener informacin variada, si bien, aparte de la descripcin, debieran tener la estimacin de la duracin de la tarea. La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada, en anlisis, en diseo, etc.).
Ilustracin 2-7: Muro Kanban
El objetivo de esta visualizacin es que quede claro el trabajo a realizar, en qu est trabajando cada persona, que todo el mundo tenga algo que hacer y el tener clara la prioridad de las tareas. Las fases del ciclo de produccin o flujo de trabajo se deben decidir segn el caso, no hay nada acotado. En la figura se han puesto un conjunto de fases de ejemplo.
Determinar el lmite del trabajo en curso (Work In Progress)

Quizs una de las principales ideas del Kanban es que el trabajo en curso (Work In Progress) debera estar limitado, es decir, que el nmero de tareas que se pueden realizar en cada fase debe ser algo conocido. Independientemente de si un proyecto es grande o 43
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.
Medir el tiempo en completar una tarea (Lead time)

El tiempo que se tarda en terminar cada tarea se debe medir, a ese tiempo se le llama lead time. El lead time cuenta desde que se hace una peticin hasta que se hace la entrega Aunque la mtrica ms conocida del Kanban es el lead time, normalmente se suele utilizar tambin otra mtrica importante: el cycle time. El cycle time mide desde que el trabajo sobre una tarea comienza hasta que termina. Si con el lead time se mide lo que ven los clientes, lo que esperan, y con el cycle time se mide ms el rendimiento del proceso. Puede haber ms mtricas, pero las anteriores son las realmente importantes y necesarias para el control y mejora continua.
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
Roles: Cliente, equipo (con los diferentes perfiles que se necesiten). Reuniones: reunin diaria. Herramientas: pizarra
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 Pizarra
Scrumban
Reunin diaria No, flujo continuo No Puede ser especializado Equipo + otros
Controlado por el estado de la tarea. Se aaden al tablero en la Se pasan al siguiente Sprint columna TO DO. Solucin inmediata Se evitan.
Tabla 2-1: Scrum vs Scrumban
Es un modelo de desarrollo especialmente adecuado para proyectos de mantenimiento o proyectos en los que las historias de usuarios (requisitos del software) varen con frecuencia o en los cuales surjan errores de programacin inesperados durante todo el ciclo de desarrollo del producto. Para estos casos, los sprints (periodos de duracin constante en los cuales se lleva a cabo un trabajo en s) de la metodologa Scrum no son factibles, dado que los errores/impedimentos que surgirn a lo largo de las tareas son difciles de determinar y por lo tanto, no es posible estimar el tiempo que conlleva cada 45
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?
Ilustracin 3-1: 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.
Primer formulario: Orientacin tradicional vs orientacin gil

Para obtener este dato de forma objetiva, se analizar cada valor gil y su relacin con la organizacin. Se han desglosado los valores del manifiesto gil y se han dividido entre orientacin gil vs orientacin tradicional, estos valores sern evaluados por la organizacin segn una escala de importancia. Valores de importancia: 0: Ninguna. 1: Baja importancia. 2: Media importancia. 3: Alta importancia.
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
Tabla 3-2: Resultado orientacin tradicional vs orientacin gil
En este caso, se demuestra que se sobrevalora lo indicado por los valores del manifiesto gil.
Segundo Formulario: Cumplimiento principios giles

Se ha extrado a un formulario cada principio gil y extraer su relacin con la organizacin. Valores en prioridad: 0: Ninguna. 1: Baja prioridad. 2: Media prioridad. 3: Alta prioridad.
1 2 3 4
Principios del Manifiesto gil Prioridad La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
53
5 6 7 8 9 10 11 12
Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo El dilogo cara a cara es el mtodo ms efectivo para comunicar informacin dentro de un equipo de desarrollo. 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 de mantener una paz constante La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento. Total
Tabla 3-3: Cumplimiento principios giles
prioridades asignadas
Siendo los principios giles 12 y la prioridad ms alta tiene un valor de 3, entonces el valor ms alto en cuanto al cumplimiento de estos principios de 36. Segn el resultado obtenido prioridades asignadas, se deduce que las metas segn el enfoque de la gerencia de sistemas de la empresa se orientan en un prioridades asignadas * 100/36 % al cumplimiento de los principios giles. Caso prctico Indicadores de los principios giles en una organizacin segn un desarrollador de la organizacin: Principios del Manifiesto gil La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo El dilogo cara a cara es el mtodo ms efectivo para comunicar informacin dentro de un equipo de desarrollo. 54 Prioridad 2 2 2 2 3 3
1 2 3 4 5 6
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
Siendo los principios giles 12 y la prioridad ms alta tiene un valor de 3, entonces el valor ms alto en cuanto al cumplimiento de estos principios de 36. Segn el resultado obtenido de 30, se deduce que las metas a seguir de la organizacin segn el desarrollador se orientan en un 83% al cumplimiento integro o total de los principios giles. El resultado ser ms representativo cuantos ms miembros de la empresa realicen el cuestionario. En el caso prctico que se acompaa se han obtenido datos objetivos que indican que la organizacin tiene un enfoque gil, por tanto, el siguiente paso sera conocer qu metodologa gil, de entre las cuatro que se estn evaluando en este Trabajo Fin de Grado, se adapta mejor a la organizacin que se est estudiando.
Eleccin de una metodologa gil

En este paso se evala la forma de trabajo de la empresa basndose en los cuatro puntos de vista de Iacovelli1. Para ello, se ha elaborado un nuevo formulario agrupando estos cuatro puntos: Uso, capacidad de agilidad, aplicacin, procesos y productos. Cada uno de ellos con sus respectos atributos, cuyos valores sern asignados por la empresa en evaluacin. El objetivo del estudio realizado por Iacovelli: Framework para la clasificacin de metodologas giles, es clasificar los mtodos a travs de cuatro puntos de vista, cada uno representando un aspecto de las metodologas. Cada punto de vista se caracteriza por un conjunto de atributos.
Adrian Iacovelli, autor de Framework for Agile Methods Classification.
55
Ilustracin 3-2: Cuatro vistas de las metodologas giles (Iacovelli)
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: Adaptarse a los entornos turbulentos. Satisfaccin del usuario final. Favorable al offshoring (outsourcing internacional). Aumento de la productividad. El respeto de un nivel de calidad. El respeto de las fechas de entrega. Cumplimiento de los requisitos.
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
Una metodologa de desarrollo de software est compuesta por un ciclo de vida. En Ingeniera del Software existen diferentes ciclos de vida, como por ejemplo modelo en V, modelo en espiral,. De acuerdo a la cronologa de aparicin de las metodologas giles, la mayora de las metodologas derivan directamente del modelo en espiral. Esto se explica ya que las dos principales caractersticas de modelo en espiral son un ciclo de vida iterativo e incremental. Por tanto, los cambios de requisitos se pueden ir integrando en cada iteracin, de manera que el plan de trabajo no tiene que ser modificado, ir cambiando a lo largo de las iteraciones. Otro punto interesante es la duracin de las iteraciones, con iteraciones cortas aumenta el nmero de reuniones con el cliente para definir y detallar sus necesidades de forma incremental. En cuanto a la interaccin de las personas, las metodologas giles tienden a romper las relaciones contractuales entre los clientes y los equipos de desarrollo. Esta relacin se expresa en este punto de vista por el atributo de colaboracin. Un equipo gil es un tipo de organizacin hologrfica en la que cada miembro tiene el conocimiento del sistema en su conjunto, as que, si un miembro deja el equipo, no se ha perdido conocimiento. El principal concepto de la agilidad son los procesos ligeros. Generalmente, las metodologas giles incluyen menos documentacin. Las pruebas son una prctica muy importante, as como la refactorizacin. Los atributos de este punto de vista son: 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
Los atributos de este punto de vista son: Grado de interaccin entre los miembros del equipo (baja, alta). El grado de interaccin con el cliente (baja, alta). Grado de interaccin con los usuarios finales (baja, alta). Grado de integracin de la novedad (baja, alta). La complejidad del proyecto (baja, alta). Los riesgos del proyecto (baja, alta). Tamao del proyecto (pequeo, grande). La organizacin del equipo (auto-organizacin, la organizacin jerrquica). El tamao del equipo (pequeo, grande).
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
Las actividades cubiertas por el mtodo gil: 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 58
Productos de las actividades del mtodo: 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
Tercer Formulario: Eleccin de una metodologa gil

USO Verdadero (V) o Falso (F) en cada una de las premisas. 1 2 3 4 5 6 7 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
Tabla 3-5: Valoracin del Uso
Respuesta
CAPACIDAD DE AGILIDAD Verdadero (V) o Falso (F) en cada una de las premisas. 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
1 2 3 4 5 6 7 8
Los requisitos no funcionales pueden cambiar El plan de trabajo puede cambiar Los recursos humanos pueden cambiar Cambiar los indicadores Reactividad (AL COMIENZO DEL PROYECTO, CADA ETAPA, 13 CADA ITERACIN) 14 Intercambio de conocimientos (BAJO, ALTO) 9 10 11 12
Tabla 3-6: Valoracin de la Capacidad de agilidad
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) 1 2 3 4 5 6 7 8
Tabla 3-7: Valoracin de la Aplicacin
Respuesta
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
Tabla 3-8: Valoracin normas y directrices giles
Respuesta
Las actividades cubiertas por el mtodo gil: 1 2 3 4 Premisa Puesta en marcha del proyecto Definicin de requisitos Modelado Cdigo 60 Respuesta
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
Productos de las actividades del mtodo: 1 2 3 4 5 6 7 8 9 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
Tabla 3-10: Valoracin de los productos de las actividades de la metodologa gil
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 XP Respeto de las fechas de entrega Cumplimiento de los requisitos Por qu utilizar un mtodo gil? Respeto al nivel de calidad Satisfaccin del usuario final Entornos turbulentos Favorable al Off shoring Aumento de la productividad CAPACIDAD DE AGILIDAD
Cul es la FALSO
ORIENTADA A LA GESTIN DE PROYECTOS SCRUM

VERDADERO
KANBAN
FALSO
SCRUMBAN
FALSO
VERDADERO FALSO
VERDADERO FALSO
VERDADERO FALSO
VERDADERO FALSO
USO
FALSO VERDADERO FALSO
VERDADERO VERDADERO VERDADERO
FALSO VERDADERO FALSO
FALSO VERDADERO VERDADERO
VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO
VERDADERO VERDADERO VERDADERO VERDADERO FALSO
Iteraciones cortas Colaboracin Centrado en las personas Refactoring poltico
parte de agilidad incluida en el mtodo?
61
Prueba poltico Integracin de los cambios De peso ligero Los requisitos funcionales pueden cambiar Los requisitos no funcionales pueden cambiar El plan de trabajo puede cambiar Los recursos humanos pueden cambiar Cambiar los indicadores Reactividad (AL COMIENZO DEL PROYECTO, CADA ETAPA, CADA ITERACIN) Intercambio de conocimientos (BAJO, ALTO) Tamao del proyecto (PEQUEO, GRANDE) La complejidad del proyecto (BAJA, ALTA) Los riesgos del proyecto (BAJO, ALTO) El tamao del equipo (PEQUEO, GRANDE) APLICABILIDAD
Cundo un
FALSO VERDADERO VERDADERO
VERDADERO
VERDADERO
VERDADERO
VERDADERO
FALSO
FALSO
VERDADERO
VERDADERO
VERDADERO
FALSO
VERDADERO
VERDADERO
VERDADERO VERDADERO
FALSO FALSO
VERDADERO FALSO
VERDADERO FALSO
ITERACIN
ITERACIN
ITERACIN
ITERACIN
ALTO
BAJO GRANDE / PEQUEO
BAJO
BAJO GRANDE / PEQUEO
PEQUEO
PEQUEO
BAJA
ALTA
BAJA
ALTA
BAJO
ALTO
BAJO
ALTO
PEQUEO
PEQUEO
PEQUEO
PEQUEO
ambiente es favorable para Grado de interaccin con usar este los usuarios finales (BAJA, mtodo? ALTA) Grado de interaccin entre los miembros del equipo (BAJA, ALTA) Grado de integracin de la novedad (BAJA, ALTA) La organizacin del equipo (AUTOORGANIZACIN, ORGANIZACIN JERRQUICA)
El grado de interaccin con el cliente (BAJA, ALTA)
ALTA
ALTA
BAJO
BAJA
BAJO
ALTA
BAJO
BAJA
ALTA
ALTA
BAJA
ALTA
ALTA
ALTA
BAJA
ALTA
AUTOORGANIZACIN
AUTOORGANIZACIN
AUTOORGANIZACIN
AUTOORGANIZACIN
PROCESOS Y PRODUCTOS
Nivel de abstraccin de las normas y directrices Gestin de proyectos FALSO VERDADERO Descripcin de Cmo estn procesos VERDADERO FALSO caracterizados los procesos Normas y del mtodo? orientaciones concretas sobre las actividades y productos VERDADERO FALSO Las actividades cubiertas por el mtodo gil
FALSO FALSO
VERDADERO FALSO
FALSO
FALSO
62
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
FALSO VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO
FALSO VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO
FALSO FALSO FALSO VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO
FALSO VERDADERO FALSO VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO
Productos de las actividades del mtodo gil 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
FALSO VERDADERO FALSO VERDADERO
VERDADERO VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO
VERDADERO VERDADERO VERDADERO VERDADERO FALSO FALSO FALSO FALSO
Tabla 3-11: Clasificacin de metodologas giles
Comparando los resultados obtenidos del formulario y la tabla de clasificacin anterior, se identificar la metodologa que mejor se adapta a la forma de trabajo de la empresa. La metodologa adecuada ser la que mayor nmero de coincidencias tenga con el cuestionario anterior. Caso prctico USO 1 2 3 4 5 6 7 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
Tabla 3-12: Ejemplo valoracin del Uso
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 El plan de trabajo puede cambiar Los recursos humanos pueden cambiar Cambiar los indicadores Reactividad (AL COMIENZO DEL PROYECTO, CADA ETAPA, CADA ITERACIN) Intercambio de conocimientos (BAJO, ALTO)
Tabla 3-13: Ejemplo valoracin de la Capacidad de agilidad
Respuesta V V V F V V 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
Tabla 3-14: Ejemplo valoracin de la Aplicacin
Respuesta PEQUEO BAJA BAJO PEQUEO ALTA ALTA ALTA ALTA JERRQUICA
PROCESOS Y PRODUCTOS Verdadero (V) o Falso (F) en cada una de las premisas. Nivel de abstraccin de las normas y directrices:
64
Premisa 1 Gestin de proyectos 2 Descripcin de procesos 3 Normas y orientaciones concretas sobre las actividades y productos
Respuesta V V F
Tabla 3-15: Ejemplo valoracin de las normas y directrices de la metodologa gil
Las actividades cubiertas por el mtodo gil: 1 2 3 4 5 6 7 8 9 10 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
Productos de las actividades del mtodo: 1 2 3 4 5 6 7 8 9 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
Tabla 3-17: Ejemplo valoracin de los productos de las actividades de la metodologa gil
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 ORIENTADA AL DESARROLLO DE SOFTWARE XP Respeto de las fechas de entrega Cumplimiento de los requisitos USO Respeto al nivel de calidad Satisfaccin del usuario final Entornos turbulentos Favorable al Off shoring Aumento de la productividad Iteraciones cortas Colaboracin Centrado en las personas Refactoring poltico CAPACIDAD DE AGILIDAD Prueba poltico Integracin de los cambios De peso ligero Los requisitos funcionales pueden cambiar Los requisitos no funcionales pueden cambiar El plan de trabajo puede cambiar Los recursos humanos pueden cambiar Cambiar los indicadores Reactividad Intercambio de conocimientos Tamao del proyecto La complejidad del proyecto APLICABILIDAD Los riesgos del proyecto El tamao del equipo El grado de interaccin con el cliente Grado de interaccin con los usuarios finales Grado de interaccin entre los miembros del equipo Grado de integracin de la novedad 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 0 1 1 ORIENTADA A LA GESTIN DE PROYECTOS SCRUM 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1 1 1 1 KANBAN 0 1 0 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 0 1 1 1 1 1 1 0 0 0 0 SCRUMBAN 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 0 0 1 0 0 1 1
66

La organizacin del equipo Gestin de proyectos Descripcin de procesos Normas y orientaciones concretas sobre las actividades y productos Puesta en marcha del proyecto Definicin de requisitos PROCESOS Y PRODUCTOS Modelado Cdigo Pruebas unitarias Pruebas de integracin Prueba del sistema Prueba de aceptacin Control de calidad Sistema de uso 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 0 0 1 0 1 0 0 0 0 0 1 0
Nivel de abstraccin de las normas y directrices
0 0 1 0 1 1 1 1 0 0 0 1 1 1 1 1 1 0 0 0
1 0 1 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
1 0 0 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0 0 0
1 0 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 33
Las actividades cubiertas por el mtodo gil
Productos de las actividades del mtodo gil
32 32 TOTAL: 34 Tabla 3-18: Metodologa gil adecuada para el ejemplo
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
Un proyecto puede triunfar debido a una gran herramienta. Un proyecto puede triunfar a pesar de una psima herramienta. Un proyecto puede fallar debido a una psima herramienta. Un proyecto puede fallar a pesar de una gran herramienta.
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.
Velocidad inicial del equipo

Antes de comenzar con la reunin de planificacin se calculan el nmero de puntos ideales de trabajo que es capaz de asumir el equipo en el presente Sprint. Es necesario tener en cuentas los siguientes parmetros: Duracin del Sprint: 15 das laborables (3 semanas). Nmero de desarrolladores del equipo y su disponibilidad: 5 desarrolladores. Factor de correccin: 0,6 Se calcula el nmero de das de trabajo tericos que es capaz de asumir el equipo:
Desarrollador 1 Desarrollador 2 Desarrollador 3 Desarrollador 4 Desarrollador 5 TOTAL
Disponibilidad 100% 100% 100% 100% 50%
Das de trabajo en el Sprint 15 15 15 15 7,5 das de trabajo 67,5 tericos
Tabla 4-1: Velocidad del equipo
Teniendo en cuenta el factor de correccin anterior, se calculan los das reales de trabajo. 67,5 das de trabajo tericos * 0,6 = 40.5 El equipo es capaz de asumir 40.5 puntos de trabajo en el Sprint.
Reunin de planificacin
Backlog de historias de usuario presentado por el cliente:
73
Prior
Proyecto
Nombre
Notas
Gestin Incidencias
Crear tarea para que procese el excel y lo Script que procese los excel subidos por los usuarios y los transforme en incidencias transforme en incidencias. en BBDD. Crear back-end para subir Almacenar el fichero Excel en BBDD. Excel con 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.
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.
2 3
Gestin Incidencias Gestin Incidencias
Permisos segn perfiles: 4 LDAP Separar vista para Administradores / No Administradores. - Administrador: Tendr acceso a los informes de todos los distribuidores - No administrador: Solo acceso a sus propios informes Es necesario tener dos perfiles diferentes a la hora de acceder a la Web: 5 LDAP Configuracin de perfiles Los perfiles a configurar son: - Administrador. - No administrador. Se requiere implantar LDAP en el acceso a la Web de Comisiones. Se necesita el que concepto por el que se comisionan las portabilidades aparezca desglosado en una nueva columna de los informes de la Web de Comisiones. El nombre de la columna ser: "Comisin Portabilidad" y se acumular la cantidad comisionada al distribuidor en concepto de portabilidad durante el ciclo de comisiones.
Comprobar gua de estilo del cliente. Test de accesibilidad. Comprobar que un usuario Administrador puede adoptar el rol de un distribuidor y consultar sus informes. Comprobar que un usuario no administrador solo tiene acceso a sus propios informes.
LDAP
Instalar Servidor LDAP Aadir un nuevo concepto de comisin en los informes
Informes
Una vez calculada la comisin por portabilidad, comprobar que se acumula en la columna de "Comisin Portabilidad".
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, , ).
El smbolo se muestra cuando un miembro del equipo es incapaz de estimar el tiempo que le llevara una tarea, en ese caso el resto del equipo hace una presentacin tcnica de la tarea para que todo el mundo pueda estimar. , se muestra la taza de caf cuando el equipo necesita cinco minutos de descanso. El tiempo de duracin de una reunin de planificacin puede ser como mximo de cuatro horas, por eso se contempla hacer descansos durante esta tarea. Los resultados obtenidos de la reunin de planificacin son las historias de usuario que se listan a continuacin, que incluyen su estimacin, tareas en las que se descompone y prioridad:
Historias de usuario
Backlog Item #7 Proyecto: Informes
Aadir un nuevo concepto de comisin en los informes

Notas Se necesita el que concepto por el que se comisionan las portabilidades aparezca desglosado en una nueva columna de los informes de la Web de Comisiones. El nombre de la columna ser: "Comisin Portabilidad" y se acumular la cantidad comisionada al distribuidor en concepto de Portabilidad durante el ciclo de comisiones. Como probarlo Una vez calculada la comisin por portabilidad, comprobar que se acumula en la columna de "Comisin Portabilidad". Prioridad
7
Estimacin
11
Tareas asociadas a esta historia de usuario:
Ilustracin 4-1: Caso Prctico Tareas de Backlog tem 7
Crear un modelo para el clculo de este tipo de comisin asociado al concepto: PORTABILIDAD. 76
Crear procedimiento SQL que agrupe las comisiones de PORTABILIDAD por distribuidor y las incluya en el informe correspondiente Font-end: Aadir una nueva columna en la vista de los informes en la web para el concepto de PORTABILIDAD. El nombre de la columna ser: Comisin Portabilidad. Back-end: Recuperar de BBDD los la cantidad de comisin por portabilidad para mostrarla en los informes.
Backlog Item #6 Proyecto: LDAP
Instalar Servidor LDAP
Notas Se requiere implantar LDAP en el acceso a la Web de Comisiones.
Prioridad
6
Estimacin
Como probarlo
3
Instalar el servidor de LDAP en los diferentes entornos: Desarrollo, Pruebas y Produccin.
77
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
Configurar usuario con perfil administrador. Configurar usuario con perfil no administrador (limitado).
78
Separar vista para Administradores / No Administradores.

Notas Permisos segn perfiles: - Administrador: Tendr acceso a los informes de todos los distribuidores - No administrador: Solo acceso a sus propios informes Como probarlo Comprobar que un usuario Administrador puede adoptar el rol de un distribuidor y consultar sus informes. Comprobar que un usuario no administrador solo tiene acceso a sus propios informes. Prioridad
4
Estimacin
Nueva opcin para simular distribuidor en el perfil administrador. Perfil no administrador que no se vea esta opcin.
79
Backlog Item #3 Proyecto: Gestin Incidencias
Crear front-end para subir Excel con incidencias.

Notas Nueva opcin en el men y nueva ventana para que el usuario descargue la plantilla Excel y una vez cubierta la enve al sistema. Como probarlo Comprobar gua de estilo del cliente. Test de accesibilidad. Prioridad
3
Estimacin
En la opcin de incidencias crear un apartado para subir fichero Excel. Definir plantilla Excel. En la opcin de incidencias poner enlace para descargar plantilla Excel de incidencias.
80
Crear back-end para subir Excel con incidencias.

Notas Almacenar el fichero Excel en BBDD. Prioridad
2
Estimacin
Como probarlo
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
Crear tarea para que procese el Excel y lo transforme en incidencias en BBDD.

Notas Script que procese los excel subidos por los usuarios y los transforme en incidencias. Prioridad
1
Estimacin
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.
Crear script Perl para que lea el fichero Excel. Crear incidencias de usuario e insertarlas en la tabla de incidencias. Aadir validaciones al script. Planificar Script en un crontab para que se ejecute cada hora.
La suma total de los puntos de cada historia de usuario es: 40
82
Si antes de comenzar la reunin de planificacin se haba calculado que la cantidad de trabajo que poda asumir el equipo era de 40.5 puntos, el equipo puede comprometerse a implementar las siete historias de usuario propuestas por el cliente para este Sprint.
Reuniones diarias
Inicio del Sprint Los miembros del equipo se renen en frente al tabln de Scrum. En la primera reunin nadie tiene una tarea asignada, por tanto, no es necesario responder a las preguntas: Qu has hecho ayer? Qu voy a hacer hoy? Algn impedimento?. Cada desarrollador coge una tarea del tabln y comienza con la implementacin. Tareas que ha cogido cada desarrollador:
Ilustracin 4-8: Caso Prctico - Tabln al inicio del Sprint
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.
Ilustracin 4-9: Caso Prctico - Burndown al inicio del sprint
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
Desarrollador 5: Ha estado trabajando en la tarea: Instalar LDAP en: Desarrollo, Pruebas y Produccin, continuar trabajando en esta tarea y la reestima en 2.5 puntos de trabajo.
Ilustracin 4-10: Caso Prctico - Tabln primer da del Sprint
Estado actualizado de la grfica Se han quitado 3,5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 35,5 puntos de trabajo restantes.
85
Ilustracin 4-11: Caso Prctico - Burndown primer da del Sprint
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
Ilustracin 4-12: Caso Prctico - Tabln segundo da del Sprint
Estado actualizado de la grfica Se han quitado 1,5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 34 puntos de trabajo restantes.
Ilustracin 4-13: Caso Prctico - Burndown segundo da del Sprint
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.
Ilustracin 4-14: Caso Prctico - Tabln tercer da del Sprint
88
Estado actualizado de la grfica Se han quitado 3,5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 30,5 puntos de trabajo restantes.
Ilustracin 4-15: Caso Prctico - Burndown tercer da del Sprint
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
Ilustracin 4-16: Caso Prctico - Tabln cuarto da del Sprint
Estado actualizado de la grfica Se han quitado 4 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 26.5 puntos de trabajo restantes.
Ilustracin 4-17: Caso Prctico - Burndown cuarto da del Sprint
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
Ilustracin 4-18: Caso Prctico - Tabln quinto da del Sprint
92
Ilustracin 4-19: Caso Prctico - Burndown quinto da del Sprint
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
Ilustracin 4-20: Caso Prctico - Tabln sexto da del Sprint
Estado actualizado de la grfica Se han quitado 4.5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 18 puntos de trabajo restantes.
Ilustracin 4-21: Caso Prctico - Burndown sexto da del Sprint
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.
Ilustracin 4-22: Caso Prctico - Tabln sptimo da del Sprint
95
Estado actualizado de la grfica Se han quitado 2.5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 15.5 puntos de trabajo restantes.
Ilustracin 4-23: Prctico - Burndown sptimo da del Sprint
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
Ilustracin 4-24: Caso Prctico - Tabln octavo da del Sprint
97
Ilustracin 4-25: Caso Prctico - Burndown octavo da del Sprint
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
Ilustracin 4-26: Caso Prctico - Tabln noveno da del Sprint
Estado actualizado de la grfica Se ha aumentado en 1.5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 12 puntos de trabajo restantes.
99
Ilustracin 4-27: Caso Prctico - Burndown noveno da del Sprint
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.
Ilustracin 4-28: Prctico - Burndown dcimo da del Sprint
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.
Ilustracin 4-29: Caso Prctico - Tabln undcimo da del Sprint
101
Estado actualizado de la grfica Se han quitado 1.5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 10.5 puntos de trabajo restantes.
Ilustracin 4-30: Caso Prctico - Burndown undcimo da del Sprint
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
Ilustracin 4-31: Caso Prctico - Tabln decimosegundo da del Sprint
Ilustracin 4-32: Caso Prctico - Burndown decimosegundo da del Sprint
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.
Ilustracin 4-33: Caso Prctico - Tabln decimotercer da del Sprint
Estado actualizado de la grfica Se han quitado 1.5 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 6 puntos de trabajo restantes.
Ilustracin 4-34: Caso Prctico - Burndown decimotercer da del Sprint
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.
Ilustracin 4-35: Caso Prctico - Tabln decimocuarto da del Sprint
Estado actualizado de la grfica Se han quitado 2 puntos de trabajo: Tenemos que marcar el punto de hoy de la grfica en 4 puntos de trabajo restantes.
Ilustracin 4-36: Caso Prctico - Burndown decimocuarto da del Sprint
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.
Ilustracin 4-37: Caso Prctico - Tabln ltimo da del Sprint
Estado final de la grfica Han faltado por completar medio punto de trabajo.
Ilustracin 4-38: Caso Prctico - Burndown ltimo da del Sprint
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 visin de los requisitos para el "cliente" Intentar que los usuarios no se cian a la gua Dar ms visibilidad de los requerimientos incluyendo a los usuarios finales de los mismos (no solo al owner como jefe)
Ideas Crear el guin de la demo como otro documento del sprint Conocer infraestructura Aportar/plantear posibles desarrollos que puedan interesar a negocio
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
Tener en cuenta las fechas de SMT con las planificaciones de sprint Planificar la demo para 2 das despus del fin de desarrollo de sprint para permitir tiempo de preparacin, resolucin de posibles problemas de ltima hora Invertir tiempo en repasar y montar si es necesario los entornos de desarrollo, QA, etc. Se debera haber hecho la demo con las funcionalidades desarrolladas Resolver impedimentos en cuanto aparecen
Tabla 4-2: Reunin retrospectiva
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 1 2
Imp 6 5
Proyecto PFG - Gua comparativa de metodologas giles 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 Seleccionar una lista delimitada de metodologas sobre N/A las que se va a desarrollar el PFG. Elaborar una documentacin sobre las metodologas de estudio que permita conocer los aspectos ms N/A importantes de cada una de ellas. N/A
Cmo probarlo
Establecer criterios de Crear una lista de criterios de comparacin entre las comparacin diferentes metodologas de estudio.
PFG - Gua comparativa de metodologas giles
Comparativa de las metodologas giles
Desarrollar la comparacin entre las metodologas seleccionadas.
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. N/A Verificar que los estndares de los PFG se han aplicado a la memoria
PFG - Gua comparativa de metodologas giles PFG - Gua comparativa de metodologas giles
Caso prctico Scrum Maquetacin de la memoria
Documentar una iteracin de un caso prctico de Scrum. Maquetacin de la memoria del PFG segn los estndares definidos por la EUISG.
Tabla 5-1: Backlog de la Guia comparativa de metodologas giles
Primera iteracin
Backlog Item #1 Proyecto: PFG - Gua comparativa de metodologas giles
Seleccionar metodologas giles a estudiar

Notas Seleccionar una lista delimitada de metodologas sobre las que se va a desarrollar el PFG. Prioridad
4
Estimacin
Como probarlo N/A
Documentar teora Scrum

Notas Elaborar una documentacin sobre Scrum que permita conocer los aspectos ms importantes. Prioridad
3
Estimacin
Como probarlo N/A
Documentar teora XP
Notas Elaborar una documentacin sobre XP que permita conocer los aspectos ms importantes. Prioridad
2
Estimacin
Como probarlo N/A
Documentar teora Kanban

Notas Elaborar una documentacin sobre Kanban que permita conocer los aspectos ms importantes. Prioridad
1
Estimacin
Como probarlo N/A
2
116
Si se trabaja con iteraciones de dos semanas, se dispone de diez puntos ideales de trabajo. Se aplica el factor de correccin: 10 pto. Ideales * 0,8 = 8 Este resultado quiere decir que en la primera iteracin se van a asumir 8 puntos de trabajo. Tomando las tareas del backlog por orden de prioridad, dentro de esta iteracin se podran desarrollar las tareas: Seleccionar las metodologas giles a estudiar y Documentar cada una de las metodologas. Como la segunda no se podra completar en la primera iteracin porque se pasara de los puntos que disponemos, se ha decidido dividir an ms la historia de usuario. Como se ha decidido estudiar cuatro metodologas giles la segunda tarea se va a dividir en cuatro de la siguiente manera:
Historia de Usuario Original Documentar cada una de las metodologas giles Total:
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
Tabla 5-2: Divisin de la tarea Documentar cada metodologa gil en subtareas
De esta manera se podrn asumir en la primera iteracin las siguientes historias de usuario:
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
Segunda iteracin
Documentar teora Scrumban

Notas Elaborar una documentacin sobre Scrumban que permita conocer los aspectos ms importantes. Prioridad
3
Estimacin
Como probarlo N/A
Establecer criterios de comparacin

Notas Crear una lista de criterios de comparacin entre las diferentes metodologas de estudio. Prioridad
2
Estimacin
Como probarlo N/A
4
118
Comparativa: Base terica para orientacin de la organizacin

Notas Rasgos de una organizacin que sigue metologas tradiciones y rasgos de una organizacin gil.. Prioridad
1
Estimacin
Como probarlo Comprobar que hay suficientes detalles para distinguir con claridad si una organizacin es tradicional / gil.
Igual que en la primera iteracin se dispone de diez puntos ideales de trabajo. Se aplica el factor de correccin: 10 pto. Ideales * 0,8 = 8 En la segunda iteracin se asumen nuevamente 8 puntos de trabajo. Siguiendo el orden de las tareas del backlog, dentro de esta segunda iteracin se podra desarrollar la tarea: Documentar teora Scrumban, Criterios de comparacin y Comparativa de metodologas giles estimada en once puntos ideales. Como no se pueden asumir ms puntos de trabajo que los que se han calculado para la iteracin, se divide la tarea ms grande en tareas ms pequeas de la siguiente manera: Divisin de la Historia de Usuario Base terica para orientacin de la organizacin Base terica para seleccin de la metodologa gil Elaboracin del cuestionario Interpretacin Ejemplo
Historia de Usuario Original
Estimacin 2 2 3 3 1 8 ptos
Comparativa de metodologas giles
Total:
Tabla 5-4: Divisin de la tarea Comparativa de metodologas giles
119
De esta manera se podrn asumir en la primera iteracin las siguientes historias de usuario:
Historia de Usuario Documentar teora Scrumban Criterios de comparacin Base terica para orientacin de la organizacin Total:
Tabla 5-5: Historias de usuario de la segunda iteracin
Estimacin 2 4 2 8 ptos
Tercera iteracin
Comparativa: Base terica para seleccin de la metodologa gil

Notas Rasgos de cada una de las metodologas giles a comparar: Scrum, XP, Kanban, Scrumban. Prioridad
3
Estimacin
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.
120
Comparativa: Elaboracin del cuestionario

Notas Formularios. Prioridad
2
Estimacin
Como probarlo Comprobar que son claros, precisos, comprensibles.
Comparativa: Interpretacin
Notas Interpretacin del vaciado de los cuestionarios. Prioridad
1
Estimacin
Como probarlo Indicar si la interpretacin del vaciado de los cuestionarios es clara y comprensible.
121
Igual que en la primera iteracin se dispone de diez puntos ideales de trabajo. Se aplica el factor de correccin: 10 pto. Ideales * 0,8 = 8 En la tercera iteracin se asumen nuevamente 8 puntos de trabajo. Siguiendo el orden de las tareas del backlog, dentro de esta tercera iteracin se asumen las tareas que no se han podido incluir la iteracin anterior: Base terica para seleccin de la metodologa gil, Elaboracin del cuestionario y Interpretacin. Historia de Usuario Base terica para seleccin de la metodologa gil Elaboracin del cuestionario Interpretacin Total:
Tabla 5-6: Historias de usuario de la tercera iteracin
Cuarta iteracin
Comparativa: Ejemplo
Notas Cumplimentar formularios e interpretar los resultados obtenidos. Prioridad
3
Estimacin
Como probarlo N/A
122
Caso prctico: Planificacin y Tareas

Notas Acta de reunin de la reunin de planificacin. Prioridad
2
Estimacin
Como probarlo N/A
Caso prctico: Desarrollo

Notas Documentar el da a da del progreso en el desarrollo de las nuevas funcionalidades. Prioridad
1
Estimacin
Como probarlo N/A
3
123
Se dispone de diez puntos ideales de trabajo. Se aplica el factor de correccin: 10 pto. Ideales * 0,8 = 8 por tanto, se asumen nuevamente 8 puntos de trabajo. Siguiendo el orden de las tareas del backlog, dentro de esta cuarta iteracin se asumen las siguientes tareas: Ejemplo, Caso Prctico Scrum. Una vez ms la tarea completa del caso prctico no se puede asumir completa en una iteracin, de manera que se divide en tareas ms pequeas de la siguiente manera:
Historia de Usuario Original Caso Prctico Scrum
Divisin de la Historia de Usuario Caso Prctico: Planificacin y tareas Caso Prctico: Desarrollo Caso Prctico: Demostracin Caso Prctico: Retrospectiva
Total:
Tabla 5-7: Divisin de la tarea Caso Prctico Scrum en subtareas
De esta manera se podrn asumir las siguientes historias de usuario: Historia de Usuario Ejemplo Caso Prctico: Planificacin y tareas Caso Prctico: Desarrollo Total:
Tabla 5-8: Historias de usuario de la cuarta iteracin
124
Quinta iteracin
Caso prctico: Demostracin

Notas Preparacin de la demostracin de las nuevas funcionalidades al cliente. Prioridad
3
Estimacin
Como probarlo Comprobar que en el guin de la demostracin aparecen todas las nuevas funcionalidades.
Caso prctico: Retrospectiva

Notas Reunin retrospectiva del equipo de Scrum. Prioridad
2
Estimacin
Como probarlo N/A
1
125
Maquetacin de la memoria
Notas Maquetacin de la memoria del PFG segn los estndares definidos por la EUISG. Prioridad
1
Estimacin
Como probarlo Verificar que los estndares de los PFG se han aplicado a la memoria
Se dispone de diez puntos ideales de trabajo. Se aplica el factor de correccin: 10 pto. Ideales * 0,8 = 8 por tanto, se asumen nuevamente 8 puntos de trabajo. Siguiendo el orden de las tareas del backlog, dentro de esta ltima iteracin todas las tareas restantes: Caso Prctico: Demostracin, Caso Prctico: Retrospectiva y Maquetacin de la memoria y an sobran dos puntos de trabajo. Se asumen las siguientes historias de usuario:
Historia de Usuario Caso Prctico: Demostracin Caso Prctico: Retrospectiva Maquetacin de la memoria Total:
Tabla 5-9: Historias de usuario de la quinta iteracin
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.
Ilustracin 5-1: Calendario del TFG
127
Ilustracin 5-2: Diagrama de Gantt del TFG
Ilustracin 5-3: Calendario y diagrama de Gantt del TFG
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.
Estimacin de la duracin de las actividades

Las horas de trabajo del coordinador ser toda la duracin del proyecto. Las del desarrollador / investigador corresponden a las tareas iniciales de anlisis ms a la definicin y elaboracin del proyecto y al testeo. Al ser una nica persona la que asume los diferentes roles las tareas se desarrollaran secuencialmente y por tanto, la dedicacin del desarrollador / investigador ser toda la duracin del proyecto.
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
Tabla 6-1: Precio / hora para cada miembro del equipo
Equipo y tiempo en el proyecto

Resumen de horas dedicadas al proyecto por cada miembro del equipo extrada de la herramienta OpenProj:
135
Ilustracin 6-1: Estimacin y tiempo en el proyecto
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
Ilustracin 6-2: Gantt agrupado por recurso
137
Estimacin de horas del proyecto

Se muestra la estimacin en horas del proyecto, se ve como el coordinador del proyecto est durante todo el proyecto y el desarrollador va realizando las diferentes tareas de anlisis, desarrollo y testeo a lo largo de todo el proyecto. Las tareas del desarrollador no se pueden solapar en ningn momento, ya que el proyecto slo tiene un desarrollador asignado. En ningn caso el desarrollador est desocupado.
Mes Coordinador Desarrollador Total
Junio 40 h 160 h
Julio 44 h 176 h
Agosto 12 h 48 h 480 h
Tabla 6-2: Horas del proyecto
Estimacin econmica del proyecto

A continuacin la parte econmica en euros teniendo en cuentas las horas del apartado anterior multiplicadas por el precio de cada recurso establecida en la tabla: Precio / hora para cada miembro del equipo. Coste mensual del proyecto Mes Coordinador (40 /h) Desarrollador (15 /h) Total
Tabla 6-3: Coste mensual del proyecto
Junio 40 h 1.600 160 h 2.400
Julio 44 h 1.760 176 h 2.640
Agosto 12 h 480 48 h 720 9600
Coste por Iteracin y coste total extrados de la herramienta OpenProj:
138
Primera iteracin
Ilustracin 6-3: Costo primera iteracin
Segunda iteracin
Ilustracin 6-4: Costo segunda iteracin
139
Tercera iteracin
Ilustracin 6-5: Costo tercera iteracin
Cuarta iteracin
Ilustracin 6-6: Costo cuarta iteracin
140
Quinta iteracin
Ilustracin 6-7: Costo quinta iteracin
Coste total
Ilustracin 6-8: Costo 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
Coste % Coste aplicado Adquisicin proyecto 700 170 150 300 Integrado Open-source 50
Tabla 6-4: Costo Hardware y Software
Recurso HW / SW TOSHIBA Satellite Windows XP Professional Microsoft-Office 2010 Adobe Acrobat Professional Microsoft Paint OpenProj Consumibles Total
Coste Proyecto 20% 140 20% 20% 20% 0% 0% 20% 34 30 60 0 0 10 274
Comunicaciones
Coste Unitario 20 Duracin Meses 3 % Coste aplicado proyecto 20% Coste Proyecto 12 12
Recurso Conexin internet Total
Tabla 6-5: Costo Comunicaciones
El costo total invertido en recursos materiales es la suma del gasto en recursos Hardware + gasto recursos Software + gasto conexiones = 274 + 12 = 286
142
Costo del proyecto

RECURSO HUMANOS MATERIALES TOTAL
Tabla 6-6: Costo total del proyecto
Coste Proyecto 9.600 286 9.886
Herramientas Empleadas
Herramientas empleadas para el desarrollo del proyecto: Hardware TOSHIBA Satellite: En Windows XP, Procesador Pentium 4 a 1,6 GHz. Mquina con la que se ha realizado todo el proyecto.
Software Windows XP Professional: Sistema operativo del ordenador utilizado para el desarrollo del proyecto Microsoft-Office 2010. ScrumNinja: Herramienta Online para la gestin de proyectos con Scrum. OpenProj: Herramienta open-source para la gestin de proyectos. Adobe Acrobat Professional.
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
Futuras lneas de trabajo

La gua comparativa de metodologas giles se ha centrado en un nmero limitado de metodologas, todas ellas pertenecientes al mundo gil. Una posible ampliacin podra ser aadir nuevas metodologas del agilismo o aadir tambin la metodologa tradicional. Otra posibilidad sera buscar nuevas caractersticas, propiedades de las metodologas que no se han contemplado en la herramienta creada y que pueden tener un peso importante a la hora de elegir una metodologa u otra.
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.
Back-end: Parte de software que procesa la entrada desde el front-end.
Crontab: Administrador regular de procesos en segundo plano que ejecuta procesos a intervalos regulares de tiempo.
Front-end: Parte del software que interacta con los usuarios.
Grfica burndown: Grfica que muestra la velocidad a la que se estn completando los requisitos del sprint.
Historia de usuario: En las metodologas giles este trmino sustituye a la especificacin de requisitos. Las historias de usuario son una forma rpida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos.
Kanban: Mtodo gil para la gestin de desarrollo software.
Manifiesto gil: Recoge los principios en los que se basan todas las metodologas giles.
Metodologa gil: Mtodos de ingeniera del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto-organizados y multidisciplinarios flexibles al cambio.
Product backlog: Lista de requisitos priorizada por el cliente.
Product owner: En equipos giles representa al cliente y es el encargado de negociar con el equipo.
155
Punto ideal: Unidad de medida ajustada del trabajo en un equipo gil.
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.
Refactorizar: Tcnica de la ingeniera de software para reestructurar un cdigo fuente, alterando su estructura interna sin cambiar su comportamiento externo.
Scrum: Mtodo gil para la gestin de desarrollo software.
Scrumban: Mtodo gil para la gestin de desarrollo 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.
Scrum master o facilitador: En equipos giles responsable de guiar y resolver obstculos al equipo.
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.
Sprint demonstration o demo: Reunin con el cliente, propia de Scrum, en la que se muestran las nuevas funcionalidades.
Sprint restrospective o retrospectiva: Reunin propia de Scrum, en la que se reflexiona sobre el Sprint que acaba de finalizar y se determina qu podra cambiarse para el siguiente Sprint y ser ms productivo y mejor.
Velocidad del equipo o velocidad de trabajo: Nmero de puntos ideales de trabajo que es capaz de asumir el equipo en el presente Sprint.
156
XP: Mtodo gil para la gestin de desarrollo software.
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
Captulo 12: ndice de Tablas
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
Captulo 13: ndice de Figuras
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
Gua Comparativa de Metodologas giles Ilustracin 4-37: Caso Prctico - Tabln ltimo da del Sprint ................................... 106 Ilustracin 4-38: Caso Prctico - Burndown ltimo da del Sprint .............................. 106 Ilustracin 5-1: Calendario del TFG .......................................................................... 127 Ilustracin 5-2: Diagrama de Gantt del TFG .............................................................. 128 Ilustracin 5-3: Calendario y diagrama de Gantt del TFG ......................................... 129 Ilustracin 6-1: Estimacin y tiempo en el proyecto .................................................. 136 Ilustracin 6-2: Gantt agrupado por recurso .............................................................. 137 Ilustracin 6-3: Costo primera iteracin ..................................................................... 139 Ilustracin 6-4: Costo segunda iteracin ................................................................... 139 Ilustracin 6-5: Costo tercera iteracin...................................................................... 140 Ilustracin 6-6: Costo cuarta iteracin ....................................................................... 140 Ilustracin 6-7: Costo quinta iteracin ....................................................................... 141 Ilustracin 6-8: Costo total ........................................................................................ 141
174

Gia Comparativa de Metologias Agiles

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gia Comparativa de Metologias Agiles

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad de Valladolid

E. U. de Informtica (SEGOVIA) Grado en Ingeniera Informtica de Servicios y Aplicaciones

Gua Comparativa de Metodologas giles

Alumno: Mara Jos Prez Prez

Tutor: Francisco J. Gonzlez Cabrera

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Mara Jos Prez Prez Grado en Ingeniera Informtica de Servicios y Aplicaciones

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Objetivos del proyecto

Gua Comparativa de Metodologas giles

Captulo 2: Metodologas giles y caractersticas

Mara Jos Prez Prez Grado en Ingeniera Informtica de Servicios y Aplicaciones

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Metodologas giles y caractersticas

Gua Comparativa de Metodologas giles

Qu es Scrum? Qu es XP (eXtreme Programming)? Kanban? Scrumban?

Gua Comparativa de Metodologas giles

Ilustracin 2-1: Ciclo de Scrum - Sprint

Gua Comparativa de Metodologas giles

Actividades de la metodologa Scrum

Ilustracin 2-2: Actividades del proceso de Scrum

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Ilustracin 2-3: Grfica burndown

En el eje Y cantidad de trabajo pendiente de terminar En el eje X tiempo (iteraciones)

Gua Comparativa de Metodologas giles

Ilustracin 2-4: Ciclos XP

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Ilustracin 2-5: Integracin Secuencial - XP

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Ilustracin 2-6: Proyecto XP

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Gua Comparativa de Metodologas giles

Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo

Ilustracin 2-7: Muro Kanban

Determinar el lmite del trabajo en curso (Work In Progress)