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.

1. 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

2. Aspectos éticos, sociales y
políticos en el Comerci
Roger S. Pressman
Copyright © 2011 Pearson Education, Inc.
CAPÍTULO 3.
Desarrollo de software Ágil.

3. 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.

4. 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.

5. 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.

6. 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

7. 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.

8. 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.

9. 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.

10. Desarrollo dirigido por un Plan y Desarrollo
Ágil

11. 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

12.  ¿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

13.  ¿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

14. Slide 8-14
Programación Extrema (XP)

15. Programación Extrema (XP)
El ciclo de liberación de la programación extrema

16. 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

17. 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.

18. SCRUM

19. 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.

20. 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

21. 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).

22. 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.

23. 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]

24. 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

25. 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.

26. 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.

27. 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?

28. 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.

29. 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.

30. 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.

31. 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.

32. 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)

33. Flujo de SCRUM

34. https://proyectosagiles.org/que-es-scrum/

35. Conclusiones SCRUM
 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