1.

Cite 3 prácticas propuestas por Extreme Programming

Prácticas​ en eXtreme Programming

1. The Planning Game: ​determine rápidamente el alcance de la próxima versión

combinando prioridades comerciales y estimaciones técnicas. A medida que la realidad
supere el plan, actualícelo.
2. Small Releases: ponga un sistema simple en producción rápidamente, luego publique
nuevas versiones en un ciclo muy corto.
3. Metaphor​: si no sos capaz de describir tu sistema en una oración, es porque no estás
entendiendo lo que tenés que hacer. Guíe todo el desarrollo con una simple historia
compartida de cómo funciona todo el sistema.
4. Simple Design: ​el sistema debe diseñarse de la manera más simple posible en
cualquier momento dado. La complejidad adicional se elimina tan pronto como se
descubre.
5. Testing: ​los programadores escriben continuamente pruebas unitarias, que deben
ejecutarse sin problemas para que el desarrollo continúe. Los ​clientes escriben pruebas
que demuestran que las funciones están terminadas.
6. Refactoring: ​no hay que tener miedo a cambiar el software, sino que hay que tener un
entorno que me permita hacerlo. Los programadores reestructuran el sistema sin
cambiar su comportamiento para eliminar duplicaciones, mejorar la comunicación,
simplificar o agregar flexibilidad.
7. Pair programming: todo el código de producción se escribe con dos programadores en
una máquina.
8. Collective ownership​: todo el mundo puede tocar el código de todo el mundo y hacer
cambios en él. Evitar los desarrolladores poco colaborativos (“este es mi código”)
9. Continuous integration: ​integre y cree el sistema muchas veces al día, cada vez que
se complete una tarea.
10. 40 hour week: no sirven los equipos superhéroes. No hay que trabajar más horas de las
estipuladas. Por lo general, no trabaje más de 40 horas a la semana. Nunca trabaje
horas extras una segunda semana consecutiva.
11. On-site customer: incluya un usuario real y en vivo en el equipo, disponible a tiempo
completo para responder preguntas.
12. Coding standards​: think twice, code once. Los programadores escriben todo el código
de acuerdo con las reglas que enfatizan la comunicación a través del código.

eXtreme Programing: ​Es un modo de desarrollar software liviano, eficiente, de bajo

riesgo, flexible, predecible, científico, y divertido.

Actividades básicas:

- Codear
- Testear
- Escuchar
- Diseñar

1
 2. Explique 1 propiedad, 1 estrategia y 1 Técnica propuesta por ​Crystal Clear

Propiedades​: Las principales son: ​Entregas frecuentes, Comunicación cercana y Mejora

reflexiva​.
1. Entregas frecuentes​, en base a un ciclo de vida iterativo e incremental. En función
del proyecto puede haber desde entregas semanales hasta trimestrales. Por ejemplo
en Scrum las entregas son, máximo, cada 4 semanas, en las Crystal se contemplan
muchas más opciones.
- Es la más importante, debería ser una norma que se de cada hora, cada día
o en el peor de los casos cada semana. Si no se realizan entregas continuas
nos podemos perder de un problema importante y descubrirlo ya cuando sea
tarde. Es sobre entregar el software a los usuarios, no simplemente iterando,
si no se realiza cada un corto periodo de tiempos, estos se vuelven más
críticos. Es necesario que los usuarios visiten al equipo, ver el sistema en
acción y probarlo, si esto no se realiza se asocia directamente a la falla final
del proyecto.
2. Mejora reflexiva​. Que viene a ser mejora continua. Las iteraciones ayudan a ir
ajustando el proyecto, a ir mejorándolo.
- El equipo lista qué funciona, qué no y discute qué podría mejorarse y realizar
cambios para la siguiente iteración, en dos palabras, REFLEXIONAR y
MEJORAR.
3. Comunicación osmótica​. Traducido al castellano, que el equipo esté en una misma
ubicación física, para lograr la comunicación cara a cara.
4. Seguridad personal​. Todo el mundo puede expresar su opinión sin miedos,
teniéndose en cuenta, considerándose su opinión, etc.
5. Enfoque​. Períodos de no interrupción al equipo (2 horas), objetivos y prioridades
claros, definiendo así tareas concretas.
6. Fácil acceso a usuarios expertos​. Crystal (a diferencia de otras como XP) no
exigen que los usuarios estén continuamente junto al equipo de proyecto (no todas
las organizaciones pueden hacerlo), sí que, como mínimo, semanalmente debe
haber reuniones y los usuarios deben estar accesibles.
7. Entorno técnico con pruebas automatizadas​, gestión de la configuración e
integración continua.

Estrategias:

Exploración de 360°​. Vericar o tomar una muestra del valor de negocios del proyecto, los
requerimientos, el modelo de dominio, la tecnología, el plan del proyecto y el proceso.
Victoria temprana. Es mejor buscar pequeños triunfos iniciales que aspirar a una gran
victoria tardía.

2
Esqueleto ambulante​. Es una transacción que debe ser simple pero completa. Poder
lograr un end to end maquetado. (mencionado por el profesor)
Re-arquitectura incremental​. Se ha demostrado que ​no es conveniente interrumpir el
desarrollo para corregir la arquitectura​. Más bien la arquitectura debe evolucionar en etapas,
manteniendo el sistema en ejecución mientras ella se modica.
Radiadores de información​. Es una lámina pegada en algún lugar que el equipo pueda
observar mientras trabaja o camina. Tiene que ser comprensible para el observador casual,
entendida de un vistazo y renovada periódicamente para que valga la pena visitarla.

Técnicas o Prácticas:
Igual que con las estrategias, hay una lista de técnicas propuestas por Crystal Clear, de las
cuales se pueden ir tomando las más convenientes según el momento en que se encuentra
el proceso de desarrollo del proyecto.
Las ​reuniones diarias (introducidas por la metodología Scrum) acompañan el seguimiento y
mantienen el foco en el próximo paso a seguir, y también permiten la discusión productiva
de líneas a seguir.
Las ​reuniones de reflexión periódicas son fundamentales para que los miembros del equipo
se expresen abiertamente, para revisar el trabajo hecho y evaluar qué cosas dan resultado
y cuáles no, o de empezar a trabajar. Todo esto permite ir armando una metodología de
trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen.

3. Cite 3 prácticas de Agile Modeling que no están propuestas en Scrum, XP y

Crystal Clear.
http://agilemodeling.com/

3
 PROPUESTAS NO PROPUESTAS

- ​Active Stakeholder Participation: ​XP - Agile Model Driven Development (AMDD)

- ​Agile Modeling and RUP: X ​ P, RUP, DAD,
scrum y EUP
- Agile Modeling and XP: X ​ P
-​Agile Requirements Change Management:
DAD y Scrum
- Agile Models Distilled
- Dowloads
No se si son independientes
Essays and Other Resources
Examining the Model Driven Architecture
(MDA)
Frequently Asked Questions (FAQ)
Generalizing Specialists
Inclusive Models
An Introduction to Agile Modeling
Introduction to the Diagrams of UML 2.0
Modeling Style Guidelines
Phases Examined
Practices of AM
Principles of AM
Site Map
Training in Agile Model Driven Development
Values of AM

4. Explique brevemente que propone Heart of Agile

La agilidad está sobre-decorada​, se cargó demasiado, se perdieron los principios sobre los
cuales está basada. La idea que propone Heart of Agile es volver a la esencia, simplificar, y
recuperar el corazón de la agilidad: colaborar, entregar, reflexionar y mejorar (CREM).

● Colabora cerca con otros para generar y desarrollar mejores primeras versiones de
las ideas.
● Entrega pequeñas pruebas iniciales para aprender cómo funciona realmente el
mundo. Aumenta tus entregas al tiempo que corriges la dirección hacia tu objetivo.
● Reflexiona periódicamente, a lo largo del camino. Piensa en lo que has aprendido
en tu colaboración y a partir de tus entregas.
● Mejora ​la dirección de tus ideas, su implementación técnica, y tu proceso interno.

4
 5. Explique brevemente que propone ​Modern Agile

Propuesto por Joshua Kerievsky, intenta captar las principales cuestiones de agilidad y
centrarse en ellas.

Ideas principales:

1. Make People Awesome - Haz que las personas sean geniales: potenciar al
equipo. Preguntarse cómo podemos hacer que las personas en nuestro ecosistema
sean increíbles. Esto incluye a las personas que usan, fabrican, compran, venden o
financian nuestros productos o servicios. Aprendemos su contexto y sus puntos
débiles, lo que los frena y lo que aspiran a lograr. ¿Cómo podemos hacerlos
increíbles?
2. Make Safety a Prerequisite - Haz de la seguridad un prerrequisito: crear un
entorno de seguridad en el cual las personas tengan las herramientas para hacer su
trabajo. La seguridad es una necesidad humana básica y una clave para
desbloquear el alto rendimiento. Hacemos que la seguridad sea un requisito previo
estableciendo seguridad antes de realizar cualquier trabajo peligroso. Protegemos el
tiempo, la información, la reputación, el dinero, la salud y las relaciones de las
personas. Y nos esforzamos para que nuestras colaboraciones, productos y
servicios sean resistentes y seguros.
3. Experiment and Learn Rapidly - Experimenta y aprende rápido: No puedes
hacer que las personas sean geniales o hacer de la seguridad un requisito previo si
no estás aprendiendo. Aprendemos rápidamente experimentando con frecuencia.
Hacemos que nuestros experimentos sean "seguros para fallar", por lo que no
tenemos miedo de realizar más experimentos. Cuando nos atascamos o no estamos
aprendiendo lo suficiente, lo tomamos como una señal de que necesitamos aprender
más realizando más experimentos.
4. Deliver Value Continuously - Entrega valor contínuamente: Cualquier cosa que
no se entregue no está ayudando a nadie a ser más increíble o seguro. En modern
agile, nos preguntamos: "¿Cómo podría entregarse un trabajo valioso más rápido?"

5
 Para entregar valor continuamente, debemos dividir grandes cantidades de valor en
piezas más pequeñas que puedan entregarse de manera segura ahora en lugar de
más tarde.

6. Enumere los 3 pilares de Kanban

1. Visualizar los estados: en cualquier momento, cualquier persona del proyecto

tiene que saber en qué estado está la tarea. Se propone un ​tablero físico, con todas las
columnas que se necesite, y debe estar disponible para todo el equipo.
2. Limitar el trabajo en progreso (WIP): para cada columna, limitar la cantidad de
historias de usuario que se pueden tener dentro de cada fase del ciclo de trabajo.
3. Medir los flujos de trabajo: controlar la producción y tomar decisiones de ajuste a
partir de esto. Se proponen 2 medidas:
a. Lead time:​ tiempo que pasa entre que el cliente me hace el pedido hasta que
recibe lo que me pidió
b. Cycle time:​ productividad del equipo, desde que éste se pone a trabajar hasta
que entrega lo que el cliente pidió.

#AlgoQuePuedenTomar:​ Diferencia entre SCRUM y KANBAN

SCRUM KANBAN

Scrum limita el WIP por iteración Kaban limita el WIP por estado en flujo de
trabajo

Product backlog organizado por prioridad Prioridad se elige en función de lo que me

va llegando, no tengo que esperar un sprint

6
 7. Explique que representa el WIP

WIP (Work In Progress) representa cuántas tareas como máximo pueden realizarse en
cada fase del ciclo de trabajo o product backlog.

Si una columna de un tablero Kanban (es decir, una fase del ciclo de producción) tiene, por
ejemplo, un WIP 5, esto quiere decir que si el equipo (no las personas, porque el WIP de un
KANBAN afecta a una parte del proceso, en la que participan n personas) en esa fase está
trabajando en cinco tareas no podrán trabajar en ninguna otra hasta que terminen alguna de
estas cinco.

Si tengo un ​WIP bajo​, las tareas se realizarán rápido (ya que podría tener hasta 4 personas
trabajando sobre una tarea) pero probablemente tendré miembros del equipo ociosos (ya
que normalmente no todas las personas podrán trabajar a la vez sobre la misma tarea).
Pero si defino un ​WIP alto​, puedo tener mucha gente, existe el riesgo de empezar muchas
tareas y terminar pocas, de estar trabajando en varias cosas a la vez sin cerrar muchos
temas, generando un cuello de botella.

8. ¿Qué representa el flujo de trabajo?

El flujo de trabajo representa la capacidad de trabajo. Lo hace a través de las 2

medidas: Lead time y Cycle time.

Kanban se basa en el desarrollo incremental, dividiendo el trabajo en partes. Una de

las principales aportaciones es que utiliza técnicas visuales para ver la situación de
cada tarea, (pizarras llenas de post-it).

El trabajo se divide en partes, normalmente cada una de esas partes se escribe en

un post-it y se pega en una pizarra. Los post-it suelen tener información variada, si
bien, aparte de la descripción, debieran tener la estimación de la duración de la
tarea. La pizarra tiene tantas columnas como estados por los que puede pasar la
tarea (ejemplo, en espera de ser desarrollada, en análisis, en diseño, etc.).

7
El objetivo de esta visualización es que quede claro el trabajo a realizar, en qué está
trabajando cada persona, que todo el mundo tenga algo que hacer y el tener clara la
prioridad de las tareas. Las fases del ciclo de producción o flujo de trabajo se deben decidir
según el caso, no hay nada acotado.

9. ¿Qué entiende por SCRUM?

Scrum: e ​ s un Framework para la gestión completa de proyectos. Un marco de trabajo por el

cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregar
productos del máximo valor posible productiva y creativamente.

10. Explique uno de los pilares de SCRUM

- ​Transparencia: todo el mundo sabe lo que se está haciendo, por medio de los tableros.
Implica dar visibilidad a todo lo que está pasando, ya que los aspectos significativos del
proceso deben ser visibles para aquellos que son responsables del resultado. La Reunión
de Planificación proporciona visibilidad al Equipo Scrum acerca de aquello que va a hacer
en el sprint; el Scrum Diario, proporciona visibilidad sobre las tareas diarias, los
impedimentos y cómo marcha el trabajo; la Revisión del Sprint ofrece visibilidad sobre los
logros, resultados y el progreso. Por último, la Retrospectiva del Sprint contribuye con la
inspección y la adaptación del proceso.

- ​Inspección: constantemente estoy evaluando lo que estoy haciendo. Scrum promueve la

inspección frecuente de los artefactos y del progreso para identificar y corregir las

8
variaciones no deseadas. La inspección tiene lugar durante: la Reunión de Planificación de
Sprint, el Scrum Diario, la Revisión del Sprint y la Retrospectiva del Sprint.

- ​Flexibilidad/Adaptación: adaptación, me voy adaptando a los cambios. Implica hacer los

ajustes en los procesos y artefactos para minimizar la desviación.

11. ¿Cuáles son las funciones del SCRUM Master?

El Scrum Master es un líder que está al servicio del Equipo Scrum. Se asegura que se
aplique el Scrum adecuadamente.

El Scrum Master se encarga de ​gestionar y asegurar el proceso Scrum​, que éste se lleve
a cabo correctamente y de facilitar la ejecución del proceso y sus mecánicas, siempre
atendiendo a los tres pilares del control empírico de procesos. Además, se encarga de
eliminar impedimento​s que puedan afectar a la entrega de producto. También se encarga
de hacer coaching al resto del equipo Scrum cuando lo necesitan, además de facilitar
reuniones y eventos si es necesario.

12. ¿Qué es el Product Backlog?

El Product Backlog o Lista de Producto es una lista ordenada de todo lo que podría ser
necesario en el producto, y es la única fuente de requisitos para cualquier cambio a
realizarse en él. El Product Owner es el responsable de la Lista de Producto, incluyendo su
contenido, disponibilidad y ordenación.

13. ¿Qué es un sprint? Explique brevemente cómo funciona.

El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de 4 semanas o menos
durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente
desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del
esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la
finalización del Sprint anterior.

9
Los Sprints contienen y consisten en la Planificación del Sprint (Sprint Planning), los Scrums
Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la
Retrospectiva del Sprint (Sprint Retrospective).

Sprint Planning: ​El trabajo a realizar durante el Sprint se planifica en la

Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum
completo.

Scrum Daily: ​El Equipo de Desarrollo usa el Scrum Daily para evaluar el progreso
hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la
finalización del trabajo contenido en la Lista de Pendientes del Sprint.

Revisión de Sprint (Sprint Review​): Al final del Sprint se lleva a cabo una Revisión
de Sprint para inspeccionar el Incremento y adaptar la Product Backlog si fuese necesario.

Retrospectiva de Sprint (Sprint Retrospective) ​La Retrospectiva de Sprint es una

oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de
mejoras que sean abordadas durante el siguiente Sprint.

14. ¿Cómo se mide el avance del proyecto en SCRUM?

El avance del proyecto en SCRUM se mide ​con las historias de usuario realizadas ​o la
cantidad de historias pendientes que van quedando.

Existen varias formas de medir el progreso del trabajo total hasta acabar el proyecto. Al
menos una vez por sprint el dueño del producto mide cuánto ha sido trabajo que se ha
terminado y cuánto queda para acabar el proyecto y lo anota.

Esta forma de contar el trabajo restante para acabar el proyecto se le llama Burndown y si
se pinta en una gráfica será la llamada gráfica de Burn-down. Se le llama así porque se va
anotando la cantidad de trabajo que queda pendiente en lugar de la cantidad de trabajo o
puntos que vamos sumando al realizar más trabajo. El trabajo va disminuyendo o
quemándose hasta llegar a 0 horas o puntos de trabajo pendiente, momento en el cual toca
suelo en el eje horizontal.

10
El gráfico Burn-up es, muy similar. Pero con la diferencia de que se parte del cero, y se va
marcando la cantidad de trabajo completado al final del Sprint, por ello la curva va hacia
arriba, no hacia abajo.
En la figura de abajo, la línea verde es el objetivo y la gráfica va hacia arriba.

15. ¿Por qué decimos que uno de los beneficios de SCRUM es que se mejoran las
estimaciones?

Uno de los beneficios de SCRUM es que se mejoran las estimaciones porque se está
estimando constantemente. Además, las técnicas de estimación utilizadas permiten llegar a
consensos más rápidamente, porque no se centran en estimar teniendo en cuenta una hora,
sino que se centran a estimar comparando complejidades, es decir, se usan medidas
relativas.

16. Describa las principales funciones del product owner.

Product Owner (PO):

● Es el representante del cliente. Se supone que tiene el conocimiento completo de las

necesidades que tienen los Stake Holders (o clientes), de su entorno
● Define cuáles son las necesidades por medio de las historias de usuario, con calidad
y de manera correcta
● Tiene como responsabilidad el ​product backlog,​ definiendo en orden todos los ítems
(historias de usuario), por valor, que aporta al cliente (mayor a menor). Esto lo puede
realizar por medio de la técnica Inseption.
● Establece cuáles son las cosas que vamos a poder hacer, y las que no.
● Tiene que estar disponible todo el tiempo para el equipo durante el desarrollo, o
bien, cuando éste lo necesite.
● Prioriza las historias de usuario
● Define los MVP (Producto Mínimo Viable)

11
 17. Explique, por medio de un ejemplo,qué pasaría si en un proyecto ágil sólo
colaborar el equipo técnico y el scrum master.

- Si solo colaboran el Equipo con el Scrum Master, terminaré el producto de manera

correcta en el tiempo correcto, pero puedo no estar haciendo el producto que el cliente
quiere

- Si sólo colaboran el Equipo y el Product Owner, probablemente hago las cosas con calidad
y lo que el cliente quiere, pero sin respetar lo que me dice scrum (no controlo tiempo,
iteraciones, etc)

- Si sólo colaboran el Scrum Master y el Product Owner, voy a tener el producto correcto en
los tiempos adecuados, pero sin calidad.

Si en un proyecto ágil solo colaboran el equipo técnico y el scrum master; lo que pasaría es
que el software que van a diseñar para la compañía no tendrá todas las características que
debería tener; por ejemplo

La empresa quiere que le desarrollen un auto y contratan a una empresa para que lo hagan,
pero al equipo le surgen dudas como, por ejemplo, el color, el tamaño, el número de
asientos, etc. Lo que se va a terminar construyendo es un auto familiar genérico, de 4
puertas, negro etc. Pero quizás la empresa lo que quería era una camioneta 4x4 con todos
los gadgets que existen y toda pintada por fuera, pero como el product owner nunca

12
participó, no dio su opinión y el equipo hizo lo que les parecía dentro de su rango de
aplicación.

18. ¿Cómo deben ser las historias de usuario?

Deben ser ​cerradas​, en periodos de tiempo pequeños​, de tal forma de que se realicen en
2 o 3 días de desarrollo ​y ​deben recordar QUÉ hay que hacer, no CÓMO hay que
hacerlo​. Finalmente, tienen que ser como el método INVEST. El método INVEST descrito
por Bill Wake nos ayuda a escribir historias de usuario y asegurar su calidad; consiste en
cumplir las siguientes características:

● Independent - Independiente: Cada historia de usuario pueda ser planificada e

implementada en cualquier orden. No dependen unas de otras, o dependen
mínimamente. Si ocurre se deben dividir o combinar ya que si tengo dos historias
dependientes, la historia que es primaria, si se atrasa, atrasa a las otras.
● Negotiable - Negociable: Las historias deben ser negociables ya que sus detalles
serán acordados por el cliente/usuario y el equipo durante la fase de
«conversación». No es algo fijo, se puede negociar con el cliente, cambiar su
prioridad, achicar historias de usuario, unirlas, etc.
● Valuable - Valor: Una historia de usuario tiene que ser valiosa para el cliente o el
usuario.
● Estimable: Una buena historia de usuario debe ser estimada con la precisión
suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación.
Si no podemos estimarla debemos incidir en la fase de conversación o dividirla.
● Small - Pequeña: Atómicas, con funcionalidad mínima. Solemos hacerlas de tal
modo que ocupen como máximo un sprint.
● Testable - Testeable: La historia de usuario debe poderse probar. Tanto el usuario
como el equipo de desarrollo tienen que poder probarla para saber cuándo está
finalizada.

13
 19. ¿Para qué sirve el método INVEST?

El método INVEST sirve para asegurar la calidad de las historias de usuario. Son un
conjunto de características que sirven para verificar si una historia de usuario está bien
escrita, ya que se parte del supuesto de que para que una historia de usuario sea correcta
debe cumplir con cada una de esas características

20. ¿Qué es un Mapa de Historias de Usuario?

Forma de organizar el product backlog.

Los mapas de historia de usuario es una aproximación a la organización y a la priorización

de las historias de usuario. Apoyan a la intención principal de las historias de usuario, la
discusión​.

La forma más utilizada es el mapa de historias. Busca tener un conocimiento completo de

las historias conocidas hasta el momento. El objetivo de usar historias es el conocimiento
compartido.

Permite comprender el producto que se construye. Intentan identificar cuando a partir de

grandes historias se va a dar el detalle (breaking down big stories as you tell them). Se usan
cuando tengo un sistema muy grande y se debe entender hacia dónde va el producto, hacia
dónde se quiere llegar. Sirven también para identificar cosas que no son prioritarias, pero
que hacen que la aplicación funcione de manera correcta.

UNA HISTORIA DE USUARIO SE CONVIERTE EN TAREAS QUE SE VAN A REALIZAR

14
#QUE RECOMIENDAN LOS MAPAS DE HISTORIA: tener un personaje
(persona/character)

21. ¿Qué propone la técnica MoSCoW?

Es un método que propone priorizar las historias de usuario en función del valor aportado al
cliente.

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de

que, aunque todos los requisitos se consideren importantes, es fundamental destacar
aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos
de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos
como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un
significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce
el efecto real que producirá su elección.

M (Must)​: Requisito que tiene que estar implementado en la versión final del producto para
que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido
en la solución final, pero que llegado el momento y si fuera necesario, podría ser
prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades

presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un
futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías
anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el

caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

15
 22. ¿Qué es el MVP?

MVP es ​la mínima cantidad de funcionalidad que el cliente está dispuesto a pagar​.
Suele ser único y evoluciona a lo largo del tiempo, pero dependiendo del tipo de producto,
se pueden tener más.

Se tiene que tener la funcionalidad que nos está pidiendo el cliente, qué es lo que él quiere
cuál es el conjunto de funcionalidades mínimas que van a formar parte de mi primer release.

23. Explique la principal diferencia entre release y prototipo

La principal diferencia es que en la ​release​, se le entrega algo de valor a un cliente, es decir

se pone en producción, es usado por el usuario. Mientras que un ​prototipo​, en este
contexto, representa un modelo que se le presenta al cliente para que lo apruebe o no, así
como también para que brinde sus sugerencias, y en base a esa información terminar el
prototipo. El prototipo no está implementado, tiene como propósito que el Product Owner
valide la funcionalidad desarrollada.

El prototipo es algo que no está en producción, mientras que la release sí está en

producción.

Un prototipo puede ser una pantalla de un login(solo la parte gráfica). Mientras que una
release va a ser todo el sistema de login funcionando.

24. ¿Qué es la velocidad del equipo?

16
Velocidad del equipo: cantidad de puntos de historia que se pueden realizar en un
sprint. ​Fuerza de trabajo que puede hacer un equipo en un sprint. ​Es la manera de medir la
productividad de un equipo en un sprint. ​Se calcula sumando el número de puntos historia
(según la unidad y escala que uses) que se estimaron para cada historia de usuario que se
ha terminado durante una iteración o sprint.

25. ¿Para qué sirven los mapas personales?

Sirven para conocer a las personas del equipo

Muchas veces pasa que trabajas durante mucho tiempo con personas, que sí, la conoces
del trabajo y tal, pero si te paras a pensar qué conoces de esas personas más allá del
trabajo, realmente no sabes nada, son desconocidos.

Se empieza cogiendo un papel en blanco (o una herramienta de mapas mentales) y ​en el

centro escribimos el nombre de la persona​ de la que vamos a hacer el mapa.

A continuación se escriben ​las categorías de interés alrededor del nombre​: hogar,

educación, trabajo, aficiones, familia, amigos, metas y valores. Expandiendo así el mapa y
rellenando cada categoría con lo que vaya contando la persona.

Una vez que se acabe, se puede realizar una reunión, o una quedada extraoficial o como
cada uno quiera (reunión vía Skype por ejemplo), y en esa reunión contar y presentar el
mapa de la persona que te haya tocado así el resto del equipo también le empezará a
conocer.

Uno de los beneficios o ventajas de los mapas personales es que ayudan a romper las
barreras entre lo profesional y lo personal.

#PreguntaDeParcial: ​Indique cuál de los principios del manifiesto ágil intenta cumplir
el análisis de costo en función del tiempo que hace Kent Beck en el libro Extreme
Programming Explained.

Curva de Boehm

Curva donde se ve el costo del cambio en función del tiempo. A medida que pasa el tiempo
de un proyecto, el costo tiende a crecer de forma exponencial, por ende, es mejor detectarlo
de forma temprana. Pensado para el modelo de vista en cascada.

17
Bohem propone invertir la curva. Si el costo del cambio aumentó lentamente con el tiempo,
actuarías de manera completamente diferente a como lo haces bajo el supuesto de que los
costos aumentan exponencialmente. ​Tomaría grandes decisiones lo más tarde posible en el
proceso​, para diferir el costo de tomar las decisiones y tener la mayor posibilidad de que
tengan razón. Sólo implementaría lo que tenía que hacer, con la esperanza de que las
necesidades que se anticipan para mañana no se hagan realidad. Introduciría elementos en
el diseño solo porque simplificarán el código existente o simplificarán la escritura del
siguiente fragmento de código.

Si una curva de costo de cambio aplanada hace posible XP, una curva de costo de cambio
empinada hace imposible XP. Si el cambio es ruinosamente costoso, sería una locura
cobrar por adelantado sin pensarlo detenidamente. Pero si el cambio sigue siendo barato, el
valor adicional y el riesgo reducido de retroalimentación concreta temprana supera el costo
adicional del cambio temprano. Kent Beck proponía que, si bien puede ser más económico
solucionar un error antes de tirar una línea de código, una vez que comienza el desarrollo
en coste del cambio, ya con código, es constante.

La única forma de desarrollar una técnica de software ágil es teniendo una calidad técnica
muy buena.

18
#PreguntaDeParcial: Cite los 4 valores que deben seguir los proyectos ágiles que
sigan Extreme Programming indicados por Kent Beck en el libro Extreme
Programming Explained, capítulo 7.

5 Valores de XP

- Coraje: ​Diremos la verdad en nuestros avances y estimados, no documentamos

excusas para el fracaso, pues planificamos para tener éxito. No tendremos miedo a
nada pues sabemos que nadie trabaja solo. Nos adaptamos a los cambios cuando
sea que estos ocurran.
- Retroalimentación/Feedback: ​Nos tomamos seriamente los compromisos con el
usuario establecidos en todas las iteraciones, entregando software en
funcionamiento en cada una. Mostraremos al usuario nuestro software
frecuentemente y de forma temprana, escuchando cuidadosamente sus
observaciones y realizando los cambios que sean necesarios. Adaptamos nuestros
procesos al proyecto y no al contrario
- Simplicidad: desarrollaremos lo que sea solicitado y necesario, pero no más que
eso. De esa forma, se maximiza el valor de la inversión realizada. Es más
complicado hacer algo simple y funcional, que algo complicado y mal hecho
- Comunicación​: Todos son parte del equipo y nos comunicamos cara a cara todos
los días. Es más rápido y confiable. Trabajamos juntos en todo, desde los
requerimientos hasta la programación.

#PreguntaDeParcial: Explique las características que debe cumplir la Reunión de

Planificación del Sprint.

● Se tienen que definir el sprint goal (objetivo, descripción corta, de una o dos
oraciones, de lo que el equipo tiene previsto alcanzar durante el sprint) y el sprint
backlog (lista de ítems del product backlog que el equipo se compromete a entregar,
más la lista de tareas necesarias para cumplir con cada uno de estos ítems).
● La duración de la reunión no debe ser mayor a 8 hs (Sprint de 4 semanas).
● El PO explica el product backlog,​ ​explicando las historias de usuario que cree él que
tienen más valor, y se negocian las que pueden llegar a realizarse, ya que las
mismas deben poder realizarse entre 2 y 5 días. En caso de no poder hacerlo, se
tienen que subdividir en historias más pequeñas.
● La estimación e ​ stá a cargo del equipo de desarrollo. Para llevarla a cabo, se usa el
método que más guste (planning poker, técnica de la camiseta, etc.) con el fin de
asignarle a cada historia de usuario cuántos puntos se le van a dar.
● Teniendo en cuenta la velocidad del equipo, el valor que le aporte al cliente y la
estimación con los puntos de historia, se realiza el ​sprint backlog​, es decir, se van a
ver cuántas historias de usuario se van a poder realizar en un período de tiempo
determinado, determinando las tareas que se van a realizar y CÓMO se van a llevar
a cabo.

19
#PreguntaDeParcial: Explique qué sucede cuando en un equipo hay más de un
Product Owner

Se debe tener un PO por equipo, porque si tengo más de eso puede ocurrir que ninguno de
los dos se ponga de acuerdo. Cuando tengo varios proyectos, y dependiendo del tipo que
sea, si son de distintos clientes, puedo tener varios, porque el PO es un representante del
cliente. Es responsabilidad del equipo en esos casos ver qué priorizar, se dan en lo casos
en los que el equipo es muy maduro, tanto técnicamente como por equipo, asimismo
conocer las prioridades que tiene el cliente para ver qué es lo que él prefiere priorizar. Lo
ideal es que el PO lo provea el cliente.

#PreguntaDeParcial: Grafique y explique cómo y dónde ubica Ambler su propuesta

Agile Modeling en relación a otras metodologías o frameworks como Scrum, XP o
RUP.

Agile Modeling (AM) es un proceso de software basado en prácticas cuyo alcance es describir cómo
modelar y documentar de manera eficaz y ágil. Las prácticas de AM deben usarse, idealmente en su
conjunto, para mejorar otro proceso de software más completo como ​eXtreme Programming (XP) ,
Rational Unified Process (RUP) , ​Disciplined Agile Delivery (DAD) y ​Enterprise Unified Process (EUP)
para nombrar unos pocos. Estos procesos cubren un alcance más amplio que AM, en los primeros
tres casos, el proceso de desarrollo; y en el cuarto, el proceso de software completo que incluye tanto
el desarrollo como la producción. Aunque todos estos procesos incluyen actividades de modelado y
documentación, de una forma u otra, definitivamente hay margen de mejora. Con DAD, las prácticas
de AM se integran directamente en el marco, con XP los procesos de modelado deberían definirse
mejor, y con los procesos de modelado RUP definitivamente podrían hacerse más ágiles.

#PreguntaDeParcial: Grafique y explique la curva de progresión Shu-Ha-Ri-Kokoro

propuesta por Cockburn en Heart of Agile. No use más de 30 palabras en la
explicación

Alistair Cockburn introdujo Shuhari como

un concepto para aprender todo tipo de
técnicas, prácticas y herramientas para el
desarrollo de software.

Shuhari dice que, si bien nos adherimos a

la sabiduría tradicional como novatos,
debemos romper con ella si es necesario,
especialmente cuando reunimos nuevos
conocimientos que nos permiten
comprender la esencia del éxito pasado.
Lo que sigue debe ser trascendencia a una nueva expresión, basada en la tradición.
Debemos ir hacia el kokoro de la agilidad.

● Shu: “seguir”, hacer algo tal cual ● Ri: hacer las cosas naturalmente
me lo han dicho ● Kokoro: volver a lo básico
● Ha: ser experto en una técnica

20
#PreguntaDeParcial: Seleccione una práctica propuesta por XP y explíquela
brevemente (menos de 30 palabras)

#PreguntaDeParcial: Seleccione una práctica propuesta por Crystal Clear y explíquela

brevemente (menos de 30 palabras)

#PreguntaDeParcial: Seleccione una práctica propuesta por Agile Modeling y

explíquela brevemente (menos de 30 palabras)

#PreguntaDeParcial:​ ¿Cuál es la idea principal en la que se basa el MVP?

21