Tema5 - Metodologias Agiles

METODOLOGÍAS ÁGILES
Tema IX: Metodologías ágiles para el

desarrollo de software
¿Qué es la agilidad en el software?
El manifiesto ágil
La hoja de ruta de un proyecto ágil
El Product Owner
Las historias de usuario
Planificación y estimación ágil
Mediciones en desarrollos ágiles
Metodologías, desarrollo y calidad en

la ingeniería de software 2
Metodologías, desarrollo y
calidad en la ingeniería de
software 3
 La ingeniería del software ha ido madurando y evolucionando
aunque sigue inmersa en una “crisis del software”
 El % de proyectos fracasados sigue siendo elevado
2009 32 24 44
2006 35 19 46
2004 29 18 53
2002 34 15 51
2000 28 23 49
1998 26 28 46
1996 27 40 33
1994 16 31 53
Exitoso Fracasado Problemático
4
 La ingeniería del software es una disciplina especial que necesita un
tratamiento diferente a otras áreas científicas.
 Las metodologías ágiles son una buena opción para dirigir y gestionar
proyectos software.
 En el software las cosas suelen cambiar:
 Requisitos, diseño, negocio, tecnología, equipo de desarrollo,…
 Problema: Incapacidad para hacer frente a los cambios que se

producen

 Las metodologías ágiles se adaptan bien a:
 Proyectos donde los requisitos cambian constantemente
 Proyectos donde los tiempos de desarrollo son estrictos
 Siguen el modelo de proceso iterativo e incremental

 Beneficios del enfoque iterativo-incremental en una metodología ágil:
 Visión de progreso: Desde las etapas iniciales del proyecto de software se puede ver
trabajo operativo real del sistema a implementar.
 Feedback del cliente/usuario sobre un prototipo
 Gestión de riesgos: Los riesgos se van a gestionar mejor, ya que al resolver los
problemas del sistema a implementar por partes no se ha de realizar un análisis de
riesgos global del software.
 Aprendizaje y experiencia del equipo de desarrollo: Al realizar prototipos

operativos en cada iteración del sistema, se mejora exponencialmente el trabajo
aumentando la productividad y optimizando el proceso de desarrollo en cada iteración.
Curso online gratuito CIO Ágil

http://asier-ares.blogspot.com.es/2012/04/recopilacion-de-las-10-primeras.html
Agilidad aplicada a la ingeniería del software es la mejor manera de
responder a los cambios constantes del software (Jacobson, 2002)
Un equipo ágil de desarrollo de software es un equipo que colaborará de

una manera real para el éxito del proyecto (Jacobson, 2002)
La agilidad aplicada a la ingeniería de software es algo más que una

respuesta efectiva al cambio y el trabajo en equipo (Pressman, 2010)
El software se debe diseñar de tal manera que permita al equipo del

proyecto adaptarse a las tareas que van surgiendo de manera continua,
eliminando todo trabajo que no vaya orientado al cliente, poniendo énfasis
en la entrega incremental para que se pueda ir validando y mejorando lo
que ya esté implementado (Pressman, 2010)

 Aspectos vinculados al desarrollo de software en los que se asienta el
proceso ágil para su implantación (Pressman, 2010):
 Predecir qué requisitos del sistema van a mantenerse y cuáles se van a

cambiar no es una tarea sencilla.
 En el desarrollo de software las fases de diseño e implementación se solapan

en el tiempo, por lo que los modelos de diseño se van probando a medida
que se van desarrollando. Por ello, resulta complejo determinar el diseño
necesario que se ha de realizar para implementarlo e ir probando el sistema.
 A la hora de planificar el proyecto software, intentar estimar lo que va a llevar

el análisis, diseño, implementación y prueba del software se convierte en una
tarea bastante complicada, ya que no resulta nada predecible en la mayoría
de los casos.
software 10
 Manifiesto escrito en Utah (2001) por profesionales de renombre en la
ingeniería del software.
 Propuestas de desarrollo ágil más utilizadas:

 Extreme Programming (XP)
 Scrum
 Dynamic Systems Development Method (DSDM)
 Crystal
 Objetivo: Establecer una serie de valores y principios que permitieran

el desarrollo de software de calidad, de una manera rápida y que se
adaptará bien a los requisitos cambiantes.

http://www.agilemanifesto.org/iso/es/
 12 Principios fundamentales del manifiesto para el desarrollo ágil del
software:
1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en periodos de un par de
semanas hasta un par de meses, con preferencia en los periodos breves.
4. Las personas del negocio y los desarrolladores deben trabajar juntos de
forma cotidiana a través del proyecto.
5. Construcción de proyectos en torno a individuos motivados, dándoles la
oportunidad y el respaldo que necesitan y procurándoles confianza para que
realicen la tarea.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta
dentro de un equipo de desarrollo es mediante la conversación cara a cara.

 12 Principios fundamentales del manifiesto para el desarrollo ágil del
software:
7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los
patrocinadores, desarrolladores y usuarios deben mantener un ritmo
constante de forma indefinida.
9. La atención continua a la excelencia técnica enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que no se
hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que
se auto-organizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más
efectivo y ajusta su conducta en consecuencia.

 A pesar de la sencillez del manifiesto, se han dado malinterpretaciones:
 Ausencia total de documentación
 Ausencia total de planificación
 El cliente hará todo el trabajo y adoptará el rol de jefe de proyecto
 El equipo de desarrollo puede cambiar de metodología sin ninguna

justificación

software 16
 El proceso ágil se debe adaptar a las necesidades de las personas
y del equipo.
 Características del equipo:

 Competencia
 Enfoque común
 Colaboración
 Habilidad para tomar decisiones
 Capacidad para resolver problemas difusos
 Confianza y respeto mutuos
 Organización propia

 La planificación ágil plantea tres niveles de abstracción (Garzás, 2013):
 Planificación de la hoja de ruta
 Planificación de la creación de
una entrega
 Planificación de cada iteración

del software

 Propietario del producto:
 Persona que tiene una visión muy clara y conocimiento profundo del
software que se va a desarrollar y que es capaz de transmitir esa visión a
todo el equipo de desarrollo
 Responsabilidades del product owner:
 Gestionar la comunicación entre todos los stakeholders
 Gestionar el trabajo que se ha de realizar
 Determinar el orden de las entregas
 Determinar las funcionalidades contempladas en cada entrega

software 20
 Origen en el modelo de proceso ágil XP
 Unidad más pequeña posible de valor para el negocio
 Representan el mecanismo para recoger los requisitos que el sistema

ha de implementar
 Patrón:
 “Como (rol o tipo de usuario), (quiero | podré | seré capaz | necesitaré | …)

con el beneficio de …”
 Suelen escribirse en post-it describiendo funcionalidades que se han

de satisfacer, pero no especifican cómo se han de desarrollar

software 22
 Una historia de usuario lleva asociado 2 aspectos de gran importancia:
 La conversación que llevan de manera implícita, ya que las historias de

usuario constituyen una herramienta para que los stakeholders puedan
interactuar.
 El determinar cómo se confirma su implementación, las pruebas a realizar

y la verificación de las mismas.
 Una historia de usuario no dará nunca tanto detalle como un requisito

software. No hay que confundirlos.

 Lo primero que hay que hacer es determinar la lista de funcionalidades
que el sistema debe implementar, es decir, crear las historias de
usuario.
 Lo siguiente sería darles prioridad según:
 Valor: Importancia que le da el cliente o el usuario final a las historias de

usuario
 Estimación: Del coste de desarrollo en unidades que representan el tiempo
teórico de desarrollo/persona

 El valor de una historia de usuario se puede
calcular en base a:
 Los beneficios que se obtienen con su implementación
 Las pérdidas que se podrían producir en caso de posponer su

implementación
 Los riesgos que tiene asociados
 Su alineación con el negocio
 El valor añadido que puede aportar con respecto a productos similares

de la competencia
 Planning Poker :
 Técnica utilizada para la estimación en proyectos ágiles por su

simplicidad y bajo coste
 Se basa en el consenso
 Los participantes usan una baraja numerada según la secuencia

Fibonacci, para reflejar la incertidumbre inherente a la estimación de
las tareas en un desarrollo de software
 Además, hay dos cartas adicionales:
 Una con una interrogación que representa que falta información
 Otra con una taza de café para realizar descansos

software 27
 Siempre existen dudas a la hora de elegir qué tipo de mediciones se deben
usar para desarrollar software adoptando un enfoque ágil.
 Un cuadro de mando ágil debe incluir métricas, gráficos y herramientas con el

fin de agrupar en un mismo sitio todo aquello que facilite el trabajo del equipo
de desarrollo y su comunicación con el cliente, de cara a un buen
funcionamiento y control del proceso de desarrollo de software.

Clasificación Indicador Descripción
Cantidad de trabajo que el equipo de desarrollo puede realizar en una iteración del proyecto. Se debe
indicar el ratio con el cual el equipo convierte historias de usuario en incrementos potencialmente
entregables. Así, se va viendo la velocidad estimada y la velocidad real que tiene el equipo. Una vez
Velocidad conocida la velocidad del equipo de desarrollo se puede utilizar para estimar en la siguiente iteración del
proyecto. Además, con el histórico de la velocidad del equipo se puede ir ajustando la estimación del
Productividad proyecto para que sea más realista.
Tasas de crecimiento, o de decrecimiento, de las velocidades del equipo de desarrollo respecto a un

periodo de referencia en base a la siguiente fórmula:
Aceleración (𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑𝑖𝑡𝑒𝑟𝑎
𝑐ó
𝑛𝑛 − 𝑣 𝑒𝑙𝑜
𝑐𝑖𝑑
𝑎 𝑐ó
𝑑𝑖𝑡𝑒𝑟𝑎𝑛0 )
𝐴𝑐𝑒𝑙𝑟𝑎𝑐𝑖ó𝑛=
𝑣
𝑒𝑙𝑜
𝑐𝑖𝑑
𝑎 𝑐ó
𝑑𝑖𝑡𝑒𝑟𝑎𝑛(0)
Gráfico que refleja el avance del equipo de desarrollo hasta un momento concreto. Se suele medir el
número de historias que se llevan implementadas hasta ese momento, en relación al esfuerzo total que
Gráficos de progreso hace falta para poder terminar el proyecto. Permite apreciar lo que falta para implementar el sistema en
su totalidad.
Progreso del Cantidad de funcionalidades que han superado las pruebas de aceptación. Este indicador favorece
proyecto Funcionalidades probadas y también la agilidad y productividad del equipo de desarrollo. Para que realmente sea útil es importante
aceptadas (del inglés que las historias de usuario se definan con un buen nivel de granularidad. Además, según se vayan
Running Tested Features, añadiendo más funcionalidades al proyecto se deberán volver a aplicar las pruebas de aceptación a todas
RTF) las funcionalidades ya implementadas.
Adaptación de la técnica tradicional de gestión de proyectos conocida como Earned Value Management
(EVM) que mide el rendimiento del proyecto en relación a su línea base, es decir, en relación a lo que se
había planificado. Con el uso de esta técnica se trata de identificar las posibles desviaciones en tiempo y
Valor presupuesto. EVM-Ágil dará a conocer a los clientes y al equipo de desarrollo de qué forma se está
entregado y EVM-Ágil (del inglés obteniendo el valor esperado, cuál es el retorno de inversión y su velocidad haciendo uso en este caso de
retorno de AgileEVM)
los puntos de historia como la medida a utilizar para realizar los cálculos. Por tanto, para poder hacer uso
inversión
de esta técnica, será necesario realizar una planificación inicial de las iteraciones, una planificación
de las historias de usuario que se van a incluir en cada iteración y el valor que se le da a cada historia de
usuario.
Herramienta que muestra la lista priorizada de incidencias abiertas, con el objetivo de solventar los
Gestión de
Impediment Backlog problemas que están impidiendo un progreso adecuado del desarrollo de las funcionalidades en cada
riesgos
iteración.

Gracias…
Tema IX: Metodologías ágiles para el

desarrollo de software

Tema5 - Metodologias Agiles

Cargado por

Copyright:

Formatos disponibles

Tema5 - Metodologias Agiles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema5 - Metodologias Agiles

Cargado por

Copyright:

Formatos disponibles

METODOLOGÍAS ÁGILES

Tema IX: Metodologías ágiles para el

La hoja de ruta de un proyecto ágil

Las historias de usuario

Planificación y estimación ágil

Mediciones en desarrollos ágiles

Metodologías, desarrollo y calidad en

 El % de proyectos fracasados sigue siendo elevado

Exitoso Fracasado Problemático

 En el software las cosas suelen cambiar:

 Requisitos, diseño, negocio, tecnología, equipo de desarrollo,…

 Problema: Incapacidad para hacer frente a los cambios que se

Metodologías, desarrollo y calidad en

 Proyectos donde los requisitos cambian constantemente

 Proyectos donde los tiempos de desarrollo son estrictos

 Siguen el modelo de proceso iterativo e incremental

Metodologías, desarrollo y calidad en

 Feedback del cliente/usuario sobre un prototipo

 Aprendizaje y experiencia del equipo de desarrollo: Al realizar prototipos

Curso online gratuito CIO Ágil

Un equipo ágil de desarrollo de software es un equipo que colaborará de

La agilidad aplicada a la ingeniería de software es algo más que una

El software se debe diseñar de tal manera que permita al equipo del

Metodologías, desarrollo y calidad en

 Predecir qué requisitos del sistema van a mantenerse y cuáles se van a

 En el desarrollo de software las fases de diseño e implementación se solapan

 A la hora de planificar el proyecto software, intentar estimar lo que va a llevar

 Propuestas de desarrollo ágil más utilizadas:

 Objetivo: Establecer una serie de valores y principios que permitieran

Metodologías, desarrollo y calidad en

1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega

Metodologías, desarrollo y calidad en

7. El software que funciona es la principal medida del progreso.

Metodologías, desarrollo y calidad en

 Ausencia total de documentación

 Ausencia total de planificación

 El cliente hará todo el trabajo y adoptará el rol de jefe de proyecto

 El equipo de desarrollo puede cambiar de metodología sin ninguna

Metodologías, desarrollo y calidad en

 Características del equipo:

Metodologías, desarrollo y calidad en

 Planificación de la hoja de ruta

 Planificación de cada iteración

Metodologías, desarrollo y calidad en

 Responsabilidades del product owner:

 Gestionar la comunicación entre todos los stakeholders

 Gestionar el trabajo que se ha de realizar

 Determinar el orden de las entregas

 Determinar las funcionalidades contempladas en cada entrega

Metodologías, desarrollo y calidad en

 Unidad más pequeña posible de valor para el negocio

 Representan el mecanismo para recoger los requisitos que el sistema

 “Como (rol o tipo de usuario), (quiero | podré | seré capaz | necesitaré | …)

 Suelen escribirse en post-it describiendo funcionalidades que se han

Metodologías, desarrollo y calidad en

 La conversación que llevan de manera implícita, ya que las historias de

 El determinar cómo se confirma su implementación, las pruebas a realizar

 Una historia de usuario no dará nunca tanto detalle como un requisito

Metodologías, desarrollo y calidad en