conceptos de desarrollo ágil
TRANSCRIPT
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
Lean Testing
Que tan “Lean” son tus Pruebas?
Documentación Herramientas Roles
AprendizajePlanificación de
PruebasFrecuencia de Despliegues
Priorización de Defectos
Seguimiento de Defectos
Objetivo de las Pruebas
ACTIVIDAD GRUPAL
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
Lean Testing
• Flujo de entrega de Software
• QA al final del ciclo es puede ser desperdicio
• El software es “digerido” en parte pequeñas
Lean Testing
• Pruebas manuales sin guiones
• En lugar de sobre-producir guiones, se aprende sobre el
software explorando ideas de pruebas.
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?
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
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
Whole Team Approach
• El Problema de los SILOS
• Se comparte información?
• Se recibe apoyo siempre?
• Se logran resultados en forma eficiente?
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
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 pocolento
Estamos lentos!Soy rapido!
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
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.
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.
Whole Team Approach
Pruebas Automatizadas
• Programadores, testers y otros miembros del equipo
colaboran para automatizar las pruebas
Tradicional Lean/Agil
AU
TO
MA
TIZ
AC
ION
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
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
Contenido
• Manifiesto Ágil
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
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
Feedback temprano y frecuente
• Analistas y Testers dan feedback a los desarrolladores
sobre las Historias de Usuario
• No siempre todos entienden lo mismo…
Feedback temprano y frecuente
• Las pruebas automatizadas proporcionan
feedback, temprano y frecuentemente
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
Feedback temprano y frecuente
• Feedback a través de Pair programming entre
desarrolladores
DriverManeja el tecladoEscribe las pruebasEscribe el código
NaveganteSe enfoca en el objetivoGuía al DriverPropone las siguientes pruebas
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
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
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
Planificación Agil
Describa en no mas de 25
palabras el propósito del
último proyecto en el que
participó
Planificación en Capas
Story (BacklogItem)Que usuario o stakeholder servirá la historia?
Como lucírá y comportará?
Como se determina si esta terminada?
Story Details
Acceptance Tests
Productoo 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
ReleaseComo 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
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)
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
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
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
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.
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
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
User Story Mapping
time
opcio
nalid
ad
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
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
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
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
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?
Requerimientos Agiles
• Que tan grandes son las Historias?
Épica
Característica(Feature)
Historia de Usuario
Representan múltiples características o muchas historiasPueden 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 historiasPueden 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 valorToma 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
Requerimientos Agiles
• Las características (Features) son servicios proporcionados por el Sistema que
resuelven necesidades de los. Las características caben en Releases. Las Historias
caben en iteraciones o sprints.
Agile Software Requirements – Dean Leffingwell
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Feature
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
2 weeks
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Use
r S
tory
Feature
Feature
Feature
Feature
Feature
2 weeks 2 weeks
Release 1
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.
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”
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”
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”
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”
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.
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?
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óny como un recordatorio
Conversaciones sobre la historia que sirven para profundizar enlos 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
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
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
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".
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
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)
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.
Actividad
En grupos, elija 3 de la lista de Historias de Usuario desarrolladas anteriormente y completelas.
15
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
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.
Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development
Acceptance Test Driven Development
• El equipo colaborativamente discute los criterios
de aceptación con ejemplos…
Acceptance Test Driven Development
• … y luego los destila en un conjunto de pruebas
de aceptación concretas antes que se inicie el
desarrollo.
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.
“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.”
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 trabajoComo un empleador, quiero publicar una oferta de trabajo pararecibir postulantes al puesto.
10
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ónHistoria de Usuario 1002: Publicar una oferta de trabajo
Describa cada escenario usando el formato:
Dado …
Cuando …
Entonces ...