Idiomas
Páginas
Jurídico
Clase 4:
Metodologías Ágiles - parte I
Ingeniería de Software
Clase 1
Objetivos 2
Conocer las metodologías ágiles y su diferencia con los
métodos tradicionales
Comprender el concepto de Historias de Usuario y su
formulación para los proyectos ágiles
Entender SCRUM y su aplicación en los proyectos de
desarrollo
Temas 3
Metodologías ágiles
Desarrollo dirigido por un plan vs. desarrollo ágil
Administración de un proyecto ágil
Historias de Usuario
SCRUM
Metodologías Ágiles 4
Antecedentes
La definición moderna del desarrollo ágil de software
evolucionó a mediados de los 90s. como parte de una
reacción contra los métodos de “peso pesado”, muy
estructurados y estrictos, extraídos del modelo de desarrollo
en cascada.
El proceso originado del uso del modelo en cascada era
visto como burocrático, lento e inconsistente con las formas
de desarrollo de software que realmente realizaban un
trabajo eficiente
Metodologías Ágiles 5
Antecedentes
RAD o Rapid Application Development tiende a englobar
también la usabilidad, utilidad y la rapidez de ejecución
Entorno de desarrollo altamente productivo (con prototipos
y herramientas CASE)
Grupos pequeños de programadores
Herramientas que generaban código tomando como
entradas sintaxis de alto nivel
Metodologías Ágiles 6
Antecedentes
En el 2001, tras una reunión celebrada en Utah, EE.UU. Por
17 críticos de los modelos de desarrollo basado en procesos
nace formalmente el término ágil aplicado al desarrollo
Los integrantes de la reunión resumieron los principios sobre
los que se basan los métodos alternativos en cuatro
postulados, lo que ha quedado denominado como
Manifiesto Ágil
Valores de las metodologías ágiles 7
Según el manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo
sobre el proceso y las herramientas
Desarrollar software que funciona más que conseguir una
buena documentación
La colaboración con el cliente más que la negociación de un
contrato
Responder a los cambios más que seguir estrictamente un
plan
Principios de las metodologías ágiles 8
1. Nuestra prioridad principal es satisfacer al cliente a través
de entregas de software valioso, de forma temprana y
continua
2. Los cambios a los requisitos son bienvenidos, aun así sean
tardíos. Los procesos ágiles aprovechan el cambio para
otorgar una ventaja competitiva al cliente.
3. Entregar software operativo frecuentemente, en un
período entre dos semanas y dos meses, con preferencia a
escalas de tiempo más cortos.
Principios de las metodologías ágiles 9
4. Las personas del negocio y los desarrolladores deben
trabajar juntos diariamente a lo largo de todo el
proyecto.
5. Ejecutar proyectos con personas motivadas. Brindar el
ambiente y soporte que ellos necesitan, y la confianza de
que ellos podrán realizar el trabajo requerido.
6. El método más eficiente y efectivo para transmitir la
información hacia el equipo son las conversaciones cara a
cara.
Principios de las metodologías ágiles 10
7. El software operativo es la principal medición del avance.
8. Los procesos ágiles promueven el desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deben ser
capaces de mantener el paso constante indefinidamente.
9. Una continua atención hacia un buen diseño y la
excelencia técnica mejora la agilidad.
10. a simplicidad como el arte de maximizar la cantidad de
trabajo que no se hace, es esencial.
Principios de las metodologías ágiles 11
11. Las mejores arquitecturas, requisitos, y diseños surgen de
los equipos organizados por sí mismos.
12. En intervalos regulares, el equipo reflexiona respecto a
cómo trabaja de forma más efectiva, entonces afina y
ajusta su comportamiento adecuadamente
¿Qué es una metodología ágil? 12
Agilidad
Capacidad para adaptar el curso del desarrollo a la evolución de
los requisitos y a las circunstancias del entorno.
La agilidad y el costo del cambio
Los costos aumentan con rapidez y no son pocos el tiempo y el
dinero requeridos para asegurar que se haga el cambio sin efectos
colaterales no intencionados
¿Qué es una metodología ágil? 13
Consiste en desarrollar una pequeña parte del software
que se desea construir. De esta forma, el cliente nos indica si
vamos por el buen camino, estableciendo aquellas partes
que le son más relevantes y así juntos, nos aseguramos de
que construimos una aplicación que añadirá valor a su
negocio
Minimiza riesgos desarrollando software en cortos lapsos de
tiempo
¿Qué es una metodología ágil? 14
Las metodologías ágiles de desarrollo están especialmente
indicadas en proyectos con requisitos poco definidos o
cambiantes
Capacidad de respuesta a cambios de requisitos a lo largo
del desarrollo
Entrega continua y en plazos breves de software funcional
Las metodologías ágiles y la
documentación 15
Aunque el manifiesto ágil no rechaza el que se documente
en los proyectos, sí antepone otras muchas cosas frente a
documentar, y muchos proyectos han interpretado esto como
que en un proyecto ágil no se debe escribir ningún
documento.
Esto es un error y muchos proyectos con los años han sufrido
mucho este problema, e incluso se han visto imposibilitados
a la hora de cambiar de proveedor de desarrollo software.
Documentar de manera ágil, pero documentar.
Desarrollo dirigido por un plan vs.
Desarrollo ágil 16
Desarrollo basado en un Plan
Desarrollo ágil
Desarrollo dirigido por un plan vs.
Desarrollo ágil 17
Está bastante aceptado y documentado, que el desarrollo
ágil es más idóneo en proyectos con cambios considerables
La realidad en las empresas parece que refleja posturas
más moderadas, híbridas y orientadas por la necesidad,
negocio y mejor práctica para cada organización
Existen dos tipos de organizaciones: las flexibles (poco
jerárquicas, poco burocráticas, etc.) y las rígidas todo lo
contrario, siendo una de las principales razones para no
migrar de métodos formales a ágiles “la cultura rígida” de
la organización.
Desarrollo dirigido por un plan vs.
Desarrollo ágil 18
Según el tipo de organización y el tipo de proyecto
Los métodos formales son más apropiados para
organizaciones rígidas con proyectos estables
Los métodos ágiles son más apropiados en organizaciones
flexibles con proyectos cambiantes
Los métodos iterativos-formales son más apropiados para
organizaciones rígidas con proyectos cambiantes, y
Los métodos ágiles optimizados o con algo de diseño
“upfront” son más apropiados en organizaciones flexibles
con proyectos estables
Desarrollo dirigido por un plan vs.
Desarrollo ágil 19
En recomendado un proceso ágil cuando:
Requiere entregas pequeñas de software, con ciclos rápidos.
Puede ser cooperativo. Cliente y desarrolladores pueden
trabajan juntos constantemente con una cercana
comunicación.
Es sencillo. El método en sí mismo es simple, fácil de
aprender y modificar.
Se necesita que sea adaptable. Permite realizar cambios
de último momento.
Desarrollo dirigido por un plan vs.
Desarrollo ágil 20
No es recomendado un proceso ágil en:
Aplicaciones distribuidas. Las pruebas unitarias son
complicadas de aplicar entre componentes. Sería necesario
construir una arquitectura de pruebas para probar
directamente los componentes
Aplicaciones que requieren seguir un diseño estricto. Por
ejemplo: sistemas operativos, software de telecomunicaciones.
Aplicaciones que requieren una documentación exhaustiva. Por
ejemplo: sistemas militares, médicos o industriales.
Desarrollo dirigido por un plan vs.
Desarrollo ágil 21
No es recomendado un proceso ágil en:
Proyectos muy grandes. La comunicación entre los miembros
del equipo es difícil de conseguir.
Proyectos escritos en lenguajes no orientados a objetos.
Lenguajes como C, Pascal, Cobol o Fortran hacen imposible
técnicas como la refactorización.
Desarrollo dirigido por un plan vs.
Desarrollo ágil 22
Tabla comparativa
Administración de un proyecto ágil 23
Énfasis en clientes y productos
Valor para los clientes a través de productos innovadores,
énfasis en:
Entregar valor a los clientes
Emplear entregas iterativas y basadas en características funcionales
Promover la excelencia técnica
Los procesos confiables se enfocan en las salidas, no en las
entradas
Los procesos confiables permiten producir productos
orientados a satisfacer necesidades de los clientes
Administración de un proyecto ágil 24
Liderazgo colaborativo
Los equipos son responsables de su rendimiento, de que
resultados alcanzan y del uso de sólidos principios de
ingeniería
Los reportes periódicos, o más bien las entregas continuas
de funcionalidad incremental, ayudan a la comunidad del
proyecto a determinar que adaptaciones realizar
No renuncia al control, sí valora la responsabilidad y revisa
la definición de qué controlar
Administración de un proyecto ágil 25
Marco de trabajo auto-organizado
Implica conseguir la gente correcta
Articular la visión del producto, sus límites y los roles en el
proyecto
Promover la interacción y flujo de información entre equipos
Facilitar la toma de decisión participativa
Insistir en la responsabilidad
Ventajas de las metodologías
ágiles 26
Rápida respuesta a cambios de requisitos a lo largo del
desarrollo.
Entrega continua y en plazos cortos de software funcional.
Trabajo conjunto entre el cliente y el equipo de desarrollo.
Minimiza los costos frente a cambios.
Mejora continua de los procesos y el equipo de desarrollo.
Evita malentendidos de requerimientos entre el cliente y el
equipo.
Cada componente del producto final ha sido probado y
satisface los requerimientos.
Metodologías ágiles 27
Programación Extrema (XP)
SCRUM
Crystal
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)
Lean Development (LD)
Historias de Usuario 28
Es la técnica utilizada para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las características que el sistema debe
poseer, sean funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinámico y
flexible. Cada historia de usuario debe ser lo suficientemente
comprensible y delimitada.
Se puede definir como el recordatorio de una conversación
con el cliente.
Historias de Usuario 29
Para efectos de planificación, las historias pueden ser de una
a tres semanas de tiempo de programación
Las historias de usuario son descompuestas en tareas de
programación y asignadas a los programadores para ser
implementadas durante una iteración.
Existen varias plantillas sugeridas pero no existe un consenso
al respecto. En muchos casos sólo se propone utilizar un
nombre y una descripción o sólo una descripción, más quizás
una estimación de esfuerzo en días.
Historias de Usuario 30
Estructura básica de una historia de usuario
Historias de Usuario 31
Debe haber al menos una historia por cada característica
importante, y se sugiere realizar una o dos historias por
programador por mes.
Si se tienen menos, probablemente sea conveniente dividir
las historias, si se tienen más lo mejor es disminuir el detalle
y agruparlas.
Regla básica para escribir una historia de usuario:
Historias de Usuario 32
Al comienzo de cada iteración estarán registrados los
cambios en las historias de usuario y según eso se
planificará la siguiente iteración
Un cuadro resumen de historias de usuario sería
Historias de Usuario 33
Formato de historia de usuario en la documentación
Historias de Usuario 34
Principio INVEST
Independiente
La historia de usuario no debe depender de otra historia ya que
esto facilitará la priorización de las mismas. Si por alguna razón la
historia de usuario es dependiente se recomienda fusionarlas
Negociable
La historia de usuario puede cambiar y evolucionar a lo largo de la
ejecución del proyecto, incluso podría dejar de tenerse en cuenta si
así el cliente lo desea
Valiosa
La historia de usuario debe brindar valor al proyecto y al usuario
final.
Historias de Usuario 35
Principio INVEST
Estimable
La historia de usuario debe tener el tiempo que ésta tomará en
implementarse
Pequeña (Small)
La historia de usuario debe ser pequeña y concisa. Si una historia
de usuario es muy grande ésta se debe dividir en otras historias
más pequeñas, esto con el fin de poder tener un mejor control sobre
ellas.
Testeable
La historia de usuario debe poderse probar en un proceso de
calidad
SCRUM 36
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike
Beedle. Define un marco para la gestión de proyectos, que
se ha utilizado con éxito durante los últimos 10 años.
Está especialmente indicada para proyectos con un rápido
cambio de requisitos.
La palabra scrum procede del rugby, donde designa al
acto de preparar el avance del equipo en unidad para
ganar el balón.
SCRUM 37
Es una metodología ágil que define un marco de trabajo para
la gestión y desarrollo de software basada en un proceso
iterativo e incremental.
Sus principales características se pueden resumir en dos:
Se basa en iteraciones, denominadas Sprints, con una duración de
no más de 30 días. El resultado de cada Sprint es un incremento
ejecutable que se muestra al cliente.
La segunda característica importante son las reuniones a lo largo
del proyecto. Una reunión diaria de 15 minutos del equipo de
desarrollo para coordinación e integración.
SCRUM - Marco de trabajo 38
SCRUM - Roles 39
Product Owner
Es el responsable oficial del proyecto, gestión, control y visibilidad
de la lista de acumulación o lista de retraso del producto. Toma las
decisiones finales de las tareas asignadas al registro. Representa la
voz del cliente
Scrum Máster o facilitador
Responsable del proceso Scrum, de cumplir la meta y resolver los
problemas. Así como también de asegurarse que el proyecto se
lleve a cabo de acuerdo con las prácticas, valores y reglas de
Scrum y que progrese según lo previsto
SCRUM - Roles 40
Team
Responsable de transformar las historias de usuario de la iteración
en un incremento de la funcionalidad del software
El equipo tiene la responsabilidad de entregar el producto.
Generalmente son equipos de 3 a 9 personas con las habilidades
transversales necesarias para realizar el trabajo.
Customer
Se refiere a las personas que hacen posible
el proyecto y para quienes el proyecto
producirá un beneficio acordado. Participa
directamente durante las pruebas del Sprint.
SCRUM - Elementos 41
Product Backlog
Son los requerimientos priorizados y revisados llamados también la
pila de producto. Este es una forma de registrar y organizar el
trabajo pendiente para el producto (actividades y requerimientos)
Sprint
Es el periodo de tiempo durante el que se desarrolla un incremento
funcional. Constituye el núcleo de Scrum, que divide de esta forma
el desarrollo de un proyecto en un
conjunto de pequeñas “carreras”.
SCRUM - Elementos 42
Sprint Backlog
Lista de tareas determinadas por el equipo para realizar en un
Sprint. Se determinan durante el planeamiento del Sprint.
Se realiza la estimación y se actualiza día a día.
SCRUM - Elementos 43
Scrum diario
Se asume que el proceso es complejo y que es necesario
inspeccionarlo frecuentemente, por eso se realiza una reunión diaria
de seguimiento
Se actualiza el Sprint Backlog con la nueva información.
Burn down chart
Es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de
cada Sprint. Dibujando una línea que
conecte los puntos de todos los Sprints
completados, podremos ver el progreso
del proyecto.
SCRUM - Sprint 44
Es el período en el cual se lleva
a cabo el trabajo en sí.
Al inicio se lleva a cabo la
reunión de planificación del
sprint, en donde se selecciona
que trabajo se hará
Al final de cada sprint, el equipo
deberá presentar los avances
logrados y el resultado obtenido
es un producto potencialmente
entregable al cliente.
SCRUM – Sprint 45
Es recomendado que la duración de los sprints sea constante y
definida por el equipo con base en su propia experiencia.
Asimismo se recomienda no agregar objetivos al sprint o sprint
backlog a menos que la falta de estos objetivos amenace al
éxito del proyecto. La constancia permite la concentración y
mejora la productividad del equipo de trabajo
SCRUM 46
En resumen:
SCRUM – Síntomas de desviación 47
Pérdida del ritmo. Síntoma: Los sprint no duran siempre lo
mismo.
El Scrum Master asigna el trabajo. Síntoma: El trabajo es
principalmente asignado por el Scrum Master sin tener en
cuenta al equipo.
Las reuniones diarias son para el Scrum Master. Síntoma: Las
reuniones diarias sirven solo para poner al corriente al
Scrum Master.
Resumen 48
Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos
Las metodologías ágiles se caracterizan por su sencillez, tanto en su aprendizaje como en su aplicación; sin embargo, gozan tanto de ventajas como de inconvenientes
Las metodologías ágiles permiten a los pequeños grupos de desarrollo concentrarse en la tarea de construir software fomentando prácticas de fácil adopción y en un entorno ordenado que permiten que los proyectos finalicen exitosamente
A pesar de las críticas que sufren, son usadas por muchas grandes empresas y se han utilizando en grandes sistemas, lo que hace prever que estas metodologías han llegado para quedarse
¿Preguntas? 49
¿Cuándo es recomendable usar una
metodología ágil?
Referencias 50
Ingeniería de Software: Un enfoque práctico (7ma edición) Roger S.
Pressman
Capítulo 3: Desarrollo Ágil
Ingeniería de Software. Un enfoque desde la guía SWEBOK (1ra. edic.)
Salvador Sánchez, Miguel Ángel Sicilia, Daniel Rodríguez
Capítulo 2: Modelos y procesos
Ingeniería del Software (9na edición) Ian Sommerville
Capítulo 3: Desarrollo ágil de software
Links:
http://www.slideshare.net/profetiacademico/metodologias-agiles-9395911
http://www.comunidadesmicrosoft.org/blogs/angel-karl/los-12-principios-
de-las-metodolog-giles
https://www.scrum.org/resources/what-is-scrum/
http://scrummethodology.com/
Top Related