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.

1. Eliminando la brecha entre clientes y desarrolladores …
mediante BDD (Behavior-Driven Development)
para especificar e implementar mejor software
Jorge Gamba
Consultor en Arquitectura y Desarrollo de Software
Web: http://jorgegamba.com
Twitter: @jorgegamba
Correo: contacto@jorgegamba.com

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

3. Eliminando la brecha entre clientes y desarrolladores …
mediante BDD (Behavior-Driven Development)
para especificar e implementar mejor software
Agenda : Por qué Qué Cómo

4. Por qué (BDD)

6. Las mujeres son de Venus Los hombres son de Marte

7. Los clientes son de Venus Los desarrolladores son de Marte

8. ¿ Y cuál es el problema ?

9. No me
cumpliste
como yo quería
¿ Y cuál es el problema ?

10. No me Pero ¿quién
cumpliste te entiende?
como yo quería
¿ Y cuál es el problema ?

11. No me Pero ¿quién
cumpliste te entiende?
como yo quería
Nunca cumples
con los tiempos
esperados
¿ Y cuál es el problema ?

12. No me Pero ¿quién
cumpliste te entiende?
como yo quería
Nunca cumples
con los tiempos Ayer lo querías
esperados de una manera
y hoy de otra
¿ Y cuál es el problema ?

13. El problema es: Comunicación …
Nodjfhdjhfjdhfdhfjdhjfd
se están entendiendo [los requerimientos]

14. El teléfono roto
Core / Business Incidental
Stakeholders Stakeholders
(ejecutivos) (usuarios)
Cliente
Equipo de Desarrollo
Business Analysts Desarrolladores
(BAs) (Devs)
QAs
(Testers)

15. Qué (BDD)

16. Desarrollo Ágil de Software

17. Agile es acerca de …
minimizar el tiempo para obtener feedback

18. http://agilemanifesto.org/iso/es/

19. “Behaviour-driven development
is about implementing an application
by describing its behaviour
from the perspective of its
stakeholders”
http://dannorth.net/

20. “BDD is a second-
generation, outside-
in, pullbased, multiple-
stakeholder, multiple-scale, high-
automation, agile methodology.
“It describes a cycle of
interactions with welldefined
outputs, resulting in the delivery
of working, tested software
that matters.”
http://dannorth.net/

21. ATDD
TDD BDD
DDD

22. Cómo (BDD)

23. El ciclo
• Outside-In
• Pull-based
• Fractal
• Decomposition
• Deriving scope
from goals
http://www.infoq.com/articles/pulling-power

24. Divide y
vencerás
http://www.infoq.com/articles/pulling-power

25. • Factor diferenciador
• Se hace software por
– Hacer dinero
Business Value – Ahorrar dinero
– Proteger dinero
• Core Stakeholders

26. “Aumentar las ventas y controlar la cartera en
un estado saludable”

27. • Todo proyecto necesita una única
visión, de un mejor futuro
– Por qué es importante
– Qué esperamos lograr
Business Value
– Cómo se reconocerá el logro
Vision
• Debe ser transmitida al equipo
• Es la definición general de “Done”
• Es el mayor punto de referencia
• Core Stakeholders

28. MyCRM dará a la organización un control que no se tiene
actualmente, 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 captura
efectiva de información útil, analizándola y reportando
indicadores que permitan evaluar el estado del negocio.

29. • Lo que necesitamos para
implementar la visión
• Son Stories muy grandes para
manejar y estimar, deben ser
divididas
Feature Sets
Visión
• Pueden corresponder con los
(Epics) subsistemas de la aplicación
• Se deben mantener en un alto
nivel de abstracción
• Incidental Stakeholders

30. Para contar con información Para tomar mejores Para diseñar mejores
que podamos evaluar decisiones en el tratamiento estrategias de cobro
Como un gerente de de clientes Como un gerente de
departamento comercial Como un asesor comercial departamento de cartera
Yo quiero capturar Yo quiero que el sistema me Yo quiero disponer de
información comercial de los proporcione información reportes que me detallen el
clientes sobre cada cliente estado actual de la cartera

31. • Es una manera de capturar y
describir una feature del sistema,
algo que el usuario quiere
• Constituye una unidad de
Feature Sets
entrega, algo que habrá que
Stories implementar
• Debe ser tan pequeña como sea
posible sin perder significado
para el negocio
• Business Analysts (BAs)

32. Para realizar una venta ágil y Para no poner en riesgo la Para concretar
sin demoras cartera de la empresa oportunamente una venta
Como un asesor comercial Como un asesor comercial Como un asesor comercial
Yo quiero disponer Yo quiero saber si le puede Yo quiero registrar los datos
información detallada sobre vender a crédito a un cliente de una venta potencial o
los artículos en venta según su endeudamiento efectiva

33. • Constituyen o detallan los
criterios de aceptación
• Son ejemplos, así de sencillo
• Deben incluir contexto, acción
Stories
Scenarios y verficación
• Given / When / Then
• Se pueden automatizar
• Qas / Testers [ + Bas + devs]

34. Dado que el cliente no es Dado que el cliente es moroso
Dado que el cliente es moroso
moroso Y no excede su límite de
Y excede su límite de crédito
Cuando solicite comprar a crédito
Cuando solicite comprar a
crédito Cuando solicite comprar a
crédito
Entonces debería aprobarse crédito
Entonces debería negarse
Entonces debería aprobarse
Y mostrarle el nuevo cupo Y debería informarse la causa
Y mostrarle el nuevo cupo

35. • No son scripts, son especificaciones
• Son mejores que la documentación
tradicional
– Especifican qué hay que hacer
– Pruebas de aceptación y regresión
Scenarios
Executable – Documentación dinámica
Specifications • Son el artefacto más durable en el
proyecto
• Son tan confiables como el código
pero más legibles
• Devs (desarrolladores)

36. Beneficios
• Win-Win
• Clientes felices
• Equipo feliz
• Calidad
• Menos bugs
• Documentación
• Pruebas
• Etc.
http://www.infoq.com/articles/pulling-power

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

38. ¿ Preguntas ?

39. Jorge Gamba
Consultor en Arquitectura y Desarrollo de Software
Web: http://jorgegamba.com
Twitter: @jorgegamba
Correo: contacto@jorgegamba.com
http://altnethispano.org/ http://agilescolombia.org/ http://mcscolombia.org/