Los requerimientos ágiles deben estar escritos desde la perspectiva del usuario, ser negociables, enfocarse en el valor de negocio y ser lo suficientemente pequeños como para ser implementados en una iteración. Analizando los items propuestos:
- Los items 1, 3, 5 cumplen con escribirse desde la perspectiva del usuario usando "Como usuario quiero..."
- Los items 2, 4, 6 describen funcionalidad pero no desde la perspectiva de un usuario específico
- El item 7 está bien redactado pero podría dividirse en historias más pequeñas para
OWASP DefectDojo - Open Source Security SanityMatt Tesauro
Originally given at the project showcase at Global AppSec DC 2019, this talk covered what DefectDojo is, what's new and why you should be using it in your security program.
¿Qué es DevOps y por qué es importante en el Ciclo de Software? por michelada.ioSoftware Guru
DevOps es una cultura que se centra en la comunicación e integración entre desarrolladores de software y los profesionales de operaciones en IT. Busca una entrega continua de valor al cliente así como automatización de procesos, mejorando las prácticas en cada fase del Ciclo de Software.
Presentado por: Karen Ventura
DevSecOps Fundamentals and the Scars to Prove it.Matt Tesauro
This talk instills the lessons learned from multiple security automation efforts and the key elements needed to be successful. Success across multiple dimensions is covered including increasing team throughput, engaging and supporting external teams, The idea is to give the audience a leg up on starting a DevSecOps program and allowing them to skip some painful lessons. Instead, they can focus on getting the key pieces in place and reaping the rewards of DevSecOps quickly. Several real-world examples (and metrics) will be provided to demonstrate why you want to start a DevSecOps journey.
OWASP DefectDojo - Open Source Security SanityMatt Tesauro
Originally given at the project showcase at Global AppSec DC 2019, this talk covered what DefectDojo is, what's new and why you should be using it in your security program.
¿Qué es DevOps y por qué es importante en el Ciclo de Software? por michelada.ioSoftware Guru
DevOps es una cultura que se centra en la comunicación e integración entre desarrolladores de software y los profesionales de operaciones en IT. Busca una entrega continua de valor al cliente así como automatización de procesos, mejorando las prácticas en cada fase del Ciclo de Software.
Presentado por: Karen Ventura
DevSecOps Fundamentals and the Scars to Prove it.Matt Tesauro
This talk instills the lessons learned from multiple security automation efforts and the key elements needed to be successful. Success across multiple dimensions is covered including increasing team throughput, engaging and supporting external teams, The idea is to give the audience a leg up on starting a DevSecOps program and allowing them to skip some painful lessons. Instead, they can focus on getting the key pieces in place and reaping the rewards of DevSecOps quickly. Several real-world examples (and metrics) will be provided to demonstrate why you want to start a DevSecOps journey.
IBM license management knowledge, risks and management advice by Eric Chiu, HW Fisher.
ITAM Review IBM & SAP Licensing Seminar, Tuesday 28th April 2015.
DevOps, sibling of Agile is born of the need to improve IT service delivery agility to the more stable environment.
DevOps movement emphasizes tearing the boundaries between makers (Development) & caretakers (Operations) of IT services/products.
User Acceptance Testing in the Testing Center of ExcellenceTechWell
Centralization of testing services into a testing center of excellence (TCoE) for system testing is common in IT shops today. To make this transformation mature, the next logical step is to incorporate the user acceptance testing (UAT) function into the TCoE. This poses unique challenges for the TCoE and mandates the testing team develop a combination of business process knowledge coupled with technology and test process expertise. Deepika Mamnani shares her experiences in implementing a UAT TCoE and best practices—from inception to planning to execution. Learn techniques to create business-oriented testable requirements, strategies to size and structure the team, and the role of automation. Review testing metrics needed to measure the success of the UAT function. Hear a real-world transformation journey and the quantitative business benefits achieved by an organization incorporating UAT as a centralized function within the TCoE. Take back strategies to incorporate UAT as a part of your TCoE.
Here is the small presentation on DevOps to DevSecOps Journey..
- What is DevOps and their best practices.
- Practical Scenario of DevOps practices.
- DevOps transformation Journey.
- Transition to DevSecOps and why we need it.
- Enterprise CI/CD Pipeline.
Elastic Security: Unified protection for everyoneElasticsearch
Prevent, detect, and respond to threats with Elastic Security, free and open for analysts everywhere. Built on the Elastic Stack, Elastic Security powers the SOC by eliminating blind spots, stopping threats at scale, and arming every analyst. Join this fast-moving session to see it in action.
Monitoring Your AWS EKS Environment with DatadogDevOps.com
Join Datadog for a webinar on monitoring Kubernetes with a focus on Amazon EKS. You'll learn how to get the most out of Datadog's intuitive platform and EKS's unique capabilities, including:
How to monitor metrics, logs and traces from your EKS environment
How to test the usability of your environment with features such as adaptive Browser Tests and globally available Real User Monitoring
How to find and fix user-facing issues with synthetic monitoring features like adaptive Browser Tests and globally available Real User Monitoring
The Zen of High Performance Messaging with NATS (Strange Loop 2016)wallyqs
Video: https://www.youtube.com/watch?v=dYrYCt2dTkw
HTML5: https://wallyqs.github.io/stl-nats-talk/
NATS is an open source, high performant messaging system with a design oriented towards both being as simple and reliable as possible without at the same time trading off scalability. Originally written in Ruby, and then rewritten in Go, a NATS server can nowadays push over 11M messages per second.
In this talk, we will cover how following simplicity as the main design constraint as well as focusing on a limited built-in feature set, resulted in a system which is easy to operate and reason about, making up for an attractive choice for when building many types of distributed systems where low latency and high availability are very important.
Connecting the Dots: Kong for GraphQL EndpointsJulien Bataillé
GraphQL is a popular alternative to REST for front-end applications as it offers flexibility and developer-friendly tooling. In this talk, we will look into the differences between REST and GraphQL, how GraphQL API Management presents a new set of challenges, and finally, how we can address those challenges by leveraging Kong extensibility.
Why DevOps?
DevOps principles
DevOps concepts
DevOps practices
DevOps people
DevOps controls
DevOps training and further reading
Where do you start with DevOps?
Una metodología de Desarrollo es como una receta de cocina, hay se visualizan los requerimientos, las herramientas y técnicas a utilizar para crear el platillo (software). De su buen eso depende el éxito del proyecto.
Shift Left Security - The What, Why and HowDevOps.com
The shift left approach in DevOps moves software testing earlier in its lifecycle to prevent defects early in the software delivery process. How can developers use this approach to ensure security? Josh Thorngren, VP of Marketing at Twistlock, will explain what it means to shift left, and share five steps to ensure a successful transition to a shift left approach with DevOps.
Join this webinar to learn:
Best practices in adopting a successful shift to the left
How ‘shifting left’ promotes security
How developers are the new security guards in protecting company information
IBM license management knowledge, risks and management advice by Eric Chiu, HW Fisher.
ITAM Review IBM & SAP Licensing Seminar, Tuesday 28th April 2015.
DevOps, sibling of Agile is born of the need to improve IT service delivery agility to the more stable environment.
DevOps movement emphasizes tearing the boundaries between makers (Development) & caretakers (Operations) of IT services/products.
User Acceptance Testing in the Testing Center of ExcellenceTechWell
Centralization of testing services into a testing center of excellence (TCoE) for system testing is common in IT shops today. To make this transformation mature, the next logical step is to incorporate the user acceptance testing (UAT) function into the TCoE. This poses unique challenges for the TCoE and mandates the testing team develop a combination of business process knowledge coupled with technology and test process expertise. Deepika Mamnani shares her experiences in implementing a UAT TCoE and best practices—from inception to planning to execution. Learn techniques to create business-oriented testable requirements, strategies to size and structure the team, and the role of automation. Review testing metrics needed to measure the success of the UAT function. Hear a real-world transformation journey and the quantitative business benefits achieved by an organization incorporating UAT as a centralized function within the TCoE. Take back strategies to incorporate UAT as a part of your TCoE.
Here is the small presentation on DevOps to DevSecOps Journey..
- What is DevOps and their best practices.
- Practical Scenario of DevOps practices.
- DevOps transformation Journey.
- Transition to DevSecOps and why we need it.
- Enterprise CI/CD Pipeline.
Elastic Security: Unified protection for everyoneElasticsearch
Prevent, detect, and respond to threats with Elastic Security, free and open for analysts everywhere. Built on the Elastic Stack, Elastic Security powers the SOC by eliminating blind spots, stopping threats at scale, and arming every analyst. Join this fast-moving session to see it in action.
Monitoring Your AWS EKS Environment with DatadogDevOps.com
Join Datadog for a webinar on monitoring Kubernetes with a focus on Amazon EKS. You'll learn how to get the most out of Datadog's intuitive platform and EKS's unique capabilities, including:
How to monitor metrics, logs and traces from your EKS environment
How to test the usability of your environment with features such as adaptive Browser Tests and globally available Real User Monitoring
How to find and fix user-facing issues with synthetic monitoring features like adaptive Browser Tests and globally available Real User Monitoring
The Zen of High Performance Messaging with NATS (Strange Loop 2016)wallyqs
Video: https://www.youtube.com/watch?v=dYrYCt2dTkw
HTML5: https://wallyqs.github.io/stl-nats-talk/
NATS is an open source, high performant messaging system with a design oriented towards both being as simple and reliable as possible without at the same time trading off scalability. Originally written in Ruby, and then rewritten in Go, a NATS server can nowadays push over 11M messages per second.
In this talk, we will cover how following simplicity as the main design constraint as well as focusing on a limited built-in feature set, resulted in a system which is easy to operate and reason about, making up for an attractive choice for when building many types of distributed systems where low latency and high availability are very important.
Connecting the Dots: Kong for GraphQL EndpointsJulien Bataillé
GraphQL is a popular alternative to REST for front-end applications as it offers flexibility and developer-friendly tooling. In this talk, we will look into the differences between REST and GraphQL, how GraphQL API Management presents a new set of challenges, and finally, how we can address those challenges by leveraging Kong extensibility.
Why DevOps?
DevOps principles
DevOps concepts
DevOps practices
DevOps people
DevOps controls
DevOps training and further reading
Where do you start with DevOps?
Una metodología de Desarrollo es como una receta de cocina, hay se visualizan los requerimientos, las herramientas y técnicas a utilizar para crear el platillo (software). De su buen eso depende el éxito del proyecto.
Shift Left Security - The What, Why and HowDevOps.com
The shift left approach in DevOps moves software testing earlier in its lifecycle to prevent defects early in the software delivery process. How can developers use this approach to ensure security? Josh Thorngren, VP of Marketing at Twistlock, will explain what it means to shift left, and share five steps to ensure a successful transition to a shift left approach with DevOps.
Join this webinar to learn:
Best practices in adopting a successful shift to the left
How ‘shifting left’ promotes security
How developers are the new security guards in protecting company information
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Charla Testing Chile 2019: Desafíos y lecciones aprendidas al incorporar el t...Claudia Badell
Testing Chile | Santiago de Chile, Chile | 26 Abril 2019
Durante esta charla, Claudia nos contará diferentes desafíos y lecciones aprendidas al incorporar las pruebas de software como parte de la cultura de un equipo multidisciplinario dedicado a desarrollar un producto. Claudia nos compartirá algunos de los cambios que han aplicado en su equipo para construir un entendimiento común sobre las pruebas de software, como también un ejemplo de cómo han adaptado sus estrategias de pruebas a nivel de equipo: el uso de mind maps para compartir y reutilizar el conocimiento adquirido durante las pruebas exploratorias.
Charla TestingUy 2019 - Compartiendo el sombrero del testingTestingUy
Expositor: Claudia Badell
Resumen: Durante esta charla, Claudia nos contará diferentes desafíos y lecciones aprendidas al incorporar las pruebas de software como parte de la cultura de un equipo interdisciplinario dedicado a desarrollar un producto. Claudia nos compartirá algunos de los cambios que han aplicado en su equipo para construir un entendimiento común sobre las pruebas de software, como también un ejemplo de cómo han adaptado sus estrategias de pruebas a nivel de equipo: el diseño de templates y juegos de datos para optimizar las pruebas de regresión visuales.
Charla TestingUy 2019: Compartiendo el Sombrero del TestingClaudia Badell
TestingUy | Montevideo, Uruguay | 13-14 Mayo 2019
Durante esta charla, Claudia nos contará diferentes desafíos y lecciones aprendidas al incorporar las pruebas de software como parte de la cultura de un equipo interdisciplinario dedicado a desarrollar un producto. Claudia nos compartirá algunos de los cambios que han aplicado en su equipo para construir un entendimiento común sobre las pruebas de software, como también un ejemplo de cómo han adaptado sus estrategias de pruebas a nivel de equipo: el diseño de templates y juegos de datos para optimizar las pruebas de regresión visuales.
Meetup TestingUY 2016 - Pruebas de Performance durante el desarrollo o al finalTestingUy
Expositor: Federico Toledo
Resumen: "Es mejor que empieces el testing desde el comienzo". Esta frase se ha repetido tantas veces últimamente gracias al auge y relevancia de las metodologías ágiles, que (por suerte) remarcan la importancia que tienen las pruebas en el proceso de desarrollo. ¿Cuál es la mejor forma de enfocar el esfuerzo en testing cuando hablamos de pruebas de performance? ¿Deberíamos comenzar desde el comienzo del desarrollo, acompañándolo, de acuerdo a lo planteado por las metodologías ágiles, o deberíamos seguir con un enfoque del tipo waterfall? Si alguien de la audiencia está pensando sobre pruebas de performance y tiene que decidir cómo enfocar sus esfuerzos, en esta presentación compartiremos cómo son ambos enfoques basándonos en proyectos reales, pudiendo así generar una mejor imagen de cada uno. Veremos los pros y contras de cada uno y después de la charla podrán llegar a la conclusión de cuál les conviene más en su contexto.
El "desarrollo basado en pruebas" se refiere a un estilo de programación en el que tres actividades están estrechamente entrelazadas:
• La implementación de las funciones justas
que el cliente necesita
• La minimización del número de defectos que
llegan al software en fase de producción.
• La producción de software modular,
altamente reutilizable y preparado para el
cambio
Esta certificación está diseñada para demostrar los niveles de habilidad de los estudiantes en cuanto al proceso de codificación de pruebas, desarrollo y refactorización de forma continua del código construido en los proyectos de
software.
Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. Los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.
Expositoras
María Fernanda Escudero., PMP
Project Manager
mescudero@thoughtworks.com
María José Ormaza
Business Intelligence
mjormaza@thoughtworks.com
Estrategias ágiles para incrementar calidad al construir y probar softwareDomingo Suarez Torres
Construir software es duro y difícil, hacerlo con calidad es aun mas difícil. En nuestra joven industria han existido muchas ideas acerca de como podríamos desarrollar software con eficiencia, muchas metodologías han emergido, casi todas ellas han fallado. El movimiento ágil, fundamentado por el Manifiesto Ágil, propone principios simples, basados en humanos y sus interacciones y no en procesos o herramientas; es esencial el factor humano.
En esta charla abordaremos rápidamente los problemas comunes al desarrollar software y como podemos minimizarlos a través de sencillos principios basados en Agile Software Development. Ademas de los principios veremos como el uso de algunas practicas tomadas de Extreme Programming pueden mejorar significativamente el proceso de desarrollo de software.
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
2. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
3. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
4. Lean Testing
Que tan “Lean” son tus Pruebas?
Documentación Herramientas Roles
Aprendizaje
Planificación de
Pruebas
Frecuencia de
Despliegues
Priorización de
Defectos
Seguimiento
de Defectos
Objetivo de
las Pruebas
ACTIVIDAD GRUPAL
5
5. Lean Testing
• Algunas “creencias” injustificables sobre las
pruebas conduce a desperdicios:
• Todas las pruebas deben tener un “guion de pruebas”
• Los planes de prueba deben seguir el formato IEEE 829
• Los usuarios deben firmar los guiones de pruebas
• Las pruebas necesitan que los requerimientos estén
completos para comenzar el diseño de las pruebas
• No probamos sobre sistemas inestables
• Repetiremos todas las pruebas cuando el sistema cambie
• Las pruebas deben permanecer “independientes” del
desarrollo
6. Lean Testing
• Flujo de entrega de Software
• QA al final del ciclo es puede ser desperdicio
• El software es “digerido” en parte pequeñas
9. Lean Testing
• Pruebas manuales sin guiones
• En lugar de sobre-producir guiones, se aprende sobre el
software explorando ideas de pruebas.
10. Lean Testing
• Backlog de requerimientos y defectos
• El usuario diferencia entre una nueva funcionalidad o un
defecto? O quiere que el Sistema se comporte bien?
15. Lean Testing
• Algunas estrategias para tratar con los desperdicios
en los procesos de prueba:
• Documentar requerimientos como ejemplos
potencialmente automatizables
• Automatizar las pruebas en distintos niveles
• Ideas de pruebas en lugar de guiones de prueba
• Documentación ligera y mapas mentales
• Aprendizaje entre pares
• Probador integrado dentro del equipo
• Seguimiento de defectos similar a los requerimientos
• Planes de prueba por iteraciones, no usar formatos IEEE
16. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
18. Whole Team Approach
• El Problema de los SILOS
• Se comparte información?
• Se recibe apoyo siempre?
• Se logran resultados en forma eficiente?
19. Whole Team Approach
• En el “Whole Team Approach” todos somos
responsables por la Calidad
• No solo los testers o el equipo de QA son los
responsables de la calidad
• No se piensa en “departamentos” sino en habilidades y
recursos para entregar el mejor producto posible
• Todo el equipo es “test-infected”
• Pruebas desde el nivel unitario
Objetivo: Producir Software de Alta
Calidad en un marco de tiempo que
maximice el valor de negocio
20. Whole Team Approach
• La diferencia entre un equipo multifunctional
Tradicional y un equipo agile es el “Whole Team
Approach
Henry Kniberg
DaveJoe Lisa
Dave
Joe
Lisa
January February March April May June July
6 months
3 months
Release
Release
Somos rapidos!
Soy un poco
lento
Estamos lentos!
Soy rapido!
22. Whole Team Approach
• Generalistas vs Especialistas
• El Equipo tiene todas las habilidades para producir
código de calidad
• Especialistas sin limitación de tareas
• Equipo toma responsabilidad de las tareas de testing
• Arme su T-Shape de conocimiento especializado y habilidades horizontales
• Encuentre un equipo en el que se complementen
23. Whole Team Approach
• Equipo diseña código testeable
• El equipo utiliza los principios S.O.L.I.D.?
Mezcla creacion de objetos con
logica. No Testeable.
Reemplazamos objetos de
produccion por “dobles”. Testeable.
24. Whole Team Approach
• En un equipo ágil cualquiera pide y recibe ayuda
• Los testers no se encasillan en pruebas manuales
• El tester no es excluido de las reuniones técnicas o
de negocio
• El tester ayuda a los clientes a proporcionar
ejemplos
• El tester se sienta con el programador
Whole team approach: Mis problemas
son problemas del equipo, los problemas
del equipo son los mios.
25. Whole Team Approach
Pruebas Automatizadas
• Programadores, testers y otros miembros del equipo
colaboran para automatizar las pruebas
Tradicional Lean/Agil
AUTOMATIZACION
26. Whole Team Approach
Involucrado continuamente desde el
inicio en:
• Facilitar la comunicación entre los
interesados de negocio y técnico
• Soportar la validación temprana
de los requerimientos
• Ayudar a los interesados del
negocio/clientes a definir los
criterios de aceptación
• Soporte a la creación de pruebas
de aceptación automatizadas
• Expandir el alcance de las
pruebas de aceptación
• Aconsejar al equipo sobre riesgos
y tendencias
• Realizar pruebas
manuales/exploratorias
• Realiza revisiones de código
• Usa herramientas de analisis
estatico
• Realiza pruebas unitarias
automatizadas (TDD)
• Realiza pruebas de integracion
entre components
(Automatizado)
• Soporta a los testers en las
pruebas de
Aceptacion/Sistema
(Automatizado)
* Necesita “habilidades técnicas”
Rol del Tester Ágil Desarrollador con relación a Pruebas
28. Whole Team Approach
• Conclusiones
• Ágil es “Calidad” no “Velocidad”
• Todo el equipo es responsable de la Calidad
• El objetivo es producir software de alta calidad en un
marco de tiempo, que maximice el valor de negocio
29. Contenido
• Manifiesto Ágil
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
30. Feedback temprano y frecuente
Que tipo de “Feedback” sobre el
producto de software suele dar u
obtener a lo largo del proceso de
desarrollo?
5
31. Feedback temprano y frecuente
• Analistas y Testers dan feedback a los desarrolladores
sobre las Historias de Usuario
• No siempre todos entienden lo mismo…
32. Feedback temprano y frecuente
• Las pruebas automatizadas proporcionan
feedback, temprano y frecuentemente
33. Feedback temprano y frecuente
• Las pruebas automatizadas se añaden y ejecutan
desde el ambiente de Integracion continua (CI)
El servidor de CI asigna una etiqueta a la
versión de código que acaba de compilar
El servidor de CI informa al equipo sobre
la compilación satisfactoria
Si la compilación o pruebas fallan, el
servidor de CI alerta al equipo
El equipo arregla los problemas en la
oportunidad mas cercana
34. Feedback temprano y frecuente
• Feedback a través de Pair programming entre
desarrolladores
Driver
Maneja el teclado
Escribe las pruebas
Escribe el código
Navegante
Se enfoca en el objetivo
Guía al Driver
Propone las siguientes pruebas
35. Feedback temprano y frecuente
• Feedback en iteraciones cortas
• Las iteraciones cortas permiten al equipo obtener
feedback del cliente rápido.
• Todo Proyecto debería tener varias ocasiones para que
los interesados proporcionen su feedback
36. Feedback temprano y frecuente
• Otras actividades de feedback del Tester
• Pedir feedback a los clientes si que se tiene los ejemplos
correctos del comportamiento deseado
• Pedir feedback al Product Owner si los casos de prueba
que escribió reflejan esos ejemplos correctamente
• Asegurarse que los programadores pueden entender
que deben codificar mirando los ejemplos y los casos de
prueba
• Proporcionar feedback a través de las pruebas
manuales/exploratorias
• Proponer mejoras en base al feedback en las
retrospectivas o planificación de la iteración
37. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
39. Planificación en Capas
Story (Backlog
Item)
Que usuario o stakeholder servirá la
historia?
Como lucírá y comportará?
Como se determina si esta terminada?
Story Details
Acceptance Tests
Producto
o Proyecto
Qué Objetivos de
Negocio debe cumplir el
producto?
Objetivo del Producto
Product Charter
Clientes
Usuarios
Iteracion o
Sprint
Que se construirá? (user
stories)
Como es que éste sprint
nos ayudara a conseguir
los objetivos del release?
Objetivo Iteración
Desarrollo
Release
Como podemos entregar valor
incrementalmente?
Que sub-conjunto de objetivos
de negocio debe alcanzar cada
release?
A que grupos de usuario servirá
el release?
Que características generales
(historias grandes) ofrecerá el
release?
Release Roadmap
Clientes Objetivo
Usuarios Objetivo
39
41. La Prueba del Ascensor
1. A (cliente blanco)
2. Que (enunciado de la
necesidad o oportunidad)
3. El (nombre del producto)
es un (categoría
del producto)
4. Que (beneficio clave,
razón convincente para
comprar)
5. Al contrario de (alternativa
primaria con la cual
compite)
6. Nuestro producto
(enunciado de
diferenciación primaria)
Enunciado de la Prueba del Ascensor – habilidad de
explicar el producto a cualquier persona en dos
minutos, de esta forma:
PARA los viajeros
QUE quieren ser recompensados con viajes con
Aerolíneas FlyPeru
EL programa de viajero frecuente de FlyPeru es
un programa de lealtad
QUE permite a los miembros fácil y cómodamente
ver y administrar sus puntos acumulados en
tiempo real, y gastar sus puntos en compras
reales con inigualable facilidad.
A DIFERENCIA de otros programas de viajero
frecuente,
NUESTRO PRODUCTO permite a los miembros usar
sus puntos fácilmente para cualquier tipo de
compra en línea o tradicional.
Describa, usando la prueba del ascensor, el propósito del último
proyecto en el que participó (5 min)
42. Roadmap del Producto
Scrum Alliance website product roadmap
• Una planificación a nivel de producto debería
tener una visión de producto, un backlog de
producto de alto nivel y un roadmap de producto
43. Actividad
Organizador personal
Agrupar las características que sean
similares o relacionadas. Nombre las
agrupaciones.
Ordenar de izquierda a derecha de manera
que muestre un sentido de secuencia.
Eliminar duplicados si hubiere.
Trabajar en grupo.
10
44. User Story Mapping
• Story Mapping una técnica
que permite Organizar y
Priorizar historias de usuario
• Organiza las historias de
usuario en un mapa
• Hace visible el flujo de cadena
de valor.
• Ayuda a completar el backlog
• Provee un contexto que
facilita la priorización.
• Permite planificar las entregas
visualizando el valor de cada
una de ellas.
Jeff Patton
46. User Story Mapping
• Contar como funciona el producto describiendo
las principales actividades que hacen los usuarios
tiempo
tiempo
• Añadir tareas debajo de cada actividad mostrando
el flujo de izquierda a derecha.
47. User Story Mapping
• Ordena verticalmente las tareas que el usuario hace al mismo
tiempo
– Si al contar la historia que digo que el usuario hace típicamente "¿esto
o esto o esto, y luego hace eso“. “o“ significa apilamiento vertical, “y
después" significa ordenarlas en sentido horizontal.
tiempo
48. User Story Mapping
• El backbone de la aplicacion es la lista de actividades
esenciales.
• El walking skeleton es el software que construimos
que soporta el minimo numero de tareas necesarias
que los usuarios necesitan para hacer su trabajo
time
necessity
The backbone
The walking skeleton
49. User Story Mapping
time
opcionalidad
necesario
menos
opcional
mas
opcional
primer release
segundo release
tercer release
• Escoja grupos de historias que juntas entreguen funcionalidad completa para el
negocio y los usuarios
• Asegurarse de entregar las características esenciales en el primer release
• Mejorar la implementación de las funcionalidad con cada unos de los releases
• Teniendo el mapa organizado por necesidad, sólo necesitamos
cortarlo en rebanadas
50. User Story Mapping
• Priorizacion con los criterios MoSCoW
Must - Tiene que tener si no ya seria una
hamburguesa
Should - Debe tenerla para poder armar la
hamburguesa
Could - Podría tener, para hacerla más sabrosa
Won’t - No es necesario que tenga, pero sería
agradable
Could - Podría tener, para hacerla más sabrosa
51. User Story Mapping
Formen equipos,
para los siguientes proyectos:
• Bolsa de Trabajo (ej. Laborum)
• Ventas por Internet (ej. Linio)
• Help Desk (ej. Aranda)
• Delivery Comida OnLine (ej. Lima Delivery)
En equipo crear el User Story Mapping del
proyecto elegido
30
54. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
55. Requerimientos Agiles
1. Como usuario quiero poder colocar libros en una lista de
favoritos para que sea visible a otros visitantes del sitio.
2. Como dueño de una tienda online, quiero administrar
productos para brindarle a mis clientes los mejores
productos.
3. Como consumidor, quiero ver mi uso diario de energía en un
histograma para que yo pueda entender rápidamente mi
pasado, presente y consumo de energía proyectado.
4. Como administrador de contenido, puedo publicar noticias
en el Sitio Corporativo.
5. Como usuario, deseo buscar vuelos disponibles.
6. Como usuario, deseo poder pagar mi reserva con VISA,
MasterCard, American Express y Dinners.
7. Como moderador del foro, deseo aprobar o rechazar
comentarios, para mantener limpio el foro.
15Dados los product backlog items, determine cuales estarían
listos para formar parte de un Sprint Backlog?
56. Requerimientos Agiles
• Que tan grandes son las Historias?
Épica
Característica
(Feature)
Historia de
Usuario
Representan múltiples características o muchas historias
Pueden tomar meses para construirse y trabajar e nivel de
release.
Es en lo que los usuarios finales tienden a enfocarse.
Más pequeñas que las épicas, pero mas grandes que las
historias
Pueden tomar semanas, posiblemente una o mas iteraciones
para construirlo.
Es en lo que el cliente o dueño de producto tiende a enfocarse.
Son los pequeños incrementos de valor
Toma días, quizás una semana o dos a lo mucho
para construirse.
Es en lo que el equipo de desarrollo tiende a
enfocarse.
Foco
principal
de esta
sesion
60. Requerimientos Agiles
Flujo completo (1 de 2)
Dada la siguiente historia de usuario
“Como Analista de Crédito, deseo aprobar una solicitud de
crédito”
No se ve demasiado compleja….
Despues de indagar (conversar) sobre el proceso de
aprobación de créditos, resulta que existen topes para la
aprobación de solicitudes, así como también se requiere
en algunos casos la aprobación de riesgos, jefe de tienda y
dos analistas de crédito mas.
61. Requerimientos Agiles
Flujo completo (2 de 2)
“Como Analista de Crédito, deseo aprobar una solicitud de
crédito”
puede refinarse en:
“... deseo aprobar una solicitud de crédito de otro Analista”
“... deseo aprobar una solicitud de crédito pre-aprobada
por Riesgos”
“... deseo aprobar una solicitud de crédito pre-aprobada
por el Jefe de Tienda”
62. Requerimientos Agiles
Variaciones en las Reglas de Negocio
“Como usuario, deseo buscar Órdenes de servicio”
puede refinarse en:
“... deseo buscar por Nro. de Orden”
“... deseo buscar rango Fecha de Registro”
“... deseo buscar por Cliente”
63. Requerimientos Agiles
Complejidad
“Como usuario, deseo poder vincular una red social a mi
actual perfil”
puede refinarse en:
“... deseo autenticarme con mi perfil de la red social”
“... deseo poder publicar en el timeline”
“... deseo poder acceder a la lista de contactos”
“... deseo poder obtener las fotos de mi perfil”
64. Requerimientos Agiles
Operaciones (CRUD)
“Como usuario puedo administrar mi cuenta”
Puede refinarse en:
“...puedo inscribirme para una cuenta”
“...puedo editar mi configuracion de cuenta”
“...puedo cancelar mi cuenta”
65. Requerimientos Agiles
Dividir un Spike*
Como usuario quiero pagar mediante Click2Sell
Puede refinarse en:
Investigar el procesamiento con Click2Sell
Implementar el procesamiento con Click2Sell
* La división en Spike debe ser la última opción.
67. Requerimientos Agiles
De los PBIs que se obtuvieron en la
práctica anterior, que información
adicional les falta para que puedan ser
estimadas por el equipo de desarrollo?
68. Historias de Usuario
• Una historia de usuario describe funcionalidad que
será valiosa para un usuario o comprador de un
sistema o software
• Una Historia consta de:
Una descripción escrita de la
historia utilizada para la
planificación
y como un recordatorio
Conversaciones sobre la
historia que sirven para
profundizar en
los detalles de la historia
Pruebas que transmiten y
documentan detalles y que se
pueden utilizar para determinar
cuando una historia esta completa
un usuario
puede limitar
quien puede
ver su
currículum
Probar con Visa (P)
Probar con MstCrd (P)
Probar con Diners (N)
Probar con T.Debido
(P)
Probar con T. Expirada
Probar con dist montos
69. Las 3 Cs
Card • Las Historias de Usuario se
escriben en Tarjetas
• Suficiente texto para identificar los
requisitos, y para recordar a todos
cuál es la historia. No es
documentación.
Conversation • El requisito se comunica desde el
cliente hacia el equipo de desarrollo a
través de la conversación
• La conversación es en gran parte
verbal, pero puede complementarse
con los documentos.
Confirmation • El cliente le cuenta al equipo
cómo va a confirmar que lo que han
hecho es lo que se necesita.
• El cliente define las pruebas de
aceptación que se utilizarán para
demostrar que la historia se ha
implementado correctamente.
• Son los pasos o escenarios que
ayudan a un desarrollador a probar y
a un cliente o usuario realizar UAT
Como Usuario
Quiero buscar por
nombre para que
pueda encontrar a mis
amigos y asociados
Como Usuario
Quiero subir una
foto para que otros
usuarios puedan
verlo
70. Las 3 Cs
Card • Las Historias de Usuario se
escriben en Tarjetas
• Suficiente texto para identificar los
requisitos, y para recordar a todos
cuál es la historia. No es
documentación.
Conversation • El requisito se comunica desde el
cliente hacia el equipo de desarrollo a
través de la conversación
• La conversación es en gran parte
verbal, pero puede complementarse
con los documentos.
Confirmation • El cliente le cuenta al equipo
cómo va a confirmar que lo que han
hecho es lo que se necesita.
• El cliente define las pruebas de
aceptación que se utilizarán para
demostrar que la historia se ha
implementado correctamente.
• Son los pasos o escenarios que
ayudan a un desarrollador a probar y
a un cliente o usuario realizar UAT
Como usuario, quiero subir una foto
de mi máquina local para que
cualquier usuario pueda verlo.
❑ Habrá un botón de carga en la
parte superior de mi página de
perfil
❑ Habrá un límite de tamaño de
archivo de 25 MB
❑ Los formatos soportados son:
JPEG, PNG, GIF y BMP
Como usuario, quiero etiquetar mis
amigos y escribir un título antes de
publicar una foto para salvarme
tiempo.
❑ Los campos que se pueden
editar son: título, ubicación, las
etiquetas.
❑ Al guardar la imagen será
publicada
71. Las 3 Cs
Card • Las Historias de Usuario se
escriben en Tarjetas
• Suficiente texto para identificar los
requisitos, y para recordar a todos
cuál es la historia. No es
documentación.
Conversation • El requisito se comunica desde el
cliente hacia el equipo de desarrollo a
través de la conversación
• La conversación es en gran parte
verbal, pero puede complementarse
con los documentos.
Confirmation • El cliente le cuenta al equipo
cómo va a confirmar que lo que han
hecho es lo que se necesita.
• El cliente define las pruebas de
aceptación que se utilizarán para
demostrar que la historia se ha
implementado correctamente.
• Son los pasos o escenarios que
ayudan a un desarrollador a probar y
a un cliente o usuario realizar UAT
1. Haga clic en el botón "Subir".
2. Especifique un archivo de imagen que
desea cargar.
A. Compruebe que .jpg, .png, .gif y se
admiten extensiones .bmp.
B. Compruebe que otros tipos de
archivos no son capaces de ser
cargados.
C. Compruebe que archivos de más de
25MB dan como resultado un error.
3. Haga clic en "Subir fotos".
72. Requerimientos Agiles
• En 2003, Bill Wake, propone el acrónimo
“INVEST” para evaluar las características
de una buena historia de usuario. Estas
características son:
❑ Independent (independiente)
❑ Negotiable (negociable)
❑ Valuable (valiosa)
❑ Estimatable (estimable)
❑ Small (pequena)
❑ Testable (comprobable)
https://www.youtube.com/watch?v=uj5iUbDf-
iw&list=UUQScrIAUqnPqwBu97eO17WQ#t=149
74. Criterios de Aceptación
• Para que una Historia sea “comprobable”, debería
considerar los siguientes tópicos cuando sean relevantes
Comportamiento Funcional Comportamiento observable externamente con acciones
del usuario bajo ciertas configuraciones.
Características de Calidad Atributos de calidad o requerimientos no-funcionales
como rendimiento, confiabilidad, usabilidad, etc.
Reglas de Negocio Definiciones en base a procedimientos y políticas. Por ejemplo
los procedimientos utilizados por una compañía de seguros para
manejar reclamos de seguro.
Interfaces Externas Pueden ser divididos en diferentes tipos (interfaces de
usuario, interfaces con otros sistemas, etc.).
Restricciones Restringe las opciones del desarrollo. Dispositivos con
embedded software que restringen cosas como tamaño,
peso e interfaces de conexión.
Definiciones de Datos Formato, tipos de dato, valores permitidos y valores por
defecto para un elemento de dato de negocio conocido
(por ejemplo el Código Postal en una dirección de correo)
75. Criterios de Aceptación
“Como usuario se me debe requerir una validación
antes de utilizar el sitio"
Criterios de Aceptación:
• El usuario esta logueado solo cuando se
proporcionen credenciales apropiadas
• Esta disponible una opción “recordarme”.
• El usuario puede requerir un recordatorio de
contraseña.
• El usuario es bloqueado luego de 3 intentos
fallidos
“Como comprador del Sitio Web quiero poder
pagar con una tarjeta de crédito para poder
confirmar inmediatamente mi compra“
Criterios de Aceptación:
• Acepta Visa, Diners, MasterCard
• Validar Nro de CC cuando sea ingresado
• Validar fecha de expiración y CVV
• Validar la dirección de facturación
• Generar mensajes de satisfacción y fallo
luego del procesamiento.
“Como contador quiero que los reportes automatizados se ejecuten al final
del mes para que los reportes estén listos al llegar a la oficina”
Criterios de Aceptación:
• Si hay un error con la generación del reporte, el Sistema necesita
notificar a soporte de producción con un ticket.
• El reporte necesita ser generado como PDF y auto-impreso.
• La selección de auto-impresion necesita ser configurable por reporte
• El Sistema debería enviar el reporte solo a la impresora configurada.
• Si la impresora tiene un error (falta papel, trabado, etc.) el usuario
debería arreglarlo.
76. Actividad
En grupos, elija 3 de la lista de
Historias de Usuario
desarrolladas anteriormente y
completelas.
15
78. Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
79. Test Driven Development
• Test-Driven Development (TDD) es una técnica usada
para desarrollar código guiado por casos de prueba
automatizados. También se le conoce como ”test-
first programming”, ya que las pruebas son escritas
antes que el código.
• Las pruebas son automatizadas y son usadas en la
Integracion Continua
• El proceso de TDD es repetido por cada pequeña
pieza de código, ejecutando las pruebas previas así
como las pruebas añadidas.
• Las pruebas sirven como una forma de especificación
de diseño ejecutable para futuros esfuerzos de
mantenimiento.
88. Behaviour Driven Development (BDD)
• Proceso de desarrollo Tradicional
La especificación escrita es muy imprecisa
y las personas suelen interpretar los
requerimientos en una forma distinta.
89. “Behaviour-Driven Development (BDD)
trata sobre la implementación de una
aplicación mediante la descripción de
su comportamiento desde la
perspectiva de sus grupos de interés”
http://dannorth.net/
“Se usan ejemplos en múltiples
niveles para crear un entendimiento
compartido y superar la
incertidumbre y así entregar el
software que importa.”
90. Entregar el software que importaRequerimientos
Noalineados
Que
ComoPobre
construcción
94. Behaviour Driven Development (BDD)
PRÁCTICA (en grupos de 3)
Para cada Historia de Usuario presentada, Identifique al menos 2
escenarios:
Historia de Usuario 1006: Buscar ofertas de trabajo por ubicación
Como un postulante, quiero buscar ofertas de trabajo por
ubicación para encontrar un empleo cerca a mi lugar de
residencia.
Historia de Usuario 1002: Publicar una oferta de trabajo
Como un empleador, quiero publicar una oferta de trabajo para
recibir postulantes al puesto.
10
101. Usando Ejemplos
PRACTICA (grupos de 3)
Para cada escenario identificado en la práctica anterior,
correspondiente a las siguientes historias:
Historia de Usuario 1006: Buscar ofertas de trabajo por ubicación
Historia de Usuario 1002: Publicar una oferta de trabajo
Describa cada escenario usando el formato:
Dado …
Cuando …
Entonces ...
103. Conclusiones
•Los escenarios en BDD pueden ser
documentados y automatizados, sin
embargo tener en cuenta que:
•Tener conversaciones es mas importante
que capturar conversaciones y mas
importante que automatizar
conversaciones