2. Agenda
Desarrollo de Software
Agile Manifesto
Metodologías Ágiles
*You can easily replace the illustrations. View master, right click on the
illustration and ‘replace image’. All pictograms are available for download in
the Brandbook and over Google Drive. You can also order new ones.
4. Expectativa
● El cliente sabe lo que quiere
● El desarrollador sabe cómo hacerlo
● Nada va a cambiar durante el proceso
Realidad en el desarrollo de software
Realidad
● El cliente descubre lo que quiere
● El desarrollador descubre cómo hacerlo
● Hay muchos cambios durante el proceso
5. Agilidad
Que es ser Agil?
Es una metodología que se caracteriza por el descubrimiento de
requisitos y la mejora de soluciones a través del esfuerzo
colaborativo de equipos autoorganizados y multifuncionales con sus
clientes o usuarios finales, la planificación adaptativa, el desarrollo
evolutivo, la entrega temprana, la mejora continua y las respuestas
flexibles a los cambios en los requisitos, la capacidad y la
comprensión de los problemas que hay que resolver.
Que es un proceso de desarrollo de software Ágil
7. Modelo Cascada (Waterfall)
● Las fases se tratan como fases discretas y
deben pasar iterativamente a la siguiente
● Todo el proceso debe ejecutarse completo
antes del lanzamiento.
● La codificación se inicia cuando se ha realizado
el trabajo de diseño y recopilación de
requisitos.
Requerimiento
Diseño
Desarrollo
Testeo
Despliegue
Mantenimiento
8. Modelo Cascada vs Modelo Iterativo
Plan Analisis Diseño Desarrollo Testeo Integracion Despliegue
Tiempo
Analisis
Diseño
Desarrollo
Testeo
Integracion
Despliegue
Analisis
Diseño
Desarrollo
Testeo
Integracion
Despliegue
Analisis
Diseño
Desarrollo
Testeo
Integracion
Despliegue
Analisis
Diseño
Desarrollo
Testeo
Integracion
Despliegue
Analisis
Diseño
Desarrollo
Testeo
Integracion
Despliegue
Plan
9. Modelo Cascada vs Modelo Iterativo
El cambio es malo, por lo tanto, se
desalienta y se controla
activamente.
El cambio sucederá y es valioso, por
lo tanto, se alienta y se acepta
Cambios
El éxito a menudo se basa en la
satisfacción del cliente y el ROI
Éxito
He terminado cuando el cliente está
contento.
Finalización
Cambios
La adherencia al plan determina el
éxito o el fracaso
Éxito
He terminado cuando mi parte del
plan está firmada
Finalización
10. Modelo Cascada vs Modelo Iterativo
Un montón de puertas de calidad
(quality gates)
Altamente iterativo para lograr la
calidad.
Calidad
Inspeccionar el trabajo a medida
que se realiza.
Inspección
Empezar con el objetivo de
satisfacer una necesidad
Inicio
Calidad
Inspeccione el producto cuando
esté completo (bucles largos de
retroalimentación)
Inspección
Empieza por predecir lo que se
entregará
Inicio
En lugar de que un grupo grande
pase mucho tiempo construyendo
algo grande.
Piensa en un pequeño equipo que
dedica poco tiempo a construir
algo pequeño.
16. The Agile Manifesto
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
17. The Agile Manifesto - 12 Principios
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con
valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles
aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al
periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el
proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiables la ejecución del trabajo.
6. 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.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
18. Agile que es?
Cultura - Creatividad, auto-organización, cometer errores y aprender, responsabilidad
Filosofía - colaboración, motivación, propósito, positividad
Mindset - Emprendedor, calidad, responsabilidad, compromiso
Colaboración - Construccion, unión, respecto, equipo
Proceso - ciclos cortos, transparencia, feedback, entrega de valor, incremental
19. Agile que NO es?
No disciplinado
Solo escribir código
No estructurado
No planificado
Hacer lo que cada uno quiera
20. Los dos lados de Agile
Procesos y Metodologías
Forma de trabajo
● Planificación
● Trabajo en equipo
● Involucrar a los clientes
● Proporcionar liderazgo
● Colaboración
● Enseñanza
● Compartir conocimiento
Tecnicas y Practicas
Crear Software (XP Programming)
● Diseño
● Codificación
● Testing
● Despliegue (Deploy)
● Operaciones
● UX
21. Agile es un “camino”
La estructura
Organizacional
Comportamiento de los
miembros del equipo
Herramientas
Dinámica del equipo
Procesos
Interacciones con los
usuarios
22. Agile - Resumen
Agile no es un proceso o metodología
Agile es un conjunto de principios
● 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
Agile tiene algunos atributos importantes
● Entrega de productos frecuente e iterativa
● Retroalimentación adaptativa y receptiva
● Relaciones cercanas con los clientes
● Altamente transparente
24. ● Visualización del flujo de trabajo y eliminación de desperdicios.
● No hay Iteraciones, tiene flujo continuo.
● Solo existen 2 reglas
○ Visualización el flujo de trabajo
○ Limitar el WIP (Work in Progress)
● No hay roles y procesos.
● Medir el tiempo de entrega (tiempo promedio para completar un artículo).
○ Optimizar el proceso para minimizar el tiempo de entrega
Kanban
26. ● Un proceso de gestión de proyectos iterativo.
● No aboga por ninguna técnica de ingeniería específica.
● Se originó con Ken Schwaber y Jeff Sutherland en la década de 1990.
● Utilizado más allá del desarrollo de software.
● Combina bien con XP Practices.
● Simple de entender, pero difícil de dominar.
● Basado en la Transparencia, Inspección y Adaptación.
Scrum
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf
29. Product Owner: Responsable de maximizar el valor del producto, crear y priorizar el product
backlog
Scrum Master: Responsable de seguir la guía de scrum y cumplir con las ceremonias y eliminar
impedimentos
Developers/Testers: Encargados de dar solución a las tareas del sprint.
No hay jerarquías
Scrum Team
30. Sprint: Es el corazón de Scrum, donde las ideas se convierten en valor
Planning: Reunión inicial del sprint, genera el sprint backlog y se define el objetivo del sprint.
Compromiso. Duración aproximada: 2 a 4 horas. Las tareas deben de cumplir con el DOR
Daily: Reunión diaria de no más de 15 minutos, reunión de las 3 preguntas, ¿Que se hizo ayer?
¿Qué se hace hoy? y si hay impedimentos. Planificación.
Eventos
31. Review: Reunión para inspeccionar el resultado del Sprint. Las tareas deben de cumplir con el
DOD. Duración aproximada: 2 a 4 horas. Franquesa.
Retrospectiva: Revisión del último sprint para verificar puntos de mejora y festejar lo que se
realizó bien: Duración aproximada: 2 a 4 horas. Respeto y Honestidad.
Refinamiento: Reunión de explicación detallada de las tareas para el próximo sprint.Duración
aproximada: 2 a 4 horas. Entendimiento.
Eventos
32. Product Backlog: Lista de todas las tareas para entregar valor al cliente, normalmente se ordena
por jerarquías, epicas, features (caracteristicas) e historias de usuario.
Sprint Backlog: Lista de historias de usuario que se comprometieron a realizar durante el sprint
Incremento: Resultado del sprint, normalmente es el sprint backlog terminado y se agrega valor
al producto y al cliente final.
Artefactos
33. Definition of Ready
Product Owner Development Team
Epica Caso de negocio
Valor de negocio
Aprobado por el Gerente de Producto
Coordinado con otros productos.
Historia de Usuario Siempre relacionado a una Épica
Necesidad de monitoreo abordada
Descripción completa de la historia según el formato
(como <función de usuario> quiero <funcionalidad>, así
que <obtengo valor>)
Criterios de aceptación
Ejemplos de la historia (sobre todo de borde)
Típicamente refinado al menos 2 veces
Dependencias coordinadas con otros productos
Entender la historia , comprender la
descripción y los criterios de aceptación
Comprobable (testeable)
Historia estimada
34. Definition of Done
Product Owner Development Team
Epica Todas las historias subyacentes finalizadas
Historia de Usuario Notas de lanzamiento (release notes) listas y
emitidas correctamente
La transferencia de conocimiento para PS y CS
finalizada y emitida correctamente
Historia aceptada por PO
Estado en listo en la herramienta de manejo
de backlog
Ayuda en línea completada
El escenario de monitoreo y las instrucciones están
documentados
El código fuente está registrado el source control
El código fuente es revisado por un miembro del
equipo (opcional)
Pruebas unitarias completadas (IMPORTANTE)
Pruebas en el entorno de Testing completas
(IMPORTANTE)
Pruebas de Regresión ejecutadas satisfactoriamente
Documentación de arquitectura actualizada (para el
nivel de contexto, contenedor y componente)
36. Accelerate
Plantea 24 capacidades claves divididas en 5 categorías:
● Entrega Continua (Continuous Delivery)
● Arquitectura
● Productos y procesos
● Liderazgo y monitoreo “suave” (Lean management)
● Cultura
37. 8. Deployment automation
9. Database change management
10. Test data management
11. Monitoring and observability
12. Loosely coupled architecture
13. Empowering teams to choose
tools
14. Shifting left on security
Capacidades Tecnicas (Accelerate)
1. Version control
2. Trunk-based development
3. Continuous integration
4. Code maintainability
5. Continuous testing
6. Cloud infrastructure
7. Continuous delivery
38. Basic of Scrum
VCDM Service
Owner training
Writing User Stories
Cursos - Visma Learn
39. Libros
● Essential Scrum
● User Stories Applied: For Agile Software Development
Links
● Agile Manifesto
● Scrum Guide
● The Lean of Scrum
● Culture
Materiales
40. YOW! 2014 Jeff Patton - User Story Mapping: Discover The Whole Story
Principles of Lean Product Managment by Jez Humble -
TECHNICAL STORIES DON'T WORK
Requirement Specification vs User Stories
Software Craftsmanship vs Software Engineering
10 prácticas técnicas FUNDAMENTALES en equipos ÁGILES
Blog de Nicolas Paez
Continuous Delivery YouTube Channel
Mas Materiales