Fundamentos de DevOps

Sesión 1: Fundamentos de DevOps

El ciclo de desarrollo y las metodologías ágiles
Ciclo de vida de desarrollo de software

Metodologías tradicionales vs ágiles

Scrum & Kanban

Testing ágil

2 de 31
Ciclo de Vida de Desarrollo de
Software

3 de 31
Ciclo de Vida de Desarrollo de Software
SDLC
Principales Metodologías Tradicionales
Principales Metodologías Ágiles

4 de 31
Ciclo de Vida de Desarrollo de Software (SDLC)

5 de 31
Principales Metodologías Tradicionales

6 de 31
Principales Metodologías Ágiles

7 de 31
Metodologías tradicionales vs ágiles

8 de 31
Metodologías Tradicionales vs Ágiles
Metodologías Tradicionales vs Ágiles
Desarrollo Iterativo vs Incremental
Origen de las Metodologías Ágiles
Manifiesto Ágil
Principios Ágiles

9 de 31
Metodologías Tradicionales vs Ágiles

10 de 31
Desarrollo Iterativo vs Incremental

11 de 31
Origen de las Metodologías Ágiles

12 de 31
Manifiesto Ágil

Un manifiesto es un documento o
escrito a través del cual se hace pública
una declaración de propósitos.

El manifiesto Ágil surge el 17 de febrero

del 2001,
cuando se reunieron diecisiete críticos
del desarrollo de software, y acuñaron
el término “metodología Ágil” para
definir los métodos que estaban
surgiendo como alternativa a las
metodologías formales.

El manifiesto Ágil está conformado por:

12 principios asociados a
4 aspectos o pilares (valores).

13 de 31
Principios Ágiles

14 de 31
Ejercicio
Piense en un proyecto de desarrollo que le haya tocado trabajar o conocer:

1. ¿Qué metodología se utilizó para desarrollarlo?

2. ¿Cuántas entregas tuvo el proyecto?
3. ¿Fue incremental? En ese caso ¿Cuáles fueron las distintas entregas?
4. ¿Fue iterativo? En ese caso ¿cuales podrían haber sido las entregas al hacerlo incremental?

15 de 31
Kanban & Scrum

16 de 31
Kanban & Scrum
Kanban
Scrum
¿Qué es Scrum?
Valores de Scrum
Principios de Scrum
Roles de Scrum
Ceremonias Scrum
Artefactos Scrum

17 de 31
Kanban

Kanban es un método para gestionar

el trabajo que surgió en Toyota
Production System. A finales de los
años 40, Toyota implementó en su
producción el sistema “just in time”
(justo a tiempo”) que en realidad
representa un sistema de arrastre.
Esto significa que la producción se
basa en la demanda de los clientes y
no en la práctica tradicional “pull” de
fabricar productos e intentar
venderlos en el mercado.

18 de 31
Scrum
Scrum es un proceso de gestión que reduce la complejidad en el desarrollo de productos para satisfacer
las necesidades de los clientes. La gerencia y los equipos de Scrum trabajan juntos alrededor de
requisitos y tecnologías para entregar productos funcionando de manera incremental usando el
empirismo.

19 de 31
 ¿Qué es Scrum?
Scrum es un marco de trabajo para desarrollo ágil de software que se ha expandido a otras industrias.
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 proyectos, caracterizado por:
•Adoptar una estrategia de
desarrollo incremental, en lugar
de la planificación y ejecución
completa del producto.

•Basar la calidad del resultado

más en el conocimiento tácito
de las personas en equipos
auto organizados, que en la
calidad de los procesos
empleados

•Solapar las diferentes fases del

desarrollo, en lugar de realizar
una tras otra en un ciclo
secuencial o en cascada
20 de 31
Valores de Scrum

21 de 31
Principios de Scrum
• Control empírico de procesos: enfatiza la filosofía
central de Scrum basada en las tres ideas principales
de transparencia, revisión y adaptación.
• Auto-organización: esto resulta en una mejor
participación de los equipos y en la propiedad
compartida de lo conseguido.
• Colaboración: aboga por la gestión de proyectos
como un proceso compartido de creación de valor
con equipos que trabajan e interactúan juntos para
ofrecer el mayor valor.
• Priorización basada en el valor: destaca el
enfoque de Scrum para ofrecer el máximo valor
comercial, desde el principio del proyecto y
continuando en todo momento.
• Time-boxing: describe cómo el tiempo se considera
una restricción limitante en Scrum, ayuda a gestionar
eficazmente la planificación y ejecución de
proyectos.
• Desarrollo iterativo: enfatiza cómo administrar
mejor los cambios y construir productos que
satisfagan las necesidades del cliente.
22 de 31
Roles de Scrum

23 de 31
Ceremonias Scrum
El modelo Scrum sugiere que cada Sprint
de inicio después de una rápida reunión
de planeamiento, y que termine con
una reunión de revisión del trabajo
realizado durante el Sprint. Además de
las reuniones de (1) planning y
(4) review, Scrum sugiere dos reuniones
más que deben darse a cada Sprint. Esas
son: (2) retrospectiva, la reunión que
promueve el momento kaizen, en donde
el equipo busca la mejora continua en lo
que se refiere al proceso y
(3) grooming (o refinamiento), la
reunión en donde el backlog del
producto es visto nuevamente buscando
el entendimiento de los próximos
requisitos, candidatos al Sprint
siguiente.

24 de 31
Artefactos Scrum
Product Backlog: Es un inventario que contiene cualquier tipo de trabajo que haya que hacer en el
producto: requerimientos, casos de uso, tareas y dependencias.

Sprint Backlog: Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos
elementos normalmente se componen de tareas técnicas más pequeñas que permiten conseguir un
incremento de software terminado.

Incremento: Un Incremento es el resultado del Sprint, es la suma de todas las tareas, casos de uso,
historias de usuario y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto
a disposición del usuario final en forma de software, aportando un valor de negocio al producto que se
está desarrollando

25 de 31
Testing ágil

26 de 31
Testing ágil
Qué es Agile Testing
Principios de Agile Testing
Prácticas relacionadas con Agile Testing
Qué es TDD

27 de 31
Agile Testing
• Como es el testing tradicional

La metodología tradicional tiende a dejar para el final de la fase de desarrollo, la etapa de

pruebas, dejando sólo un espacio acotado para resolver problemas de la implementación en
función de los casos de negocio y la plataforma tecnológica.

28 de 25
Agile Testing
• Como es el testing tradicional

Esto trae consigo una serie de problemas:

Tiempos muy acotados para generar pruebas que entreguen valor.

No existe una visión global de la solución, sólo parcial del problema.

Se tiende a confundir a los testers como obstáculos de los proyectos.

Existe una sobrecarga de trabajo en un espacio de tiempo muy acotado.

29 de 25
Agile Testing
• Como es el Agile Testing
Agile Testing es una práctica de pruebas de software que sigue los principios del desarrollo
ágil de software.

En Agile Testing, el tester genera valor

perteneciendo al equipo desde el comienzo
para tener una visión completa de la solución,
De principio a Fin Agrega valor
así de esta manera cumplir con los
requerimientos de calidad del software y con
la agilidad comprometida.

Colaborativo Entrega continua

30 de 25
Principios de agile testing
El agile testing cumple con los siguientes principios:

31 de 25
Principios de agile testing
Las siguientes pirámides muestran la diferencia entre el testing tradicional y el agile:

32 de 25
Prácticas relacionadas con Agile Testing
Algunas de las principales prácticas relacionadas al Agile Testing son las siguientes:
• Testing exploratorio:
La principal característica de esta práctica está relacionada con la diversidad de pruebas
que se realizan sobre el código, sin tener una guía preestablecida y explorando diferentes
opciones permitidas por la nueva funcionalidad.

33 de 25
Prácticas relacionadas con Agile Testing

• Automatización de pruebas de regresión:

Tanto la integración continua como la
refactorización de código, son prácticas
esenciales para cumplir con una metodología
de desarrollo de software ágil. La
automatización de pruebas de regresión es
fundamental, y está orientada al correcto
funcionamiento de una aplicación a alto nivel
funcional. Para este curso, revisaremos el
uso de herramientas orientadas a esta
práctica, tales como Selenium.

34 de 25
Prácticas relacionadas con Agile Testing

• Automatización de pruebas unitarias:

Consiste en usar un marco de trabajo o framework para ejecutar tests unitarios, en lugar
de ejecutar estos manualmente una y otra vez cada vez que modificas el código. Para ello
existen múltiples frameworks, muchos de los cuales pueden integrarse en los ambientes
IDE. Para este curso utilizaremos JUnit.

35 de 25
Qué es TDD

● Qué es TDD

Test Driven Development (TDD) o desarrollo guiado por pruebas, es una técnica que
combina un enfoque de refactorización del lado del desarrollo, en conjunto con la
definición en la primera etapa de las pruebas de la funcionalidad a implementar. Esta
técnica tiene el siguiente flujo de trabajo:

36 de 25
Qué es TDD

● Pasos para aplicar TDD

Tomar un requerimiento o característica Escribir una serie de pruebas Desarrollar código necesario
del software claramente definida y iniciales para ese requisito, las para “aprobar” esos casos de
aprobada por el dueño de producto. cuales naturalmente fallan al no estar pruebas.
desarrollado el requerimiento.

De la revisión pueden surgir nuevos casos de

Desarrollar más código o prueba producto del refinamiento de la definición Verificar los casos de prueba
refactorizar el existente para pasar del producto, adicionalmente, se incluyen y se marcan como
los casos de prueba adicionales. pruebas de nuevas funcionalidades recibidas del aprobados.
dueño de producto.

El proceso continúa hasta que

no pueden idearse más casos
de prueba.

37 de 25
Prácticas relacionadas con Agile Testing
● TDD vs ATDD vs BDD

Si comparamos los 3 podemos decir que TDD se ocupa solo a nivel unitario o una porción
pequeña de la aplicación en desarrollo, BDD se va a ocupar de que las pruebas sobre la
integración de esas unidades a un nivel de negocio para que no solo sean pruebas sino que
también sean documentación viva de la aplicación al alcance de cualquier usuario y en su
mismo idioma (términos que usa comúnmente). Por último ATDD pasa a participar a nivel de
la creación de la US, asegurándose que estamos construyendo lo que el cliente realmente
necesita en esta etapa de desarrollo.

TDD (Test Driven Development) BDD (Behavior Driven Development)

ATDD (Acceptance Test Driven Development)

38 de 25
 Rodrigo Rojas Gallegos
rodrigo.rojas.g@usach.cl

Carlos Lobos de Medina

carlos.lobos@usach.cl

David López Carreño

David.lopez.c@usach.cl

39 de 31
 Fundamentos de DevOps

Sesión 1: Fundamentos de DevOps