Filosofía Ágil
Manifiesto
Ágil
Procesos Empíricos
Los 12 principios del Manifiesto Ágil
¿Qué es Ágil?
NO es una metodología o proceso
Ágil es una ideología con un conjunto definido de principios que guían
el desarrollo del producto
Valores de los equipos ágiles …
• Planificación continua, multi-nivel
• Facultados, auto-organizados, equipos completos
• Entregas frecuentes, iterativas y priorizadas
• Prácticas de ingeniería disciplinadas
• Integración continua Iterative TDD/ ATDD
development
• Testing Concurrente
Desarrollo ágil de Software (Agile)
• Un compromiso útil entre nada de proceso y demasiado proceso
(Fowler, 2001)
¿Pero qué significa Ágil?
• Balance entre ningún proceso y demasiado proceso. La diferencia
inmediata es la exigencia de una menor cantidad de
documentación, sin embargo no es eso lo más importante:
• Los métodos ágiles son adaptables en lugar de predictivos.
• Los métodos ágiles son orientados a la gente en lugar de
orientados al proceso.
FDD
Algunos ATDD Crystal
Frameworks
frameworks Ágiles
ágiles
Scrum XP
8
Ser Ágil no es ser indisciplinado.
Entonces hacemos todo por pedacitos y
somos agiles!!!?? NO!
Requerimientos
Ágiles
Requerimientos en Agile
El costo del tradicional BRUF
(Big Requirements Up Front)
Los productos
“Exitosos”
también tienen
un desperdicio
significante
Fuente: Jim Johnson of the Standish Group, Keynote Speech XP 2002
15
Gestión Ágil de Requerimientos de Software
Los requisitos cambiantes son una ventaja competitiva
si puede actuar sobre ellos
Prioridad
High
{ Each iteration
Cada implement
iteración the highest-
implementa los
Priority priority requirements
requerimientos de prioridad alta
Alta
Each
Cadanew requirement
nuevo is
requerimiento es
prioritized and added to
priorizado y agregado a la pila
the stack
Requirements
Los may be pueden ser
requerimientos
priorizados enany
reprioritized at time
cualquier momento
Requirements may be pueden ser
Los requerimientos
removed
removidos en time
at any cualquier momento
Prioridad
Low
Baja
Priority
Requirements
Requerimientos Copyright 2004 Scott W. Ambler
16
Analice cuando lo
necesite, no antes
El cara-a-cara permite que fluya información
vocal, subvocal, gestual con realimentación rápida.
2 personas en
el pizarrón
Efectividad en la Comunicación
2 personas
en el teléfono
Video
2 personas
en el chat
Audiotaped
Papel
Más frío Más
cálido Riqueza del Canal de Comunicación
Tipos de Requerimiento de Negocio
Disminuir un X% de tiempo invertido en procesos manuales relacionados con
Requerimientos atención al cliente.
Requerimiento de Usuario
Realizar consultas en línea del estado de cuenta de los clientes
Requerimiento Funcional
Generar reporte de saldos de cuenta. Recibir notificaciones por mail.
Requerimiento No funcional
Formato del reporte PDF. Cumplir niveles de seguridad para credenciales de
usuarios según la ley bancaria 9999XX
Requerimiento de Implementación
Servidores en la nube
Requerimientos Dominio
de Negocio del
Problema
Requerimientos de
Usuario
Requerimientos de Software
Dominio
de la
Solución
Tradicional
vs. Ágil
Los cambios son la única constante.
Stakeholders: no son todos los que están.
Siempre se cumple eso de que: “El usuario dice lo
Por último que quiere cuando recibe lo que pidió”.
No hay técnicas ni herramientas que sirvan para
todos los casos.
Lo importante no es entregar una salida, un
requerimiento, lo importante es entregar, un
resultado, una solución de “valor”.
Principios Ágiles relacionados a los
Requerimientos Ágiles
1- LA PRIORIDAD ES 2 -RECIBIR CAMBIOS 4 - TÉCNICOS Y NO 6 - EL MEDIO DE 11 - LAS MEJORES
SATISFACER AL DE TÉCNICOS COMUNICACIÓN ARQUITECTURAS,
CLIENTE A TRAVÉS REQUERIMIENTOS, TRABAJANDO POR EXCELENCIA ES DISEÑOS Y
DE RELEASES AUN EN ETAPAS JUNTOS TODO EL CARA A CARA REQUERIMIENTOS
TEMPRANOS Y FINALES PROYECTO EMERGEN DE
FRECUENTES (2 EQUIPOS
SEMANAS A UN AUTOORGANIZADOS
MES)
User Stories
“….se las llama “stories” porque se supone que Ud. cuenta una
historia. Lo que se escribe en la tarjeta no es importante, lo que
Ud. habla, si!.
--- Jeff Patton, InfoQ,
La parte más difícil de construir un sistema de software es
decidir precisamente qué construir. Ninguna otra parte del
trabajo conceptual es tan difícil como establecer los
requerimientos técnicos detallados... Ninguna otra parte
del trabajo afecta tanto el sistema resultante si se hace
incorrectamente. Ninguna otra parte es tan difícil de
rectificar más adelante”
Fred Brooks - “No Silver Bullet - Essence and Accidents of Software
Engineering”. IEEE Computer, Abril de 1987.
¿Cuáles son las partes de una User Story?
Tarjeta
Conversa
ción
Confirma-
ción
User Story
Forma de expresar las Historias
de Usuario
Como <nombre del rol>,
yo puedo <actividad> Representa quién está
de forma tal que <valor realizando la acción o
quién recibe el valor
de negocio que de la actividad.
recibo>
Representa la
acción que realizará
Comunica porque es el sistema
necesaria la actividad
User Story: un ejemplo de tarjeta
Frase verbal
Buscar Destino por Dirección
Como Conductor quiero buscar un destino a partir
de una calle y altura para poder llegar al lugar
deseado sin perderme.
¿Qué es una User Story?
Las User Stories son Multipropósito
•Las historias son:
• Una necesidad del usuario
• Una descripción del producto
• Un ítem de planificación
• Token para una conversación
• Mecanismo para diferir una conversación
* Kent Beck coined the
term user stories in Extreme
Programming Explained 1st
Edition, 1999
Prioridad Cada iteración implementa los ítems
Alta de trabajo de mayor prioridad
El Product Modelado
Cada nuevo requerimiento es
Owner con
mayor
priorizado y agregado a la pila
Prioriza las detalle
Los ítems de trabajos
historias pueden ser re-
priorizados en cualquier
en el Modelado
momento
con
Product menor
detalle Los ítems de trabajo pueden ser
Backlog removidos en cualquier momento
Prioridad
Baja
Ítems de Trabajo 34
User stories: Porciones Verticales
Story 1 Story 2
GUI
Business Logic
Donde impacta Database
“fuertemente”
esto??
Modelado de Roles
Modelado de Roles: Tarjeta de Rol de Usuario
Rol de Usuario: Reclutador Interno
Nos es un experto en computadoras, pero
bastante adepto a utilizar la Web. Utilizará el
software con poca frecuencia pero muy
intensamente. Leerá anuncios de otras compañías
para averiguar cuál es la mejor palabra para
sus anuncios. La facilidad de uso es
importante, pero más importante es que lo que
aprenda, lo pueda recordar meses después.
Modelado de Roles:
Técnicas Adicionales Mario trabaja como reclutador en el
departamento de Speedy Networks, una
fábrica de componentes de red de alta gama.
• Personas El ha trabajado para Speedy Networks por 6
años. Mario tiene un arreglo de horario
flexible y trabaja desde casa cada viernes.
Mario es muy fuerte con las computadoras y
se considera a sí mismo un usuario avanzado
de los productos que usa. La esposa de
Mario, Kim, está terminando su Doctorado en
Química en la Universidad de Stanford. Dado
que Speedy Networks ha estado creciendo
consistentemente,
Mario siempre está
buscando ingenieros.
Modelado de Roles: Técnicas Adicionales –
Personajes Extremos
Diseño de un PDA para:
• El Papa
• Una mujer de 20 años con muchos
novios
• Un traficante de drogas
Tanto la mujer como el traficante
desearán mantener agendas separadas
en caso de que la vea la policía o
un novio. El Papa probablemente
tenga menos necesidad de discreción
pero querrá un tamaño de fuente más
grande.
Usuarios Representantes (Proxies)
• Tipos de usuarios representantes:
• Gerentes de Usuarios
• Gerentes de Desarrollo
• Alguien del grupo de marketing
• Vendedores
• Expertos del Dominio
• Clientes
• Capacitadores y personal de soporte.
Criterios de Aceptación de User Stories
Criterios de Aceptación de
Historias de Usuario
• Definen límites para una user story (US)
• Ayudan a que los PO respondan lo que
necesitan para que la US provea valor
(requerimientos funcionales mínimos)
• Ayudan a que el equipo tenga una visión
compartida de la US
• Ayudan a desarrolladores y testers a derivar
las pruebas.
• Ayudan a los desarrolladores a saber cuando
parar de agregar funcionalidad en una US
User Story: un ejemplo de tarjeta
Buscar Destino por Dirección
Como Conductor quiero buscar un destino a partir de una calle y altura para
llegar al lugar deseado sin perderme.
Criterios de Aceptación:
• La altura de la calle es un número.
• La búsqueda no puede demorar más de 30 segundos.
¿Cuáles son los Criterios de Aceptación buenos?
• Definen una intención, no una solución
• Ej.: El usuario debe elegir al menos una cuenta para
operar
• Son independientes de la implementación
• Relativamente de alto nivel, no es necesario que se
escriba cada detalle
¿Y los detalles? 46
¿Dónde van?
• Detalles como:
• El encabezado de la columna se nombra “Saldo”
• El formato del saldo es 999.999.999,99
• Debería usarse una lista desplegable en lugar de
un Check box.
• Estos detalles que son el resultado de
las conversaciones con el PO y el
equipo puede capturarlos en dos
lugares:
• Documentación interna de los equipos
• Pruebas de aceptación automatizadas
Pruebas de Aceptación de User Stories
Pruebas de Aceptación de
Historias de Usuario
Expresan detalles resultantes
de la conversación
Complementan la
User Story
Proceso de dos pasos:
1. Identificarlas al dorso de la US.
2. Diseñar las pruebas completas
User Story: Tarjeta y Pruebas de Aceptación
Buscar Destino por Dirección Pruebas de Usuario
❑ Probar buscar un destino en un país y ciudad
existentes, de una calle existente y la altura existente
(pasa).
Como Conductor quiero buscar un destino a ❑ Probar buscar un destino en un país y ciudad
partir de una calle y altura para poder llegar al existentes, de una calle inexistente (falla).
lugar deseado sin perderme. ❑ Probar buscar un destino en un país y ciudad
existentes, de una calle existente y la altura
inexistente (falla).
Criterios de Aceptación: ❑ Probar buscar un destino en un país inexistente
(falla).
• La altura de la calle es un número. ❑ Probar buscar un destino en País existente, ciudad
inexistente (falla).
• La búsqueda no puede demorar más de 30 ❑ Probar buscar un destino en un país y ciudad
segundos. existentes, de una calle existente y demora más de
30 segundos (falla).
Ejemplo: para un software de un GPS
Como Conductor quiero buscar un destino a partir
de sus coordenadas para conocer el camino a
recorrer para llegar al destino deseado.
Ejemplo:
Como Conductor quiero buscar un destino a partir de • Probar buscar un destino en un país y ciudad
sus coordenadas para conocer el camino a recorrer existentes, de dos coordenadas existentes (pasa).
para llegar al destino deseado. • Probar buscar un destino en un país y ciudad
existentes, de una coordenada inexistente (falla).
• Probar buscar un destino en un país y ciudad
Criterios de Aceptación: Las coordenadas se representan con tres existentes, de dos coordenadas existentes sin indicar la
números que indican longitud y tres números que indican latitud. orientación (falla).
Cada número representa los grados, minutos y segundos • Probar ingresar coordenadas de latitud y longitud
respectivamente. Además se debe indicar
válidas (pasa).
la orientación (norte, sur, este, oeste).
• Probar ingresar coordenadas de latitud y longitud
inválidas (falla).
Ejemplo: User Stories / Casos de Prueba
Como compañía quiero pagar por una búsqueda de puestos con una tarjeta de crédito,
así resuelvo mi necesidad en forma más eficiente.
Criterio de Aceptación:
• Se acepta Visa, MasterCard y American Express
• En compras mayores de $100 se piden el número del dorso de la tarjeta
Probar con Visa (pasa)
Probar con MasterCard (pasa)
Probar con American Express (pasa)
Probar con Dinner’s Club (falla)
Probar con números de tarjeta buenos
Probar con números de tarjeta malos
Probar con números de tarjeta faltantes
Probar con tarjetas vencidas
Probar con montos menores de $100
Probar con montos mayores de $100
Definición de listo – Definition of Ready
Definición de Hecho – Definition of Done
*INVEST Model
• Independent – calendarizables e
implementables en cualquier orden
• Negotiable – el “qué” no el “cómo”
• Valuable – debe tener valor para el cliente
• Estimatable – para ayudar al cliente a armar un
ranking basado en costos
• Small – deben ser “consumidas” en una iteración
• Testable – demostrar que fueron implementadas
* “INVEST in Stories” – Bill Wake
http://xp123.com/xplor/xp0308/index.shtml
Algo más sobre las User Stories…
• No son especificaciones detalladas de requerimientos (como los casos de
uso)
• Son expresiones de intención, “es necesario que haga algo como esto…”
• No están detallados al principio del proyecto, elaborados evitando
especificaciones anticipadas, demoras en el desarrollo, inventario de
requerimientos y una definición limitada de la solución.
• Necesita poco o nulo mantenimiento y puede descartarse después de la
implementación.
• Junto con el código, sirven de entrada a la documentación que se
desarrolla incrementalmente después.
Diferentes niveles de abstracción
Idea
Problema
Necesidad
Cambios en el Negocio Impacto en el
Cliente
Ideas / Cambios en
el Software
Especificaciones
58
Spikes
• Tipo especial de historia, utilizado para quitar riesgo e incertidumbre de una
User Story
u otra faceta del proyecto.
• Se clasifican en : técnicas y funcionales.
• Pueden utilizarse para:
• Inversión básica para familiarizar al equipo con una nueva tecnología o dominio.
• Analizar un comportamiento de una historia compleja y poder así dividirla en
piezas manejables.
• Ganar confianza frente a riesgos tecnológicos, investigando o prototipando para
ganar confianza.
• Frente a riesgos funcionales, donde no está claro como el sistema debe resolverla
interacción con el usuario para alcanzar el beneficio esperado.
Spikes
Spikes
Técnicas Funcionales
Técnicas Funcionales
• Utilizadas para investigar enfoques • Utilizadas cuando hay cierta
técnicos en el dominio de la
solución. incertidumbre respecto de
• Evaluar performance potencial cómo el usuario interactuará
• Decisión hacer o comprar con el sistema.
• Evaluar la implementación de cierta
tecnología. • Usualmente son mejor
• Cualquier situación en la que el evaluadas con prototipos para
equipo necesite una comprensión obtener realimentación de los
más fiable antes de comprometerse
a una nueva funcionalidad en un usuarios o involucrados.
tiempo fijo.
Spikes
Spikes
Técnicas Funcionales
• Algunas User Stories requieren de ambos tipos de spikes. Por ejemplo:
• Como un cliente, quiero ver mi uso diario de energía en un histograma, para
poder comprender rápidamente mi consumo de energía pasado, presente y
proyectado.
• En este caso un equipo puede crear dos spikes:
• Spike Técnico:
• Investigar cuanto tiempo requiere actualizar un display de un cliente al uso actual,
determinando requerimientos de comunicación, ancho de banda y si los datos se actualizan en
formato push o pull.
• Spike Funcional:
• Crear un prototipo de histograma en el portal web y obtener la retroalimentación de algunos
usuarios respecto del tamaño, el estilo de la presentación y los atributos gráficos.
Lineamientos para Spikes
Estimables, demostrables, y aceptables
La excepción, no la regla
• Toda historia tiene incertidumbre y riesgos.
• El objetivo del equipo es aprender a aceptar y resolver cierta incertidumbre en cada iteración.
• Los spikes deben dejarse para incógnitas mas críticas y grandes.
• Utilizar spikes como última opción.
Implementar la spike en una iteración separada de las historias resultantes
• Salvo que el spike sea pequeño y sencillo y sea probable encontrar una solución rápida en cuyo
caso, spike e historia pueden incluirse en la misma iteración.
Algunas cosas para dejar en claro
DIFERIR EL ANÁLISIS HASTA ENTONCES, SE LAS USER STORIES NO SON
DETALLADO TAN TARDE CAPTURAN REQUERIMIENTOS DE
COMO SEA POSIBLE, LO QUE REQUERIMIENTOS EN LA SOFTWARE, NO NECESITAN
ES JUSTO ANTES DE QUE EL FORMA DE “USER STORIES”. SER DESCRIPCIONES
TRABAJO COMIENCE. EXHAUSTIVAS DE LA
FUNCIONALIDAD DEL
SISTEMA.
Tips para que las user stories sean útiles para el equipo
Usar palabras claras en
Un paso a la vez (evitar
los criterios de
la palabra “Y”)
aceptación
No olvides la parte Las user stories se
invisible: la escriben desde la
conversación perspectiva del usuario
No forzar todo para
escribirlo como user
stories
69
Material Bibliográfico de Referencia
• Libro:
• Cohn, Mike - USER STORIES APPLIED – Editorial Addison Wesley 2004-
Capítulos 1, 2 y 6
• Papers
• Dean Leffingwell and Pete Behrens – A user story primer (2009)
• Link
• http://www.mountaingoatsoftware.com/
