MDA

Question

La metodología Scrum preescribe roles entre los integrantes de un proyecto.

Answer 1

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

Answer 2

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

Answer 3

Todas son correctas.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

Ninguna es correcta.

Answer 13

Basada en una planificación previa detallada.

Answer 14

Desarrollo iterativo e incremental.

Answer 15

El cliente está integrado en el proyecto.

Answer 16

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

Answer 17

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

Answer 18

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

Answer 19

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.

Answer 20

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.

Answer 21

Ivar Jacobson

Answer 22

Ken Schwaber

Answer 23

Jim Highsmith

Answer 24

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.

Answer 25

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.

Answer 26

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.

Answer 27

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.

Answer 28

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

Answer 29

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

Answer 30

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.

Answer 31

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.

Answer 32

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

Answer 33

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

Answer 34

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.

Answer 35

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

Answer 36

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

Answer 37

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.

Answer 38

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

Answer 39

Respuesta ante el cambio sobre documentación exhaustiva.

Answer 40

Respuesta ante el cambio sobre negociación contractual.

Answer 41

Respuesta ante el cambio sobre seguir un plan.

Answer 42

El Scrum Master

Answer 43

El Product Owner

Answer 44

El equipo de desarrollo

Answer 45

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.

Answer 46

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

Answer 47

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

Answer 48

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.

Answer 49

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

Answer 50

Todas las respuestas son correctas.

Answer 51

No existe esta práctica en XP

Answer 52

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.

Answer 53

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

Answer 54

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

Answer 55

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.

Answer 56

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.

Answer 57

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.

Answer 58

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.

Answer 59

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.

Answer 60

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.

Answer 61

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.

Answer 62

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.

Answer 63

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.

Answer 64

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

Answer 65

Permite aplicar mejor las prácticas de XP.

Answer 66

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

Answer 67

Favorece la comunicación entre los miembros del equipo.

Answer 68

Se reduce el gasto considerablemente.

Answer 69

No existe un principio llamado así en XP.

Answer 70

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.

Answer 71

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.

Answer 72

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.

Answer 73

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

Answer 74

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

Answer 75

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.

Answer 76

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

Answer 77

Una alta relación con el usuario.

Answer 78

Eliminar las pruebas de integración.

Answer 79

Reducir el número de entregas del sistema.

Answer 80

Eliminar las pruebas unitarias.

Answer 81

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

Answer 82

Las actas de revisión del Sprint.

Answer 83

La pila de producto o product backlog.

Answer 84

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.

Answer 85

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.

Answer 86

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.

Answer 87

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.

Answer 88

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.

Answer 89

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.

Answer 90

Ninguna es correcta.

Answer 91

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

Answer 92

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

Answer 93

Un proceso muy sencillo y divertido de desarrollar software.

Answer 94

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.

Answer 95

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.

Answer 96

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.

Answer 97

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.

Answer 98

No existe esta práctica en XP.

Answer 99

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

Answer 100

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

Answer 101

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

Answer 102

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

Answer 103

60 puntos.

Answer 104

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

Answer 105

56 puntos.

Answer 106

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.

Answer 107

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

Answer 108

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

Answer 109

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

Answer 110

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

Answer 111

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

Answer 112

El usuario.

Answer 113

El gestor del proyecto.

Answer 114

El Product Owner.

Answer 115

El programador.

Answer 116

Gestor del producto.

Answer 117

Responsable de entrega.

Answer 118

Escritor técnico.

Answer 119

Diseñador de interacción.

Answer 120

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

Answer 121

É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.

Answer 122

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.

Answer 123

Release Meeting.

Answer 124

Daily Meeting.

Answer 125

No existe reunión diaria en XP.

Answer 126

Stand Up Meeting.

Answer 127

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.

Answer 128

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.

Answer 129

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.

Answer 130

No existe un principio llamado así en XP.

Answer 131

Daily Meeting y Planificación de iteración.

Answer 132

Ciclo semanal y Ciclo trimestral.

Answer 133

Equipo completo y Espacio de trabajo informativo.

Answer 134

Planificación global y Planificación local.

Answer 135

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

Answer 136

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

Answer 137

Todas son correctas.

Answer 138

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.

Answer 139

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

Answer 140

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

Answer 141

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.

Answer 142

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.

Answer 143

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.

Answer 144

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.

Answer 145

El Product Owner.

Answer 146

El Scrum Master.

Answer 147

Todos los miembros del Scrum Team.

Answer 148

Ninguna es correcta.

Answer 149

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.

Answer 150

Cuando hayamos consumido todo el esfuerzo estimado para esa historia.

Answer 151

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

Answer 152

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.

Answer 153

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.

Answer 154

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.

Answer 155

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

Answer 156

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.

Answer 157

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.

Answer 158

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.

Answer 159

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.

Answer 160

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.

Answer 161

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

Answer 162

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.

Answer 163

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.

Answer 164

No existe un principio llamado así en XP.

Answer 165

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.

Answer 166

Entregas finales.

Answer 167

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

Answer 168

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

Answer 169

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

Answer 170

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

Answer 171

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.

Answer 172

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.

Answer 173

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

Answer 174

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.

Answer 175

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.

Answer 176

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

Answer 177

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

Answer 178

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

Answer 179

Responsabilidad aceptada.

Answer 180

Humanidad.

Answer 181

Entorno informativo.

Answer 182

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

Answer 183

Durante la reunión diaria o daily meeting.

Answer 184

Siempre que lo creamos necesario.

Answer 185

Es interesante cambiar el escenario habitual donde se trabaja.

Answer 186

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

Answer 187

Todas son correctas.

Answer 188

Entre 1 y 3 semanas.

Answer 189

Entre 2 y 6 semanas.

Answer 190

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

Answer 191

Entre 1 y 2 meses.

Answer 192

No existe este rol en el equipo de trabajo XP.

Answer 193

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.

Answer 194

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

Answer 195

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

Answer 196

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

Answer 197

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

Answer 198

Colaboración con el cliente sobre procesos y herramientas.

Answer 199

Scrum Manager, Product Owner, Development Team.

Answer 200

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

Answer 201

Ninguno de los anteriores.

Answer 202

Integración continua.

Answer 203

Cliente en el sitio.

Answer 204

Sentarse juntos.

Answer 205

Historias de usuario.

Answer 206

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

Answer 207

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

Answer 208

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

Answer 209

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

Answer 210

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.

Answer 211

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

Answer 212

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.

Answer 213

Aumenta la productividad del equipo de forma exponencial.

Answer 214

Estar siempre formado por personas de ambos sexos.

Answer 215

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

Answer 216

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

Answer 217

Ninguna es correcta.

Answer 218

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

Answer 219

15 minutos máximo.

	Criado por Pepe Lopez mais de 8 anos atrás

Próximo

MDA

Descrição

Resumo de Recurso

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Questão 21

Questão 22

Questão 23

Questão 24

Questão 25

Questão 26

Questão 27

Questão 28

Questão 29

Questão 30

Questão 31

Questão 32

Questão 33

Questão 34

Questão 35

Questão 36

Questão 37

Questão 38

Questão 39

Questão 40

Questão 41

Questão 42

Questão 43

Questão 44

Questão 45

Questão 46

Questão 47

Questão 48

Questão 49

Questão 50

Questão 51

Questão 52

Questão 53

Questão 54

Questão 55

Questão 56

Questão 57

Questão 58

Questão 59

Questão 60

Questão 61

Questão 62

Questão 63

Questão 64

Questão 65

Questão 66

Questão 67

Questão 68

Questão 69

Questão 70

Questão 71

Questão 72

Questão 73

Questão 74

Questão 75

Questão 76