IS1_Cap3_Desarrollo_Agil

Vista previa del material en texto

Ingeniería de 
Software I 
Roger S. Pressman
Ingeniería de Software. Un 
Enfoque Práctico
Septima edicion
E-commerce: Business. Techology. 
Society.
Slide 8-1
Aspectos éticos, sociales y 
políticos en el Comerci
Roger S. Pressman
Copyright © 2011 Pearson Education, Inc.
CAPÍTULO 3.
Desarrollo de software Ágil.
Objetivos
A través de este capítulo el estudiante:
 Comprenderá las razones de los métodos de desarrollo ágil 
de software, el manifiesto ágil, así como las diferencias 
entre el desarrollo ágil y el dirigido por un plan;
 Conocerá las prácticas clave en la programación extrema y 
cómo se relacionan con los principios generales de los 
métodos ágiles;
 Entenderá el enfoque de Scrum para la administración de 
un proyecto ágil;
 Reconocerá los conflictos y problemas de escalar los 
métodos de desarrollo ágil para el diseño de sistemas de 
software grandes.
Desarrollo Ágil de Aplicaciones.
Los procesos de desarrollo del software rápido se diseñan para producir
rápidamente un software útil. El software no se desarrolla como una
serie de incrementos, y cada uno de ellos incluye una nueva
funcionalidad del sistema. comparten algunas características
fundamentales:
 Los procesos de especificación, diseño e implementación están
entrelazados. No existe una especificación detallada del sistema, y la
documentación del diseño se minimiza o es generada
automáticamente por el entorno de programación
 El sistema se desarrolla en diferentes versiones. Los usuarios finales y
otros colaboradores del sistema intervienen en la especificación y
evaluación de cada versión.
 Las interfaces de usuario del sistema se desarrollan usando con
frecuencia un sistema de elaboración interactivo, que permita que el
diseño de la interfaz se cree rápidamente en cuanto se dibujan y
colocan iconos en la interfaz.
Manifiesto
La filosofía detrás de los métodos ágiles se refleja en el
manifiesto ágil, que acordaron muchos de los desarrolladores
líderes de estos métodos. Este manifiesto afirma:
 Estamos descubriendo mejores formas para desarrollar
software, al hacerlo y al ayudar a otros a hacerlo. Gracias a
este trabajo llegamos a valorar:
 A los individuos y las interacciones sobre los procesos y las
herramientas Al software operativo sobre la documentación
exhaustiva
 La colaboración con el cliente sobre la negociación del
contrato La respuesta al cambio sobre el seguimiento de un
plan
 Esto es, aunque exista valor en los objetos a la derecha,
valoraremos más los de la izquierda.
Métodos de Desarrollo Ágil
 Programación Extrema (XP)
 SCRUM
 De Desarrollo de Software Adaptativo
 Desarrollo dirigido a Características
El éxito de dichos métodos condujo a cierta integración con
métodos más tradicionales de desarrollo, basados en el
modelado de sistemas, lo cual resulta en la noción de
modelado ágil y ejemplificaciones ágiles del Proceso
Unificado
Características Comunes XP y SCRUM
Los métodos ágiles han tenido mucho éxito para ciertos tipos de
desarrollo de sistemas:
1. Desarrollo del producto, donde una compañía de software
elabora un producto pequeño o mediano para su venta.
2. Diseño de sistemas a la medida dentro de una
organización, donde hay un claro compromiso del cliente
por intervenir en el proceso de desarrollo, y donde no
existen muchas reglas ni regulaciones externas que
afecten el software.
Principios de Desarrollo Ágil
Principio Descripcióm
Participación del 
Cliente
Los clientes deben intervenir estrechamente durante 
el proceso de desarrollo.
Entrega Incremental El software se desarrolla en incrementos y el cliente 
especifica los requerimientos que se van a incluir en 
cada incremento.
Personas, No Procesos Tienen que reconocerse y aprovecharse las 
habilidades del equipo de desarrollo
Adoptar el Cambio Esperar a que cambien los requerimientos del sistema 
y, de este modo, diseñar el sistema para adaptar 
dichos cambios.
Mantener Simplicidad Enfocarse en la simplicidad tanto en el software a 
desarrollar como en el proceso de desarrollo.
Principios
 Es atractiva la idea del involucramiento del cliente en el proceso de 
desarrollo, su éxito radica en tener un cliente que desee y pueda 
pasar tiempo con el equipo de desarrollo.
 Quizás algunos miembros del equipo no cuenten con la 
personalidad adecuada para la participación intensa característica 
de los métodos ágiles
 Priorizar los cambios sería difícil, sobre todo en sistemas donde 
existen muchos participantes
 Mantener la simplicidad requiere trabajo adicional
 Muchas organizaciones pasan años cambiando su cultura, de tal 
modo que los procesos se definan y continúen.
Desarrollo dirigido por un Plan y Desarrollo 
Ágil
Para decidir sobre el equilibrio entre un enfoque basado en un plan y uno 
ágil, se deben responder algunas preguntas técnicas, humanas y 
organizacionales:
 ¿Es importante tener una especificación y un diseño muy detallados 
antes de dirigirse a la implementación? un enfoque basado en un 
plan.
 ¿Es práctica una estrategia de entrega incremental, donde se dé el 
software a los clientes y se obtenga así una rápida retroalimentación 
de ellos? Considere el uso de métodos ágiles.
 ¿Qué tan grande es el sistema que se desarrollará? Los métodos ágiles 
son más efectivos cuando el sistema logra diseñarse con un pequeño 
equipo asignado que se comunique nformalmente
 ¿Qué tipo de sistema se desarrollará? Los sistemas que demandan 
mucho análisis antes de la implementación necesitan un diseño 
bastante detallado. Quizá sea mejor un enfoque basado en un plan.
Desarrollo dirigido por un Plan y Desarrollo Ágil
 ¿Cuál es el tiempo de vida que se espera del sistema? Los sistemas 
con lapsos de vida prolongados podrían requerir más documentación 
de diseño, para comunicar al equipode apoyo los propósitos originales 
de los desarrolladores del sistema. los defensores de los métodos 
ágiles argumentan acertadamente que con frecuencia la 
documentación no se conserva actualizada, ni se usa mucho para el 
mantenimiento del sistema a largo plazo.
 ¿Qué tecnologías se hallan disponibles para apoyar el desarrollo del 
sistema? Los métodos ágiles se auxilian a menudo de buenas 
herramientas para seguir la pista de un diseño en evolución
 ¿Cómo está organizado el equipo de desarrollo? Si el equipo de 
desarrollo está distribuido, o si parte del desarrollo se subcontrata, 
entonces tal vez se requiera elaborar documentos de diseño para 
comunicarse a través de los equipos de desarrollo.
Desarrollo dirigido por un Plan y Desarrollo Ágil
 ¿Existen problemas culturales que afecten el desarrollo del sistema? 
Las organizaciones de ingeniería tradicionales presentan una cultura 
de desarrollo basada en un plan, pues es una norma en ingeniería. 9. 
¿Qué tan buenos son los diseñadores y programadores en el equipo 
de desarrollo?
 Se argumenta en ocasiones que los métodos ágiles requieren niveles 
de habilidad superiores a los enfoques basados en un plan, en que los 
programadores simplemente traducen un diseño detallado en un 
código. 
 ¿El sistema está sujeto a regulación externa? Si un regulador externo 
tiene que aprobarel sistema (por ejemplo, la Agencia de Aviación 
Federal [FAA] estadounidense aprueba el software que es crítico para 
la operación de una aeronave), entonces, tal vez se le requerirá 
documentación detallada como parte del sistema de seguridad
Desarrollo dirigido por un Plan y Desarrollo Ágil
Slide 8-14
Programación Extrema (XP)
Programación Extrema (XP)
El ciclo de liberación de la programación extrema
Principios XP
 Planeación Incremental 
(The Planning Game)
 Pequeñas entregas 
(small releases)
 Metáfora (Metaphor)
 Diseño Simple (Simple 
Design)
 Pruebas (Testing)
 Refactorzación
(Refactoring)
 Programación en 
Parejas (Pair
Programming)
 Propiedad Colectiva 
(Collective Ownership)
 Integración Colectiva 
(Continous Integration) 40 horas semanales
 Cliente en Casa
 Estándares de 
Codificación
Interrogantes económicas y psicológicas
 La dificultad de estimar cuánto va a costar un 
proyecto.
 Los efectos que puede causar la refactorización no 
están del todo claros.
SCRUM
Qué es SCRUM
Scrum es un proceso en el que se aplican de manera 
regular un conjunto de buenas prácticas para trabajar 
colaborativamente, en equipo, y obtener el mejor 
resultado posible de un proyecto.
En Scrum se realizan entregas parciales y regulares del 
producto final, priorizadas por el beneficio que aportan al 
receptor del proyecto. Por ello, Scrum está especialmente 
indicado para proyectos:
 En entornos complejos, donde se necesita obtener 
resultados pronto, 
 Donde los requisitos son cambiantes o poco 
definidos, 
 Donde la innovación, la competitividad, 
laflexibilidad y la productividad son fundamentales.
Roles SCRUM
 Un proyecto de desarrollo se puede llevar a cabo 
mediante uno o más equipos Scrum.
 Un equipo Scrum está formado por personas que juegan 
tres tipos de roles: Product Owner, Scrum Master y 
Development team menber.
 Un equipo Scrum se auto-organiza y no necesita jefes o 
gestores, aunque si serán necesarios en el contexto de la 
organización: contratación, formación, establecimiento y 
control de objetivos, gestión económica, asignación de 
personas y tareas, etc
Actores SCRUM. Product Owner.
Un product owner es uno de los futuros usuarios del sistema, 
alguien que sabe lo que quieren los usuarios del sistema en 
desarrollo. 
El product owner es clave en un proyecto ágil. Y si no realiza su 
trabajo puede poner en riesgo el proyecto.
7 responsabilidades vitales de un product owner:
 Escribir buenas historias de usuario
 Decidir qué construir… ¡y qué no!
 Fijar criterios de aceptación para cada historia de usuario.
 Definir “productos mínimos viables”.
 Priorizar historias de usuario, tener claro el valor de las ellas y 
el valor que necesita el producto en cada momento.
 Estar accesible, y disponible, para explicar al equipo técnico 
dudas funcionales, para validar entregas y participar en 
reuniones.
 Definir el plan de releases (o la visión estratégica).
Actores SCRUM. SCRUM Máster.
 Velar por que todos los participantes del proyecto sigan 
los valores y principios ágiles, las reglas y proceso 
de Scrum y guiar la colaboración intra-equipo y con 
el cliente de manera que las sinergias sean máximas. 
Esto implica:
 Asegurar que exista una lista de requisitos priorizada 
y que esté preparada antes de la siguiente iteración.
 Facilitar las reuniones de Scrum (planificación de la 
iteración, reuniones diarias de sincronización del 
equipo, demostración, retrospectiva), de manera que 
sean productivas y consigan sus objetivos.
 Enseñar al equipo a autogestionarse. No da 
respuestas, sino que guía al equipo con preguntas 
para que descubran por sí mismo una solución.
Actores SCRUM. Scrum Máster.
 Quitar los impedimentos que el equipo tiene en su 
camino para conseguir el objetivo de cada iteración 
(proporcionar un resultado útil al cliente de la manera más efectiva) 
y poder finalizar el proyecto con éxito. Estos obstáculos 
se identifican de manera sistemática en las reuniones 
diarias de sincronización del equipo y en las reuniones 
de retrospectiva.
 Proteger y aislar al equipo de interrupciones externas 
durante la ejecución de la iteración (introducción de 
nuevos requisitos, De esta manera, el equipo puede 
mantener su productividad y el compromiso que 
adquirió sobre los requisitos que completaría en la 
iteración [el equipo debe reservar tiempo para colaborar 
con el cliente en la preparación de la lista de requisitos 
para la próxima iteración]
Historias de Usuario
Una historia de usuario describe:
 Funcionalidad que será útil para el usuario, o 
comprador, de un sistema software. 
 La conversación que conllevan, ya que son una 
herramienta para interactuar.
 El cómo se confirma su implementación, las pruebas y 
verificación de la misma.
Suelen escribirse en post-it o tarjetas.
Las historias de usuario sólo dicen el “qué”.
Una historia de usuario no es la especificación de un 
requisito software
Historias de Usuario
Se recomienda que las historias de usuario se escriban en 
un espacio reducido, y que el soporte físico, el post-it o la 
tarjeta, tenga apenas una frase.
Una historia de usuario debería ser:
 pequeña, 
memorizable, y
 que pudiera ser desarrollada por un par de 
programadores en una semana. 
En tan reducido espacio no pueden contener el diseño, las 
pruebas, normativa, etc. Ni tampoco detalles para codificar.
Su objetivo es, entre otros, lograr la interacción con el 
equipo y con el usuario mas que documentar.
Metodología de Trabajo
 Equipos de entre 6 y 10 personas revisan los 
requisitos, la tecnología disponible y evalúan los 
conocimientos para Colectivamente determinar 
como incrementar la funcionalidad.
 Reuniones diarias, antes de empezar a trabajar, 
con una duración máxima de 4 hrs. 
 Se llevan a cabo hasta que el proyecto este listo 
para ser puesto en producción o ser lanzado al 
mercado.
Metodología de Trabajo
 En la primera reunión se explica al equipo la 
forma de trabajo, especificando que son 
reuniones cortas para coordinar trabajo y no 
para solucionar problemas. 
 Se establecen los criterios para arreglar los 
errores por prioridades (base del éxito del 
sistema).
 En cada reunión las preguntas claves a contestar 
son:
 Qué es lo que se hizo desde la última 
reunión? 
 Qué es lo que se va a hacer hasta la siguiente 
reunión? 
 Cómo se va a llevar a cabo?
Artefactos SCRUM. Sprint
 Es la base del desarrollo Scrum.
 Su duración máxima es de 30 días.
 Se llevan a cabo las tareas pre-
establecidas y no se puede modificar el
trabajo acordado en el backlog.
 Sólo el Scrum Master puede abortar un
sprint si lo considera no viable por
alguna de las siguientes razones:
 Las circunstancias del negocio han
cambiado.
 La tecnología acordada no funciona.
 El equipo ha tenido interferencias.
Artefactos SCRUM. Product Backlog
 Especifica la serie de tareas que se van
a desarrollar según los requisitos
señalados.
 Estas tareas tienen una duración de
entre 4 y 6 hrs. de trabajo.
 Las de mayor duración intentar
descomponerlas en Sub-Tareas dentro
de ese rango de tiempo.
 Al final del sprint se busca un
incremento en la funcionalidad.
Artefactos SCRUM. Print Backlog
 Especifica la serie de tareas que se van
a desarrollar según los requisitos
señalados.
 Estas tareas tienen una duración de
entre 4 y 6 hrs. de trabajo.
 Las de mayor duración intentar
descomponerlas en Sub-Tareas
dentro de ese rango de tiempo.
 Al final del sprint se busca un
incremento en la funcionalidad.
Proceso SCRUM. 
En Scrum un proyecto se ejecuta en bloques 
temporales cortos y fijos (iteraciones que normal-
mente son de 2 semanas, aunque en algunos equipos 
son de 3 y hasta 4 semanas, límite máximo de 
feedback y reflexión). Cada iteración tiene que 
proporcionar un resultado completo, un incremento 
de producto final que sea susceptible de ser 
entregado con el mínimo esfuerzo al cliente cuando lo 
solicite.
El proceso parte de la lista de objetivos/requisitos 
priorizada del producto, que actúa como plan del proyecto. 
En esta lista el cliente prioriza los objetivos 
balanceando el valor que le aportan respecto a su 
coste y quedan repartidos en iteraciones y entregas.
Proceso SCRUM. 
Las actividades que se llevan a cabo en Scrum son las 
siguientes:
 Planificación de la iteración
 Seelección de lo requisitos (4 horas)
 Planificación de la iteración (4 horas)
 Ejecución de la iteración
 Reunión de sincronización (Diario, 15 minutos)
 El cliente con el equipo refinan la lista de requisitos
 Inspección y Adaptación
 Demostración (4 horas)
 Retrospectiva (4 horas)
Flujo de SCRUM
https://proyectosagiles.org/que-es-scrum/
ConclusionesSCRUM
 Valor para la organización ante todo, representado en 
software funcional
 Es preferible tener el 70% de funcionalidad a tiempo que 
tratar de lograr el 100% y fallar .
 Metodología sencilla pero efectiva.
 Visibilidad durante todo el proyecto.
 No existen sorpresas.
 Scrum no dice como desarrollar, el equipo de desarrollo 
escoge la metodología