Universidad De Costa Rica

Transcripción

1 Universidad De Costa Rica Sistema de Estudios de Postgrado Programa de Posgrado en Computación e Informática PF 3872 Metodologías Ágiles para Desarrollo de Software Prof: Andrés Arias Camaño aarias@codefactorycr.com andres.arias@ecci.ucr.ac.cr Casillero # 22 Horario: Jueves de 5:30pm a 8:50pm, aula 301 Créditos: 4 Carta al Estudiante II Semestre 2010 Justificación: Vivimos en un mundo en constante cambio y evolución, donde la competencia se encuentra asimismo en una constante búsqueda de mejoras en sus procesos, productos y servicios, donde el costo de oportunidad de poder contar con un bien o servicio interesante para nuestros clientes puede perderse en poco tiempo si no contamos con una solución implementada y lista para nuestros usuarios. Asimismo, en el mundo del software estamos acostumbrados a trabajar siempre en metodologías RUP o Cascada, con etapas fijas que no permiten realizar cambios o ajustes de manera fácil, sin que esto implique una infinidad de atrasos en el mismo proyecto, desembocando usualmente en un proyecto poco exitoso. Junto a esto, vivimos siempre con la idea de que el equipo desarrollador de software es el último responsable del sistema, cuando más bien es el cliente quien es el responsable de que el proyecto tenga sentido y sirva para algo. En el mundo del software es muy complicado hacer permear este concepto entre desarrolladores y clientes, pero es parte del cambio que debemos iniciar en los profesionales del software para poder tener proyectos exitosos y útiles. Además, en las metodologías tradicionales de desarrollo de software se le da poca o ninguna importancia a la parte de pruebas y control de calidad, cuando esto más bien es vital para que el proyecto sea exitoso. En las metodologías tradicionales las pruebas siempre van de último, mientras que en las metodologías Ágiles las pruebas y el control de calidad comienzan al mismo tiempo que los programadores empiezan a programar, pues la calidad no es una etapa del proyecto, es un proceso interno presente a lo largo de todo su desarrollo. Ante estas situaciones, surge la necesidad de incursionar en otras metodologías de desarrollo, tales como las Ágiles, que están muy de moda en estos tiempos, pero que muchas veces se piensa que son desordenadas y caóticas, cuando más bien requieren de un mayor esfuerzo y una gran disciplina por parte de los miembros del equipo del proyecto, para poder asegurar el éxito. Descripción: Aplicar las tecnologías ágiles y de programación extrema para el desarrollo de software, resaltando las diferencias y ventajas respecto de otras metodologías de desarrollo. Co-requisitos: PF 3873 Laboratorio de Metodologías Ágiles para Desarrollo de Software Objetivo General: Al finalizar este curso el o la estudiante habrá recibido una introducción a las prácticas y principios de las metodologías de desarrollo Ágiles, de manera tanto teórica como práctica, al elaborar un proyecto piloto bajo las directrices propias de estas metodologías de desarrollo. 1

2 Objetivos Específicos Al finalizar el curso el o la estudiante será capaz de: 1. Describir los conceptos generales de la metodología de desarrollo Ágil. 2. Describir los conceptos generales del Desarrollo de Software Dirigido por Pruebas. 3. Identificar los roles dentro del proyecto, filosofía de seguimiento de proyectos y uso de herramientas que faciliten su incorporación en el equipo de trabajo. 4. Promover el uso de herramientas gratis y open-source que ayuden al desarrollo de software al estilo Ágil, tales como Bugzilla, CruiseControl, Hudson, RallyDev, SVN, JUnit, NUnit, entre otros. 5. Implementar proyectos en tecnologías dominantes (Java,.NET, PHP, Ruby) utilizando metodología Ágil y desarrollo orientado a pruebas. Contenido: 1. Tema I Introducción a Ágil 1.1. Introducción. Qué es Ágil? Diferencias con otras metodologías Principios básicos de Ágil 1.3. Roles dentro del proyecto Historias de Usuario vrs. Casos de Uso 2. Tema II - Estimaciones en Ágil 2.1. Administración empírica vrs. enfoques tradicionales 2.2. Cálculo de la velocidad del equipo 2.3. Equipos auto-administrados y proactivos. 3. Tema III Recursos tecnológicos que soporten y ayuden a Ágil 3.1. Desarrollo Dirigido por Pruebas 3.2. Integración Continua Generación de versiones construidas o liberaciones periódicas Manejo de proyectos usando RallyDev 4. Tema IV Manejo y Seguimiento de un Proyecto Ágil 4.1. Reuniones de revisión y retrospectiva luego de cada iteración Uso de casos de prueba como criterio de aceptación de historias de usuario 4.3. Gráficos de trabajo pendiente y trabajo realizado 5. Tema V Ejemplos de otras metodologías Ágiles 5.1. Programación Extrema 5.2. Desarrollo Ligero de Software 5.3. Desarrollo de Software Adaptivo Metodología Sugerida: Teoría: Clase magistral con discusiones y lecturas al hogar. Práctica: Proyecto práctico en grupos de 2 ó 3 personas. Referencias: Shwaber, Ken: Agile Software Development with Scrum, Cohn, Mike: User Stories Applied: For Agile Software Development, Hunt, Andy: Practices of an Agile Developer, Larman, Craig: Agile and Iterative Development: A Manager's Guide, Langr, Jeff: Agile Java Crafting Code with Test-Driven Development, Otros 2

3 Evaluación Sugerida: Teoría 5 Exámenes Cortos (Quices) de 7% cada uno: 35% Durante el semestre se harán 7 quices en total, pero se eliminarán los 2 quices con notas más bajas. Los quices no se reponen. El fraude o plagio durante cualquier quiz será penalizado eliminando el quiz a todos los involucrados en el plagio-copia. Práctica Proyecto Grupal (en grupos de 2 ó 3 personas): 65% Trabajo Individual en el Proyecto: (28%) Aportes personales en el Blog: 10% (4 aportes de 2.5% cada uno) Cada alumno o alumna deberá publicar 4 aportes personales en el Blog del curso, de la siguiente manera: o 1 aporte al iniciar el curso, con lo que espera del curso o 1 aporta al iniciar la primera iteración, con sus expectativas del mismo. o 2 aportes más, uno al terminar cada iteración, con lo aprendido durante cada iteración. Cada uno de estos aportes debe incluir al menos 2 cosas buenas que pasaron, 2 cosas malas que pasaron y 2 cosas por mejorar. Este aporte es individual y obligatorio para cada uno de los miembros de cada grupo. No se aceptarán aportes iguales entre compañeros de grupo. En dado caso que se identifiquen 2 o más aportes muy similares, se anularan todos. Cada aporte debe ser publicado en el Blog del curso a más tardar a las 11:59pm del Viernes de cada semana descrita en el punto anterior. Asimismo, cada alumno o alumna es libre de agregar más aportes en el blog, conforme vayamos avanzando con el curso, siempre y cuando cumpla con los 4 aportes anteriormente descritos y los temas se relacionen con el curso. Reportes Semanales de Avance: 9% (9 reportes de 1% cada uno) Cada alumno o alumna deberá enviar semanalmente un reporte de avance con la siguiente información: Qué hizo durante la semana Qué hará la siguiente semana Si tiene algún obstáculo que le impida alcanzar sus objetivos La semana que cubre cada reporte arranca después de la lección, y termina antes de la siguiente lección a las 4:59pm. Los reportes empiezan a correr a partir de la semana en que arranca el proyecto programado, y terminan en la última semana del curso. Cada reporte semanal debe enviarse al correo aarias@codefactorycr.com, con copia a todos sus compañeros de grupo, a más tardar a las 4:59pm del día que tengamos clases, antes de la lección del curso. Este aporte es individual y obligatorio para cada uno de los miembros de cada grupo. Reportes Semanales de Tiempo: 9% (9 reportes de 1% cada uno) La metodología Ágil se basa en la medición continua de la velocidad y el desempeño del equipo. Es por esto que cada alumno deberá registrar las horas trabajadas por semana en su proyecto, con el fin 3

4 de ir recopilando un histórico de esfuerzo por grupo, y así poder usarlo como base para las estimaciones de la segunda iteración. Cada alumno o alumna deberá registrar las horas dedicadas al curso/proyecto cada Viernes antes de las 11:59pm. Cada registro ingresado en el sistema de tiempos ( deberá incluir un breve comentario de lo realizado. El o la estudiante deberá iniciar el registro de sus horas dedicadas a partir de la segunda semana del proyecto y terminan en la última semana del curso (9 semanas en total). Este aporte es individual y obligatorio para cada uno de los miembros de cada grupo. Trabajo Grupal en el Proyecto: (37%) Proyecto Programado en la tecnología de su elección: 17% A lo largo del curso cada grupo implementará un proyecto descrito por el profesor. Para efectos del curso, y utilizando nomenclatura Ágil, el profesor será el Dueño del Producto, pues él describirá y priorizará los requerimientos que deberán ser implementados en cada iteración. Cada uno de los miembros del equipo deberá ser el o la ScrumMaster del equipo durante una iteración, para que esta responsabilidad recaiga sobre todos por igual a lo largo del curso. Esto es obligatorio y no es negociable. Este proyecto será implementado en la tecnología que el grupo prefiera, ya sea.net, Java, PHP, Ruby on Rails o alguna otra. La idea es que se enfoquen en aprender el estilo de trabajo y no tanto a aprender una tecnología. Sin embargo, cada proyecto programado debe cubrir los siguientes requisitos: Uso de un sistema de control de versiones: 4% Todo grupo deberá utilizar el repositorio de Subversion (SVN) suministrado por el profesor para manejo de versiones. Se deberá utilizar la estructura SVN recomendada (trunk, branches, tags), donde trunk es producción (o lo que ve el cliente), branches tiene los directorios de trabajo (p.e. un branch por iteración) y tags tiene copias de cada liberación hecha hacia el cliente. Todo cambio hecho en SVN debe tener obligatoriamente un mensaje de log o bitácora, para seguimiento y control del profesor y los demás miembros del grupo. Tales mensajes incluyen pulgas arregladas, requerimientos implementados, entre otros. Cada commit que se encuentre en SVN sin un mensaje en el log será penalizado con 0.5% menos en éste rubro para todo el grupo. Uso de algún sistema de integración continua: 3% Cada grupo deberá contar con algún sistema de integración continua de su elección, como Hudson, CruiseControl, CruiseControl.NET, Xinc, entre otros, o al menos un script que realice la versión construida de manera automatizada. Éste será utilizado para generar las liberaciones que le serán entregados al profesor para su revisión y aceptación de requerimientos. Todo grupo deberá mostrar cómo funciona su sistema de integración continua cuando le toque realizar su reunión de revisión y retrospectiva de la iteración. 4

5 No importa la herramienta de CI que use el equipo, siempre y cuando en el repositorio de Subversion se encuentre el script para generar una liberación, que típicamente son utilizados por los sistemas de CI. Puede utilizar Ant, NAnt, Makefile o algún otro de su elección. Uso de pruebas de unidad: 4% Todo proyecto deberá incluir dentro de su proceso de generación de versión construida la ejecución de pruebas de unidad programadas también por el equipo. Puede usar la librería de su elección, como Nunit, Junit, PHPUnit, entre otros. La cobertura de las pruebas de unidad deberá ser de al menos el 50% de las clases de lógica de negocio implementadas para el proyecto. De haber menos del 50% de las clases con pruebas de unidad, se calculará la diferencia entre el porcentaje de clases que tengan pruebas de unidad y el 50%, y éste será el valor que se restará a esta nota. Por ejemplo, si la cobertura de pruebas de unidad es de 47%, la nota en este rubro será 9 (50-47) = 9 3 = 6%. Liberación de liberaciones periódicas: 6% Como se indicó anteriormente, cada grupo tendrá un subdominio donde se publicarán las liberaciones periódicas producto del avance de cada equipo, para que puedan ser revisados por el profesor. A partir de la tercer semana del proyecto, se espera contar con al menos una liberación semanal, donde cada uno valdrá 1%. La idea es que cada uno de estas liberaciónes contenga lo siguiente: Número de versión. Éste debe ser consistente a lo largo de todo el curso. Notas indicando qué se incluye en esta liberación (pulgas arregladas, requerimientos listos, etc). Una copia de la base de datos actualizada de acuerdo al número de versión, e instrucciones de como actualizarla. Notas adicionales sobre instalación o ambiente. URL donde se encuentra publicada la liberación Recuerde enviarle un correo al profesor cuando su liberación se encuentre publicado en su subdominio, para que el proceda a revisarlo. Asimismo, cada grupo deberá publicar su liberación en algún servidor público, para que el profesor pueda revisarlo en cualquier momento. Si la universidad no cuenta con servidores públicos para el curso, se sugiere el uso de alguno de estos servicios gratis:.net: Un servidor suministrado por la UCR Un cloud server configurado sólo para funcionar durante el curso. 5

6 Cada semana que pase sin que haya una liberación se le restará 1% a este rubro. Nota: los equipos que trabajen en PHP pueden usar el subdominio suministrado por el profesor para publicar sus liberaciones, si éste contiene todo lo necesario para ejecutarse correctamente. De necesitar librerías especiales (p.e. Zend) favor coordinar con el profesor para ver si el servicio de hosting lo permite. Reunión de revisión y retrospectiva de Iteración: 10% Cada vez que termine una iteración, la mitad de los grupos realizarán una reunión de revisión y retrospectiva del mismo en el aula, durante la lección. Durante esta reunión se debe cubrir lo siguiente (no más de 1 hora cada grupo): Exponer lo implementado durante la iteración que terminó. El criterio de aceptación de cada iteración es que al menos el 75% de los casos de prueba de los requerimientos hayan pasado satisfactoriamente antes de la reunión de revisión. Exponer como funciona su sistema de Integración Continua. Explicar lo bueno, malo y las cosas por mejorar que sucedieron durante la iteración. Cada alumno o alumna está obligado a participar en esta reunión, explicando lo que hizo durante la iteración. La participación de cada miembro del grupo en esta reunión tiene un valor de 5%. Cada ScrumMaster deberá enviar la agenda de esta reunión al profesor, con copia al resto del equipo, a más tardar el Jueves que les toque exponer a las 4pm. Esta agenda tiene un valor de 5%. Esta es una exposición totalmente técnica, y no es necesario llevar filminas ni presentaciones en PowerPoint. La idea de de estas presentaciones es que sean como si le estuviesen mostrando el proyecto a algún compañero de trabajo o de la universidad, y no es una exposición de ventas. El profesor realizará consultas técnicas (de programación) y de uso de la metodología a todos los compañeros del grupo, para confirmar que todos hayan participado en todo el proceso. Uso del sistema de manejo y seguimiento de proyectos (RallyDev): 10% Cada equipo tendrá un proyecto configurado en RallyDev ( El profesor les enviará las credenciales para ingresar. Las historias de usuario y pruebas de aceptación serán escritas en clase en ejercicios grupales durante las primeras semanas del curso. Los casos de prueba corresponden al criterio de aceptación de cada historia, por lo que éstos serán revisados por el profesor en la liberación correspondiente generada por cada equipo. Es responsabilidad de cada alumno o alumna del grupo mantener la información actualizada en RallyDev, incluyendo el porcentaje de completitud de sus tareas asignadas. Es responsabilidad del profesor mantener actualizada la información de los resultados de la ejecución de los casos de prueba. Asimismo, de haber pulgas o errores, se publicará una pulga en y será asignada al dueño de la historia revisada. 6

7 Es responsabilidad del profesor hacer una reunión en clase con todo el grupo sobre los stories que deberán ser implementados en cada iteración, y evacuar dudas. Durante esta lección se llegará a un acuerdo en cada grupo de la complejidad en puntos de cada historia. Un punto es una unidad de tamaño y no tiempo o esfuerzo, y la idea es que sirva para distinguir cuando una historia es más grade o más pequeño que otro.. Asimismo, el profesor estará disponible por correo y por Google Talk con la dirección aarias@codefactorycr.com para evacuar dudas con la mayor prontitud posible. Durante el transcurso de cada iteración, durante las lecciones, el profesor seleccionará al azar 2 grupos en el aula y les pedirá que muestren el estado de su proyecto en RallyDev, y que además brinden un resumen (no más de 15 minutos por grupo) de cómo va el proyecto, cuantos requerimientos han sido aceptados y cuantos están pendientes. Cada revisión de estas tendrá un valor de 2.5%, y cada equipo tendrá un total de 2 revisiones durante el semestre. La estimación de la primera iteración se hará en clase con el profesor, pero las estimaciones de la segunda iteración deberán ser hechas por el equipo, utilizando los siguientes insumos: La complejidad en puntos definida durante la reunión en clase. La velocidad del equipo. Cada miembro del equipo debe registrar las horas por semana que le dedica al proyecto. Luego de la primera iteración, el profesor le dará a cada equipo el reporte de las horas dedicadas, y así podrá sacar la velocidad del equipo, que puede definirse como V = Puntos/hora de trabajo. La estimación de cada iteración deberá estar lista en RallyDev antes de las 4:59pm de la siguiente lección en la que arranque cada iteración. Cada estimación tiene un valor de 5% y debe incluir estimaciones de tiempos y asignación de stories para miembro del grupo. 7

8 Desglose de la Evaluación: Tema Rubro Valor Teoría Quices 35% Blog 10% Proyecto Individual Reportes de Avance 9% Reportes de Tiempo 9% SVN 4% Integración Continua 3% Proyecto Grupal Pruebas de Unidad 4% Liberaciones Periódicas 6% Reunión de Revisión y Retr. 10% Uso de RallyDev 10% Total: 100% Políticas Generales del Curso: En caso de atraso en cualquiera de los entregables de curso, se penalizará con un 10% del valor del entregable por cada día natural de atraso que pase. Por ejemplo, si el entregable tiene un valor de 4%, y se entrega 2 días tarde, la nota de la entrega será 4 20% = 3.2. Horas de Consulta: Por definir. 8