Bienvenidos!

Como facilitador

Necesito presentarme

Para que toda la clase me conozca

Facilitador

Marvin López - Panamá

linkedin.com/in/marvinlopez/

lopezm.marvin@gmail.com

Ingeniero de Sistemas Computacionales

e Ingeniería de SW +10 años de experiencia

en Desarrollo de SW, Calidad de SW,

Gestión de Proyectos y Gestión de equipos

Certificaciones:

- Professional Scrum Master (Scrum.org)

- Professional Scrum Developer (Scrum.org)

- Professional Software Tester (istqb.org)

658675121

Como miembro de la clase

Necesito presentarme

Para que el facilitador y el resto del grupo me conozcan y podamos trabajar de forma efectiva

Como miembro de la clase

Necesito anotar mis expectativas del curso

Para que el facilitador y el grupo puedan conocerlas y ayudarme a conseguirlas

Como clase

Necesito establecer reglas de convivencia del curso

Para que todos podamos aprovechar el tiempo y los recursos que tenemos disponibles de la mejor forma

Como clase

Necesito conocer los objetivos del curso

Para entender que voy a aprender en él

Objetivos

Entender los principales aspectos de la Agilidad y cómo se relaciona con Scrum.
Aprender los diferentes aspectos de un equipo Scrum y cómo trabajan en conjunto para entregar software de calidad y funcionando.
Entender como las prácticas modernas de Ingeniería de Software y las herramientas de DevOps ayudan al equipo de desarrollo a mejorar la entrega de software de calidad.
Obtener conocimientos para aprovechar las herramientas y prácticas modernas de desarrollo de software.

Como facilitador

Necesito introducir el contenido y herramientas del curso

Para que el grupo conozca como cumpliremos los objetivos

Herramientas del curso

Otras herramientas

Google Classroom (Material de referencia)
Socrative (quizzes, test exam)
Material impreso y útiles de oficina para desarrollar las prácticas
Computadora por participante para realizar el taller práctico Desarrollo de Aplicación Móvil de películas tipo Netflix
Uso de herramientas de desarrollo: Git, Visual Studio Code, Flutter
Utilización de Azure DevOps como herramienta ALM & DevOps

Contenido - Día 1

Introducción a Ágil y Scrum

Introducción a Ágil – Porque Ágil, Manifiesto Ágil, valores y principios ágiles
- Mentalidad Ágil
Introducción a Scrum
- Roles
- Eventos
  - Backlog Refinement
- Artefactos
Radiadores de información
- Burndowns, Burnups y Cumulative Flow Charts
Impedimentos
Definición de Done (Hecho)

Como clase

Necesito conocer qué realmente es agilidad y de dónde viene

Para entender las bases de Scrum

Pregunta:

Qué es agilidad

para ti?

Escribe en un post-it y en una sola

oración, lo que piensas que es agilidad.

Juego de las cartas

Dividir el salón en 2 equipos

1 Cliente (recibe las cartas al final, toma el tiempo completo), 1 Jefe (toma el tiempo por trabajador) y los trabajadores.

Iteraciones:

1. Cada participante debe voltear todas las cartas antes de pasarlas a su compañero de al lado.

2. Cada participante voltea sólo la mitad de cartas antes de pasarlas a su compañero de al lado.

3. Cada participante voltea sólo 1 carta por vez antes de pasarla a su compañero de al lado.

Manifiesto Ágil

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.

https://agilemanifesto.org/iso/es/manifesto.html

Mentalidad Ágil

Agile Mindset

Fábrica de aviones

Criterios de aceptación Aviones

Debe estar hecho de 1/2 página o 1 página, el mismo diseño para todos los aviones
Debe volar más de 5 metros.
Tener escrito el número de serie en las alas.
Tener escrito el nombre del equipo constructor en ambos lados.
El avión debe tener 2 puertas con manigueta en cada lado.
El avión tiene que tener 3 ventanas redondas en cada lado.

Fábrica de aviones

iteración

Se da 2 minutos al equipo para que comenten la cantidad de aviones que se comprometen a realizar en 5 minutos.
Se da 5 minutos para que realicen los aviones comprometidos con el cliente.
Al finalizar el tiempo, se revisa cuantos cumplen con la definición de hecho (Dependiendo el número de participantes puede variar de 5 a 15 Minutos). Aquí el facilitador verifica que los aviones cumplen todos los criterios de satisfacción.
Se contabilizan y se escriben en el papel.
Se da al equipo 2 minutos para que análisis sus resultados y que observen propuestas para mejorar el proceso.

Como clase

Necesito conocer y entender qué es Scrum

Para poder aplicarlo en mi equipo de trabajo y proyectos

Pregunta:

Qué es Scrum

para ti?

Escribe en un post-it y en una sola

oración, lo que piensas que es Scrum.

Scrum

Es un marco de trabajo (framework) a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.

Es:

• Ligero

• Simple de entender

• Dificil de dominar

"NO es una metodología"

https://scrumguides.org

Build your Own Scrum

En equipos de 5 personas, cada equipo deberá crear su propio proceso de Scrum. Al final cada equipo deberá presentar al resto del grupo su resultado.

40 Min.

https://weisbart.com/byos

Línea de tiempo en Scrum

Inicio del Sprint

Fin del Sprint

Línea de tiempo en Scrum

Inicio del Sprint

Fin del Sprint

Roles en Scrum

5 min. Escribir en post-its las cosas importantes que consideran debe hacer cada rol.
Luego, hacemos una agrupación por afinidad, donde, agruparemos los post-its y definiremos los conceptos similares.

Eventos en Scrum

5 min. Quién / Cuándo / Dónde
5 min. Mito o Realidad equipo/estación.
Luego, revisamos las respuestas y aclaramos dudas.

Backlog Refinement

No es un evento o reunión “oficial” en Scrum… pero es muy típico usarla.

Artefactos en Scrum

Radiadores

información

Otros radiadores de información

Burn-down chart

Sprint
Release

Cumulative flow diagram

Kanban o story board

Burn-up chart

Impedimentos en Scrum

Cualquier cosa que frene la velocidad del equipo Scrum e impida llegar al objetivo deseado del sprint.

Generalmente es algo que escapa del área de control del equipo, que requiere una búsqueda adicional de información, un análisis y una serie de acciones con otras personas fuera del equipo. Son una forma de desperdicio o “waste”.

Definition of Done

"Done" significa que un PBI es un incremento que potencialmente se puede poner en producción.

Se representa como:

- Un checklist

- Visible para todos

- Documento vivo

Definition of Done

- El PBI es aceptado por el Product Owner

- Se completó el code review

- Se hizo push al Dev Branch

- El CI build ejecuta sin errores

- Pasan todas las pruebas de aceptación

- Pasan todas las pruebas de desarrollo

- Se hizo deploy en ambiente de pruebas

Definition of Done

Cual seria el "Definition of Done" de tu equipo actualmente?

Definition of Done

- #######################

Comunicación

Simplicity the art of maxmizing the amount of work not done is essential.

Revisemos los conceptos

claves y dudas

Comunicación

Business people and developers must work together daily during the project.

Contenido - Día 2

Recopilando Requerimientos
Escribir historias de usuario y Criterios de Aceptación
Crear Product Backlog - Proyecto Nextflix
- Azure Devops Backlog
Product Backlog refinement
- Estimación Relativa (team) Planning Poker / T-Shirt Size
Sprint Planning - Crear un Backlog del Sprint - Proyecto Nextflix
- Sprint Goal y Definition of Done
Sprint 1 - Proyecto Nextflix, Azure DevOps, Git
Sprint Review - Proyecto Nextflix
Sprint Retrospective - Proyecto Nextflix
Pair Programming / Swarming / Mob Programming-Testing

Daily Scrum

Que aprendí ayer, que me llamo mas la atención?
Que quisiera aprender hoy?
Alguna experiencia que pueda compartir relacionada con el tema que hemos visto?

Como clase

Necesito conocer y entender cómo se aplica lo que he aprendido sobre Scrum

Para poder aplicarlo en mi equipo de trabajo y proyectos

Recopilando Requerimientos

El problema de la documentación

Porque la vida es

muy corta...

para escribir todo

Recopilando Requerimientos

No se maneja el cambio

Planning

La comunicación no llega correctamente.

Comunicación

- 20 segundos por Iteración
- 1ra iteración: Cada uno selecciona un color y lo levanta en su mano
- 2da iteración: Sin hablar tratar de comunicarse para ver si llegamos a un concenso
- Iteración N: Hasta que todos tengamos el mismo color en la mano

Principio Ágil

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

Historias de Usuario

Descripciones cortas de funcionalidades que nuestro cliente quisiera ver algún día en el software.

{VALOR}

Historias de Usuario

Deben tener sentido para el cliente
No se escriben en lenguaje técnico
Representan un End-2-End
Independiente
Negociable
Se pueden probar
Pequeña y estimable

Historias de Usuario

Título

Descripción

(Qué se quiere lograr

y porqué)

Para quién

Qué

Por qué

Historias de Usuario

Título

Como <tipo de usuario/rol>

Quiero <objetivo/funcionalidad>

Para <razón/beneficio>

Para quién

Qué

Por qué

Las 3 C’s de la historia de usuario

Tarjeta(Card),

la Conversación (Conversation)

Confirmación (Confirmation).

Ejemplo

de historia de usuario

Como usuario

Quiero que se muestre un carrusel

de imágenes que contenga las

imágenes de las Series de

TV POPULARES

Para poder navegar en toda

la lista fácilmente

El diseño de esta aplicación puede considerar algunos aspectos similares al de Netflix.
Con respecto a su contenido de la aplicación debe ser sencilla y fácil de manejar.
En la portada de presentación debe salir las siguientes listas de películas:
- En cartelera, Tendencia, Por estrenar
En la portada de presentación debe salir las siguientes listas de series de TV:
- Populares, Tendencia, Más votadas,
Cuando el cliente de click a una película, éste debe ser redirigido a otra pantalla donde se muestre la imagen de la película o de la serie de TV más un contenido de texto indicando de que trata la película y a que genero pertenece.
En la portada de presentación se debe mostrar una opción que liste sólo películas y otra que liste sólo series de TV.
Para Usuarios infantiles incluir lista infantil como 1ra lista, adulto mayor incluir sección de películas clásicas como primera lista; Usuario joven/adulto como se ha descrito antes.
La app debe cargar rápido

Vamos a crear Historias de Usuario

https://azure.microsoft.com/es-es/services/devops/

Criterios de Aceptación

Los criterios de aceptación definen cómo debe comportarse la aplicación al realizar una acción determinada, normalmente por parte de un usuario de la aplicación. Es lo que utiliza el Product Owner para aceptar o no una Historia de Usuario.

Escenario

Dado que <condición>

Cuando <acción>

Entonces <resultado>

Criterio 1
Criterio 2
Criterio 3
...
Criterio N

Criterios de Aceptación

Titulo debe decir 'EN CARTELERA'
El carrusel de imágenes se muestra debajo del titulo
Cada imagen tiene super puesto el nombre de la pelicula

Criterios de Aceptación

AC#1: Carrusel de imágenes

Dado que Inicio la APP

Cuando se muestra la pantalla inicial

Entonces puedo ver debajo del logo un Titulo que dice 'EN CARTELERA'

Y debajo de este titulo un carrusel de imágenes

Y cada imagen tiene super puesto el nombre de la imagen

Backlog Refinement

¿cuánto tiempo vamos a tardar en hacer esto?

Estimación

Necesitamos una forma de estimar qué:

- Nos permita planificar para el futuro

- Nos recuerde que nuestras estimaciones son solo supuestos

- Reconoce la complejidad inherente de crear Software

Estimación Relativa

One Cookie = 10 sec
7 cookies = 10 sec x 7 = 70 Secs

14 cookies = 10 sec x 14 = Secs

Text

> x2 as big

Story Points

Nos recuerda que nuestras estimaciones son supuestos.
Se mide en base a tamaño o esfuerzo, no considera tiempo.
Es rápido, fácil y simple.

Sprint Planning

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente.

Como clase

Necesito conocer técnicas de trabajo en equipo enfocado a entregar valor rápidamente

Para poder aplicarlo en mi equipo de trabajo y proyectos

Spaghetti Tower Marshmallow Challenge

Tiempo: 18 minutos
Instrucciones: Cada equipo debe construir una estructura que sostenga un malvavisco en la parte superior de la estructura, cada equipo se organizará y colocará los materiales como estime conveniente.
Materiales: 20 espaguetis, 1 metro de cinta adhesiva, 1 metro de cuerda y 1 malvavisco.

Gana el equipo que construya la estructura más alta en 18 minutos y se sostenga sola.

Pair Programming

El pair programming, es una práctica de desarrollo donde dos programadores trabajan juntos compartiendo la máquina para la producción de software.

Roles:

Driver, conduce la implementación del código hacia la meta o la consecución de la tarea.
Navigator, encargado de revisar la conducción, proponer rutas, asegurar la calidad del viaje o aprender las habilidades de la conducción del piloto, ya que será él quien posteriormente asuma la labor de driver.

Pair Programming

Ventajas

Calidad de código.
Reviews de código.
Mayor productividad.
Mejor sistema de aprendizaje para los desarrolladores inexpertos.
Validación de ideas.
Distribución coherente de los conocimientos del proyecto.
Mejora de la relación interna entre empleados.
Compartir conocimientos.
Desarrollo y entrega más rápido.

Desventajas?

Swarming

La idea es dedicar todos los esfuerzos del equipo a un único PBI (el de mayor prioridad), todo lo necesario para completarla se hace tan en paralelo como sea posible.

El Product Backlog debe estar priorizado.

Patrón Rey – Sirviente

Mob-Programming/Testing

El Mob Programming es una estrategia de desarrollo de software en la que todo el equipo trabaja en lo mismo, al mismo tiempo, en el mismo sitio y en la misma computadora. Igual que en Pair Programming existe un Driver, con la diferencia de que hay mas de 1 Navigator.

Cada cierto 15 o 20 min. se rota el responsable de escribir el código o ejecutar las pruebas.

Equipo no superior a 6 ó 7

Qué nos permiten

Mob-Programming/Testing y Swarming

Alineación. Todo el equipo toma parte en el desarrollo.
Reglas de codificación. Todo el equipo define normas de codificación y reglas de calidad de software.
Aprendizaje, traspaso de conocimientos. Los programadores más junior aprenden más y mejor de los programadores más senior.
Durante el desarrollo de esta técnica de trabajo se evitan reuniones de alineamiento, puesto que ya se está trabajando y desarrollando sobre la funcionalidad.
Se evitan problemas de comunicación.
Se evitan problemas de toma de decisiones, las toma el equipo al completo.

Revisemos los conceptos

claves y dudas

Contenido - Día 3

Arquitectura Emergente
Agile Testing
Unit Testing - Test-Driven Development (TDD)
- Refactoring
- Test Smells
Acceptance testing, ATDD
Code Reviews
Clean code – SOLID
Code Metrics
Integración Continua (CI)
Continuous Delivery vs. Continuous Deployment
DevOps

Dayli Scrum

Que fue lo que más me llamó la atención de lo que aprendí ayer?
Que espero aprender hoy?
Hay algo que no me quedo claro, o tengo alguna duda respecto a lo que vimos ayer?
Cómo aplicaría uno de los conceptos en mi entorno de trabajo.

Qué está mal en esta historia de usuario?

COMO Capitan

YO QUIERO que en la función de log se

utilice automáticamente la fecha

estelar de hoy

Como clase

Necesito conocer que otras

prácticas de ingeniería y herramientas de Desarrollo de Software Ágil me pueden ayudar en un equipo Scrum

Para poder aplicarlo en mi equipo de trabajo y proyectos

Agile Testing

Pirámide del Testing

El testing es responsabilidad de todos!

Agile Testing

Pirámide del Testing

Cómo son las pruebas en tu proyecto? Explicar.

Qué está mal aquí?

Unit Testing

Pruebas Unitarias

Pequeños test creados específicamente para cubrir todos los requisitos de unidades especificas del código y verificar sus resultados.

Ventajas:
1. Proporciona un trabajo ágil;
2. Calidad del código;
3. Detectar errores rápido;
4. Facilita los cambios y favorece la integración;
5. Proporciona información;
6. Proceso debugging;
7. El diseño;
8. Reduce el coste;

TDD - Test Driven Development

Ciclo de TDD

TDD - Test Driven Development

3 leyes de TDD:

No se permite escribir cualquier código de producción, a menos que sea para hacer pasar un test unitario fallido.
No se permite escribir más que un test unitario que sea lo suficiente para que éste falle; los errores de compilación se consideran fallos.
No se permite escribir cualquier código de producción mas que el que sea suficiente para hacer pasar un test unitario.

Refactoring

"Cambiar la estructura del código sin cambiar su comportamiento"

La refactorización también es:

Una limpieza de código, básicamente
La refactorización no arregla errores ni incorpora funcionalidades
Si durante una refactorización se ha cambiado el comportamiento del software o web, es que has generado un error o bug

Refactoring

(GRASP / SoC) Si un objeto / clase tiene muchas responsabilidades, separar en tantos objetos como responsabilidades se requieran.
(SoC / KISS) Si el método tiene más de una tarea, refactorizar en tantos métodos como tareas haya.
(LoD) Si un objeto conoce mucho sobre la estructura de otro, modificar hasta que el conocimiento sea mínimo.
(YAGNI) Si el método hace algo que no está en los requerimientos, se elimina o refactoriza por uno que cumpla con los mismos.
(IoC) Si un método no tiene parámetros y modifica el estado de un objeto, refactorizar para que acepte parámetros e intentando que respete algunos conceptos de programación funcional como la pureza de las funciones.

TDD - Test Driven Development

F.I.R.S.T.

– Fast: Tests should be fast.

– Independent: Tests should not depend on each other.

– Repeatable: Tests should be repeatable in any environment.

– Self-Validating: Tests should have a boolean output (pass or fail).

– Timely: Tests should be written before the production code.

https://www.codewars.com/kata/convert-boolean-values-to-strings-yes-or-no/train/dart

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

Test Smells

Las pruebas son difíciles de crear
Lógica de contexto en el código de producción
Hacen cosas extrañas para poder probar el código
Las pruebas fallan intermitentemente

El resultado de las pruebas

cuenta la historia de

cómo en realidad está el

código de producción.

Y si encuentro errores?

Un buen reporte de error debe contener:

- Un buen título

- Buena gramática en la descripción
- Un único error por reporte
- Pasos para reproducir el error, sin especificar supuestos
- Resultados esperados y resultados obtenidos
- Versión de la aplicación donde se encontró el error
- Imágenes videos que puedan describir el error
- No debe indicar ni asumir culpas dentro del equipo

Code Coverage

El Code Coverage o cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas.

De esta medida, podemos sacar varias conclusiones:

Podemos necesitar más pruebas unitarias.
Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

Code Coverage

ATDD

Acceptance Test Driven Development

El equipo discute en colaboración criterios de aceptación, con ejemplos, y luego los divide en un conjunto de pruebas de aceptación en concreto antes de que comience el desarrollo.

Historia con 3 palabras

Como equipo seleccionemos:

Nombre de una chica
Un lugar
Un objeto que encuentras en una casa
1 voluntario para escribir la historia

Reglas:

Tienen 10 min para crear una historia dónde cada uno dirá una sola palabra por turno, yendo en círculos.
La historia debe “fluir”
Se debe decir "stop" para empezar una nueva oración.
Las palabras seleccionadas deben se usadas en la historia.

Arquitectura Emergente

Un equipo que practica SCRUM deja que la arquitectura emerja a medida que se construye el software.

Think Big, Act small, Fail fast and Learn Rapidly

Todas las decisiones de arquitecturas tienen que estar soportadas por código

Clean Code

"Un Código limpio (Clean Code) siempre parece que lo escribió alguién que le importa. No hay nada obvio que puedes hacer para mejorarlo."

- Michael Feathers, autor del libro Working Effectively with Legacy code

Elegante, Eficiente, Directo,

Claro, Bien Escrito, Simple,

Tiene significado,

Auto-documentado,

Bonito ...

Clean Code: Boy Scout Rule

Curiosa regla con altas dosis de moralidad y profesionalidad aplicable a muchísimas profesiones y, como no, el desarrollo de software no es una excepción.

“deja el campamento más limpio de como te lo encontraste”

Clean Code: Teoría de las ventanas rotas

En criminología, la teoría de las ventanas rotas sostiene que mantener los entornos urbanos en buenas condiciones puede provocar una disminución del vandalismo y la reducción de las tasas de criminalidad.

Cómo aplica esto en desarrollo de Software?

El código incorrecto

es el principio del desastre.

Clean Code: Cómo medirlo?

Clean Code: S.O.L.I.D.

Single Responsibility Principle (SRP)

Open-Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversión Principle (DIP)

Son cinco principios fundamentales, uno por cada letra, que hablan del diseño orientado a objetos en términos de la gestión de dependencias. Las dependencias entre unas clases y otras son las que hacen al código más frágil o más robusto y reutilizable.

Clean Code: Nombres

“Dar nombres a las cosas es una de las cosas mas dificiles de la profesión”.

Utilizar nombres que:

- Tengan sentido

- Sean claros y concretos de la responsabilidad que tiene

- Eviten la desinformación

- No contengas prefijos

- Se puedan pronunciar

- Se puedan buscar

- No estén codificados

....

Clean Code: Nombres

Clean Code: Funciones

● Pequeñas!

● Hacen una sola cosa!

● Se leen de arriba hacia abajo, como un libro

● Mínima cantidad de argumentos

● No tienen efectos alternos

– “checkPassword” no debería crear una sesión

● Capturar Excepciones sobre códigos de Error

● DRY

Clean Code: Funciones

Clean Code: Comentarios

Siempre explicar en el código.
No ser redundantes.
No agregar ruido.
No comentar el código sin uso. Mejor quitarlo.
Utilizar como explicación de la intención.
Utilizar como aclaración de código.
Utilizar como advertencia de consecuencias.

Clean Code: Formatting

Separate concepts vertically.
Related code should appear vertically dense.
Declare variables close to their usage.
Dependent functions should be close.
Similar functions should be close.
Place functions in the downward direction.
Keep lines short.
Don't use horizontal alignment.
Use white space to associate related things and disassociate weakly related.
Don't break indentation.

Clean Code: Deuda Técnica

El código se rompe en la presencia de cambio.

La deuda técnica = Defectos, complejidad, falta de testing, duplicidad... NO HAY QUE DEJARLA CRECER!

Code Reviews

Los distintos miembros de un equipo revisan de forma individual o en conjunto la implementación realizada por otro miembro.

Code Reviews

Las reglas para revisar el código son establecidas por el equipo en conjunto.

Integración Continua

CI - Continuous Integration

La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas.

Continuous Delivery & Continuous Deployment

DevOps

NO es un título o un rol en una organización
NO es una sola persona haciendo DevOps
NO es una herramienta o grupo de herramientas

DevOps

Objetivos

Permitir ciclos de entrega continua y despliegue continuo en producción aplicando las ventajas que ofrece el desarrollo de software ágil;
Mejorar la colaboración entre negocio, desarrollo y operaciones.
Aceptación cultural de la necesidad de enfocarse en el flujo de los procesos entre equipos en ves de sólo enfocarse a mejoras en cada equipo de forma individual.
Dar respuesta rápida a las actividades de mantenimiento de software, a través del monitoreo y la detección rápida de defectos.