Conceptos de desarrollo ágil

103
Prácticas modernas de pruebas basadas en Lean/Agile 1. Conceptos de Desarrollo Ágil

Transcript of Conceptos de desarrollo ágil

Prácticas modernas de pruebas basadas en Lean/Agile

1. Conceptos de Desarrollo Ágil

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

• Documentacion “Viva”

• Funcionalidad basada en ejemplos y automatizable

Lean Testing

• Documentacion “Ligera”

• Ideas concretas en lugar de llenar plantillas extensas

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

• Concentrarse en una sola actividad. La multitarea

es desperdicio

5

Lean Testing

• Aprendizaje en pares o equipos

Lean Testing

• Cuanto mas rápido se encuentre un defecto,

generará menos desperdicio

Lean Testing

• ACTIVIDAD

• Push vs Pull

• Aviones

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

Trabajas en un equipo o en un SILO?

5

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

• Equipos de Alta Performance (VIDEO)

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

• ACTIVIDAD

• Desarrollo guiado por 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

Planificación en Capas

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

Cliente de Correo Electronico. Ejemplo tomado de: Winnipeg Agilist

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

Release Plan

Sprint Planning

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

• Epicas, Caracteristicas (Feature) e Historias de Usuario

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

Patrones para dividir Historias

de Usuario

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.

Actividad

Aplicar los patrones de división a los

PBIs de la actividad anterior

30

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

Requerimientos Agiles

Ejemplos de Historias Inadecuadas

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

Conclusiones

Cómo es que las historias de Usuario ayudan a tener un entendimiento compartido?

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.

Test Driven Development

• Test-Driven Development (TDD) cycle

Test Driven Development

•VIDEO• Red-Green-Refactor Cycle by Uncle Bob

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.

Acceptance Test Driven Development

• ATTD vs TDD

Behaviour Driven Development (BDD)

• Porque este escenario es tan común?

Behaviour Driven Development (BDD)

• El entendimiento no siempre es compartido

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.”

Entregar el software que importaR

equ

eri

mie

nto

sN

oal

ine

ado

sQ

ue

ComoPobre construcción

Behaviour Driven Development (BDD)

• Proceso de desarrollo con BDD

Behaviour Driven Development (BDD)

Behaviour Driven Development (BDD)

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

Usando Ejemplos

Usando Ejemplos

Usando Ejemplos

Usando Ejemplos

Usando Ejemplos

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 ...

Usando Ejemplos

Los escenarios pueden ser automatizables

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 automatizarconversaciones