Nathalia Muñoz Silva – Jahir Ricardo Avila Gutierrez

• Sugerencias para ayudar a su equipo con la transición hacia la

planificación ágil.
RTA:
1. Es imperativa la participación activa de los usuarios.
2. El equipo de desarrollo debe tener la facultad para tomar decisiones.
3. Los requisitos evolucionan, pero la escala de tiempo y fechas de entregas
son fijas (control del alcance).
4. Capturar los requisitos a un alto nivel, ligero y visual (prototipos).
5. Desarrollar versiones pequeñas, incrementales e itere sobre ellas.
6. Enfocarse en la entrega frecuente de productos.
7. Completar cada funcionalidad antes de pasar a la siguiente.
8. Aplicar la regla 80/20, trabajar funcionalidades principales – principio de
Pareto
9. Las pruebas se integran en todo el ciclo de vida del proyecto – prueba
temprano y con frecuencia.
10. Un enfoque de colaboración y cooperación entre todas las partes
interesadas es esencial.

• Guía sobre las iteraciones. ¿Cómo deberían ser? ¿El equipo sólo debería
trabajar en las iteraciones? durante una versión en particular? ¿Qué debería
hacer el equipo entre versión y versión?
RTA: Las Iteraciones constituyen una técnica apropiada, una mejor práctica, para
la construcción de software. Se requieren nuevas habilidades en el manejo de
proyectos, coordinación de equipos, documentación de software, desarrollos en
tiempos más pequeños, pero más especializados, equipos multidisciplinarios y
compromiso de parte de todos los involucrados en el proyecto. Pero funciona, sin
duda, en cualquier tipo de proyecto, con cualquier número de desarrolladores, sea
cual fuere su complejidad.
as iteraciones se pueden entender como mini proyectos: en todas las iteraciones
se repite un proceso de trabajo similar (de ahí el nombre “iterativo”) para
proporcionar un resultado completo sobre producto final, de manera que el cliente
pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada
requisito se debe completar en una única iteración: el equipo debe realizar todas
las tareas necesarias para completarlo (incluyendo pruebas y documentación) y
que esté preparado para ser entregado al cliente con el mínimo esfuerzo
necesario. De esta manera no se deja para el final del proyecto ninguna actividad
arriesgada relacionada con la entrega de requisitos.
En cada iteración el equipo evoluciona el producto (hace una entrega incremental)
a partir de los resultados completados en las iteraciones anteriores, añadiendo
nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un
aspecto fundamental para guiar el desarrollo iterativo e incremental es la
priorización de los objetivos/requisitos en función del valor que aportan al cliente.
• Consejos para crear historias de usuario y comprender la función del
propietario del producto. ¿Qué son las historias de usuario? ¿Quién las
debería redactar? ¿Cuál es la diferencia que existe entre una epopeya y una
historia? ¿Cuál debería ser la longitud del trabajo incluido en la historia?
¿Quién es el propietario del producto en el proceso?
RTA: Definir quién utilizara la funcionalidad a desarrollar: Es útil imaginarnos
qué características tienen las personas que usarán el producto, y detallar su
necesidad y problemas actuales para dar lugar al entendimiento sobre sus
expectativas reales.
Para poder identificar más fácilmente quién es nuestro usuario podemos hacernos
preguntas como ¿Para qué usuario estamos trabajando en esta historia? ¿Qué
hace, en qué trabaja, cómo y dónde vive, cuántos años tiene? ¿Qué tecnología
sabe usar? ¿Le sería fácil aprender? ¿Para qué quiere usar la aplicación? ¿Qué
problemas se le presentan actualmente para resolver su necesidad?
Especificar qué producto quiere el usuario: Las historias de usuario deben
describir qué se espera como salida de la implementación, y cómo se ve
beneficiado el usuario final. Se expresa en lenguaje natural y sencillo, para poder
conversar directamente con ellos sobre el tema. Hay que considerar que los
usuarios finales tienden a desconocen el lenguaje técnico, por lo que deben
evitarse las palabras difíciles. Al usuario no le importa qué tecnología se usa, lo
que busca es que le ayudemos a resolver su problema, y cómo usará esta
solución; desea que sea simple, intuitiva y fácil de usar.
Para qué utilizará el producto: En este sentido es importante definir el contexto
donde surge la historia que se está creando. Esto ayudará a entender el valor
agregado que se dará, establecer el objetivo de construcción, y aporta la
posibilidad de explorar otras alternativas para llegar al mismo fin.
Los criterios de aceptación: Aquí se especifica qué salidas obtendremos cuando
finalice el proceso de ejecución de la funcionalidad, y nos sirve para verificar que
está terminada la funcionalidad. Está relacionada con las pruebas que se
realizaran para verificar el cumplimiento de la expectativa de diseño, usabilidad,
rendimiento, y la satisfacción del usuario.
Y finalmente, los comentarios: Las historias de usuarios facilitan la interacción
permanente con el cliente para verificar que lo que estamos construyendo está de
acuerdo a sus expectativas. Esta negociación se va registrando según se necesite
como comentarios o notas adicionales a tener en cuenta. Esta forma de trabajo
permite colaborar y mantener una comunicación fluida entre los miembros del
equipo. Así, la historia va cambiando durante la marcha de la iteración y se va
perfeccionando en conjunto
Las historias de usuario son pequeñas descripciones de los requerimientos de un
cliente. Su utilización es común cuando se aplica marcos de entornos ágiles como
Scrum. Al redactar las historias de usuario se debe tener en cuenta describir el
Rol, la funcionalidad y el resultado esperado en una frase corta. Debe venir
acompañada (al reverso) de los criterios de aceptación, hasta un máximo de 4 por
historia, redactado también en una frase que indique el contexto, el evento y el
comportamiento esperado ante ese evento.
Los elementos estructurales de las historias son las anécdotas, los personajes,
moraleja, el narrador, el tiempo, el espacio y el lenguaje figurativo. Empieza con la
presentación de una situación inicial, tras la cual se plantea un problema que a
veces tiene solución y otras no. La historia empieza o finaliza con una moraleja.
Los elementos esenciales de la historia son la presencia de un narrador
omnisciente, personajes en un lugar y tiempo, son intemporales. Otros aspectos
constitutivos de la fábula son los elementos fijos u objetos y los mutables o
proceso, los procesos pueden ser signo negativo o positivo.
El núcleo temático se resume en la acción del héroe, La estructura se articula a
partir de un narrador omnisciente, La ironía está excluida, En síntesis, los
elementos estructurales de la epopeya son:
Historia: Se desarrolla a partir de un solo asunto
Contenido: Acciones por oposición, personajes, dioses y semidioses o humanos.
Narrador: Omnisciente
Espacio y tiempo en la obra: No se puede ubicar con exactitud en todas las
epopeyas.
Lenguaje artístico y popular: Mediante epítetos, símiles, metáforas, etc.
Los tipos de epopeyas que existen son: clásicas, medievales y renacentistas
El propietario de producto es quien:
Decide en última instancia cómo será el resultado final, y el orden en el que se van
construyendo los sucesivos incrementos: qué se pone y qué se quita de la pila del
producto, y cuál es la prioridad de las funcionalidades.
Conoce el plan del producto, sus posibilidades y plan de inversión, así como del
retorno esperado a la inversión realizada, y se responsabiliza sobre fechas y
funcionalidades de las diferentes versiones de este.

• Consejos sobre cómo planificar y gestionar los registros a nivel del

producto, la versión y la iteración. Cada nivel de planificación tiene su propio
registro. ¿Qué deberían incluir estos registros diferentes? ¿Qué nivel de
estimación se requiere para cada nivel de planificación?
 Plan de Gestión del Cronograma
 Lista de Actividades con sus Atributos
 Calendarios de recursos: La información sobre la disponibilidad potencial de
recursos también se utiliza para estimar los recursos de las actividades.
Además de cuándo pueden estar disponibles, esta información también
incluye la consideración de otros aspectos, tales como las diversas
habilidades, experiencia y capacidades requeridos para los recursos
humanos. O, por ejemplo, las ubicaciones geográficas de los que están
disponibles.
 Registro de Riesgos: Salida del proceso 11.2 Identificar los Riesgos.
Determinados eventos asociados al riesgo pueden influir en la selección y
disponibilidad de los recursos. Las actualizaciones del registro de riesgos
se cuentan entre las actualizaciones de los documentos del proyecto.
 Factores ambientales: Se refiere a la disponibilidad y habilidades de los
recursos de la empresa.
 Activos de los procesos de la Organización: Políticas y procedimientos de
recursos humanos, relacionados con el alquiler y/o adquisición de equipos e
información histórica relevante.

• Técnicas para medir e interpretar la velocidad del equipo. ¿Qué clase de

información se puede extrapolar a partir de la velocidad del equipo?
RTA: Velocidad es la magnitud determinada por la cantidad de trabajo realizada
en un periodo de tiempo.
Velocidad en scrum técnico es la cantidad de trabajo realizada por el equipo en un
sprint. Así, por ejemplo, una velocidad de 150 puntos indica que el equipo realiza
150 puntos de trabajo en cada sprint.
Al trabajar en implantaciones de scrum pragmático, que pueden realizar sprints de
diferentes duraciones, o no siempre con el mismo número de miembros en el
equipo, la velocidad se expresa indicando la unidad de tiempo y en su caso
también si se refiere a la total del equipo, o a la media por persona. Así, por
ejemplo: “La velocidad media del equipo es de 100 puntos por semana.” “La
velocidad media de una persona del equipo es de 5 puntos por día.”