eliminando la brecha entre clientes y desarrolladores mediante bdd
DESCRIPTION
Muchos, si no la mayoría, de los problemas o fracasos en proyectos de desarrollo de software se debe a que clientes y equipos de implementación de aplicaciones sencillamente no se entienden porque ven el mundo de manera muy distinta, hay una brecha entre ambas partes, dificultando materializar los requerimientos en software que realmente aporta valor para el negocio. La metodología ágil BDD (Behavior-Driven Development) tiene precisamente el objetivo de lograr que ambas partes, cliente y equipo de desarrollo, en un proyecto se comuniquen de manera efectiva, ayudando a los primeros a especificar de manera sencilla y clara sus requerimientos, y a los segundos a entregar software que realmente cumple esas expectativas. Tomando muchas de las buenas prácticas de desarrollo ágil de software y Lean, BDD fomenta y facilita la colaboración entre los miembros de diferentes roles, así como la integración de todas las etapas del proceso de desarrollo de software de tal manera que, aun escribiendo código fuente, nunca se pierda la referencia y conexión con las especificaciones del cliente, asegurando que el producto que se entrega coincide con ellas, es de calidad y, como un beneficio adicional, queda soportado por pruebas automatizadas. Esta sesión mostrará, tanto a gente de negocios (gerentes de proyectos y analistas de negocios), como a gente técnica (especialistas en QA, arquitectos y desarrolladores de software), como aplicar BDD para obtener todos sus beneficios a la vez que hacen más felices a sus clientes con un proceso más eficiente y mejor producto.TRANSCRIPT
Jorge GambaConsultor en Arquitectura y Desarrollo de SoftwareWeb: http://jorgegamba.comTwitter: @jorgegambaCorreo: [email protected]
Eliminando la brecha entre clientes y desarrolladores …mediante BDD (Behavior-Driven Development)
para especificar e implementar mejor software
http://altnethispano.org/ http://agilescolombia.org/ http://mcscolombia.org/
Eliminando la brecha entre clientes y desarrolladores …mediante BDD (Behavior-Driven Development)
para especificar e implementar mejor software
Eliminando la brecha entre clientes y desarrolladores …mediante BDD (Behavior-Driven Development)
para especificar e implementar mejor software
Agenda : Por qué Qué Cómo
Por qué (BDD)
Los hombres son de MarteLas mujeres son de Venus
Los desarrolladores son de MarteLos clientes son de Venus
¿ Y cuál es el problema ?
¿ Y cuál es el problema ?
No me cumpliste
como yo quería
¿ Y cuál es el problema ?
No me cumpliste
como yo quería
Pero ¿quiénte entiende?
¿ Y cuál es el problema ?
No me cumpliste
como yo quería
Pero ¿quiénte entiende?
Nunca cumplescon los tiempos
esperados
¿ Y cuál es el problema ?
No me cumpliste
como yo quería
Pero ¿quiénte entiende?
Nunca cumplescon los tiempos
esperadosAyer lo queríasde una maneray hoy de otra
djfhdjhfjdhfdhfjdhjfdEl problema es: Comunicación …No se están entendiendo [los requerimientos]
Core / BusinessStakeholders(ejecutivos)
IncidentalStakeholders
(usuarios)
Business Analysts(BAs)
QAs(Testers)
Desarrolladores(Devs)
Cliente
Equipo de Desarrollo
El teléfono roto
Qué (BDD)
Desarrollo Ágil de Software
Agile es acerca de …minimizar el tiempo para obtener feedback
http://agilemanifesto.org/iso/es/
“Behaviour-driven developmentis about implementing an application by describing its behaviourfrom the perspective of itsstakeholders”
http://dannorth.net/
“BDD is a second-generation, outside-in, pullbased, multiple-stakeholder, multiple-scale, high-automation, agile methodology.
“It describes a cycle of interactions with welldefinedoutputs, resulting in the delivery of working, tested softwarethat matters.”
http://dannorth.net/
BDDTDD
ATDD
DDD
Cómo (BDD)
El ciclo
• Outside-In
• Pull-based
• Fractal
• Decomposition
• Deriving scope from goals
http://www.infoq.com/articles/pulling-power
http://www.infoq.com/articles/pulling-power
Divide y vencerás
Business Value
• Factor diferenciador
• Se hace software por
– Hacer dinero
– Ahorrar dinero
– Proteger dinero
• Core Stakeholders
“Aumentar las ventas y controlar la cartera en un estado saludable”
Vision
• Todo proyecto necesita una únicavisión, de un mejor futuro– Por qué es importante
– Qué esperamos lograr
– Cómo se reconocerá el logro
• Debe ser transmitida al equipo
• Es la definición general de “Done”
• Es el mayor punto de referencia
• Core Stakeholders
Bu
sin
ess
Val
ue
MyCRM dará a la organización un control que no se tieneactualmente, al proporcionar información valiosa que serviráde soporte para la toma de decisiones y definición de estrategias para proteger nuestro patrimonio.
Esto mediante proporcionar herramientas de capturaefectiva de información útil, analizándola y reportandoindicadores que permitan evaluar el estado del negocio.
Feature Sets(Epics)
• Lo que necesitamos paraimplementar la visión
• Son Stories muy grandes paramanejar y estimar, deben serdivididas
• Pueden corresponder con los subsistemas de la aplicación
• Se deben mantener en un alto nivel de abstracción
• Incidental Stakeholders
Vis
ión
Para contar con informaciónque podamos evaluarComo un gerente de departamento comercialYo quiero capturarinformación comercial de los
clientes
Para tomar mejoresdecisiones en el tratamientode clientesComo un asesor comercialYo quiero que el sistema me proporcione informaciónsobre cada cliente
Para diseñar mejoresestrategias de cobroComo un gerente de departamento de carteraYo quiero disponer de reportes que me detallen el estado actual de la cartera
Stories
• Es una manera de capturar y describir una feature del sistema, algo que el usuario quiere
• Constituye una unidad de entrega, algo que habrá queimplementar
• Debe ser tan pequeña como sea posible sin perder significadopara el negocio
• Business Analysts (BAs)
Feat
ure
Set
s
Para realizar una venta ágil y sin demorasComo un asesor comercialYo quiero disponerinformación detallada sobrelos artículos en venta
Para no poner en riesgo la cartera de la empresaComo un asesor comercialYo quiero saber si le puedevender a crédito a un clientesegún su endeudamiento
Para concretaroportunamente una ventaComo un asesor comercialYo quiero registrar los datosde una venta potencial o efectiva
Scenarios
• Constituyen o detallan los criterios de aceptación
• Son ejemplos, así de sencillo
• Deben incluir contexto, accióny verficación
• Given / When / Then
• Se pueden automatizar
• Qas / Testers [ + Bas + devs]
Sto
ries
Dado que el cliente no esmorosoCuando solicite comprar a créditoEntonces debería aprobarse
Y mostrarle el nuevo cupo
Dado que el cliente es morosoY no excede su límite de créditoCuando solicite comprar a créditoEntonces debería aprobarseY mostrarle el nuevo cupo
Dado que el cliente es morosoY excede su límite de créditoCuando solicite comprar a créditoEntonces debería negarseY debería informarse la causa
Executable Specifications
• No son scripts, son especificaciones• Son mejores que la documentación
tradicional– Especifican qué hay que hacer– Pruebas de aceptación y regresión– Documentación dinámica
• Son el artefacto más durable en el proyecto
• Son tan confiables como el códigopero más legibles
• Devs (desarrolladores)
Scen
ario
s
Beneficios• Win-Win• Clientes felices• Equipo feliz• Calidad• Menos bugs• Documentación• Pruebas• Etc.
http://www.infoq.com/articles/pulling-power
Referencias
• Dan North - http://dannorth.net/
• Liz Keogh - http://lizkeogh.com/
• Jorge Gamba - http://jorgegamba.com/
• Skills Matter - http://skillsmatter.com/
• InfoQ - http://www.infoq.com/
¿ Preguntas ?
Jorge GambaConsultor en Arquitectura y Desarrollo de SoftwareWeb: http://jorgegamba.comTwitter: @jorgegambaCorreo: [email protected]
http://altnethispano.org/ http://agilescolombia.org/ http://mcscolombia.org/