Evaluación de Métodos de Desarrollo
Procedimiento de Evaluación
La evaluación y calificación del proyecto integrado, en lo concerniente a la asignatura de Métodos de Desarrollo, se realizará en base a un esquema gamificado. De acuerdo con dicho esquema, existirán una serie de elementos evaluables, los cuales se evaluarán y calificarán varias veces a lo largo del desarrollo del proyecto integrado.
Cada elemento evaluable tendrá asociado una serie de puntos y estará ligado a una o más actividades. Por ejemplo, el elemento Relación con el Product Owner está vinculado a todas aquellas actividades donde el equipo de desarrollo tenga que interactuar con el Product Owner. Estas actividades, en concreto, serían Sprint Planning Meeting I, Product Backlog Refinement y Product Review. Estas concretas actividades se ejecutan una vez por sprint. Dado que el proyecto integrado se compone de tres sprints, este elemento evaluable concreto recibirá un total de nueve evaluaciones a lo largo del desarrollo del proyecto integrado.
Por cada evaluación de un elemento, se indicará a los alumnos qué han hecho bien, para que sigan potenciándolo, y en qué tendrían que mejorar, con objeto de que subsanen los errores cometidos. Cada corrección estará disponible siempre antes de la ejecución de la siguiente actividad donde se evalúe un determinado elemento, de manera que los alumnos puedan corregir los errores cometidos y mejorar así su calificación. Se espera que los alumnos traten de atender de alguna forma las sugerencias de mejora. A este respecto, merece la pena resaltar que, con carácter general, se penalizará especialmente la notificación reiterada de errores para los que no se observe la realización de esfuerzos para su erradicación o mitigación.
Dependiendo de la naturaleza de cada elemento, su calificación será común para todo el grupo o individual para cada alumno. Las actividades que son inherentemente grupales, como la ejecución de la técnica de Planning Poker, tendrán una calificación de grupo, mientras que actividades de naturaleza individual, como interpretar un Burndown Chart, tendrán una calificación individual. Para que un alumno pueda poder obtener los puntos otorgados al grupo por la realización de una actividad es necesario que éste alumno haya participado en dicha actividad. Es decir, si un grupo obtiene 35 puntos por la realización de un Planning Poker, para que un alumno pueda obtener esos 35 puntos, deberá haber participado en la ejecución de ese Planning Poker. Además, en el caso de las actividades de grupo, de manera excepcional, se podrán otorgar puntos extras individuales a aquellos alumnos que muestren un desempeño o rendimiento excepcional durante la realización de estas actividades.
Los casos correspondientes a circunstancias excepcionales, como que el alumno no pueda asistir a un Planning Poker porque haya sido citado a declarar como testigo en sede judicial, se analizarán y tratarán de manera individual, procurando encontrar una solución adecuada y razonable para cada uno de ellos. No obstante, merece la pena resaltar que los casos excepcionales deberían ser, como su nombre indica, extrañas e infrecuentes excepciones, y no escenarios habituales y cotidianos.
Para verificar que cada alumno ha estado participando activamente dentro su correspondiente equipo de trabajo, se realizará una vez concluidos los tres sprints del proyecto integrado un pequeño Test sobre Metodologías Ágiles. Dicho test tendrá entre 5 y 6 cuestiones cortas, de las cuales varias se deberían poder contestar sin ningún problema si se ha estado participando activamente en el desarrollo del proyecto integrado. Por tanto, si un alumno obtuviese una calificación inferior a 3 puntos sobre 10 en esta prueba, se entendería que el alumno no ha participado en el desarrollo del proyecto y, por tanto, su calificación es fruto del trabajo de sus compañeros y no de su buen hacer. Si se llegase a esta situación, se analizaría cada caso en cuestión para decidir como proceder, pero la calificación otorgada al alumno quedaría automáticamente anulada.
Destacar también que se velará porque cada miembro del equipo mantenga una actitud de colaboración y respeto con el resto de sus compañeros. La falta de respeto por parte de un miembro del equipo, durante el desarrollo de una actividad supondrá automáticamente una calificación de cero puntos en todos los elementos evaluables asociados a dicha actividad.
En el siguiente apartado se listan todos los elementos evaluables que se considerarán durante el desarrollo del proyecto integrado en lo concerniente a la asignatura de Métodos de Desarrollo, así como su valor en puntos. La suma de los puntos correspondientes a todas las actividades evaluables es de 930. La calificación final del alumno se obtendrá dividiendo los puntos obtenidos por el alumno por 90. Es decir, si un alumno obtiene una calificación final de 900 puntos, su calificación en el proyecto integrado será de 10. Cada elemento evaluable está enlazado con una descripción individual del mismo donde se detalla su criterio de evaluación concreto, si su calificación es individual o de grupo y las actividades del proyecto donde se llevará a cabo su evaluación.
Elementos Evaluables de Métodos de Desarrollo
# |
Elemento Evaluable |
Puntos |
|---|---|---|
00 |
60 |
|
01 |
90 |
|
02 |
60 |
|
03 |
40 |
|
04 |
20 |
|
05 |
20 |
|
06 |
20 |
|
07 |
20 |
|
08 |
40 |
|
09 |
60 |
|
10 |
60 |
|
11 |
40 |
|
12 |
40 |
|
13 |
60 |
|
14 |
60 |
|
15 |
90 |
|
16 |
30 |
|
17 |
40 |
|
18 |
20 |
|
19 |
60 |
Criterios de Evaluación Individualizados
Relación con el Product Owner
Calificación |
Común al grupo |
Actividades |
|
Este ítem mide la capacidad de cada grupo de ejercer labores de comercial o de relaciones públicas. Se evalúa con carácter general que el grupo se preocupe por crear un entorno agradable al Product Owner en el cual éste se sienta cómodo y se favorezca la comunicación con el equipo. En general, el Product Owner debe tener la sensación de que el equipo de trabajo es profesional, colaborativo y se preocupa por desarrollar un producto que se adecúe a sus necesidades. Además, al Product Owner le debe resultar fácil interactuar con el equipo de desarrollo, el cual debe ser capaz de explicar con claridad y efectividad las diferentes cuestiones técnicas que puedan surgir durante el desarrollo del proyecto.
De manera más concreta, los puntos de este ítem se otorgarán en función del grado de cumplimiento de los siguientes elementos:
El equipo de trabajo ha tratado al Product Owner con educación y respeto.
El equipo de trabajo ha sido puntual y el Product Owner no ha tenido que esperar al equipo de trabajo.
El Product Owner ha tenido facilidades para poder trabajar con el Scrum Team, como acceso adecuado a algún material donde poder escribir y elaborar bocetos.
El equipo de trabajo ha atendido de buen grado, o ha procurado atender, todas las ideas y sugerencias del Product Owner.
El equipo de trabajo ha planteado al Product Owner alternativas y sugerencias a las diferentes propuestas que hayan surgido durante el desarrollo del proyecto.
Los miembros del equipo de desarrollo intervienen en la actividad respetando los turnos de palabra y sin interrumpirse.
El Product Owner se ha sentido cómodo y adecuadamente atendido durante la realización de las diferentes actividades donde se precisa su participación.
Todos los miembros del equipo de trabajo interactúan, en mayor o menor grado, con el Product Owner.
Las intervenciones de los diferentes miembros del equipo son breves, concisas y precisas.
El equipo de trabajo es capaz de transmitir con claridad y precisión, sin entrar en detalles técnicos innecesarios, cuestiones relativas al funcionamiento de la aplicación, incidencias surgidas o decisiones adoptadas durante el desarrollo de la aplicación, entre otros elementos.
El incumplimiento del punto 1 podrá suponer automáticamente una calificación de cero puntos en este apartado. El incumplimiento del punto 2 supondrá una penalización de 1/4 de los puntos asignados a este elemento. Cada incumplimiento de los puntos 3, 4, 5 ó 6 supondrá una penalización de hasta 3/4 de los puntos asignados a este elemento. Cada incumplimiento de los puntos 7, 8, 9 ó 10 supondrá una penalización de hasta 1/4 de los puntos asignados a este elemento, sin que se pueda acumular por cada punto una penalización superior a 1/2 de los puntos asignados a este apartado.
Nota
Mientras dure la crisis sanitaria asociada a la Covid-19, se valorará porque el equipo de trabajo se esfuerce por mantener un entorno seguro desde el punto de vista sanitario que minimice el riesgo de contagio del Product Owner.
Peligro
La falta de respeto al Product Owner supondrá automáticamente una calificación de cero en este apartado, pudiendo además acarrear una penalización extra adicional.
Nota
Recordad que el Product Owner no tiene por qué tener conocimientos técnicos de las tecnologías que estáis usando para desarrollar el producto. Por tanto, es mejor evitar nombres técnicos que podría desconocer, como toast o spinner.
Capacidad de Planificación
Calificación |
Común al grupo |
Actividades |
|
Este ítem mide la capacidad del equipo de desarrollo para organizar de manera adecuada las actividades que impliquen la participación del Product Owner, de manera que esas actividades se puedan ejecutar de manera efectiva, es decir, que resulten breves y productivas. Para ello, se verificará más concretamente que:
Cada actividad ejecutada que precise la participación del Product Owner haya sido previamente planificada por el equipo de trabajo.
La planificación realizada sea adecuada para el objetivo de la actividad.
La planificación de la actividad sólo incluye actividades que sean pertinentes para esa actividad.
La agenda de la actividad se haya dado a conocer al Product Owner.
No haya sido necesario improvisar durante el desarrollo de la actividad como consecuencia de una mala planificación.
El Scrum Team sea quien haya coordinado y dirigido la actividad desde el inicio, evitando así que el Product Owner se haya visto forzado a asumir esta responsabilidad.
El Product Owner no haya estado ocioso o desocupado durante el desarrollo de la actividad.
La planificación haya permitido ejecutar la actividad de manera breve y productiva.
El coordinador de la actividad haya velado porque las intervenciones de los diferentes miembros del equipo sean breves.
El incumplimiento del primer punto supondrá automáticamente una calificación de cero puntos en este apartado. El incumplimiento del segundo punto supondrá una penalización de hasta 3/4 de los puntos asignados a este apartado. El incumplimiento de los puntos tercero, cuarto, quinto, sexto y séptimo impedirá obtener más de la mitad de los puntos asignados a este elemento. En concreto, se penalizará especialmente el incumplimiento del tercer punto.
Ortografía, Gramática y Maquetación
Calificación |
Común al grupo |
Actividades |
|
Para la evaluación de este elementos se comprobará que los diferentes artefactos entregados, como por ejemplo, las especificaciones de historias de usuario, estén libres de errores ortográficos, gramaticales, tipográficos o de formato. Por errores de formato se entienden cuestiones como párrafos con distinto tipo de letra o márgenes diferentes.
Con carácter general, se restarán 10 puntos por cada error ortográfico, gramatical o tipográfico encontrado. Errores ortográficos de gravedad, como escribir envase a en lugar de en base a podrán computarse como fallos dobles, triples o incluso suponer directamente una calificación de cero puntos para este elemento, en función de gravedad y frecuencia de los fallos detectados.
Conformidad del Product Backlog
Calificación |
Común al grupo |
Actividades |
|
Tras realizar cualquier actividad que implique la modificación del Product Backlog, se comprobará que el Product Owner no eche en falta ningún elemento dentro del mismo, así como que los elementos incluidos sean conformes a la indicado por el Product Owner. Para ello, más concretamente, verificará que:
El Product Owner no echa en falta dentro del Product Backlog ninguna historia de usuario o ticket de cambio que éste haya solicitado incluir.
El Product Backlog no contiene ninguna historia de usuario o ticket de cambio que el Product Owner haya solicitado incluir.
El Product Owner considera adecuado el valor de negocio asignado de cada historia de usuario o ticket de cambio.
La descripción de cada historia de usuario o ticket de cambio es conforme a lo especificado por el Product Owner.
El Product Owner no echa en falta ningún criterio de confirmación para los elementos del Product Backlog que hayan sido negociados para su inclusión en un determinado sprint.
No exista ningún elemento dentro de la descripción de los elementos del Product Backlog que sea decisión propia del equipo de trabajo y no hayan sido consensuados con el Product Owner.
Por cada violación de la lista de comprobación anterior se disminuirán en 10 los puntos otorgados a cada equipo. Además, si el Product Owner considerase que la violación se produce sobre un elemento esencial para el desarrollo del producto, y de cuya esencialidad se ha advertido explícitamente al grupo, no se podrán obtener más de la mitad de los puntos asignados a este apartado.
Especificación de las Historias de Usuario
Calificación |
Común al grupo |
Actividades |
|
En este apartado se evaluará que las historias de usuario existentes dentro del Product Backlog estén especificadas de manera correcta. Para no tener que evaluar el Product Backlog completo, que sería una tarea excesiva, se utilizarán para esta evaluación las historias de usuario seleccionadas para ser desarrolladas en un sprint durante los Sprint Planning Meeting I y las historias de usuario que se incorporen como nuevas al Product Backlog como resultado de un Product Backlog Refinement.
La corrección de las historias de usuario se verificará tanto a nivel sintáctico como a nivel semántico. A nivel sintáctico se verificará que cada historia de usuario contenga los elementos que deba contener y que estos elementos estén en el formato correcto. A nivel semántico se comprobará que el valor de esos elementos tenga sentido dentro del proyecto que se está desarrollando.
Para la verificación de los aspectos sintácticos se comprobará que:
Cada historia de usuario tiene un nombre.
El nombre de cada historia de usuario comienza por un verbo.
Cada historia de usuario tiene asignada una descripción.
La descripción de cada historia de usuario sigue el formato Yo, como <rol>, quiero <requisito> de manera que <objetivo>.
Cada historia de usuario tiene asignado su bussines value.
Cada historia de usuario tiene estimado su esfuerzo en puntos.
Para la verificación de los aspectos semánticos se comprobará que:
El nombre de cada historia de usuario es coherente con su descripción.
El nombre de cada historia de usuario describe adecuadamente su comportamiento.
Cada historia de usuario describe una funcionalidad atómica de la aplicación, es decir, no se puede descomponer con facilidad en historias de usuario de menor tamaño.
Cada historia de usuario no contiene dependencias innecesarias con otras historias de usuario.
Los puntos de esfuerzo asociados a cada historia de usuario son coherentes con la escala establecida y con los valores asignados a otras historias de usuario.
La descripción de cada historia de usuario es breve y concisa.
La descripción de cada historia de usuario no es compleja de entender.
El rol de cada historia de usuario está correctamente identificado.
El objetivo de la descripción de cada historia de usuario no es una simple consecuencia de su acción.
El objetivo de la descripción representa con claridad qué espera obtener el usuario al ejecutar dicha acción.
Los mock-ups, bocetos o diagramas de cualquier clase generados durante la negociación de una historia de usuario con el Product Owner se hayan añadido como elementos adjunto a la tarjeta de la correspondiente historia de usuario.
Para poder obtener al menos la mitad de los puntos de este elemento, no debe existir ningún error de tipo sintáctico en las historias de usuario evaluadas y menos de un error semántico por cada historia de usuario.
Nota
Se valorará positivamente que cada historia de usuario tenga asignado su valor para el modelo de Kano.
Completitud de los Test de Aceptación
Calificación |
Común al grupo |
Actividades |
En este apartado se valorará la completitud de los criterios de confirmación especificados durante la negociación de las historias de usuario dentro de la actividad de Sprint Planning Meeting I. Más concretamente, se verificará que:
Exista un criterio de confirmación para el caso de éxito consensuado con el Product Owner.
Existan criterios de confirmación consensuados con el Product Owner para tratar las posible entradas de datos no válidos.
Existan criterios de confirmación consensuados con el Product Owner para tratar posibles pérdidas de conexión a red.
Existan criterios de confirmación consensuados con el Product Owner para tratar posibles errores en el acceso servicio de datos.
Existan criterios de confirmación consensuados con el Product Owner para tratar posibles errores en el acceso a los sistemas de persistencia de datos.
Existan criterios de confirmación consensuados con el Product Owner para tratar resultados de operaciones que puedan considerarse anómalos, como filtrados de elementos que retornen listas vacías.
Existan criterios de confirmación consensuados con el Product Owner para tratar situaciones que puedan considerarse anómalas, como la ausencia de fecha en ciertos elementos de una colección a la hora de ordenar dicha colección por fecha.
Para poder obtener al menos la mitad de los puntos de este apartado, no se deberá violar ninguno de los cinco primeros puntos. Se considera importante aclarar que cualquier criterio de confirmación no consensuado con el Product Owner se considerará como no especificado. Es decir, es lo mismo que si no estuviese.
Nota
Qué se considera exactamente una entrada inválida debe estar especificado en algún sitio dentro de la tarjeta de la historia de usuario. Puede estar bien dentro del propio criterio de confirmación o bien como una nota adjunta.
Especificación de los Tickets de Cambio
Calificación |
Común al grupo |
Actividades |
En este apartado se evaluará que los tickets de cambio que se incorporen al Product Backlog tras una Product Review estén correctamente especificados. La corrección de las tickets de cambio se verificará tanto a nivel sintáctico como a nivel semántico. A nivel sintáctico se verificará que cada ticket de cambio contenga los elementos que deba contener y que estos elementos estén en el formato correcto. A nivel semántico se comprobará que el valor de esos elementos tenga sentido dentro del proyecto que se está desarrollando.
Para la verificación de los aspectos sintácticos se comprobará que:
Cada ticket de cambio tiene un nombre.
Cada ticket de cambio tiene asignada una descripción.
La descripción de cada ticket de cambio describe en sus primeros párrafos el problema concreto a resolver.
La descripción de cada ticket de cambio describe tras el problema a resolver la solución a adoptar, en un párrafo o párrafos separados.
Cada ticket de cambio tiene asignado su bussines value.
Cada ticket de cambio tiene estimado su esfuerzo en puntos.
Para la verificación de los aspectos semánticos se comprobará que:
El nombre de cada ticket de cambio es coherente con su descripción.
El nombre de cada ticket de cambio describe adecuadamente su contenido.
El nombre de cada ticket de cambio es breve.
Cada ticket de cambio describe una modificación atómica que no se puede descomponer con facilidad en tickets de menor tamaño.
Los puntos de esfuerzo asociados a cada ticket de cambio son coherentes con la escala establecida y con los valores asignados a otras elementos del Product Backlog.
La descripción de cada ticket de cambio es breve, concisa y precisa.
La descripción de cada ticket de cambio no es compleja de entender.
Para poder obtener al menos la mitad de los puntos de este elemento, no debe existir ningún error de tipo sintáctico en los tickets de cambio evaluados y menos de un error semántico por cada ticket de cambio.
Creación del Sprint Backlog
Calificación |
Común al grupo |
Actividades |
En este ítem se valorará que la selección de elementos del Product Backlog para ser desarrollados dentro de un sprint concreto se haya realizado de manera correcta. Para verificar la corrección de esta selección, se verificarán los siguientes elementos:
La selección realizada cuenta con la aprobación y conformidad del Product Owner.
La suma de los valores de esfuerzo de los elementos del Product Backlog seleccionados se ajusta de manera adecuada a la velocidad de equipo.
No existe una selección alternativa de elementos del Product Backlog que, ajustándose a la velocidad del equipo, permita obtener un mayor bussines value para el producto.
El incumplimiento de uno de los dos primeros puntos, o el incumplimiento de manera obvia del tercer punto, supondrá una calificación de cero puntos en este apartado.
Planificación de Tareas
Calificación |
Común al grupo |
Actividades |
En este apartado se evaluará la corrección de la descomposición de tareas creada para desarrollar cada elemento del Product Backlog seleccionado. Para ello, se verificarán que:
cada descomposición de un elemento del Product Backlog sea correcta;
las tareas creadas en cada descomposición estén correctamente especificadas;
la carga de trabajo asignada a cada miembro del equipo de trabajo está equilibrada con respecto a sus compañeros;
la asignación de tareas permita un ritmo de trabajo constante y sostenible para cada miembro del equipo a lo largo del sprint.
Para evaluar la corrección de la descomposición en tareas realizada se verificará que:
Cada elemento de la definición de completado tiene al menos una tarea que implica su ejecución.
Ninguna tarea pueda ser descompuesta fácilmente en subtareas independientes.
Para evaluar la corrección sintáctica de las tareas creadas se verificará que:
Cada tarea tiene un nombre.
Cada tarea tiene especificado una estimación de su esfuerzo en horas.
Cada tarea está asignada a un miembro del equipo.
Cada tarea tiene asociada una breve descripción que especifica tanto el objetivo de la tarea como toda aquella información que se considere relevante para la realización de la misma. Una excepción a este punto son las tareas repetitivas y bien conocidas [1].
Para evaluar la corrección semántica de las tareas creadas se verificará que:
El nombre de cada tarea es significativo.
La descripción de cada tarea es correcta desde un punto de vista técnico.
La descripción de la tarea permite entender con facilidad su objetivo, los pasos a realizar y los resultados a generar.
Para evaluar el equilibrio de la carga de trabajo se verificará que, dentro del sprint que se esté evaluando, la carga de trabajo de cada miembro del equipo sea similar a la de sus compañeros en proporción de lo que le corresponda en función de las normas para calcular cargas de trabajo. Es decir, si hay miembros del equipo con una capacidad máxima de 36 horas de trabajo cada uno, y tareas asignadas a cada uno con un valor total en torno a las 30 horas de trabajo, lo que representaría aproximadamente un 80% de la capacidad total de trabajo de estos miembros, entonces un miembro con 16 horas como capacidad máxima de trabajo debería tener asociadas en ese sprint tareas por valor total de aproximadamente 13 horas de trabajo, lo que representaría alrededor del 80% de la capacidad máxima de trabajo de esta persona.
Por último, para evaluar que la asignación de tareas permita un ritmo de trabajo constante y sostenible se verificará que miembros del equipo puedan trabajar en paralelo sin mayores problemas. Para ello, se comprobará principalmente que no existan miembros del equipo trabajo que estén ociosos en determinadas fases del desarrollo del sprint. Un trabajador temporalmente ocioso sería alguien no tenga apenas tareas que realizar en la segunda semana de un sprint.
Cada violación del punto a, se penalizará con 1/2 de asignados a este elemento evaluable. Si el punto b se viola un número de veces igual o superior al número de elementos del Product Backlog seleccionado, la calificación de este apartado será inferior a la mitad de los puntos que tenga asignados.
La violación en cualquiera de los puntos c a e supondrá una supondrá una penalización de la mitad de los puntos asignados a este elemento evaluable. La violación del punto f una supondrá una penalización de un cuarto de los puntos asignados a este elemento evaluable.
La violación de los puntos g a i sólo podrá suponer una pérdida de puntos superior a la mitad de los puntos asignados a este elemento cuando se perciba una manifiesta dejadez en la redacción de las descripciones y en la asignación de los nombres.
La violación del punto 3 supondrá una penalización de aproximadamente 1/3 de los puntos asignados a este elemento evaluable. Finalmente, cada violación del punto 4 supondrá una penalización de aproximadamente 1/4 de los puntos asignados a este elemento evaluable.
Ejecución del Planning Poker
Calificación |
Común al grupo |
Actividades |
|
En este apartado se evaluará que cada Scrum Team sea capaz de ejecutar un Planning Poker con corrección. Para ello, se verificará el grado de cumplimiento de los siguientes elementos:
Cada miembro equipo tiene una baraja de cartas para planning poker.
La sesión de Planning Poker está moderada.
Las barajas utilizadas por los diferentes miembros del Scrum Team son homogéneas.
El escenario utilizado para la ejecución del Planning Poker facilita la ejecución de la actividad.
En caso de votaciones dispares, el Scrum Team procede siempre a debatir las estimaciones dispares.
Los debates de las estimaciones dispares siempre incluyen al menos un representante de las opciones más dispares. Por ejemplo, en el caso de estimaciones con valor 2, 5, 5, 5 y 8, deberán intervenir, al menos, los responsables de las estimaciones con valor 2 y 8.
Se vuelva a votar de nuevo siempre que se debatan estimaciones.
Todas las intervenciones se hacen previa concesión del turno de palabra por parte del moderador, sin interrumpir a otros compañeros.
Las justificaciones de cada estimación no hacen referencia a intervenciones de otros miembros.
La moderación de la sesión es adecuada.
Todas las intervenciones de los miembros del Scrum Team tratarán de ser breves y precisas.
Los diferentes miembros del equipo mantiene una actitud negociadora y no se enrocan en opiniones particulares.
El incumplimiento de los puntos 1 ó 2 supondrá una calificación de cero puntos en este apartado. Los incumplimientos de los puntos 3 ó 4 supondrán una penalización de 2/3 de los puntos asignados a este apartado. Cada violación de los puntos 5, 6 ó 7 se penalizarán con 1/3 de los puntos asignados a este apartado. Cada violación de los puntos 8 ó 9 se penalizarán con 1/4 de los puntos asignados a este apartado. Finalmente, las penalizaciones asociadas a los puntos 10, 11 y 12 no podrán suponer más de la mitad de los puntos asignados a este apartado.
Ejecución de los Daily Scrum Meeting
Calificación |
Común al grupo |
Actividades |
En este apartado se evaluará que cada Scrum Team sea capaz de ejecutar un Daily Scrum Meeting con corrección. Para ello, se verificará que el grado de cumplimiento de los siguientes elementos:
El Daily Scrum Meeting ha estado coordinado.
La dinámica de los Daily Scrum Meeting está interiorizada por cada miembro del equipo y no hace falta explicarla al inicio de cada reunión.
Cada intervención de un miembro del equipo ha seguido el formato qué hice ayer, qué voy a hacer hoy, qué problemas he encontrado o qué necesidades de coordinación tengo.
Las posibles soluciones a los problemas comunes se han debatido al final de las intervenciones individuales, y no durante las mismas.
Por cada problema o necesidad de coordinación reportado, se ha elaborado una plan de acción para resolverlo [2].
En caso de que un miembro del equipo no haya encontrado problemas, lo hace saber explícitamente durante su intervención.
Cada intervención se ha desarrollado de manera precisa y sintética.
El incumplimiento del punto 1 supondrá una calificación de cero puntos en este apartado. Las violación del punto 2 supondrá una penalización de 2/3 de los puntos asignados a este apartado. Cada violación de los puntos 3, 4 ó 5 se penalizará con 1/3 de los puntos asignados a este apartado. Cada violación del punto 6 se penalizará con 1/4 de los puntos asignados a este apartado. Finalmente, cada violación del punto 6 se penalizará con entre 5 y 10 puntos, hasta un máximo de la mitad de los puntos asignados a este apartado.
Gestión de las Tareas y del Tablero Kanban
Calificación |
Individual |
Actividades |
En este apartado se evaluará que cada miembro de un Scrum Team sea capaz tanto de gestionar correctamente las tareas definidas dentro del tablero Kanban del equipo como de interpretar de manera adecuada el estado de dicho tablero Kanban. Para ello, se verificará el grado de cumplimiento de los siguientes elementos:
El alumno conoce las reglas de gestión de tablero Kanban.
El alumno es capaz de mover las tarjetas dentro de Scrumdesk de acuerdo con las normas de gestión del tablero Kanban.
El alumno es capaz de modificar correctamente los valores de estimated, spent y remanining de sus tareas.
El alumno es capaz de interpretar correctamente los valores de estimated, spent y remanining de cualquier tarea del sprint.
El alumno es capaz de explicar correctamente el por qué de los valores de estimated, spent y remanining asignados a sus tareas.
El incumplimiento del punto 1 supondrá una calificación de cero puntos en este apartado. Cada violación de los puntos 2, 3 y 4 supondrá una penalización de 1/3 de los puntos asignados a este apartado. Cada violación del punto 5 se penalizará con 1/4 de los puntos asignados a este apartado.
Interpretación del Sprint Burndown Chart
Calificación |
Individual |
Actividades |
En este apartado se evaluará que cada miembro de un Scrum Team sea capaz, mediante la utilización del Sprint Burndown Chart, tanto de argumentar cómo ha sido la evolución del sprint hasta la fecha, como de predecir cómo será el esfuerzo a realizar para poder terminar el sprint a tiempo. Para ello, se verificará que:
El alumno sea capaz de abrir el Sprint Burndown Chart.
El alumno sea capaz de utilizar la escala adecuada para razonar sobre la evolución del sprint.
El alumno sea capaz de estimar cuál sería la fecha de finalización prevista para cualquier día del sprint.
El alumno sea capaz de distinguir entre progreso efectivo y horas trabajadas
El alumno sea capaz de explicar el por qué de la pendiente de la gráfica entre dos días concretos del sprint.
El alumno sea capaz de razonar si el sprint se podrá terminar en fecha bien o es necesario hacer un esfuerzo extra.
El alumno sea capaz de decir cuántas horas de trabajo restan para la finalización del sprint.
El incumplimiento de los puntos 1 ó 2 supondrá una calificación de cero puntos en este apartado. Cada violación de los puntos 2, 3, 4, 5, 6 ó 7 supondrá una penalización de 1/3 de los puntos asignados a este apartado.
Gestión de la Configuración
Calificación |
Común al grupo |
Actividades |
En este apartado se evaluará que el equipo respete tanto la política de gestión de la configuración como la estructura de los repositorios. Para ello se verificará que el grupo no haya violado ninguna de las normas proporcionadas para estos dos elementos.
Cada incumplimiento de de una de estas normas supondrá una penalización de 1/3 de los puntos asignados a este apartado.
Cumplimiento de la Definición de Completado
Calificación |
Común al grupo |
Actividades |
En este ítem se evaluará que el desarrollo de cada elemento del Product Backlog incluido dentro de un sprint determinado satisfaga la definición de completado.
Cada incumplimiento de un punto entero de la definición de completado supondrá una penalización de 2/3 de los puntos asignados a este apartado. Este sería el caso, por ejemplo, en el que una historia de usuario desarrollada carezca de su correspondiente informe de calidad.
Cada incumplimiento parcial de un punto de la definición de completado supondrá una penalización de 1/3 de los puntos asignados a este apartado. Este sería el caso, por ejemplo, en el que faltase implementar una prueba de las definidas para una historia de usuario a desarrollar.
Satisfacción del Product Owner
Calificación |
Común al grupo |
Actividades |
En este apartado se evaluará tanto la adecuación del producto desarrollado a las expectativas y deseos iniciales del Product Owner como la confianza y seguridad que el equipo de desarrollo sea capaz de transmitir al Product Owner durante el desarrollo del sprint. Se trata de una calificación en gran parte subjetiva que dependerá de las sensaciones que el equipo de desarrollo haya transmitido al Product Owner durante el desarrollo del sprint. La calificación representa, en cierta forma, la percepción que tenga en Product Owner del equipo de desarrollo como un grupo de profesionales cualificados que son capaces de crear un producto en tiempo y forma acorde a sus necesidades reales.
Si el Product Owner se considera muy satisfecho, la calificación en este apartado será siempre superior a los 3/4 de los puntos asignados a este apartado. Si el Product Owner se considera satisfecho, la calificación en este apartado será siempre superior a 1/2 de los puntos asignados a este apartado, e inferior a los 3/4. Si el Product Owner se considera algo insatisfecho, la calificación en este apartado será siempre inferior a 1/2 de los puntos asignados a este apartado, pero superior a 1/4. Por último, si el Product Owner se considera muy insatisfecho, la calificación en este apartado será inferior a 1/4 de los puntos asignados a este apartado.
En el último sprint, la calificación de este ítem vendrá determinada fundamentalmente por la capacidad del equipo de atender las sugerencias de mejora realizadas por el *Product Owner en los sprints anteriores.
Ejecución de la Retrospectiva
Calificación |
Común al grupo |
Actividades |
En este ítem se evaluará que la retrospectiva de un determinado sprint haya estado correctamente organizada y ejecutada. Para ello, el grupo deberá haber seleccionado una dinámica de grupo orientada a la generación de ideas y haber ejecutado dicha dinámica correctamente de acuerdo con sus reglas. Para ello, se prestará especial atención a que:
La retrospectiva haya estado planificada.
La retrospectiva haya estado coordinada.
La dinámica seleccionada para ejecutar la retrospectiva sea adecuada.
La dinámica se haya desarrollado conforme sus reglas.
Los miembros del equipo hayan mostrado una actitud profesional durante toda la dinámica que favorezca la productividad y efectividad de la actividad.
Los miembros del equipo se hayan esforzado por realizar intervenciones precisas y sintéticas.
El incumplimiento de los puntos 1 ó 2 supondrá una calificación de cero puntos en este apartado. El incumplimiento del punto 3 supondrá una penalización de hasta 2/3 de los puntos asignados a este apartado. Cada violación del punto 4 supondrá una penalización de 1/4 de los puntos asignados a este apartado. Las violaciones del punto 5 podrán suponer, como máximo, una penalización global de hasta 1/3 de los puntos asignados a este apartado.
Resultados de la Retrospectiva
Calificación |
Común al grupo |
Actividades |
En este ítem se evaluará que, como resultado de ejecutar cada retrospectiva se generen planes de acciones adecuados para un número adecuado de aspectos tanto positivos como negativos a potenciar o mitigar durante el siguiente sprint. Para ello, se prestará especial atención a que:
Los resultados de la retrospectiva sean conformes a la plantilla proporcionada.
Los aspectos positivos y negativos identificados durante las retrospectivas contengan elementos que durante el desarrollo del sprint haya resultado obvio [3] que eran beneficiosos o perjudiciales.
El número de aspectos tanto positivos como negativos identificados es amplio. Con carácter general, se considerará un número suficientemente amplio cuando haya al menos un aspecto positivo y un aspecto negativo identificado por cada miembro de un equipo; y un número adecuadamente amplio cuando haya al menos un aspecto positivo o un aspecto negativo por cada miembro del grupo.
Los planes de acción tanto para los aspectos positivos como negativos contienen acciones concretas a realizar en el siguiente sprint y no se quedan en simples propósitos de año nuevo.
El plan de acción cada aspecto positivo o negativo contiene una solución coherente que permite potenciar o mitigar, respectivamente, dicho aspecto.
La descripción de cada aspecto positivo o negativo sea correcta y fácil de entender.
La descripción de cada aspecto positivo o negativo es precisa y sintética.
El incumplimiento del punto 1 supondrá una calificación de cero puntos en este apartado. Cada violación del punto 2 supondrá una penalización de 1/2 de los puntos asignados a este apartado. Respecto al punto 3, cuando el número de aspectos identificados se considere suficientemente amplio no se aplicará penalización alguna. Cuando el número de aspectos identificados sea simplemente adecuadamente amplio se aplicará una penalización de 1/3 de los puntos asignados a este apartado. Cuando el número de aspectos identificados no se pueda considerar adecuadamente amplio, se aplicará una penalización de 3/4 de los puntos asignados a este apartado.
Cada violación del punto 4 ó 5 supondrá una penalización de 1/8 de los puntos asignados a este apartado. Finalmente, cada violación de los puntos 6 ó 7 supondrá una penalización de 1/10 de los puntos asignados a este apartado, no pudiendo exceder el total de estas penalizaciones 1/2 de los puntos asignados a este apartado.
Manual de Usuario
Calificación |
Común al grupo |
Actividades |
Este ítem evalúa la claridad y corrección del manual de usuario creado para historia de usuario desarrollada. Para ello, se verificará que:
Por cada historia de usuario exista una entrada adecuada en el manual de usuario donde se explique el funcionamiento de dicha historia de usuario.
En el caso de manuales escritos, las capturas de pantalla indican claramente, de manera resaltada, los lugares referenciados desde el texto.
En el caso de manuales en formato vídeo, se puede ver con precisión qué acciones hay que realizar.
La calidad de las imágenes es adecuada y favorece su legibilidad.
Las descripciones proporcionadas son fáciles de seguir y entender.
Las descripciones proporcionadas son precisas y sintéticas.
El incumplimiento del punto 1 supondrá una calificación de cero puntos en este apartado. Cada violación de los puntos 2, 3 ó 4 supondrá una penalización de 1/3 de los puntos asignados a este apartado. Cada tres violaciones de los puntos 5 ó 6 supondrán una penalización de 1/3 de los puntos asignados a este apartado.
Test sobre Metodologías Ágiles
Calificación |
Común al grupo |
Actividades |
Prueba Escrita |
Una vez finalizado los sprints, se realizará una pequeña prueba escrita con dos objetivos separados: (1) confirmar que cada alumno ha participado de manera activa en el desarrollo del proyecto integrado y no se ha limitado a vivir del trabajo de sus compañeros de equipo; y, (2) verificar que el alumno entiende ciertos principios de las técnicas ágiles.
Para verificar estos dos objetivos, el alumno deberá responder a 6 preguntas cortas elaborando para ello un cierto razonamiento. Algunas de estas preguntas se podrán responder fácilmente a partir de la experiencia adquirida durante el desarrollo del proyecto integrado ya que se referirán a acciones que el alumno, en caso de que haya participado activamente en el proyecto, deberá haber ejecutado en diversas ocasiones. Otras preguntas cuestionarán el porqué de ciertas prácticas ágiles, sirviendo para demostrar que el alumno además de haber realizado ciertas actividades, comprende el fundamento del por qué esas actividades son como son, no habiéndose limitado simplemente a seguir órdenes como si de un autómata se tratase.
Una calificación inferior a 3 en esta prueba indicaría que el alumno o bien no ha participado activamente en el proyecto integrado, habiéndose simplemente beneficiado del trabajo de sus compañeros; o bien ha adquirido un muy escaso conocimiento de las técnicas de desarrollo ágil, o ambas cosas a la vez. En cualquier caso, si se diese esta situación, el alumno tendría el proyecto integrado temporalmente suspenso, hasta que el equipo docente analice en detalle la situación y decida sobre la solución más adecuada para cada caso en particular.