Esto es porque considera que hay personas que están directamente comprometidas con el desarrollo y otras que únicamente están implicadas.

Esto es porque todas las metodologías ágiles preescriben necesariamente roles entre sus integrantes.

Todas son correctas.

El objetivo de Scrum, y en general de cualquier metodología ágil, no es dar garantías de previsibilidad sobre un plan previo, sino aportar el mayor valor posible en cada iteración y de forma continua.

Scrum, al ser una metodología ágil, considera que es más interesante la respuesta al cambio, por encima del seguimiento de un plan. Por tanto, no utiliza ningún tipo de planificación ya que emplea iteraciones muy cortas.

Scrum hace uso de planificación poco detallada, cuya principal regla es trabajar siempre según las prioridades acordadas con el cliente.

Es imprescindible que el cliente participe en todas las reuniones que plantea la metodología. De esta manera podremos saber si se están alcanzando los objetivos del proyecto.

Es muy importante establecer reuniones al finalizar cada Sprint. De esta manera podemos evaluar el estado real del proyecto y anticipamos el fracaso.

Tanto el Scrum Manager como todo el equipo de desarrolladores deben participar diariamente en una reunión breve que les permita conocer el estado actual de todo el proyecto.

Es de gran ayuda a la hora de realizar un seguimiento diario de un Sprint, al indicarnos el total de días restantes para finalizar nuestro proyecto.

Permite que el Product Owner pueda realizar un seguimiento diario de las distintas historias de usuario que faltan por realizar durante un Sprint.

Ninguna es correcta.

Basada en una planificación previa detallada.

Desarrollo iterativo e incremental.

El cliente está integrado en el proyecto.

Simplicidad en el diseño para agilizar el desarrollo y facilitar el mantenimiento.

Asegurar que los desarrolladores siguen la metodología fielmente y que el producto tiene la calidad suficiente como para ser entregado al cliente.

Realizar la planificación del desarrollo, estableciendo una serie de hitos, actividades y entregas del proyecto, y controlando que los desarrolladores sigan el plan.

La planificación dentro de un equipo de XP la realizan los programadores. Es por esta razón por la que esta metodología no incorpora este rol dentro del equipo de trabajo.

Facilitar la comunicación dentro del equipo de trabajo, coordinar la comunicación con los clientes y sincronizar la planificación con lo que está ocurriendo en la realidad.

Ivar Jacobson

Ken Schwaber

Jim Highsmith

Kent Beck

La metodología Scrum, si bien es una de las más conocidas de entre las que promueven el agilismo, no fue la primera metodología ágil.

Los orígenes de Scrum se remontan a la década de los ochenta, cuando Jeff Sutherland y Ken Schwaber realizaron un estudio sobre los principales problemas que existían, en ese momento, en diferentes empresas de desarrollo software.

La metodología Scrum, si bien nació en la década de los noventa, no se formalizó hasta el año 2001 tras la firma del manifiesto ágil.

Ayudar a los usuarios a escribir historias, evaluar la forma de utilizar el sistema desplegado, con el fin de encontrar nuevas historias, y refinar las interfaces de usuario.

Diseñar las interacciones entre los distintos subsistemas del software. Esto es importante para que cada equipo pueda trabajar de forma independiente.

No existe este rol en el equipo de trabajo de XP.

Definir el diseño del software de forma incremental. Para esto, se reúnen con otros diseñadores y programadores, y determinan los aspectos a mejorar del diseño.

Ayudar a los usuarios a escribir historias, evaluar la forma de utilizar el sistema desplegado, con el fin de encontrar nuevas historias, y refinar las interfaces de usuario.

Diseñar las interacciones entre los distintos subsistemas del software. Esto es importante para que cada equipo pueda trabajar de forma independiente.

No existe este rol en el equipo de trabajo de XP.

Definir el diseño del software de forma incremental. Para esto, se reúnen con otros diseñadores y programadores, y determinan los aspectos a mejorar del diseño.

Las integraciones se realizan de acuerdo a la planificación mensual que haya realizado el equipo de desarrollo, estableciendo una serie de fechas concretas durante el desarrollo del proyecto

Las integraciones se realizan al finalizar cada iteración, justo antes de entregar el producto al cliente, de manera que los desarrolladores tengan tiempo de finalizar todas las tareas que tienen asignadas

Las integraciones se realizan en ciclos de tiempo cortos, persiguiendo que todos los días, o incluso cada pocas horas, se obtenga una versión actualizada del producto.

El equipo completo, al finalizar el día de trabajo, realiza la reunión de integración del código, donde verifican que las partes desarrolladas por cada una de las pareja compilan perfectamente

1999

2009

2003

2004

Respuesta ante el cambio sobre documentación exhaustiva.

Respuesta ante el cambio sobre negociación contractual.

Respuesta ante el cambio sobre seguir un plan.

El Scrum Master

El Product Owner

El equipo de desarrollo

El Product Owner, siendo responsabilidad del Scrum Master asegurar que ningún otro rol comprometido con el proyecto exprese su opinión al respecto de estas prioridades.

El Product Owner, quien podrá ser aconsejado por cualquier otro miembro del equipo, siempre y cuando la decisión final sea de éste.

El Scrum Master ya que es quien debe asegurar el correcto uso de la metodología.

De esta manera el equipo es el responsable final de su propio trabajo. Así se fortalece el compromiso de finalizar un Sprint en la fecha fijada cumpliendo todos los objetivos asumidos.

Así los desarrolladores pueden responder como equipo y no como personas individuales, fortaleciendo el trabajo colaborativo.

Todas las respuestas son correctas.

No existe esta práctica en XP

Analizar los fallos que ocurren cuando se realiza la integración diaria y se ejecutan las pruebas de aceptación. El objetivo de este análisis es generar un informe donde se detallen los posibles errores que se hayan detectado.

Informar a los directivos de cuál es el porcentaje de errores que aparecen en el software desplegado. Esto sirva para analizar la calidad del producto y es necesario para determinar cuándo el software está listo para ser utilizado

Tener registrado los fallos que ocurren cuando no pasa una prueba. La mayoría de las herramientas de pruebas tienen un registro (log) donde se vuelva un resumen de los fallos ocurridos al ejecutar las pruebas

Las gráficas BurnDown, la gráfica Burn Up y el de un tablón que represente el estado de las historias y tareas de la pila de producto. Scrum no obliga a usar estar herramientas sino que destaca su gran utilidad.

Las gráficas BurnDown, la gráfica Burn Up y el de un tablón que represente el estado de las historias y tareas de la pila de Sprint durante el desarrollo de éste. Scrum considera obligatorio hacer uso de estas herramientas.

Las gráficas BurnDown, la gráfica Burn Up y el de un tablón que represente el estado de las historias y tareas de la pila de Sprint durante el desarrollo de éste. Scrum no obliga a usar estas herramientas, sino que destaca su gran utilidad.

No hay un período concreto establecido, aunque se recomienda que se realice en plazos de tiempo cortos, incluso de pocas horas. Esto permite que haya una mayor comunicación y realimentación dentro del equipo de trabajo.

Las parejas suelen cambiar en cada iteración. Al inicio de la iteración se conforman las parejas y éstas permanecen estables hasta que se entrega el producto al cliente. Esto permite que cada pareja se concentre en una funcionalidad concreta, de forma que tenga el tiempo suficiente para acabar su trabajo correctamente.

La Programación por parejas es una práctica corolaria y, por lo tanto, no es necesaria implementarla. Es el equipo de trabajo el que elige si la incorpora y el que define la frecuencia en que se realizan los intercambios.

Las parejas cambian cada pocos meses. Es en la planificación a largo plazo donde se establecen las parejas, de forma que cada una se especialice en un aspecto concreto del software. Esto hace que aumente la productividad, ya que los programadores no pierden el tiempo con cambios inútiles de contexto.

Todas las personas comprometidas con el proyecto pueden desempeñar su labor a partir de unos objetivos claros en el momento de enfrentarse a ellos.

El cliente puede saber, en el momento que lo desee, el estado real del proyecto y contactar, siempre que le sea necesario, con los miembros del equipo de desarrollo.

La gestión del proyecto prescinde completamente de la documentación ya que se utiliza una comunicación directa (cara a cara).

Permite aplicar mejor las prácticas de XP.

Ayuda a reducir los defectos y aumentar la calidad del producto.

Favorece la comunicación entre los miembros del equipo.

Se reduce el gasto considerablemente.

No existe un principio llamado así en XP.

Evitar las tareas complejas que requieren mucho trabajo por parte de los desarrolladores. Este tipo de tareas se suelen postergar hacia el final del desarrollo, de manera que no interrumpan el flujo natural de las tareas más productivas.

Definir, previamente, un conjunto de entregables y establecer las actividades necesarias para cumplir con esas entregas. Se establece el flujo continuo de tareas que terminan con la instalación del software en el entorno del cliente, a modo de fases intermedias.

Mantener un ritmo constante de entregas del producto durante todo el desarrollo, involucrándose en todas las actividades simultáneamente. Las prácticas en XP están orientadas a un flujo constante de actividades más que a fases discretas.

Definir la infraestructura que dará soporte al software una vez que se haya desplegado en el entorno del cliente.

Realizar las refactorizaciones de gran escala, escribir las pruebas de sistema orientadas a probar la arquitectura e implementar historias.

Diseñar la arquitectura del software con la suficiente antelación, y lo más flexible posible, para que se pueda adaptar a los posibles cambios futuros.

No existe este rol en el equipo de trabajo de XP, ya que la arquitectura no es un aspecto relevante para esta metodología.

Una alta relación con el usuario.

Eliminar las pruebas de integración.

Reducir el número de entregas del sistema.

Eliminar las pruebas unitarias.

Scrum no utiliza documentación en ningún caso ya que no aporta valor al proyecto.

Las actas de revisión del Sprint.

La pila de producto o product backlog.

Al igual que en otras metodologías ágiles, XP no promueve la calidad dentro del equipo de trabajo, ya que éste requiere una organización compleja que suele estar asociada con la elaboración de documentación detalla.

Los criterios de calidad se deben establecer al principio del proyecto. Esto es necesario ya que, por lo general, la calidad está relacionada con el coste final del producto y el cliente necesita conocer con antelación cuál va a ser éste.

Las prácticas que propone la metodología están orientadas a que el producto se realice con la máxima calidad posible. Ésta no es negociable.

La calidad, al igual que el coste, el tiempo y el ámbito del software, son variables que se pueden ajustar. Se debe negociar con el cliente para llegar a un equilibrio entre todas ellas.

Aceptar que los problemas e impedimentos propios de un proyecto de desarrollo software son muy difíciles de predecir. Por tanto, planificamos de manera que se pueda actuar en el momento que ocurran lo más rápido y efectivo que nos sea posible.

Asegurar que todos y cada uno de los impedimentos y problemas que ocurran durante un proyecto puedan ser fácilmente solventables. Esto es porque nuestra planificación está preparada para ello.

Ninguna es correcta.

Un proceso ligero, de bajo riesgo, flexible, predecible, científico y divertido de desarrollar software.

Un método para probar la exactitud de un determinado módulo de código fuente.

Un proceso muy sencillo y divertido de desarrollar software.

Un marco de trabajo para el desarrollo de software, basada en un proceso iterativo e incremental, que se divide en varias fases con unos objetivos bien definidos.

Facturar por cada una de las entregas realizadas. Al principio del proyecto, se establecen una series de fechas en las que el equipo se compromete a realizar las distintas entregas y el cliente realiza el pago fraccionado.

Cobrar cada vez que se utiliza el sistema. De esta manera, el dinero sirve de realimentación y la información que se genera puede servir para mejorar el desarrollo del software.

Utilizar sistemas de cloud computing para reducir los costes del desarrollo. De esta forma, no se utilizan recursos de la empresa sino que se utilizan recursos externos que son más económicos.

No existe esta práctica en XP.

Pruebas de caja blanca, Pruebas de caja negra, Pruebas de abuso, Pruebas negativas y Pruebas de integración.

Las únicas pruebas que se realizan son las de caja negra, ya que son los programadores los encargados de realizar y ejecutar las pruebas.

Pruebas de sistemas (System Test), Pruebas de módulos (Module Test) y Pruebas de clases (Class Test).

Pruebas unitarias (Unit Test) y Pruebas de aceptación o de sistema (Acceptance Test).

60 puntos.

La información del enunciado no es suficiente para calcular la velocidad.

56 puntos.

Obtener un sistema que permita al equipo presentar el producto según se vaya completado. El objetivo de esto es reducir la carga de gestión que supone una única entrega.

Obtener un sistema que fuerce al equipo a entregar software que funciona al cliente siempre que éste lo requiera.

Obtener un sistema que brinde un desarrollo sostenible y basado en la entrega continua.

Que muestre el total de historias de usuario contenidas en la pila de producto.

Que permita visualizar el estado real de las historias de usuario que se ha acordado completar al finalizar un Sprint.

Que representa formalmente el total de historias de usuario que se ha acordado completar al finalizar un Sprint.

El usuario.

El gestor del proyecto.

El Product Owner.

El programador.

Gestor del producto.

Responsable de entrega.

Escritor técnico.

Diseñador de interacción.

Se trata de un documento ‘vivo’ que evolucionará con el tiempo.

Ésta debe contener la mayor cantidad de historias de usuario posibles (y las tareas relacionadas con cada historia), con el objetivo de que nuestro cliente quede satisfecho con el incremento que se presente al finalizar el Sprint.

La estimación del esfuerzo que nos va a suponer el Sprint debe ser un acuerdo entre el product owner y el equipo, y debe abarcar un compromiso asumible.

Release Meeting.

Daily Meeting.

No existe reunión diaria en XP.

Stand Up Meeting.

En XP se hace un símil entre un proyecto de desarrollo de software y la evolución de un recién nacido: ambos crecen poco a poco y van pasando por distintas etapas. En la etapa en la que el bebé empieza a realizar sus primeros pasos, es cuando se producen los cambios más importantes. Este es el punto en el que el equipo debe asumir la adaptación al cambio como principio fundamental.

Es el método de aprendizaje que se promueve en XP. La formación del equipo debe ser progresiva, aprendiendo en cada momento las cosas que se necesitan para el trabajo del día a día. Un desarrollador con poca experiencia tiene unas necesidades de formación diferente a las de un desarrollador experimentado.

Este principio constata la idea de que los cambios hay que realizarlos en pequeños pasos. La carga de trabajo que supone estos pequeños pasos es menos que el coste que supone deshacer grande cambios.

No existe un principio llamado así en XP.

Daily Meeting y Planificación de iteración.

Ciclo semanal y Ciclo trimestral.

Equipo completo y Espacio de trabajo informativo.

Planificación global y Planificación local.

Se basan en documentos para plasmar y comunicar de un especialista al siguiente.

Los ciclos de retroalimentación son demasiado largos o no existen.

Todas son correctas.

Todos los miembros tienen que tener acceso al código del resto del equipo y pueden opinar acerca de cómo está hecho. Pueden exigir, al que realizó el código, que lo modifique si no cumple con los criterios de calidad establecidos.

Siempre se utiliza un sistema de control de versiones para que todo el equipo tenga acceso al código fuente desde cualquier parte.

Cualquier miembro del equipo puede mejorar cualquier parte del sistema, en cualquier momento, si lo cree oportuno.

Para evitar que los programadores puedan actuar irresponsablemente, cada miembro del equipo se hace cargo de una parte del código. Todos los ficheros tienen escrito el nombre del autor que lo ha realizado, de forma que, si otro miembro detecta algún problema, puede contactar directamente con el autor.

Si durante un Sprint, alguno de los miembros del equipo de desarrollo detectase una necesidad fundamental no contemplada al planificar, ese equipo podría modificar sin necesidad de intermediarios.

En el caso de que el objetivo fijado en un Sprint quedase obsoleto por circunstancias externas al proyecto, se podría cancelar el Sprint. El único miembro con potestad para tomar esta decisión es el propietario del producto.

Si durante un Sprint se observa que el plazo establecida para finalizar es insuficiente, generalmente se amplía la duración del Sprint dando más tiempo al equipo de desarrollo.

El Product Owner.

El Scrum Master.

Todos los miembros del Scrum Team.

Ninguna es correcta.

En el momento que el resultado obtenido por esta verifique el criterio de validación fijado por la persona del Scrum Team que sea responsable de ella.

Cuando hayamos consumido todo el esfuerzo estimado para esa historia.

La reunión diaria persigue, entre otro objetivos, actualizar el esfuerzo y realizar un control diario del trabajo.

La reunión diaria debe realizarse de la manera más cómoda posible con el objetivo de que el equipo esté relajado durante ésta.

La reunión diaria debe realizarse todos los días y de manera breve para que no acapare el tiempo de trabajo durante el Sprint.

Sentarse juntos se refiere a la práctica de utilizar las herramientas tecnológicas que existen actualmente para facilitar la comunicación entre los miembros del equipo. De esta manera es beneficioso que miembros del grupo de trabajo se ubiquen en diferentes zonas geográficas y se comuniquen diariamente a través de la web.

No existe una práctica llamada así en XP.

Es la práctica que se utiliza en XP para realizar la programación por parejas. Al sentarse juntos, la pareja consigue aumentar la comunicación y, mientas uno escribe el código, el otro va corrigiendo los defectos que se introducen.

Se persigue que el equipo de desarrollo trabaje junto, en un entorno de trabajo abierto, y no tenga barreras que dificulten la comunicación directa entre sus miembros.

Son los responsables de dirigir y gestionar a varios grupos XP. Sus funciones están orientadas a coordinar el trabajo de los equipos, facilitar la comunicación entre éstos y gestionar la movilidad de sus miembros.

Hacen las funciones de un jefe de proyecto, controlando que el proyecto se realiza de acuerdo al plan establecido y tomando decisiones que afectan a la calidad del producto.

Promueven el coraje, la confianza y la responsabilidad dentro del equipo, así como la mejora. También se encargan de alinear los objetivos del equipo con los objeticos a largo plazo de la organización.

La metodología XP no tiene en cuenta este tipo de roles, ya que no intervienen, directamente, en el desarrollo del producto.

Los desarrolladores tienen que tener la suficiente confianza y valentía para abordar los cambios que necesitan los clientes. Este principio persigue que los programadores no tengan temor a realizar cambios o refactorizaciones importantes del código.

La valentía, el coraje y el respeto son principio básicos de XP que se traducen en varias prácticas, como pueden ser: la mejora continua, la calidad, la humanidad y otras. Estos conforman el carácter del equipo de desarrollo y potencian el trabajo en equipo.

No existe un principio llamado así en XP.

El equipo formado por los desarrolladores y gestores del proyecto deben tener la potestad de comunicar a los clientes y directivos los posibles problemas que surjan durante el desarrollo, aunque éstos puedan poner en peligro el éxito del proyecto.

Entregas finales.

Ejecución basada en entregar incrementos funcionales en períodos no superiores a dos semanas.

Ejecución en bloques temporales cortos y con el objetivo de alcanzar una duración fija.

El Product Owner, que se compromete a facilitar el desarrollo del Sprint sin interferir directamente durante ese período.

El Scrum Master, que debe ejercer de enlace entre los otros roles durante el Sprint.

El Scrum Master, siempre y cuando no ocurra ningún evento que sea muy urgente. En ese caso el Product Owner es libre de interferir en el Sprint sin intermediarios.

Una planificación a largo plazo, que abarca varios meses (Release Planning), cuyo cometido es el de definir una temática de las historias que se van a implementar, y una planificación por iteración (Iteration Planning) en la que se eligen las historias a implementar en el corto plazo y se dividen en tareas.

En XP no se realiza planificación, ya que es una metodología ágil.

El jefe de proyecto es el responsable de crear la planificación del proyecto. Al principio, crea un boceto de los hitos y actividades globales que se prevén realizar y, a medida que se va acercando cada iteración, refina la planificación para tener en cuenta las historias que se van a implementar.

Básicamente, existen tres tipos de planificaciones: planificación de equipo (Team Planning), donde se planifica el trabajo del equipo en el largo y el corto plazo; planificación de la interacción con el usuario (Interaction Planning), estableciendo la forma de relacionarse con el usuario; y planificación de las entregas (Release Planning), donde se establecen los periodos en los que se irán entregando las versiones del producto al cliente.

La documentación dificulta el desarrollo y no aporta valor al proyecto.

La documentación es contraproducente para conseguir los objetivos de un proyecto.

La documentación no puede sustituir el valor que se logra con la comunicación directa entre personas.

Responsabilidad aceptada.

Humanidad.

Entorno informativo.

Flujo.

Al final de cada Sprint, con el objetivo de que todo el equipo conozca en ese momento el trabajo de los demás.

Durante la reunión diaria o daily meeting.

Siempre que lo creamos necesario.

Es interesante cambiar el escenario habitual donde se trabaja.

Debemos presentar todo el trabajo realizado aunque no esté del todo terminado, para demostrar el esfuerzo realizado.

Todas son correctas.

Entre 1 y 3 semanas.

Entre 2 y 6 semanas.

Suelen organizarse en múltiplos de 30 días (30, 60 o 90 días).

Entre 1 y 2 meses.

No existe este rol en el equipo de trabajo XP.

Son los responsables de realizar la integración del código y ejecutar todas las pruebas. Realizan informes de los fallos que puedan haber ocurrido.

Ayudan a los clientes a elegir y escribir pruebas de sistema automatizadas y enseñan a los programadores técnicas de pruebas.

Realizan las pruebas una vez que los programadores han terminado de realizar la implementación y comunican los posibles errores.

Colaboración con el cliente sobre negociación contractual.

Colaboración con el cliente sobre documentación exhaustiva.

Colaboración con el cliente sobre procesos y herramientas.

Scrum Manager, Product Owner, Development Team.

Scrum Manager, Product Owner, Scrum Team y los inversores (o skateholders).

Ninguno de los anteriores.

IBM.

Chrysler.

AT&T.

Toyota.

Integración continua.

Cliente en el sitio.

Sentarse juntos.

Historias de usuario.

Diseño simple, comunicación, realimentación, responsabilidad aceptada y coraje.

Diseño simple, calidad, humanidad, flujo y valentía.

Simplicidad, equipo auto-­‐organizado, mejora continua, sinceridad y pequeñas entregas.

Simplicidad, comunicación, realimentación, coraje y respeto.

Facilita la tarea de los que realizan las pruebas ya que su función se reduce a ejecutar las pruebas y generar los informes con los resultados.

Limita el alcance del código, genera confianza en los programadores y establece un ritmo constante en la producción.

Los jefes de proyecto tienen un control más preciso de cómo va el proyecto y pueden realizar un estudio a priori sobre la calidad del producto.

Aumenta la productividad del equipo de forma exponencial.

Estar siempre formado por personas de ambos sexos.

Ser auto-­‐organizado y multidisciplinar, huyendo del técnico especialista.

Ser auto-­‐organizado y especializar siempre a cada trabajador en un tipo de tarea determinada.

Ninguna es correcta.

La duración máxima debe estar entre 5 y 20 minutos.

15 minutos máximo.