Embed Size (px)
Citation preview
TUNE-UP Process: enfoque y herramienta de apoyo para gestión ágil de proyectos (equipos de trabajo).
TDRE: Método para desarrollo ágil centrado en las pruebas de aceptación (PAs).
+Información: http://www.tuneupprocess.com
http://agile-roadmap.tuneupprocess.com
http://agilismo.tuneupprocess.com
2
¿Qué resultados de I+D tenemos?
Definición: Prueba de Aceptación (PA)
“Una PA tiene como propósito demostrar al cliente el cumplimiento de
un requisito del software”
Precisando más, una PA:
Describe un escenario, compuesto por una situación del sistema
(condición de ejecución) una secuencia de pasos de uso y el
resultado alcanzado, todo ello desde la perspectiva del usuario
Puede estar asociada a requisitos funcionales o no funcionales
Un requisito tendrá una o más PAs asociadas
Las PAs cubren desde escenarios típicos/frecuentes hasta los más
excepcionales
Gestión de Requisitos y Testeo de Aceptación.
Métodos Ágiles … Test-Driven Development (TDD) “and beyond” …
Las pruebas deben dirigir el proceso de desarrollo.
TDD actúa a nivel de implementación a través de testeo unitario.
“No escribas código hasta que no tengas los casos de prueba que ese código deberá satisfacer”
TDRE – Test-Driven Requirement Engineering. Una interpretación más amplia, incluyendo todo el proceso de desarrollo sería:
“No implementes un requisito hasta que no tengas definidas las pruebas de aceptación que ese requisito debe satisfacer”
4
Motivación
5
TDRE, TDD a nivel de PAs
Requisitos
Análisis
Diseño de Arquitectura
Diseño de Módulos
Programación
Pruebas Unitarias
Pruebas de Integración
Pruebas de Sistema
Pruebas de Aceptación
Especificación y Diseño de Pruebas Aplicación de Pruebas
TDD
TDRE Test-Driven Requirements Engineering
6
Desarrollo basado en PAs
Versióni Versióni+1
Nuevo requisito Mejora Corrección de defecto
Cambio en comportamiento
Expresados en términos de Pruebas de Aceptación
Tipos de cambios en el producto
Un ítem es un cambio implementado en el
producto
Funcionalidad: Requisito Reintegro
Escenarios => Pruebas de Aceptación
Reintegro normal (suficiente saldo)
Intento de reintegro con saldo insuficiente, cliente estándar
Falta de ciertos tipos de billetes
Cancelación de operación
Aviso de no entrega de recibo
Fuera de servicio por falta de billetes
Excedido tiempo comunicación con banco
Excedido tiempo inactividad usuario
…
7
Identificación de Pruebas de Aceptación
Ejemplo: Requisito Reintegro
Escenarios => Pruebas de Aceptación
Reintegro normal (suficiente saldo)
Intento de reintegro con saldo insuficiente, cliente estándar
Falta de ciertos tipos de billetes
Cancelación de operación
Aviso de no entrega de recibo
Fuera de servicio por falta de billetes
Excedido tiempo comunicación con banco
Excedido tiempo inactividad usuario
…
8
Identificación de Pruebas de Aceptación
9
Definición de Pruebas de Aceptación
Estructura de una PA
Nombre Condición
--- ---
Pasos --- ---
Resultado esperado --- ---
Ejemplo de PA
«Intento de reintegro con saldo insuficiente» Condición
Cliente con saldo positivo Acceder a ventana de reintegro
Pasos Introducir cantidad mayor que el saldo
Resultado esperado Mensaje «saldo insuficiente» Se ofrece nueva introducción
10
Gestión del Proyecto Gestión del Producto
Reintegro
Ítem «Reintegro»
Requisito afectado por un ítem. Si el nodo no existe se debería crear.
Estructura de Requisitos del
Producto
Cada nodo representa una característica o requisito con cierto nivel de abstracción
Cada nodo contiene un conjunto de PAs que representan el
comportamiento del sistema respecto de dicha característica o requisito
Ejemplo: Ítem «Adaptación a nuevo protocolo internacional». Esta es una mejora que afectará a varios nodos, uno de ellos el de Reintegro.
Cambios en el requisito Reintegro (2 nuevas PAs, 1 PA modificada)
Reintegro normal (suficiente saldo) Configuración de moneda Advertir comisión aplicada en otro país
Intento de reintegro con saldo insuficiente, cliente estándar Falta de ciertos tipos de billetes, según moneda
Cancelación de operación Aviso de no entrega de recibo Fuera de servicio por falta de billetes Excedido tiempo comunicación con banco Excedido tiempo inactividad usuario …
11
Mantenimiento del Software basado en PAs
12
Software Maintenance based on ATs
Reintegro
Ítem «Adaptación al nuevo
protocolo internacional»
Un ítem puede afectar a varios requisitos
Estructura de requisitos del producto
El ítem puede añadir, modificar o eliminar PAs
en un nodo afectado
PAs añadidas
PAs modificadas
PAs eliminadas
13
Proceso de Desarrollo dirigido por PAs
Definen ítems en términos
de PAs
Escribe código para satisfacer las
PAs
Diseña instanciaciones y
aplica las PAs
Cambios en la estructura de requisitos y/o
en PAs
Ítems
“Encargado de” analizar
“Encargado de” programar
“Encargado de” testear
Cliente
Ciclo de vida de una PA
Identificada
Diseñada Aplicada
Manualmente
Automatizada
Definida
Programada
Aplicada Automáticamente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Ciclo de vida de una PA
Identificada
Diseñada
Automatizada
Definida
Programada
Aplicada Automáticamente
Aplicada Manualmente
Utilizar herramientas específicas según el tipo de PA, por ejemplo: funcional, de rendimiento, de usabilidad, etc.
Versión 1 Versión 2 Versión 3
PAs en un proceso Iterativo e Incremental
Cada cambio elemental lo denominamos UT = Unidad de Trabajo (también son llamados ítems o Historias de Usuario)
El desarrollo es incremental produciendo regularmente una nueva versión. Si es conveniente se utilizan Sprints con el propósito de establecer un ritmo
constante de versiones, acorde con la capacidad del equipo.
…PAs en un proceso Iterativo e Incremental
Versión 1 Versión 2 Versión 3
Tipos de UT
Nuevo Requisito
Mejora
Corrección de fallo
Actividades en cada UT
Especificar requisitos
Programar
Aplicar PAs
Versión 1 Versión 2 Versión 3
… PAs en un proceso Iterativo e Incremental
Backlog
Versión 1 Versión 2 Versión 3
Backlog’ Backlog’’
… PAs en un proceso Iterativo e Incremental
Las UTs son priorizadas y preparadas en el Backlog antes de implementarse en un Sprint.
El Backlog puede ir cambiando en contenido y prioridades.
Versión 1 Versión 2 Versión 3
… PAs en un proceso Iterativo e Incremental
Workflow de una UT (un ejemplo)
Tablero kanban: Desarrollo centrado en PAs
Introducir
UT 1
To Do Doing
Evaluar Prioridad
To Do Doing
Especificar requisitos
To Do Doing
Validar con cliente
To Do Doing
Diseño Preliminar y Estimación
To Do Doing
Confirmar Sprint
To Do Doing
Programar
To Do Doing
Aplicar Pruebas
To Do Doing
UT 2 UT 3
UT 4
UT 5 UT 6 UT 7
UT 8
UT 9
UT 10
UT 11
UT 12
UT 13 UT 14
Trabajo realizado “idealmente” en el Backlog
Trabajo realizado en el Sprint
Tablero kanban en TUNE-UP Process
Filtros para poder visualizar de forma integrada o separada el trabajo
Lista de UTs seleccionadas en el kanban kanban que sintetiza las contabilizaciones se UTs según los filtros aplicados
Tablero kanban: Desarrollo centrado en PAs
Diseño Preliminar y Estimación
Introducir
UT 1
To Do Doing
Evaluar Prioridad
To Do Doing
Especificar requisitos
To Do Doing
Validar con cliente
To Do Doing To Do Doing
Confirmar Sprint
To Do Doing
Programar
To Do Doing
Aplicar Pruebas
To Do Doing
UT 2 UT 3
UT 4
UT 5 UT 6 UT 7
UT 8
UT 9
UT 10
UT 11
UT 12
UT 13 UT 14
Identificada Definida La especificación de requisitos de un cambio es la especificación de las PAs asociadas a dicho cambio.
Tablero kanban: Desarrollo centrado en PAs
Diseño Preliminar y Estimación
Introducir
UT 1
To Do Doing
Evaluar Prioridad
To Do Doing
Especificar requisitos
To Do Doing
Validar con cliente
To Do Doing To Do Doing
Confirmar Sprint
To Do Doing
Programar
To Do Doing
Aplicar Pruebas
To Do Doing
UT 2 UT 3
UT 4
UT 5 UT 6 UT 7
UT 8
UT 9
UT 10
UT 11
UT 12
UT 13 UT 14
Diseñada Programada Aplicada
Manualmente
Las PAs se aprovechan en captura de requisitos, negociación con cliente, decisiones de planificación
Tablero kanban: Automatización de PAs
Evaluar Prioridad de PA
To Do Doing
Automatizar PA
To Do Doing
Tarea 7
Tarea 2
Tarea 9
Tarea 10
Tarea 11
Tarea 12
Tarea 8
Automatizada
Usando alguna herramienta específica según el tipo de PA
32
Estado de PAs usado para seguimiento
33
¿Cómo pueden ayudar a las empresas a mejorar?
Ventajas de un enfoque ágil basado en PAs (los requisitos se
especifican básicamente como PAs).
Se evita el esfuerzo invertido en derivar de PAs a partir de
requisitos (tradicionales).
Se facilita el mantenimiento del producto y de su
especificación de requisitos.
La validación con el cliente basada acordar PAs puede ser
más detallada y precisa.
La granuralidad ofrecida por las PAs favorece las tareas
de estimación, planificación y seguimiento.
La satisfacción de las PAs permite al programador contar
con un criterio preciso para finalizar su trabajo.
Más de 10 años aplicando y refinando nuestro enfoque y herramienta TUNE-UP Process.
Aplicación de TDRE en más de 10 productos industriales. El más representativo es un ERP donde tenemos más de 15.000 PAs definidas y más de 4.000 pruebas automatizadas asociadas a dichas PAs.
Consultoría y apoyo a la implantación de prácticas ágiles en más de 20 empresas (en España, Chile y Paraguay).
Aplicación del enfoque y herramienta en dos asignaturas de informática. Unos 100 alumnos cada año trabajando en equipos de hasta 8 integrantes.
34
¿Qué evidencias tenemos que esto funciona?
Patricio Letelier Torres
Departamento de Sistemas Informáticos y Computación (DSIC)
Universidad Politécnica de Valencia (UPV)
Email : [email protected]
LinkedIn : linkedin.com/in/letelier
Blog : agilismoatwork.blogspot.com
Twitter : twitter.com/yopolt
35
Datos de contacto
